[Go] To use the APK signature to give the application system privileges

[to] use the APK signature to give the application system privileges (2013-01-08 13:40:50)

Reproduced

It
Category: Android

Source: http://blog.csdn.net/doom66151/article/details/7085464

Issue:
system preinstalled software, need to access some configuration files, configuration file owner is set to system. So the application needs to be authorized to read and write.
Google search found the following article to solve this problem.
The following explains:
Android system permission rules?
How do I get the application to gain system permissions?
The process of the APK signature? How does the
apk signature work?
#################################################################
The following to go from:
http://hi.baidu.com/ Donghaozheng/blog/item/23ca75ec0028bbdc2e2e21c5.html
Android System is running on the Linux kernel, Android and Linux have their own set of strict security and authority mechanism ,
A lot of newbies like me, especially those accustomed to the Windows Low security restrictions, it is easy to confuse this, the following is my summary of the Android system permissions related content,
as this time on the Android rights learning summary, but also hope to be helpful to everyone, Please indicate the incorrect point. The
first distinguishes between the two concepts:
to differentiate between the permissions that the APK runtime has and the permissions that are accessed on the file system (read and write execution). The
APK program is run on the virtual machine, corresponding to the unique Android permissions mechanism, only to reflect the file system on the use of Linux permissions settings.
(i) permissions on the Linux file system
-rwxr-x--x system system 4156 2010-04-30 16:13 test.apk
represents the corresponding user/user group and other people's access to this file, The permissions that are running with this file are completely unrelated. The
example above only shows that the system user has read and write execution permissions on the file, that the user of the system group has access to the file, and that the other person has only execute permissions on the file.
and what test.apk can do when it's running, it's irrelevant.
do not look at the APK file system belonging to System/system users and user groups, or root/root users and user groups, it is assumed that the APK has system or root permissions.
(ii) Permissions rules for Android

(1) The APK in Android must be signed

