Learn about the reverse analysis and protection mechanism of Android app

"Knowledge by learning" is the NetEase Cloud Yi Shield to create a brand column, the word from the Han Wang Chong "on the value of". People, the ability to compete against the points, learning to know the truth of things, and then only wisdom, not to ask will not know. "Knowledge by learning" hope that through a technical dry, trend interpretation, character thinking and precipitation to bring you the harvest at the same time, but also hope to open your horizons, the achievement of different you.

The following is the text of the article:

Want to know the common protection methods of Android apps and their corresponding reverse analysis methods?

Jong Yaping, senior security engineer of NetEase Cloud Yi Shield

March 17, the Android Bus Global Developer Forum was held in Chongqing, NetEase senior security engineer Jong Yaping attended the exchange activities, and did "Android app reverse and protection" speech. In the sharing, he introduced the common protection method of Android app and its corresponding inverse analysis method, and analyzed the common reinforcement scheme principle and countermeasure method.

Android app security contains a lot of content, this time sharing the confusion code, the overall DEX reinforcement, split Dex reinforcement, virtual machine hardening and so on. In fact, these are also a major trend in the security of Android apps in China in recent years.

first, confusing the code

Java code is very easy to decompile, as a cross-platform, interpreted language, Java source code is compiled into the intermediate "bytecode" stored in the class file. Because of the cross-platform needs, these bytecode with a lot of semantic information, it is easy to decompile the Java source code. To protect Java source code Well, developers often confuse the compiled class file.

Confusion is the re-organization and processing of the published program, so that the processed code and the pre-processing code to complete the same function, and the confusing code is difficult to decompile, even if the anti-compilation success is difficult to derive the true semantics of the program. Proguard is an open source project that confuses code, and can confuse bytecode, reduce volume, optimize, and so on.

The Proguard processing flowchart is shown below with four main links for compression, optimization, obfuscation, and preflight:

Compression (Shrink): Detects and removes useless classes, fields, methods, and features in code (ATTRIBUTE);
Optimization (Optimize): The bytecode is optimized to remove useless instructions. Optimization code, non-Ingress node class will be added private/static/final, unused parameters will be deleted, some methods may become inline code;
Obfuscation (obfuscate): Renaming classes, fields, and methods with A, B, C, D, and a short, meaningless name;
Preflight (Preveirfy): The processed code is pre-checked on the Java platform to ensure that the loaded class file is executable.

In sharing, Jong Yaping shows an example of an apk effect that uses Proguard to decompile the Dex2jar:

Proguard after processing

The Proguard obfuscation not only protects the code, but also streamlines the compiled program size and reduces memory consumption.

Obfuscation code Reverse analysis

If you want to decompile the obfuscation code, Jong Yaping shares a foreign tool deguadr, which can be confused by statistical means. Although the accuracy of this tool is less than 100%, it can help decompile the code to some extent.

Examples of confusion using the Deguadr solution:

The Com.xxxxx.common.util.CryptoUtil Web site also provides an anti-build service, as follows:

java.lang.String a(byte[]) -> encodeToString

java. lang. String a(byte[],boolean,java. lang. String) -> a

byte [] a(byte[],byte[]) -> encrypt

byte [] b(byte[]) -> getKey

byte [] b(byte[],byte[]) -> Decrypt

byte [] D(java. lang. String) -> getKey

java. lang. String a(byte,char[]) -> a

java. lang. String a(java. Io. File) -> gethash

java. lang. String a(java. lang. String) -> C

java. lang. String b(java. lang. String) -> encode

second, the overall Dex reinforcement

In order to strengthen the protection strength of Android, with the development of security technology, there is a new type of "strengthening technology". Dex Hardening is to add shell protection to the Dex file, to prevent the static anti-compilation tool to crack and leak the source code, the first appearance is the overall reinforcement technology solution.

The principle of the integral reinforcement technique is as shown above, including replacing Application/classes.dex, decrypting/dynamically loading the original Classes.dex, invoking the original application related method, and application the original object/ The name is set to the four related variables within the system. One of the most critical steps is to decrypt/ Dynamic loading of the original Classes.dex, by encrypting the compiled final Dex source file, and then in a new project with the new Project application start to decrypt the original project code and load into memory, and then replace the current process with the decrypted code, can be good to hide the source and prevent direct anti-compilation.

Inverse analysis of overall DEX reinforcement

