App A定义了以下的自定义权限：
com.package.permission.READ_APP_DATA
当应用程序B安装声明自定义权限时,它被授予.
但是,如果在应用程序B之后安装了应用程序A,那么该许可不会授予应用程序B.
虽然这可能不是常见的事情,由于应用程序B通常是应用程序A的插件,它当然可以发生和为我的应用程序.
使用SuperUser应用程序同意引入android.permission.ACCESS_SUPERUSER的全局自定义权限,如果用户决定切换SuperUser应用程序,这可能是一个很大的问题.
为了处理此问题,我打算在我的应用程序中使用以下代码来获取我即将开始声明的自定义权限：
checkPermissions(this,getCallingActivity().getPackageName()); // get the package name from the sender first
private boolean checkPermissions(Context context,String callingPackage) {
final List<PackageInfo> apps = context.getPackageManager().getInstalledPackages(PackageManager.GET_PERMISSIONS);
for (PackageInfo pi : apps) {
if (pi.packageName.equals(callingPackage)) {
String[] permissions = pi.requestedPermissions;
if (permissions != null) {
for (String permission : permissions) {
if (permission.equals("com.package.permission.READ_APP_DATA")) {
return true;
}
}
}
}
}
return false;
根据这个问题的标题：这种方法是否“安全”？或者有一种方法/ root-hack,应用程序的清单在安装后可以被更改,并且以程序化方式“添加”到应用程序B中的权限？
解决方法
不是一个简单的方法.用户必须在他的设备上安装一个MOD,可以在应用程序请求时立即授权任意权限. IIRC,清单文件本身在安装时解析.
所以我们在mod中使用的是改变com.android.server.pm.PackageManagerService类中的grantPermissionsLPw方法.
它用于授予启动器权限android.permission.EXPAND_STATUS_BAR,它在其清单中没有声明.
我不确定,如果这将被用于您的应用程序.但是总结一下：如果用户想要授予一个应用程序一个仲裁,自定义权限：是的,这是可能的.
UPDATE
当然,我可以详细说一下.我可以看到两种情况发生
静态模式
上面提到的类驻留在services.jar中.我们知道,这样的文件可以被反编译,修改和重新编译.实际上,这是一个相当容易的编辑这个文件.我不知道有什么办法直接在电话上做,但我会考虑这样做.这是不可行的,广泛的解决方案可用,因为它需要大量的处理能力.攻击者不能只提供通用文件.这些文件从设备更改为固件版本.或者,攻击者需要提供大量的修补文件,或者通过将其上传到服务器,进行修补,重新下载和安装来补丁.如果你问我这种情况不太可能.
动态模式
有多个框架可用,允许在操作时改变进程.最流行的是Xposed Framework.基本上,它是一个修补的app_process和一个相应的API,利用Reflection来改变运行的进程.现在攻击者可以用这个框架发送他的应用程序,并且具有根访问权,可以安静地安装它.通过root访问,他甚至可以自己启用模块,这通常需要用户交互.一旦这样的模块被启用,攻击者可以挂钩上述方法并更改所请求的权限.他将通过获取拥有所请求的权限的对象字段来添加他需要的对象字段,然后运行原始方法,添加原始定义的权限.
请注意,这两种情况都需要用户自己安装恶意应用程序.你没有提到你的应用程序是什么,所以我不能真正帮助你更多地评估风险.我可以说的是,攻击者可以做这样的事情.
