Android 7The Impact of New Signature in .0 on Multi-channel Packaging Explained

The principle of old signature multi-channel packaging

Preface

due to Android7.0 released a new signing mechanism, which strengthened the signature reinforcement, resulting in the inability to continue creating multi-channel packages in the Meituan style under the new signing mechanism. However, when talking about the new signing mechanism's impact on packaging schemes
Before understanding the impact and why it affects our original packaging mechanism, we need to first understand the packaging principle and the role of signing in the entire packaging process.

Android packaging process

The Android packaging process is roughly as shown in the figure, the entire process is to integrate Java code, resource files, and third-party libraries into an APK file, and then sign and optimize the integrated files. The entire process can be briefly

The single process is divided into the following steps:

1. Resource pre-compilation: Generate an ID for each non-assert resource and save it in an R file.
2. Java file compilation: Compile the manually written Java files and the Java files generated in the previous steps into .class files
3. Dex file generation: Integrate the previously generated class files and third-party library class files into a .dex file, which is equivalent to the index table of all .class files, through which each .class file can be found
4. Resource file packaging: Optimize the size of the resources and include the configuration information of all resources with IDs in the resource.arsc file, which is equivalent to the index table of resources.
5. APK file generation: Integrate the previously generated .dex files, resource.arsc files, and resource files (res files, which contain some compiled binary files such as layout files, and some uncompiled binary files such as images), and files without assigned IDs (assert files) into an APK file (a special .zip file).
6. Signing: Sign the generated APK to add a unique identifier, thus ensuring that it can be installed and overlaid normally, and will not be maliciously overlaid, as well as to indicate the source and owner of the APK.
7. Alignment processing: Adjust the binary position of some resources in the APK to speed up the running speed of the APK.

The steps for generating APK are roughly like this, we don't need to worry about some details of the implementation, just understanding these processes can help us understand the principle of our packaging scheme. Of course, it may seem like APK

It is a very magical file that can be installed and run. In fact, APK is just a special .zip file, but it can be recognized and installed as an application by our Android machine. We can unzip the APK file to see its contents.

As can be seen, the file content is basically consistent with what we mentioned before. Next, let's take a look at the most important folder, which is the file in Chapter 3 of the figure, all these files are in the META-In the INF folder, this is the file we add during the signing process as the unique identifier for the APK. What does this mean for our packaging optimization? Let's leave that as a suspense and discuss it later. Before understanding this, we must first clarify the matter of signing.

签名的作用和原理

The role and principle of signing

The role of signing
Apps may add some of their own content inside, such as embedded advertisements for profit, and then release the tampered App for users to cover and install. We might suffer significant losses. Of course, such things will not happen. Google has added a signing mechanism for each App, just like when we go to a bank to handle business, we not only need to provide our ID card but also sign our name and押金. The ID number is visible to everyone, but the signature and押金 can only be done by ourselves, and others cannot imitate it. Apps ensure their uniqueness and security through this mechanism. The Android App has a unique identifier during development, which we call the package name, such as the package name of the large client is com.Quanr. The package name is like an ID card number, which corresponds to each person one by one. When installing the App, the machine also identifies the application through the package name. There cannot be two applications with the same package name in one machine, which is the uniqueness of the App in the machine. When we upgrade the App, such as cover installation, it is identified and matched through the package name to ensure that the App can be upgraded smoothly without overwriting other Apps. Similarly, other Apps with different package names cannot overwrite our App. Although Android provides a package name identification mechanism, can only the package name be enough? Imagine if someone uses our package name to create a new App to cover our App or if criminals crack our

So, how does signing achieve these things?

The principle of signing

There are several tools for signing APKs, but their principles are more or less the same. Here, let's take the signapk tool as an example. To sign an APK, you just need to use this tool with some parameters and our unique signature file, which can be done directly using the tool. It is very simple to use the tool for signing, but what we need to pay more attention to is its principle and specific implementation, so that we can find the secret of tampering with channel packages from it. Before using the signing tool, we must prepare the private key and public key needed for signing (a–(private key)–>b–(public key)–>a), and then use the signing tool to sign the APK. After that, the signature process will create a new META inside the APK.-Generate three files inside the INF folder, which are the key to signing and the basis for verification.