There are two common methods for the inverse analysis of overall DEX reinforcement. One is in-memory brute-force search dex\n035, and then dump. The following are examples of effects in a 32-bit system:

Another approach is through hookdvmdexfileopenpartial (void* addr, int len, dvmdex**).

third, split Dex reinforcement

With the scale of business to a certain extent, and constantly add new features, adding new class library, code in the rapid expansion of the same time, the corresponding APK package size also increased sharply, then the simple overall reinforcement scheme can not be well meet the security requirements, in addition to the overall reinforcement scheme, there is a split reinforcement technology solution.

However, as shown above, when the Dex file is hardened, a portion of the data that is missing in the middle is replaced with the decrypted data, and sometimes this split substitution can result in inaccurate data. So what kind of data should be split? You need to know the data structure of the Dex file.

The Dex file structure is extremely complex, which is a great choice for selecting the most important content. In fact, the Dex file is a class-centric assembly of files, the most important of which is the Classdata and Classcode two parts, with its specific interface and instruction data, select the two parts to split, even if the split will not reveal the class data and bytecode data, Anti-compilation is not complete, security is high.

split Dex to reinforce reverse analysis

For the inverse analysis of Dex split hardening, as shown below, the classdata can be replaced and assembled into a new Dex file, although not exactly the same as the original Dex file, but also to some extent the appearance of the split data is restored.

However, it is important to note that this method is only applicable to the split data deformation one-time completion, that is, in the case of other protection ideas to avoid the use of, and even if it is necessary to choose to use this class to recover.

There is also a lower level of tools dexhunter, this tool is more avant-garde, but also some limitations, such as some of the instruction data will be optimized, the formation of the Code interface is not very beautiful and so on.

iv. consolidation of virtual machines

Virtual machine hardening is also part of Dex's split hardening, which deals with some changes to bytes. As shown below, this is a code in a normal Android system where virtual machine hardening is done:

With Add-int V0, V1, v2, Sub-int v0, V1, v2, Mul-int v0, V1, v2 These three instructions are replaced and then hardened and compiled, this way, even if the replacement data is restored, it will not be add-int V0, V1, v2, Sub -int V0, V1, v2, Mul-int v0, V1, v2 These three instructions to replace, and then to strengthen the compilation, this way, even after the replacement of the data restored, will not be formed into the previous bytecode, a higher safety factor.

Virtual Machine Hardening Reverse Analysis-hook JNI interface

In this way, the reverse analysis, on the one hand can be implemented by Hook JNI interface, it has two implementation methods.

One is the class member/static variable operation related interface, for example:

Getstaticdoublefieldsetstaticdoublefield Getdoublefield Setdoublefield ...
(Byte, object, Int,long ...)

The second is the reflection call class method, for example:

Callvoidmethodacallbooleanmethoda Callshortmethoda Callobjectmethoda ...
Callstaticvoidmethodacallstaticbooleanmethoda Callstaticshortmethoda Callstaticobjectmethoda ...
(Byte, int, long,double ...)
Callobjectmethoda (jnienv* env, Jobject object, Jmethoid method, ...)

Virtual machine reinforcement Reverse analysis via HOOKJNI interface

By using the Hook JNI interface, you can understand the app's approximate invocation process without having to reverse the underlying. However, for complex invocation procedures, or a large number of virtualization methods, this method of reverse analysis seems to be confusing, for instructions that do not need to be returned to the Java layer, such as arithmetic, logic operations, etc., cannot be monitored.

Virtual Machine Hardening Reverse analysis-analysis instruction opcode mapping

On the other hand, it is possible to analyze the instruction opcode mapping to reverse the analysis. In the same hardening version, or with the same mapping relationship, you can take the following method:

However, in the actual situation, the mapping relationship of each reinforcement is random, as shown below, it is not possible to directly establish a mapping relationship.

The mapping relationship that does not depend on opcode is only related to the structure of the virtual machine, so it is necessary to establish a mapping relationship based on the offset relationship for reverse analysis.

The above is the "Android app reverse and protection" theme of all the share content.

As an important part of the development work, the reverse protection of Android app has been the application service that NetEase Cloud Shield is committed to providing. "In the future, we will conduct a more in-depth study of so cryptographic protection. "Jong Yaping finally said.

* This article netease Cloud Yi Shield , from freebuf.com

Learn about the reverse analysis and protection mechanism of Android app