Use APK signature to make the application have system Permissions

Problem:
Pre-installed software in the system. You need to access some configuration files. The owner of the configuration file is set to system. Therefore, the application must be authorized to read and write data.
Google search found the following article to solve this problem.

The following content explains:
Permission rules for the Android system?
How can an application obtain system permissions?
What is the APK signature process?
How does the APK Signature work?
######################################## #########################
The following content is transferred from:

Http://hi.baidu.com/donghaozheng/blog/item/23ca75ec0028bbdc2e2e21c5.html

The Android system runs on the Linux kernel. Android and Linux have their own strict security and permission mechanisms,
Many new users like me, especially those who are used to low security restrictions on Windows, are easily confused in this regard. The following is my summary about permissions related to the Android system,
As a summary of the permission learning for Android during this period, I hope it will be helpful to you. If this is incorrect, please point it out.
First, we should clarify two concepts:
You need to distinguish the permissions that the APK has when running from the permissions that are accessed (read/write execution) on the file system.
The APK program runs on a virtual machine and corresponds to the unique permission mechanism of Android. It uses Linux permission settings only when it is embodied in the file system.

(1) Linux File System Permissions
-Rwxr-X -- X system 4156 2010-04-30 16:13 test.apk
It indicates the access permissions of the corresponding user/user group and others to the file, and the permissions for running the file are completely irrelevant.
For example, the preceding example only shows that the System user has the permission to read and write the file, the system group user has the permission to read and execute the file, and other users only have the permission to execute the file.
Test.apk is irrelevant to what can be done after it is run.
Do not check that the APK file system belongs to system/system users and user groups, or root/root users and user groups. In this case, the APK has system or root permissions.

(2) Permission rules for Android

(1) The APK in Android must be signed.