From the picture, we can see that the three files are as follows:

1. MANIFEST.MF
2. CERT.RSA
3. CERT.SF
   

Next, let's talk about how these three files are generated.

MANIFEST.MF

Let's take a look at its content, and we can see that it is a SHA corresponding to the Name1The value is easy to know that this file saves a unique value corresponding to each file. The function of the MANIFEST.MF file is as described earlier, when signing the APK, it will first perform digital encoding on each file to generate a unique SHA1The value, different file content corresponds to different SHA1The value is also different, so if someone tampered with the file content, then the corresponding SHA1The value will also change. When signing the APK, check each of your files and generate the corresponding SHA1These contents are all saved in a newly created MANIFEST.MF file and placed in the META-After completing the first signature file generation under the INF directory, the first signature file is generated.

CERT.SF

After generating a MANIFEST.MF file, we can record the unique value of each file, thus ensuring that the file is not tampered with. Although this ensures the security of the files recorded in the MANIFEST, it cannot ensure the security of the MANIFEST itself. Others can still modify the original file and generate the corresponding SHA1Then modify the MANIFEST file, so we still need to strengthen the MANIFEST to ensure security. After the first file is generated, the signature tool starts generating the second file, which is CERT.RSA. In this step, the file generated in the previous step is digitally encoded again, and the result is saved in the header of the newly generated CERT.RSA file. Then, the digital encoding of each attribute block in the MANIFEST.MF file is performed again, and the result is stored in an attribute block of the CERT.SF file.

CERT.RSA

These files are all binary. After generating the CERT.SF file, we use the private key to encrypt the CERT.SF and calculate the signature, save the obtained signature and the public key certificate information together in CERT.RSA, and the entire signing process is completed.

Below is a simple description of the verification steps in the Apk installation process, which is actually similar to the steps for generating signature files:

1. First, check that the digital encoding of all files in the Apk is consistent with the digital encoding in MANIFEST.MF
2. Verify whether the signature information of the CERT.SF file is consistent with the content of CERT.RSA
3. The entire file signature of MANIFEST.MF is whether it matches the header attribute value in the CERT.SF file and whether the signature of each attribute block in the MANIFEST.MF file matches in the CERT.SF file

From the above process, it can be clearly seen that there has never been any digital encoding of the META-Any file in the INF folder is digitally encoded and encrypted because this folder is generated during the signing process. When the first file MANIFEST.MF was generated, no digital encoding was performed on any files in this folder because it must be empty. The second file is generated based on the first file, and the third file is generated based on the second file, so throughout the process, this META-INF folder is almost out of control. We can add some files to avoid the signature process. This is the breakthrough point of Meituan's multi-channel package scheme.

Meituan completes multi-channel packaging by taking advantage of the signature principle

By understanding the previous packaging process, we can know that to quickly generate multi-channel packages, we need to skip the packaging stage and directly find a way to modify the Apk file, but this needs to challenge the Android signature verification rules. However, just as we analyzed the signing process, we found that we can modify the Apk file in the META-INF folder arbitrarily add files to avoid the signature rule check, at this time, the new scheme is born, after packaging a generated Apk file without channels, we copy this Apk and in the META-INF to add a file, and then determine the channel number through the file name. Different Apk files are in the META-INF to add different channel name files, and you can determine different channels. After that, what we need to do is to directly go to this file when we need channel parameters, which perfectly skips the packaging process. Then, how long does this scheme take? It's just based on the Apk file to copy and insert a file, and such actions can be done in one minute on a high-end computer900 times. So, at this time, it takes4minutes, to print100 channel packages also only need four minutes and a little extra, of course, this is not the limit, if there is900 channels, each channel package needs to be packed one by one900x4minutes, the Meituan scheme only needs5minutes, which improved the efficiency by several hundred times, so the Meituan scheme is very perfect under the old signing.

Impact of the new signing method on the existing scheme

In Android 7After .0, Google adopted new signing verification rules to enhance the security of signing, which is not for each file to perform digital encoding, as shown in the figure:

