Android introduced a privilege mechanism the initial point of view is to strictly control and handle security issues through a privilege policy, see: The following two articles, but there are still some small but not negligible questions about the Android authority's mechanism, and the so-called while outsmart, There are still a few ways to bypass permissions. This article aims to analyze some shortcomings and deficiencies of the Authority mechanism, and it cannot be used as a reference book for illegal application.
Android Permission Permission Mechanism primer
The specific use of the Android permission Authority mechanism
Deficiencies and deficiencies of the Authority mechanism
(1) The application is free to name a new permission without having to follow certain naming rules and restrictions, and it is not advisable to expect users to be alert to any given permission name used by different applications, including programs that have not been installed.
That's a bit of a struggle, actually, Android. When declaring permissions on a new application (Custom Permission app), it does not specify naming rules and restrictions for the name of the permission, no rules radius, and the irregular name can cause some problems.
(2) Once the permission is granted to the application, it will not be removed during the life of the application, even if the source program that declares the permission is deleted.
After a declarative application (custom Permission app) is removed, there are no mechanisms to notify which applications that use that permission (custom Permission Client), but rather to use the application of that permission (custom Permission Client) When running to a specified location requires permission to do the error.
(3) A system with two different permissions can declare the same name.
(4) When the authority is insufficient, log will report, for example:
Copy Code code as follows:
03-01 15:02:31.488:e/androidruntime (565): Java.lang.SecurityException:Permission denial:starting Intent {cmp= com.example.custompermission/. Mainactivity} from Processrecord{44ffc5e0 565:com.example.customtest/10043} (pid=565, uid=10043) requires Custom.permission.STARTACTIVITY
03-01 15:02:31.488:e/androidruntime (565): at Com.android.internal.os.zygoteinit$methodandargscaller.run ( zygoteinit.java:868)
So an ulterior developer would like to use this approach to add certain permissions (other app claims) and then call the app that claims permission.
Establish a sense of authority
Splitting up the flaws above, we should still need to pay attention to the application of the authority, after all, Google in the Android authority has made a lot of effort.
(1) User initial judgment
Users can download the software to determine whether the authority is excessive, such as an input method should not send text messages, some of the process of memorizing words should not send text messages, view contacts and short message permissions. Users need to be aware of each app's permission requests before installing the application, and Android will clearly list some of the high risk privileges and ignore some of the relatively low risk permissions, so users can only look at these listed permissions, and do to identify it.
(2) Third party software/rom
You can restrict permissions through Third-party software, such as app Shield, which is an Android application that needs to be paid for by modifying the application's APK installation package and deleting the corresponding "in the Androidmanifest.xml file that declares the permissions." Android.permission.* "entry, and then re-sign the installation package with a public certificate (you need to allow" unknown source "), so that the application does not request the previously required permissions to the system. When the application runs to the appropriate process, the system will directly reject, thereby achieving the user control permissions. For installed applications, Appshield will also make the APK installation package in the same way, then let the user uninstall the original application, then install the adjusted application. In addition to the application of digital signatures, users can restore revoked permissions at any time by performing the same process. Of course, the third party ROM can also be done, such as MIUI when the software used a certain permissions will actively intercept and ask the user whether to grant permissions.
Cross permission mechanism
However – there are still several ways to bypass the permission mechanism to use permissions that require permission without requesting permission.
(1) root device silent installation
If your phone has been root, then some apps can be installed silently on your phone.
Silent installation means that the app does not have the installation interface to prompt the user for the app's permissions, instead of simply installing it on your phone, the user loses the minimum chance to authenticate by permission; This is not a privilege mechanism, but these silently installed programs Not showing permissions is equivalent to not having any permissions.
(2) applications using the same Shareduserid
First of all, a brief introduction: Shareduserid
By default, Android assigns a separate user space to each apk, that is, each application has a UID, and only this UID is available to access the information covered by the UID.
Therefore, if the AP-1 is different from the UID of the AP-2, then both parties cannot read each other's data in default (default). This divide and conquer way, can reduce hacker software malicious harm data, enhance the security of the handset.
However, if two applications are signed with the same UID, the Shareduserid keyword is used. This example needs to be used in conjunction with two programs, both of which declare an identical shareduserid in the Androidmanifest.xml file, such as the following:
Go back to AP-1 and AP-2, assume that AP-1 is a more formal program, only read contacts permissions, due to more formal appearance, users may trust and install, and later the user installed after a period of AP-2, This AP-2 only has the right to connect to the Internet, but it's easy to upload the contact information that the AP-1 stored in the database to the Internet.
(3) to crack acceptance of broadcast receiver (receiver) program
This is a much more used approach, which requires 2 or more applications to match. For example, virus developers will analyze the current market, some of the popular text messaging applications, and through a certain technology decompile code, Java reflection and other technology, in short, can find a normal application to send SMS receiver, and then through their own virus applications to send radio, to achieve the purpose of deceitful act.