As we all know, during the process of installing Apk, the Android system will perform signature verification on the Apk. Only after the verification passes can the installation be successful. So do you know what the signature verification mechanism is? What is the specific content being verified? What is the SAH1 value filled in when applying for a third-party SDK (such as WeChat Pay)? How do the many current rapid batch packaging solutions bypass signature verification?

I will solve these doubts through a series of articles:

This article first introduces the basic knowledge related to Apk signature.

To know what a signature is, let’s first look at why a signature is needed. As we all know, when communicating messages, at least two problems must be solved: one is to ensure the authenticity of the source of the message, and the other is to ensure that the message will not be tampered with by a third party. When installing an Apk, you also need to ensure the authenticity of the source of the Apk and that the Apk has not been tampered with by a third party. How to solve these two problems? The method is for the developer to sign the Apk: write a "fingerprint" in the Apk. After the fingerprint is written, any modification in the Apk will cause the fingerprint to be invalid. The Android system will fail the signature verification when installing the Apk, thus ensuring security.

To understand how to implement a signature, you need to understand two basic concepts: digital digests and digital certificates.

To put it simply, after calculating a data of any length through a Hash algorithm, a fixed-length binary data can be obtained. This data is called "summary". The abstract has the following characteristics:

As mentioned earlier, signatures can be used to ensure the reliability of the data source and the non-tamperability of the data. The signature is encrypted on the basis of the digest. The encrypted data of the digest can be used as a digital signature. When installing the Apk, the signature needs to be verified. If the verification is passed, the installation can continue.

There are two processes here: the signature process and the verification process.

Let’s talk about the signature process first:

Let’s look at the verification process:

There is a premise here: the receiver must know the sender’s public key and all algorithm used. If the digital signature and the public key are tampered with, the recipient cannot know and the verification will still pass. How to ensure the reliability of the public key? The answer is a digital certificate. The digital certificate is issued by the Certificate Authority and contains the following information:

After receiving the message, the recipient first verifies the legitimacy of the certificate with the CA (according to the signature of the certificate , bound domain name and other information. The CA organization is authoritative and can ensure the reliability of this process) and then perform signature verification.

It should be noted that Apk certificates are usually self-signed, that is, they are made by the developer themselves and do not apply to the CA organization. When Android installs the Apk, it does not verify the legitimacy of the certificate itself. It only extracts the public key and encryption algorithm from the certificate. This is why after re-signing the third-party Apk, it can continue to operate on systems that do not have the Apk installed. Reason for installation.

When we sign the Apk, we do not directly specify the private key, public key and digital certificate, but use the keystore file. This information is included in the keystore file. There are many types of keystore files based on different encodings. Android uses the Java standard keystore format JKS (Java Key Storage), so the keystore file exported through Android Studio ends with .jks.

The certificate standard used by keystore is X.509. The X.509 standard also has multiple encoding formats. There are two commonly used ones: pem (Privacy Enhanced Mail) and der (Distinguished Encoding Rules). jks uses the der format, and Android also supports direct use of pem format certificates for signing, which we will introduce below.

The difference between the two certificate encoding formats:

X.509 certificate format:

Android provides two methods for Apk Signature methods, one is based on JAR and the other is based on Apk. The main difference between them is that the signature files used are different: jarsigner uses keystore files for signing; apksigner supports using keystore files for signing. , also supports directly specifying the pem certificate file and private key for signing.

I don’t know if you have noticed a problem. When we generate a keystore through keytool or AS (sign your application), in addition to the keystore password, you also need to enter an alias and key password. . When signing, in addition to specifying the keystore file and password, the password for alias and key must also be specified. Why is this?

The reason is that keystore is a keystore, which means that it can store multiple pairs of keys and certificates. The password of the keystore is used to protect the keystore itself. A pair of keys and certificates are obtained through alias. differentiated. It can be seen from here that jarsigner supports using multiple certificates to sign Apk. apksigner is also supported. For introduction to the use of apksigner, please refer to the official document apksigner.

Ok, the basic concept of signature and verification process are introduced here. For a detailed introduction of JAR signature and V2 signature mechanism, please refer to the following two articles: