以编程方式更改清单 - Android 自定义权限 [英] Programmatically alter Manifest - Android custom permissions
问题描述
App A 定义了以下的自定义权限:
App A defines the custom permission of:
com.package.permission.READ_APP_DATA
当应用 B 被安装并声明自定义权限时，它被授予.
When app B is installed declaring the custom permission, it is granted.
但是，如果应用 A 在应用 B 之后安装，则权限不授予应用 B.
However, if app A is installed after app B, then the permission is not granted to app B.
虽然这种情况可能并不常见，但由于应用 B 通常是应用 A 的插件，它当然会发生并且对我的应用也适用.
Whilst this may not be a common occurrence, due to app B often being a plugin of app A, it of course can occur and does for my application.
SuperUser 应用程序同意引入 android.permission.ACCESS_SUPERUSER 的全局自定义权限，如果用户决定切换 SuperUser 应用程序，这很可能是一个大问题.
With SuperUser applications agreeing to introduce the global custom permission of android.permission.ACCESS_SUPERUSER this may well be a big problem should a user decide to switch SuperUser app.
为了处理这个问题，我打算在我的应用程序中使用以下代码来获得我即将开始声明的自定义权限:
In order to handle the issue, I intend to use the following code in my application for the custom permission I am about to start declaring:
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?
As per the title of this question: Is this method 'safe'? Or is there a way/root-hack that an application's manifest could be altered after it is installed and the permission programmatically 'added' to app B?
推荐答案
我不确定我的问题是否正确，因为我不知道在安装后将权限侵入清单是如何连接到代码的你在上面发帖.但要回答你的最后一段:
I'm not sure if I'm getting the question right, as I don't know how hacking a permission into the manifest after install connects to the code you posted above. But to answer your last paragraph:
不容易.用户必须在他的设备上安装一个 mod，它可以在应用程序请求时即时授予任意权限.IIRC 清单文件本身仅在安装时解析.
Not in an easy way. The user has to have a mod installed on his device, that can grant arbitrary permissions on the fly while the app is requesting them. IIRC the manifest file itself is parsed just at install time.
所以我们在 mod 中使用的是改变 com.android.server.pm.PackageManagerService 类中的方法 grantPermissionsLPw.
So what we used in a mod is altering the method grantPermissionsLPw in class com.android.server.pm.PackageManagerService.
它用于授予启动器权限 android.permission.EXPAND_STATUS_BAR，它没有在其清单中声明.
It is used to grant a launcher the permission android.permission.EXPAND_STATUS_BAR, which it didn't declare in its manifest.
不过，我不确定这是否会用于您的应用.但总结一下:如果用户想要授予应用任意的自定义权限:是的，这是可能的.
I am not sure though, if this would ever be used for your app. But to sum it up: If the user wants to grant an app an arbitray, custom permission: Yes, it is possible.
更新
当然，我可以详细说明一点.我可以看到两种情况发生
I can elaborate a bit more, of course. I can see two scenarios happening
1.静态模组
上面提到的类驻留在services.jar 中.众所周知，像这样的文件可以被反编译、更改和重新编译.实际上，对这个文件进行相当容易的编辑.我不知道直接在电话上执行此操作的方法，但我认为这是可能的.只是不太可行，可以使用广泛的解决方案，因为它需要大量的处理能力.攻击者不能只提供通用文件.这些文件因设备而异，也因固件版本而异.或者，攻击者需要提供大量修补文件，或者通过将其上传到服务器、修补、重新下载和安装来实时修补.如果你问我，这种情况不太可能发生.
The above mentioned class resides in services.jar. As we know, files like this can be decompiled, altered, and recompiled. Actually, it's a fairly easy edit on this file. I don't know about a way to do this on the phone directly, but I would consider it possible. It's just not that feasible, that widespread solutions are available, as it needs a good amount of processing power. An attacker can't just supply an universal file. These files change from device to device, and also between firmware versions. Either, the attacker would need to supply a huge amount of patched files, or do the patching live, by uploading it to a server, patch it, redownload and install it. This scenario is not very likely if you ask me.
2.动态模组
有不止一种框架可用，它们允许在操作时更改进程.其中最受欢迎的是 Xposed 框架.基本上，它是一个打补丁的 app_process 和一个相应的 API，它利用 Reflection 来改变正在运行的进程.现在攻击者可以使用这个框架发布他的应用程序，并拥有 root 访问权限，静默安装它.有了 root 访问权限，他甚至可以自己启用模块，这通常需要用户交互.一旦启用了这样的模块，攻击者就可以挂钩上述方法并更改请求的权限.他将通过获取保存请求权限的对象字段来执行此操作，添加他需要的一个，然后运行原始方法，该方法添加了最初定义的权限.
There are more than one frameworks available, that allow altering processes while they opertae. The most popular of them is the Xposed Framework. Basically, it is a patched app_process and a corresponding API that leverages Reflection to alter running processes. Now an attacker can ship his app with this framework, and having root access, install it silently. With root access, he can even enable the module by himself, which normally requires user interaction. Once a module like that is enabled, the attacker can hook into the above mentioned method and alter the requested permissions. He would be doing this by getting the object field, which holds the requested permissions, add the one he requires, THEN run the original method, which adds the originally defined permissions.
请注意，这两种情况都需要用户自己安装恶意应用程序.您没有提及您的应用程序的用途，因此我无法真正帮助您评估风险.我只能说，攻击者可以做这样的事情.
Please note that both scenarios require the user to install the malicious app himself. You didn't mention what your app is for, so I can't really help you more with evaluating the risk. All I can say is, that an attacker CAN do things like that.
这篇关于以编程方式更改清单 - Android 自定义权限的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
