Signature is a combination of abstract key encryption and asymmetric key encryption. Abstract is like the fingerprint information of content. Once the content is tampered with, the abstract will change, and the signature is the encrypted result of the abstract. If the abstract changes, the signature will also be invalid. The same is true for Android APK signature. If the APK signature does not correspond to the content, the Android system thinks that the APK content has been tampered with, thus refusing to install it to ensure system security. At present, there are three kinds of Android signatures: V 1, V2(N) and V3(P). This paper only looks at the first two kinds of signatures, V 1 and V2, and does not consider the round encryption of V3. Let's take a look at the style after APK only signs V 1:
Look at the APK packaging style with V2 signature:
Signed by V 1 V2 at the same time:
It can be seen that if there is only v2 signature, the content of APK package is almost unchanged, and there will be no new file in META_INF. According to Google's official document, when signing with V2 signature scheme, an APK signature block will be inserted in the APK file, which is located before and after the central directory part of zip. In the APK signature block, the signature and signer identity information will be stored in the APK signature scheme v2 block to ensure that the whole APK file will not be modified, as shown in the following figure:
The signature of V 1 guarantees the integrity of the signature and information through three files in META-INF:
How does the signature of V 1 ensure the integrity of information? The signature of V 1 mainly includes three parts. If the signature and public key are narrowly defined, they are only used in the. Rsa file, three files signed by V 1 are actually a set of mechanisms, so we can't just say one.
If the resource file in APK is replaced, the summary of the resource must also be changed. If the information on the list. If MF is not modified, the verification of V 1 will fail during installation, so it cannot be installed. However, if the abstract values in the list. MF was modified at the same time that the file was tampered with, which is the verification of MANIFEST. MF can be bypassed.
A qualified SF is a bit like redundancy, more like a secondary guarantee of file integrity. It's like bypassing the MANIFEST. MF。 SF check can be easily bypassed.
Certified RSA and certificate. SF correspond to each other, and their names must have the same prefix. I don't know if it's a boring standard. Look at the contents of the certificate. RSA file:
Certified RSA files store information such as certificate public key, expiration date, issuer, encryption algorithm and so on. According to the public key and encryption algorithm, Android system can calculate the abstract information of CERT. SF, its strict format is as follows:
From the certificate. RSA, the fingerprint information of the certificate that we can obtain, is often used in WeChat sharing and third-party SDK applications. In fact, it is a signature of public key+developer information:
Except for the certificate. The RSA file and the other two signature files actually have nothing to do with the keystore, but mainly the abstraction and secondary abstraction of the file itself. List generated when signed by different keystores. MF is the same as CERT. The only difference is the certificate. RSA signature file. In other words, the first two mainly ensure the integrity of each file, and CERT. RSA guarantees the source and integrity of APK as a whole, but the file in META_INF is not within the scope of verification, which is also a shortcoming of V 1. How does V2 signature ensure the integrity of information?
As mentioned earlier, the file integrity in the V 1 signature can be easily bypassed. The significance of checking the integrity of a single file is not understandable, but installation takes time, so it is better to adopt a simpler and more convenient verification method. V2 signature does not check a single file, but checks APK, which is divided into 1M blocks, calculates the value of each block, then summarizes all the summaries, and then uses the summaries to sign.
That is to say, the abstract signature of V2 is divided into two levels. The first level is the 1, 3, 4 part of the APK file, and the second level is the abstract set of the first level, and then it is signed with the key. During installation, block summaries can be processed in parallel to improve the inspection speed.
APK is to digest first and then sign. Let's take a look at the definition of digest: Message Digest: Digest is a one-way hash of message data to generate a fixed-length hash value, which is the message digest. MD5 and SHA 1, which are often heard, are one of the summarization algorithms. Theoretically, there must be collisions in the abstract, but as long as the collision rate is low within a limited length, the integrity of the message can be guaranteed by using the abstract, and as long as the message is tampered with, the abstract will definitely change. But if the message and the digest are modified at the same time, there is no way to know.
And what is a digital signature (public key digital signature)? Using asymmetric encryption technology, the abstract is encrypted with private key to generate a string, which can be regarded as the digital signature of the message. For example, RSA is a commonly used asymmetric encryption algorithm. Without the private key, the asymmetric encryption algorithm can ensure that others cannot forge the signature, so the digital signature is also an effective proof of the authenticity of the sender's information. However, because the keystore certificate of Android is self-signed and there is no third-party authoritative authentication, users can generate the keystore themselves. Android signature scheme cannot guarantee that APK will not be signed twice.
After understanding the concepts of abstraction and signature, let's take a look at how the signature file of Android comes from. How to affect the original APK package? The command to sign APK through apksign in sdk is as follows:
It is mainly implemented in the folder of android/platform/tools/apksig. The main body is ApkSigner.java's sign function, which is relatively long and is analyzed in several steps.
Let's take a look at this step first. The function of ApkUtils.findZipSections is mainly to parse the APK file, get some simple information in ZIP format, and return a ZipSections.
ZipSections contains some information about the ZIP file format, such as the central directory information and the end information of the central directory. In contrast, the zip file format is as follows:
After obtaining the ZipSections, you can further parse the ZIP package APK and continue the following signing process.
As you can see, a V2 signature is checked first, which is used for signing here. Why do you want to check first? When signing for the first time, you will go directly to this abnormal logic branch, and the previous V2 signature can only be obtained when signing repeatedly. It is suspected that the purpose of obtaining V2 signature here should be to exclude V2 signature and obtain data blocks other than V2 signature, because the signature itself cannot be counted in the signature, and then you will parse the central directory area and build a DefaultApkSignerEngine for signature.
Firstly, the central directory area is parsed, the AndroidManifest file is obtained, minSdkVersion (Influence Signature Algorithm) is obtained, and the DefaultApkSignerEngine is constructed. By default, the signatures of V 1 V2 are all open.
The main tasks of the fifth and sixth steps are as follows: the preprocessing of apk, including the sorting of some directories, should aim at dealing with signatures more efficiently. After preprocessing, the signing process will be started, and V 1 will be signed first (it exists by default unless it is actively closed):
Steps 7, 8 and 9 can all be regarded as the processing logic of V 1 signature, which is mainly processed in V 1SchemeSigner, including creating some signature files under the META-INFO folder, updating the central directory, updating the end of the central directory and so on. The process is not complicated, so I won't repeat it here. The simple process is as follows:
Here, I'd like to mention the problem of duplicate signature: an APK that has been signed by V 1 will have no problem in re-signing. The principle is that when re-signing, the previous signature file will be excluded.
You can see directories, files in META-INF folders, files ending in sf, rsa and so on. Will not be signed by V 1, so there is no need to worry about multiple signatures here. The next step is to process the V2 signature.
V2SchemeSigner handles V2 signature, and the logic is clear. It directly abstracts the APK with V 1 signature in blocks, and then collects the signatures. V2 signature will not change any information after V 1. After signing, add a V2 signature block before the central directory and update the end information of the central directory, because the offset of the central directory will change again after V2 signing:
The process of signature verification can be regarded as the reverse process of signature, but the cover installation may have to verify the consistency of public key and certificate information, otherwise the cover installation will fail. The entrance of signature verification is in the installation of PackageManagerService, where official documents are installed. For mobile phones above 7.0, V2 signature should be detected first. If V2 signature does not exist, V 1 signature should be verified. For mobile phones below 7.0, there is no V2 signature verification mechanism, only V 1 can be verified. Therefore, if your application's Minisdkversion
The verification process is the opposite of signing. Just know the signature process. This article is not very detailed. I am interested in analyzing it myself. I just want to mention covering and covering. In addition to checking the integrity of APK, they also need to check whether the certificates are consistent. Only if the certificates are consistent (same keystore signature), it is possible to overwrite the upgrade. Compared with the newly installed one, the cover installation has several more inspections.
Only the certificate part is involved here:
On the Signature Principle of Android V 1 and V2
For reference only, please correct me.