The new signing method is to sign based on the zip file structure, and the Apk file is essentially a .zip file. As shown in the figure, it can be divided into three parts before signing.

1. Compressed file entity data Contains all specific data of elements
2. Core directory data Contains the relative offset of all metadata
3. Directory end marker Contains the offset position of directory data and related directory detail records

In the figure below, the blue part represents the Contents of ZIP entries, and the pink part represents the Central Directory.

File Entry represents a file entity, and a compressed file contains multiple file entities.

A file entity consists of a header and file data (compressed, the compression algorithm is described in the header)

The Central Directory is composed of multiple File headers, each of which saves the offset of a file entity

The file ends with a structure called End of central directory.

Let's take a look at the role of End of Central Directory, which records the offset position of the Central Directory relative to the header. Take a look at our new signature data Apk Signing Block, which is placed between the Contents of ZIP entries and the Central Directory. It is a unique data generated by encoding and signing all the contents of the three modules of the unsigned ZIP file. It can be understood according to the numerical encoding mentioned earlier. If any content in these three blocks changes, the data generated by this block will be inconsistent. Therefore, it is impossible to modify any content of the Apk after signing. However, we haven't modified the content outside the Apk signature before, so at this point, isn't it worth considering modifying the content of the Apk Signing Block? We will add a small tail at the end. It is obvious that this method is also not feasible. As mentioned earlier, there is a part called End of Central Direcotry, which records the offset of the Central Direcotry relative to the starting position of the ZIP file. The APK Signing Block is exactly in front of the Central Direcotry. If the length of the APK Signing Block is changed, the offset of the Central Direcotry relative to the header will change, and the content will be inconsistent with the record in the End of Central Directory, and the entire Apk package will be destroyed. So can we modify this offset? Clearly not, after modifying this offset, the APK Signing Block will also change, and only the developer who has the signature file can get the correct APK Signing Block data. Those who want to tamper with it can only sigh in vain. This is the principle of the new signing mechanism. Under this new mechanism, our old signature may need to be appropriately modified.

The approach to improving the plan

As mentioned earlier, our new packaging plan will again be at a disadvantage under the new signing mechanism (of course, if you still use the old signature, then you don't need to consider this problem), but Google has a good plan, and we have a way to climb over the wall~

As mentioned before, there are several ways to add channel packages:

1. Directly modify the code, modify the code for one channel package at a time, and then package it
2. Do not directly modify the code, release a channel parameter to dynamically change before packaging and then re-package
3. Modify the completed packaging file and add the channel number by skipping the signature verification
4. Now these three methods are not working, it doesn't matter, we still have the fourth one.
   

It has been analyzed before that if any module content of the zip file is modified, the APK Signing Block will change, thus unable to bypass the signature mechanism.

However, this is not a problem, the signature mechanism is just to ensure the security of our Apk, we obviously don't want to maliciously tamper with the App, we are developers, holding the private key and public key of the signature file, since the signature mechanism cannot be bypassed, then we can directly modify the Apk package and re-sign it. Although this is not as efficient as bypassing the signature mechanism, but compared with the several minutes of packaging process, these time is acceptable. Generally, re-signing takes about three or four seconds, which is obviously acceptable and can continue to be used compared to our four-minute packaging process.

Of course, this is just a scheme based on our signature mechanism, before that, we analyzed the entire process and mechanism of packaging and signing, and maybe there are better ways to mine from it, which requires us to think collectively. Carefully analyze and think about these processes and principles, and maybe you can find a better solution to continue to optimize our packaging plan~

Summary

That's all about Android7.0 new signature affects all the content of multi-channel packaging17238;, hoping that the content of this article can bring some help to Android developers, and everyone can leave a message for communication if there are any doubts

Declaration: The content of this article is from the Internet, the copyright belongs to the original author, the content is contributed and uploaded by Internet users spontaneously, this website does not own the copyright, does not undergo manual editing, and does not bear relevant legal liabilities. If you find any content suspected of copyright infringement, please send an email to: notice#w3Please send an email to codebox.com (replace # with @ when sending emails) to report violations, and provide relevant evidence. Once verified, this site will immediately delete the content suspected of infringement.