Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to understand the APK packaging process and signature security mechanism. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

0x00, what are we talking about today?

What are we talking about today? Long time no see, it's time to talk about something. Without saying much, let's first talk about the reverse road of Hu Xiaomao's Android. Of course, what you want to know must not have come such a long way, so let's take a look at the new zishi he has come to again. (this article is a summary of MaoXH, Xi Da Pengpu, Hu Xiaomao's new id:MaoXH).

0x01, to the point, apk file structure

To get to the point, Hu Xiaomao made a summary in the process of learning the reverse of Android. Let's first take a look at the apk file structure:

First of all, take a general app to explain, open with zip compressed file will appear the following folder:

The Assets directory is used to store static resource files that need to be packaged into Android applications, such as picture resource files, JSON configuration files, channel configuration files, binary data files, HTML5 offline resource files, and so on. Unlike the res/raw directory, the assets directory supports subdirectories of any depth, and the files under that directory do not generate the resource ID.

The Lib directory stores the so dynamic link library files used by the current app, and the so file is realized by using the underlying c and C++ code.

The META-INF directory holds the certificate signature files used, including: MANIFEST.MF (summary file), CERT.SF, and CERT.RSA. The MANIFEST.MF file is the SHA-256-Digest;CERT.SF of each file and the first three lines of each file are SHA-256-Digest;CERT.RSA. This file saves the signature and public key certificate.

The Res directory puts the resource files of the application, including image resources, string resources, color resources, size resources, etc., and the resources under this directory will appear in the index of the resource manifest file R.java.

The system manifest file of the AndroidManifest.xml:Android project, and the four major components of the Android application (Activity, Service, BroadcastReceiver and ContentProvider) are configured and declared here.

Classes.dex: the executable file of the application. If the APP has more than one dex, it is because the current number of methods exceeds 65535 and has been subcontracted. If not exceeded, there is only one dex. All the code for Android is concentrated here. You can convert it to a jar package through the decompiler dex2jar, and then view its code through jd-gui.

Resources.arsc: a resource index table that describes the configuration information of a resource with an ID value.

0x02, start the drama, apk packaging process

After reading the above apk file structure, I am about to start our real play, first of all, "waiter, above picture ~, long picture ~"

Don't worry, it's not a meme.

The figure above is a detailed packaging process of apk package, including the tools that may be used in each refinement process. You can pay more attention to the orange font part. Then let's take a look at the following directories involved in the application installation:

System/app-the application that comes with the system, which can only be deleted with adb root permission

Data/app-the directory where the user program is installed. Copy the apk file to this directory during installation

Data/data-holds the data of the application

Data/dalvik-cache- installs the dex file from apk into the dalvik-cache directory (the dex file is the executable of the dalvik virtual machine and its size is about 1/4 of the original apk file size)

The installation process is as follows:

Copy the APK installation package to the data/app directory, extract and scan the installation package, save the dex file (Dalvik bytecode) to the dalvik-cache directory, and create the corresponding application data directory in the data/data directory.

The corresponding uninstallation process is:

Delete the files and directories created in the above three directories during installation.

0x03, real ING, virtual machine

If you have something to say, there is nothing to mention the virtual machine. Hu Xiaomao also made me dizzy. Don't panic. Take a closer look. I found that Xiao Mao's learning ideas are still noteworthy. The dalvik virtual machine mentioned above may not have attracted the attention of the viewers, so let's talk about it again.

The first is the java virtual machine, we know that a very important feature of the Java language is that "cross-platform" can achieve the effect of "compile once, run everywhere". How can we have such a characteristic? Mainly rely on the java virtual machine (JVM). When we write a java program, such as test.java. It is then compiled into a bytecode file test.class. By running the bytecode file on the java virtual machine, the java virtual machine can interpret the bytecode file as the execution of machine instructions on a specific platform, thus realizing the cross-platform characteristics of java.

Then we need to know that Android is based on a Dalvik virtual machine (DVM) or an art virtual machine (aot mechanism). The Dalvik virtual machine is mainly used in Android5.0 and before, while the ART (Android Runtime) virtual machine is released by Android 4.4 to replace the Dalvik virtual machine. Android 4.4 defaults to DVM, but you can choose to use ART. In Android version 5. 0, ART,DVM is used by default to withdraw from the stage of history.

For more information, please see https://www.jianshu.com/p/a37d3be0a341.

For the relationship among JDM, DVM and ART, please refer to the following figure:

0x04, knowledge extension, Android signature mechanism remember the META-INF directory mentioned earlier? Apk signature certificate file is generated during the signing process, apk signature process can be summarized as follows: 1, each file in Apk to do an algorithm (data SHA1 abstract + Base64 encoding), saved to the MANIFEST.MF file, specific approach can be understood as the program traverses all files in the APK package, non-directory, non-signature files, one by one with SHA1 to generate summary information, and then use Base64 for encoding after saving. The security mechanism based on this file can check the file integrity: if the file of the APK package is modified, during the APK installation check, the modified file is different from the MANIFEST.MF check information, the program will not be installed normally, in the same way CERT.SF and CERT.RSA files are also applied to the apk integrity check. MANIFEST.MF file format is as follows: 2, the entire MANIFEST.MF file to do an algorithm (data SHA1 summary + Base64 encoding), stored in the CERT.SF file header attributes, and then each attribute block in the MANIFEST.MF file to do an algorithm (data SHA1 summary + Base64 coding), saved to an attribute block. The format of the CERT.SF file is as follows: 3. Sign the CERT.SF file and save the content to CERT.RSA, so CERT.RSA is an encrypted file, so it looks ugly. If you don't believe it, read it for yourself:

After understanding the signature process of the above apk, we can think deeply about the following passage (the original words of a great god):

If we are illegal and want to tamper with apk content, what do we do? If we only change the original file (such as adding our own virus code), then after repackaging, the system will think that the inconsistency between the file's SHA1- Base64 value and MF leads to installation failure. In that case, why don't we change the MF to make them consistent? If only this is the case, then the system will find that the SHA1-Base64 of the contents of the MF file is inconsistent with SF, or the installation will fail. In this case, why don't we change the consistency between SF and MF? If you do so, the system will find that the decrypted value of RSA is inconsistent with the SHA1 of SF, and the installation fails. Well, it would be nice for us to make the encrypted value consistent with the SHA1 of SF, but this is used to sign and encrypt the private key, and the public key is played freely, but we don't have the private key, so we can't be consistent. So the above process is interlinked, and finally points to the guarantee of RSA asymmetric encryption.

Finally, we must know that the signature mechanism only ensures the integrity of apk, and the system does not know whether it is its own apk package, so for the above integrity verification through apk signature, attackers can bypass the verification by directly resigning so that all the information is consistent, so that it can be installed after re-signature. So whether the application signature has been tampered with or not is another subject of knowledge.

How to understand the APK packaging process and signature security mechanism is shared here. I hope the above content can be helpful to everyone and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.