Transfer from application to obtain system Permissions

Http://blog.csdn.net/liujian885/archive/2010/03/22/5404834.aspx

 

Available in Android APIs
Systemclock. setcurrenttimemillis () function to modify the system time. Unfortunately, no matter how you call this function, it is useless, whether it is a simulator or a real
Logcat will always get "unable to open alarm DRIVER: Permission denied
". This function can be used only after root permission or running and system processes.

I thought there was no way to change the system at the application layer for a long time. Later I searched the internet for a long time and knew that this goal could still be achieved.

The first method is simple, but it needs to be compiled using make in the environment of the Android system source code:

1. Add the Android: shareduserid = "android. uid. System" attribute to the manifest node in androidmanifest. xml of the application.

2. Modify the Android. mk file and add local_certificate: = platform.

3. Use the MM command to compile the generated APK and you will have the permission to modify the system time.

The second method is troublesome, but you do not need to run the virtual machine to the source code environment and use make to compile it:

1. Similarly, add the Android: shareduserid = "android. uid. System" attribute.

2. Compile the APK file using eclipse, but this APK file cannot be used.

3. Open the APK file with the compression software, and delete the CERT. SF and cert. RSA files under the META-INF directory.

4.
Use the platform key of the target system to re-sign the APK file. This step is troublesome. First, find the key file in the my android source code directory.
Is "build/target/product/security", the following two files: Platform. pk8 and platform. x509.pem. However
And then use the signapk tool provided by Android to sign it. The source code of signapk is under "build/tools/signapk" and its usage is "signapk ".
Platform. x509.pem platform. pk8 input.apk
Output.apk ", it is best to use an absolute path for the file name to prevent it from being found. You can also modify the source code to use it directly.

In this way, the final APK is the same as the first method.

The following explains the principle. First, add the Android: shareduserid = "android. uid. System" attribute. Shared user
ID, with the same user
Multiple apk ids can be configured to run in the same process. Then, assign the UID of the program to Android. uid. system, that is, run the program in the system process.
You have the permission to modify the system time.

It is not enough to add uid. If the APK cannot be installed at this time, the system prompts that the signature is inconsistent because the program wants to run in the system process and the platform of the target system is required.
Key, which is the two platform. pk8 and platform. x509.pem files mentioned in the second method above. The APK can be put into the system only after the two keys are signed.
Running. Adding local_certificate: = platform to the first method is actually using the two keys for signature.

This also has a problem, that is, the program generated in this way can only be used in the original Android system or a self-compiled system, because such a system can get platform. pk8
And platform. x509.pem files. If other companies do not even install Android. Try the original Android key for signature.
Run OK on the simulator, but the prompt "package... has no signatures that match those in
Shared user Android. uid. System ", which also protects the system security.

Finally, the Android: shareduserid attribute can not only put the apk in the system process, but also configure multiple APK to run in one process to share data, it should be very useful.