Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about the reverse analysis and protection mechanism of Android APP. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

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

Android APP security contains a lot of content, this time shared confusing code, overall Dex hardening, split Dex hardening, virtual machine hardening and so on. In fact, these contents are also a major trend of Android App security protection in China in recent years.

First, confuse the code

Java code is very easy to decompile, and as a cross-platform, interpreted language, Java source code is compiled into intermediate "bytecode" and stored in class files. Due to the need for cross-platform, these bytecodes carry a lot of semantic information and can be easily decompiled into Java source code. In order to protect Java source code well, developers often confuse compiled class files.

Confusion is to reorganize and process the released program, so that the processed code can complete the same function as the pre-processing code, and the confused code is difficult to be decompiled, even if the decompilation is successful, it is difficult to get the true semantics of the program. ProGuard is an open source project that confuses code, capable of confusing, reducing size, optimizing, and so on.

The flow chart of Proguard processing is shown below, which includes four main steps: compression, optimization, confusion and pre-inspection.

Shrink: detects and removes useless classes, fields, methods, and features from code (Attribute)

Optimize: optimizes bytecode to remove useless instructions. Optimize the code, non-entry node classes will add private/static/final, unused parameters will be deleted, and some methods may become inline code

Obfuscate: renaming classes, fields, and methods using short, meaningless names such as a, b, c, d

Preveirfy: prechecks the processed code on the Java platform to ensure that the loaded class file is executable.

In sharing, Zhong Yaping shows an example of the Apk effect of decompiling Dex2jar with Proguard:

After Proguard processing

Proguard obfuscator can not only protect the code, but also reduce the size of the compiled program and reduce the memory consumption.

Reverse analysis of obfuscation code

If you want to decompile and confuse the code, Zhong Yaping shares a foreign tool, DEGUADR, which can solve the confusion in a statistical way. Although the correct rate of this tool is less than 100%, it can help decompile the code to some extent.

An example of using DEGUADR to resolve confusion:

The com.xxxxx.common.util.CryptoUtil website also provides a decompilation service, as follows:

Java.lang.String a (byte [])-> encodeToStringjava.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 II. Integral Dex reinforcement

In order to strengthen the strength of Android protection, with the development of safety technology, a new type of "reinforcement technology" appears. DEX reinforcement is a shell protection for DEX files to prevent the source code from being cracked by static decompilation tools. The first thing that appears is the overall reinforcement technology.

The principle of the integral reinforcement technology is shown above, including replacing application/classes.dex, decrypting / dynamically loading the original classes.dex, calling the original application related methods, and setting the original application object / name to the relevant variables within the system. The most critical step is to decrypt / dynamically load the original classes.dex, encrypt the compiled final dex source file, then use the application startup of the new project to decrypt the original project code and load it into memory, and then replace the current process with the decrypted code, which can hide the source code and prevent direct decompilation.

Reverse analysis of integral Dex reinforcement

There are two common methods for reverse analysis of integral Dex reinforcement. One is to violently search dex\ n035 in memory, and then dump. The following is an example of the effect on a 32-bit system:

Another way is through HookdvmDexFileOpenPartial (void* addr, int len, DvmDex**).

Third, split Dex reinforcement

As the business scale develops to a certain extent, new functions and class libraries are constantly added, while the code expands rapidly, the size of the corresponding apk package also increases sharply, so the simple overall reinforcement scheme can not meet the security requirements well, and there is a split reinforcement technical scheme in addition to the overall reinforcement scheme.

However, as shown above, when dex files are reinforced, some of the data missing in the middle will be replaced with decrypted data, and sometimes this split replacement will also lead to inaccurate data. So what kind of data should be split? You need to understand the data structure of the dex file.

The Dex file structure is extremely complex, and the following illustration selects the more important contents. In fact, the dex file is a file assembled with class as the core, the most important of which are classdata and classcode, which have their specific interfaces and instruction data. If you choose to split these two parts, they will not disclose class data and bytecode data even if they are split, and decompiled out of them will not be complete and secure.

Reverse analysis of split Dex reinforcement

For the reverse analysis of dex split reinforcement, as shown below, you can use classdata replacement to assemble a new dex file, which is not exactly the same as the original dex file, but also restores the appearance of the split data to some extent.

It should be noted, however, that this method is only suitable for the split data deformation to be completed at one time, that is, to avoid using it as far as possible when there are other protection ideas. and try to restore it when this class is used even if necessary.

In addition, there is a lower-level tool, dexhunter, which is more avant-garde, but also has some limitations, such as some instruction data will be optimized, the resulting code interface is not very beautiful, and so on.

IV. Virtual machine reinforcement

Virtual machine hardening is also a kind of dex split hardening, which makes some changes to the bytes. As shown below, this is the code from a normal Android system in which virtual machine hardening is performed:

Replace with add-int v0, v1, v2, sub-int v0, v1, v2, mul-int v0, v1, v2, and then consolidate and compile. After this operation, even if the replaced data is restored, it will not be replaced with add-int v0, v1, v2, sub-int v0, v1, v2, mul-int v0, v1, v2, and then reinforced compilation. Even if the replaced data is restored, it will not be transformed into the previous bytecode, and the safety factor is higher.

Virtual machine hardened reverse analysis-HOOK JNI interface

Reverse analysis in this way, on the one hand, can be realized through the HOOK JNI interface, it has two ways of implementation.

One is the interface related to class member / static variable operation, such as:

GetStaticDoubleFieldSetStaticDoubleField GetDoubleField SetDoubleField...

(byte, object, int,long...)

The second is reflection calling class methods, such as:

CallVoidMethodACallBooleanMethodA CallShortMethodA CallObjectMethodA...

CallStaticVoidMethodACallStaticBooleanMethodA CallStaticShortMethodA CallStaticObjectMethodA...

(byte, int, long,double...)

CallObjectMethodA (JNIEnv* env, jobject object, jmethoID method, …)

Implementation of virtual machine hardening reverse analysis through HOOKJNI interface

Through the HOOK JNI interface, you can understand the general invocation process of APP without reversing the underlying layer. However, for complex calling procedures, or for a large number of virtualization methods, this reverse analysis method looks confusing; instructions that do not need to be sent back to the Java layer, such as arithmetic, logical operations, and so on, cannot be monitored.

Virtual machine hardening reverse analysis-analysis instruction opcode mapping

On the other hand, it can also be reverse analyzed by analyzing the instruction opcode mapping. In the case of the same hardened version, or the same mapping relationship, you can take the following approach:

However, in the actual situation, the mapping relationship during each reinforcement is random, as shown below, in which case it is impossible to establish the mapping relationship directly.

The mapping relationship which does not depend on the opcode is only related to the structure of the virtual machine, so it is necessary to establish the mapping relationship according to the offset relationship, so as to carry out reverse analysis.

The above is the Android APP reverse analysis and protection mechanism shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.