This signature is not based on an authoritative certificate. It does not determine whether an application allows installation, but is a self-signed certificate.
It is important that the permissions of the Android system are signature-based. For example, if the system-level permission has a specific signature and the signature is incorrect, the permission cannot be obtained.
The default APK file is signed by debug.
For details about the signatures used when obtaining system permissions, see how to grant system permissions to Android applications.
(2) process-level security mechanism based on userid
As we all know, a process has an independent address space, and the process and process cannot access each other by default. It is a reliable protection mechanism.
Android assigns a unique Linux userid for each package (APK) installed on the device. The name is "app _" and a number is added, for example, app_43.
Different userids run in different processes, so the APK cannot access each other by default.
Android provides the following mechanism to break the barriers mentioned above.
In androidmanifest. XML, the shareduserid attribute is used to allocate the same userid to different packages. In this way, two packages can be treated as the same program,
The system will assign the same userid to the two programs. Of course, based on security considerations, the two packages must have the same signature, otherwise it makes no sense to do so without verification.
(Add one point here: it does not mean that the same userid is assigned, and the two programs run in the same process. The following command is extracted from the ps command,
Obviously, the PID of the two processes corresponding to system and app_2 is different. I don't know how Android implements its mechanism)
User PID ppid
System 953 883 187340 55052 ffffffff afe0cbcc s system_server
App_2 1072 883 100264 19564 ffffffff afe0dcc4 s com. Android. inputmethod.
System 1083 883 111808 23192 ffffffff afe0dcc4 s Android. process. omsservi
App_2 1088 883 156464 45720 ffffffff afe0dcc4 s Android. process. acore

(3) The data generated by the default APK is invisible to the outside world.
The implementation method is: Android will allocate the userid of the program for the data stored in the program.
By virtue of Linux's strict File System Access Permissions, the mechanism that APK cannot access each other seems to have data.
For example, the default permission for a file created by my application is as follows. You can see that only programs with userid app_21 can read and write the file.
-RW ------- app_21 app_21 87650 2000-01-01 09:48 test.txt
How can we open it to the outside world?
<1> use the mode_world_readable and/or mode_world_writeable flag.
When creating a new file with getsharedpreferences (string, INT), openfileoutput (string, INT), or openorcreatedatabase (string, Int, sqlitedatabase. cursorfactory), you can use the mode_world_readable and/or mode_world_writeable flags to allow any other package
To read/write the file. when setting these flags, the file is still owned by your application, but its global read and/or write permissions have been set appropriately so any other application can see it.

(4) explicit permission declaration in androidmanifest. xml
Android applications do not have any permissions to operate other applications or system-related features by default. Applications must explicitly apply for corresponding permissions when performing certain operations.
You must apply for the following permissions:
A participating permission may be enforced at a number of places during your program's operation:
At the time of a call into the system, to prevent an application from executing certain functions.
When starting an activity, to prevent applications from launching activities of other applications.
Both sending and broadcasting ing broadcasts, to control who can receive your broadcast or who can send a broadcast to you.
When accessing and operating on a content provider.
Binding or starting a service.

During application installation, the package installer detects the application request permissions and assigns the corresponding permissions based on the Application signature or prompts the user.
Permissions are not checked during the program running. If the permission fails to be obtained during installation, the execution will fail, and the insufficient user permissions will not be prompted.
In most cases, failure due to insufficient permissions will cause a securityexception, which will have related records in the system log.
(5) Permission Inheritance/userid inheritance
When we encounter an APK with insufficient permissions, we sometimes consider writing a Linux program, and then the APK calls it to do something that it has no permissions to do. Unfortunately, this method does not work.
As mentioned above, Android permissions are run at the process level. That is to say, the permissions of a sub-process started by an APK application cannot exceed the permissions of its parent process (that is, the permissions of the APK ),
Even if an application runs independently and has the permission to do something, if it is called by an APK, the permission will be limited.
In fact, Android implements this mechanism by assigning the userid of the parent process to the child process.
 
(3) Analysis of Common insufficient Permissions

First, you must know that the common APK program runs at a non-root or system level. That is to say, when you view the permission of the file to be accessed, you can view the last three digits.
In addition, the permission for APK installed through system/APP is generally higher than that for APK installed directly or ADB install.

To put it bluntly, when running an Android Application, you may encounter insufficient permissions. Generally, there are two scenarios:
(1) the error message about insufficient permissions is displayed in the log.
In this case, androidmanifest. XML does not have the corresponding permission settings. It is the easiest to handle this problem to find the permission list.
Sometimes the permission is added, but the permission is still insufficient. What is the situation?
The Android system requires a certain level of APK to run APIs and permissions.
For example, if systemclock. setcurrenttimemillis () is used to modify the system time, the write_secure_settings permission seems to require system-level permissions.
That is to say, userid is system.
(2) logs do not report insufficient permissions, but some other exception prompts, which may also be caused by insufficient permissions.
For example, if you want to read/write a configuration file or other files that are not created by yourself, the Java. Io. filenotfoundexception error is often reported.
Generally, files that are considered important have strict permission settings, especially important (configuration) files or directories.
For example
-R -- r ----- Bluetooth 935 2010-07-09. conf
Drwxrwx -- X system 2010-07-07 data

The metadata. conf file seems to be a Bluetooth configuration file. In terms of permissions, it cannot be changed at all. Non-Bluetooth users do not have the right to read the file.
The/data directory stores private data of all programs. By default, Android does not allow normal APK access to the/data directory. You can see through the permission settings of the data directory, other users do not have the read permission.
Therefore, if you press the LS command in the data directory under the general permission of ADB, you will get the opendir failed and permission denied errors. You cannot get the content in the data directory through the code file. listfiles.

In the above two cases, you generally need to upgrade the APK permission. Currently, the apk I know can be upgraded to system (For details, refer to: how to obtain system permissions for Android applications ),
It is not clear how to upgrade to the root level if there is a root level. I am grateful to anyone who knows how to upgrade to the root level.

######################################## ######################################

See how to grant system permissions to Android applications.

Http://hi.baidu.com/donghaozheng/blog/item/30a00d4f9fca873baec3ab69.html

1. Add the Android: shareduserid = "android. uid. System" attribute to the manifest node in androidmanifest. xml of the application.
2. Compile the APK file using eclipse, but this APK file cannot be used.
3. Use the platform key of the target system to re-sign the APK file.

The following explains the principle. First, add the Android: shareduserid = "android. uid. System" attribute. With the shared user ID, multiple APK with the same user ID can be configured to run in the same process. Then, assign the UID of the program to Android. uid. system, that is, to allow the program to run in the system process, so that you have the permission to modify the system time.

It is not enough to add the 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 key of the target system is required, the platform mentioned in the second method above. pk8 and platform. x509.pem files. The APK can be put into the system process only after the two keys are signed. Adding local_certificate: = platform to the first method is actually using the two keys for signature.

There is also 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 the platform. pk8 and platform. x509.pem files.
If other companies do not even install Android. Try the original Android key for signature. The program runs 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.

Summary: Three Steps
>>>>>>> Use the platform key to sign the APK
1. Create a directory
2. Sort required files:
Key File: Go to build/target/product/security and find the default keys used by the [platform. pk8] and [platform. x509.pem] systems.
Signapk tool: Go to build \ tools \ signapk to find signapk. Java, run javac or directly compile with MM.
Signapk. Jar source code location build/tools/signapk, compiled file path: Out/host/linux-x86/framework/signapk. Jar
3. Execute the command: Java-jar signapk. Jar platform. x509.pem platform. pk8 your.apk your_signed.apk
The meaning of this command is: success ".
The generation of the private key and public key used here is not described here. See http://blog.csdn.net/absurd/article/details/5002763

######################################## #####################################
Procedure and principle of program Signature

This note is based on the following articles.

Http://www.blogjava.net/zh-weir/archive/2011/07/19/354663.html

Here is another article about APK cracking, which may be helpful for your understanding.

Http://www.blogjava.net/zh-weir/archive/2011/06/11/352099.html

Signapk. jar is a signature tool in the android source code package. Because Android is an open-source project, we can directly find the source code of signapk. jar, path:/build/tools/signapk. java. By reading the signapk source code, we can clarify the entire process of signing the APK package.

A folder named META-INF is added to the signed APK package. There are three files named manifest. MF, cert. SF, and cert. RSA. Signapk. Jar generates these files.
1. Generate the manifest. MF file:
The program traverses all the files (entries) in the update.apk package. For non-Folder unsigned files, generate the digital signature information of sha1 one by one, and then encode it with base64. For specific code, see this method:
Private Static manifest adddigeststomanifest (jarfile jar)
The key code is as follows:

1 For (jarentry entry: byname. Values ()){
2 string name = entry. getname ();
3 if (! Entry. isdirectory ()&&! Name. Equals (jarfile. manifest_name )&&
4! Name. Equals (cert_sf_name )&&! Name. Equals (cert_rsa_name )&&
5 (strippattern = NULL |! Strippattern. matcher (name). Matches ())){
6 inputstream DATA = jar. getinputstream (entry );
7 while (num = data. Read (buffer)> 0 ){
8 Md. Update (buffer, 0, num );
9}
10 attributes ATTR = NULL;
11 if (input! = NULL) ATTR = input. getattributes (name );
12 ATTR = ATTR! = NULL? New Attributes (ATTR): new attributes ();
13 ATTR. putvalue ("SHA1-Digest", base64.encode (Md. Digest ()));
14 output. getentries (). Put (name, ATTR );
15}
16}

Then, write the generated signature to the manifest. MF file. The key code is as follows:

1 manifest = adddigeststomanifest (inputjar );
2 je = new jarentry (jarfile. manifest_name );
3 je. settime (timestamp );
4 outputjar. putnextentry (JE );
5 manifest. Write (outputjar );
Here is a brief introduction to the sha1 digital signature. In short, it is a secure hash algorithm, similar to the MD5 algorithm. It converts an input of any length into an output of a fixed length using the hash algorithm (this is called "abstract information "). You cannot use this abstract information to restore the original information. In addition, it ensures that the abstract information of different information is different from each other. Therefore, if you change the file in the APK package, the modified file summary information is different from the manifest. MF check information during APK installation verification, so the program cannot be successfully installed.

2. Generate the CERT. SF file:

The manifest generated in the previous step is signed with the private key using the SHA1-RSA algorithm. The key code is as follows:

1 Signature = signature. getinstance ("sha1withrsa ");
2 signature. initsign (privatekey );
3 je = new jarentry (cert_sf_name );
4 je. settime (timestamp );
5 outputjar. putnextentry (JE );
6 writesignaturefile (manifest,
7 new signatureoutputstream (outputjar, signature ));
RSA is an asymmetric encryption algorithm. Use the RSA algorithm to encrypt the digest information. Only the public key can be used for decryption during installation. After decryption, it is compared with the unencrypted summary information. If it is consistent, it indicates that the content is not modified abnormally.

3. Generate the CERT. RSA file:
No key information is used to generate manifest. MF. The private key file is used to generate the CERT. SF file. We can easily guess that the generation of the CERT. RSA file must be related to the public key.
The CERT. RSA file stores information such as the public key and the encryption algorithm used. The core code is as follows:

1 je = new jarentry (cert_rsa_name );

2 je. settime (timestamp );
3 outputjar. putnextentry (JE );
4 writesignatureblock (signature, publickey, outputjar );
The writesignatureblock code is as follows:

1 Private Static void writesignatureblock (
2 signature, x509certificate publickey, outputstream out)
3 throws ioexception, generalsecurityexception {
4 signerinfo = new signerinfo (
5 new x500name (publickey. getissuerx500principal (). getname ()),
6 publickey. getserialnumber (),
7 algorithmid. Get ("sha1 "),
8 algorithmid. Get ("RSA "),
9 signature. Sign ());
10
11 pkcs7 pkcs7 = new pkcs7 (
12 new algorithmid [] {algorithmid. Get ("sha1 ")},
13 new contentinfo (contentinfo. data_oid, null ),
14 new x509certificate [] {publickey },
15 New signerinfo [] {signerinfo });
16
17 pkcs7.encodesigneddata (out );
18}
Now, after analyzing the signature process of the APK package, we can clearly realize that:

1. the android signature mechanism is actually a verification mechanism for the integrity of the APK package and the uniqueness of the publishing organization.
2. the android signature mechanism cannot prevent the APK package from being modified, but the modified signature cannot be consistent with the original signature. (Except for private keys ).
3. The public key encrypted in the APK package is packaged in the APK package, and different private keys correspond to different public keys. In other words, the APK public keys of different private key signatures must also be different. Therefore, we can compare the public key to determine whether the private key is consistent.