Actual Android packaging and signature

Xiaobian has introduced a lot of Android project packaging experience to you before. In this article, we will explain the process of Android packaging and signature through a project example.

Android packaging

The following is the schematic diagram:

The Android project is compiled and packaged to form:

. DEX file

resources.arsc

uncompiled resources

AndroidManifest.xml

Unzip a common APK file. The extracted files are as follows:

Classes.dex is a. DEX file. Resources.arsc is the resources file. Androidmanifest.xml is the androidmanifest.xml file. Res is uncompiled resources. Meta inf is the signature folder.

Where resources.arsc is equal to the index of the resource file, which is convenient to find the resource file

Specific packaging flow chart:

Android signature

After Android is signed, there are multiple meta inf files in the file, including three files:

Here's how to generate apksinger for the three files:

1、MANIFEST.MF

Traverse all entries one by one. If it is a directory or three files (manifest.mf, cert.rsa, cert.sf), skip it. If it is a file, extract the summary of the file with SHA1 (or sha256) message summary algorithm, and then write it into a block in the manifest.mf file as the value of "SHA1 digest" attribute after Base64 encoding. The block has a "name" attribute whose value is the path of the file in the APK package.

2、CERT.SF：

1》 Calculate the overall SHA1 value of the manifest.mf file, and record it under the "SHA1 digest manifest" attribute value of the cert.sf main attribute block (on the file header) after Base64 encoding

2》 The SHA1 of each block in the manifest.mf file is calculated one by one, encoded by Base64, and recorded in the block with the same name in cert.sf. The name of the attribute is "SHA1 digest"

3、CERT.RSA

Here, the previously generated cert.sf file will be used to calculate the signature with the private key, and then the signature and the digital certificate containing the public key information will be written into cert.rsa and saved. Cert.rsa is a file that meets pkcs7 format.

Why sign like this

Above, we have introduced the details of the three files after signing APK. Now let's summarize why this method is used for encryption and signature in Android. Is this encryption the most secure? Let's analyze what happens if the APK file is tampered with.

First, if you change any file in the APK package, the changed file summary information is different from the verification information of manifest.mf during APK installation verification. Therefore, the verification fails and the program cannot be installed successfully.

Secondly, if you calculate the new summary value for the changed file, and then change the corresponding attribute value in the manifest.mf file, it must be different from the summary value calculated in the cert.sf file, and the verification fails.

Finally, if you continue to calculate the summary value of manifest.mf and change the value in cert.sf accordingly, the digital signature value must be different from that recorded in cert.rsa file, or it fails.

So can we continue to forge digital signatures? Impossible because there is no private key corresponding to the digital certificate.

Therefore, if the repackaged application can be installed on Android devices, it must be re signed.

It can be concluded from the above analysis that as long as any content in APK is modified, it must be re signed, otherwise it will prompt the installation failure. Of course, it will not be analyzed here. The later article will focus on analyzing why it prompts the installation failure.