This signature is not based on an authoritative certificate, and does not determine whether an app is allowed to install, but a self-signed certificate.
It is important that the permissions on the Android system are based on signatures. For example: The system level of permissions have a specific signature, the signature is not correct, the permissions will not be obtained.
The default generated APK file is the debug signature.
The signature used to get the system permissions, see: How to get the Android app permissions
(2) UserID-based process-level security mechanisms
As we all know, the process has a separate address space, the process and process between the default is not mutual access, is a very reliable protection mechanism.
Android is implemented by assigning a unique Linux userid to each package installed on the device (APK), with the name "App_" plus a number, such as app_43
Different userid, running in different processes, so the apk between the default can not access each other.
Android offers one of the following mechanisms that allows two apk to break the aforementioned barrier.
Using the Shareduserid attribute in Androidmanifest.xml to assign the same userid to different packages, by doing so, the two package can be used as the same program,
The system assigns the same userid to two programs. Of course, for security reasons, two of the package needs to have the same signature, otherwise there's no point in verifying it.
(Add this: not that the same userid is assigned, the two programs run in the same process, the following are extracted by the PS command,
Obviously, the system, app_2 respectively corresponding to the two process PID are different, I do not know how the Android is how to implement 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 default APK generated data is not visible to outsiders
By doing this, Android assigns the program's userid to the data stored by the program.
With Linux's strict access to the file system, there is no mechanism for the APK to have access to each other like data.
Example: A file created by my app with the default permissions as follows, you can see that only a program with UserID App_21 is able to read and write to the file.
-RW-------app_21 app_21 87650 2000-01-01 09:48 test.txt
How to open?
<1> use mode_world_readable and/or mode_world_writeable markers.
When creating a new file with Getsharedpreferences (string, int), Openfileoutput (string, int), or openorcreatedatabase (Str ing, int, sqlitedatabase.cursorfactory), you can use the mode_world_readable and/or mode_world_writeable Y other package to read/write the file. When setting these flags, the file was still owned by your application and its global read and/or write permissions had B Een set appropriately so any other application can see it.
(4) explicit permission declaration in Androidmanifest.xml
The Android default app does not have any permissions to manipulate other apps or system-related features, and the app needs to explicitly apply the appropriate permissions when doing certain things.
The following actions are generally required to apply the appropriate permissions:
A particular permission is enforced at a number of the 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 a activity, to prevent applications from launching activities of the other applications.
Both sending and receiving 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.
When the app is installed, package installer detects the permissions requested by the app, depending on the app's signature or prompting the user to assign the appropriate permissions.
The permission is not detected during the run of the program. If permission acquisition fails during installation, execution will go wrong and the user will not be prompted for insufficient permissions.
In most cases, a failure caused by insufficient permissions will cause a SecurityException to be logged 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 complete something that it does not have permission to complete, unfortunately, this method is not feasible.
As mentioned earlier, Android permissions are operating at the process level, that is, an APK app starts the child process permissions can not exceed its parent process permissions (that is, the rights of the APK),
Even if running an app alone has permission to do something, if it is called by an APK, then the permissions will be limited.
In fact, Android implements this mechanism by assigning the userid of the parent process to the child process.
(iii) Analysis of the problem of common authority insufficiency
The first thing to know is that the normal APK program is run on a non-root, non-system level, that is, to see the permissions of the file to be accessed, looking at the last three bits.
In addition, the permissions of the APK installed through System/app are generally higher than the permissions of the APK installed directly or adb install.
To get to the problem, running an Android application is not a sufficient privilege to run, generally in two situations:
(1) Log can clearly see the prompt for insufficient permissions.
This situation is generally missing the appropriate permission settings in the Androidmanifest.xml, well find a list of permissions, should be resolved, is the most easy to handle the situation.
Sometimes the permissions are added, but still reported insufficient authority, what is the situation?
The Android system has some APIs and permissions that require the APK to have a certain level to run.
such as Systemclock.setcurrenttimemillis () modify the system time, write_secure_settings permissions seem to need to have system-level permissions.
This means that the UserID is System.
(2) Log does not report the lack of authority, but some other exception hints, this may also be due to insufficient permissions.
For example: We often want to read/write a configuration file or some other files that are not created by ourselves, often reported java.io.FileNotFoundException errors.
The system thinks that the more important file general permission settings will be more stringent, especially some very important (configuration) files or directories.
Such as
-R--R-----Bluetooth bluetooth 935 2010-07-09 20:21 dbus.conf
Drwxrwx--x System system 2010-07-07 02:05 data
Dbus.conf seems to be the configuration file of Bluetooth, from the rights point of view, it is impossible to change, non-Bluetooth users even read the right to not.
/data directory is stored in the private data of all programs, by default, Android does not allow the normal apk to access the contents of the/data directory, the permissions set through the data directory, other users do not have Read permissions.
So the ADB normal permissions under the data directory to knock the LS command, you will get Opendir failed, Permission denied error, through the code file.listfiles () can not get the contents of the data directory.
In both cases, it is generally necessary to elevate the APK permissions, and now I know that the APK can be elevated to the system (see: How to get the Android app access to the system),
As to whether there is a root level, how to ascend to the root level is unknown, know the friend trouble to tell, grateful.
##############################################################################
The following is organized from: How to get System permissions for Android apps
Http://hi.baidu.com/donghaozheng/blog/item/30a00d4f9fca873baec3ab69.html
1. Add the android:shareduserid= "Android.uid.system" attribute to the manifest node in the application's androidmanifest.xml.
2. Use eclipse to compile the apk file, but this apk file is not available.
3. Use the target system's platform key to re-sign the apk file.
Finally explain the principle, first add android:shareduserid= "Android.uid.system" this attribute. With the shared user ID, multiple apk with the same user ID can be configured to run in the same process. Then the UID of the program into a android.uid.system, that is, to let the program run in the system process, so that there is permission to modify the system time.
Just adding UID is not enough, if you install the APK at this time found unable to install, prompt signature does not match, because the program wants to run in the system process and the target system platform key, The second method mentioned above is the PLATFORM.PK8 and Platform.x509.pem two files. Using these two keys to sign the APK before it can actually be put into the system process. The first method adds Local_certificate: = Platform is actually signed with these two keys.
There is also a problem, that is, the generated programs can only be used in the original Android system or in their own compiled system, because such a system can get platform.pk8 and Platform.x509.pem two files.
If the other company does not have the Android installed on the installation. Try the original Android key to sign, the program runs OK on the emulator, but put on the G3 to install the direct prompt "package ... has no signatures that match those in shared user Android.uid. System ", which also protects the security of the systems.
Last but not least, this Android:shareduserid property can not only put the APK into the system process, you can also configure multiple apk running in a process, so that the data can be shared, it should be useful.
Summarize the simple three steps
>>>>>>> sign the APK with the platform key
1 Creating a Directory
2 organize the necessary files:
Key file: Enter Build/target/product/security to find the key used by default for "Platform.pk8" and "Platform.x509.pem" system.
signapk tool: Enter build\tools\signapk to find Signapk.java, run Javac or direct mm compile.
Signapk.jar Source Location build/tools/signapk, the file path generated after compilation: Out/host/linux-x86/framework/signapk.jar
3. Execution command: Java-jar signapk.jar platform.x509.pem platform.pk8 your.apk your_signed.apk
The meaning of this command is: by Signapk.jar this executable jar package, "PLATFORM.X509.PEM" This public key file and "Platform.pk8" This private key file to the "your.apk" signature, the signed file is saved as "your_ signed.apk ".
There is no further introduction to the way the private key and public key are generated here. can refer to http://blog.csdn.net/absurd/article/details/5002763
#############################################################################
Procedure and principle of program signature
This note is mainly based on the following articles organized.
Http://www.blogjava.net/zh-weir/archive/2011/07/19/354663.html
There is also an article here that will help you understand the APK hack, perhaps.
Http://www.blogjava.net/zh-weir/archive/2011/06/11/352099.html
Signapk.jar is a signature tool in the Android source package. Because Android is an open source project, so we can directly find Signapk.jar source code, the path is/build/tools/signapk/signapk.java. By reading the signapk source code, we can sort out the entire process of signing the APK package.
The signed APK package has a folder called Meta-inf. Inside there are three files, named MANIFEST.MF, CERT, respectively. SF and Cert.rsa. Signapk.jar is the creation of these files.
1. Generate MANIFEST.MF File:
The program iterates through all the files in the UPDATE.APK package (entry), generates SHA1 digital signature information for non-folder non-signed files, and then encodes it with Base64. 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);
3 ·
Ten Attributes attr = null;
one if (input = null) attr = input.getattributes (name);
attr = attr! = null? New Attributes (attr): New Attributes ();
Attr.putvalue ("Sha1-digest", Base64.encode (Md.digest ()));
Output.getentries (). Put (name, attr);
15}
16}
The resulting signature is then written to the MANIFEST.MF file. The key code is as follows:
1 Manifest 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. Simply put, it is a secure hashing algorithm, similar to the MD5 algorithm. It turns the input of any length into a fixed-length output by hashing the algorithm (here we call "summary information"). You cannot restore the original information by simply using this summary information. In addition, it ensures that the summary information of different information differs from each other. So, if you change the files in the APK package, then in the APK installation check, the changed file summary information and MANIFEST.MF test information is different, so the program will not be installed successfully.
2. Generate CERT.SF File:
For the manifest generated in the previous step, use the SHA1-RSA algorithm to sign with the private key. The key code is as follows:
1 Signature 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. The digest information is encrypted with the private key through the RSA algorithm. You can only use the public key when you install to decrypt it. After decryption, it is compared to unencrypted summary information, and if it matches, the content is not modified by exception.
3. Generate Cert.rsa File:
The build MANIFEST.MF does not use key information, and the generated CERT.SF file uses the private key file. Then we can easily guess, CERT. The generation of RSA files is definitely related to the public key.
CERT. The RSA file holds information such as the public key, the encryption algorithm used, and so on. 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 code for Writesignatureblock is as follows:
1 private static void Writesignatureblock (
2 Signature Signature, X509Certificate publickey, outputstream out)
3 throws IOException, Generalsecurityexception {
4 SignerInfo signerinfo = new SignerInfo (
5 New X500name (Publickey.getissuerx500principal (). GetName ()),
6 Publickey.getserialnumber (),
7 Algorithmid.get ("SHA1"),
8 Algorithmid.get ("RSA"),
9 signature.sign ());
10
PKCS7 PKCS7 = new PKCS7 (
New algorithmid[] {algorithmid.get ("SHA1")},
New ContentInfo (contentinfo.data_oid, NULL),
New x509certificate[] {PublicKey},
New signerinfo[] {signerinfo});
16
Pkcs7.encodesigneddata (out);
18}
Well, after analyzing the signature process of the APK package, we can clearly realize:
1. The Android signature mechanism is a verification mechanism that is unique to the APK package integrity and publishing organization.
2. The Android signature mechanism cannot prevent the APK package from being modified, but the modified re-signature cannot be consistent with the original signature. (except where the private key is owned).
3, the APK package encrypted public key is packaged in the APK package, and different private keys corresponding to different public keys. In other words, the different private key signatures of the APK public key will also not be the same. So we can judge whether the private key is consistent according to the public key.

[Go] To use the APK signature to give the application system privileges