What is the reverse analysis and protection mechanism of Android APP?

Want to know the common protection methods for Android Apps and their corresponding reverse analysis methods?

In this sharing, multiple aspects of Android APP security are discussed, including obfuscated code, overall Dex reinforcement, split Dex reinforcement and virtual machine reinforcement. These contents have become a major trend in Android App security protection in China in recent years.

1. Obfuscated code

Java code is very easy to decompile. As a cross-platform, interpreted language, Java source code is compiled into intermediate "bytecode" and stored in class file. Due to the need to be cross-platform, these bytecodes contain a large amount of semantic information and are easily decompiled into Java source code. Developers often obfuscate compiled class files to better protect Java source code.

Obfuscation is to reorganize and process the released program so that the processed code completes the same function as the pre-processed code. The obfuscated code is difficult to decompile, even if the decompilation is successful, it will be very difficult. It is difficult to figure out the true semantics of the program. ProGuard is an open source project that can obfuscate, reduce and optimize bytecode.

The Proguard processing flow chart is shown below, including four main links: compression, optimization, obfuscation, and pre-checking:

Compression (Shrink): Detect and remove useless classes, fields, methods and attributes (Attribute) in the code;

Optimize (Optimize): Optimize the bytecode and remove useless instructions. Optimize the code, non-entry node classes will be added with private/static/final, unused parameters will be deleted, and some methods may become inline code;

Obfuscate: use a, b , c, d such short and meaningless names, rename classes, fields and methods;

Preflight (Preveirfy): Preflight the processed code on the Java platform to ensure that it is loaded class files are executable.

In the sharing, Zhong Yaping showed an example of the Apk effect after using Proguard to decompile Dex2jar:

After Proguard processing

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

Obfuscated code reverse analysis

Zhong Yaping shared a foreign tool called DEGUADR, which uses statistical methods to deobfuscate code for decompilation. Although the accuracy of this tool is not 100%, it can still help partially in decompiling the code.

Example of using DEGUADR to deobfuscate:

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

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

2. Overall Dex reinforcement

With the continuous development of security technology, new "reinforcement technology ” has appeared to enhance the protection strength of Android. DEX reinforcement is to pack and protect DEX files to prevent them from being cracked by static decompilation tools and leaking the source code. The first to appear is the overall reinforcement technology solution.

The principle of the overall reinforcement technology is as shown above, including replacing application/classes.dex, decrypting/dynamically loading the original classes.dex, calling the original application related methods, Set 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 code file, and then use the new project's application startup in a new project to decrypt the original project code and load it into memory, and then The current process is replaced with decrypted code, which can hide the source code well and prevent direct decompilation.

Overall Dex reinforcement reverse analysis

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

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

3. Split Dex reinforcement

As the business scale develops to a certain extent, new functions and new class libraries are constantly added. While the code expands rapidly, the size of the corresponding apk package also increases. With the rapid increase, the simple overall reinforcement solution cannot meet the security requirements well. In addition to the overall reinforcement solution, split reinforcement technical solutions have emerged.

But as shown above, when the dex file is reinforced, some of the missing data will be replaced with decrypted data. Sometimes this kind of disassembly Substitution can also lead to inaccurate data. You need to understand the data structure of the dex file to determine what type of data should be split.

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

Split Dex reinforcement reverse analysis

For the reverse analysis of dex split reinforcement, as shown below, you can replace it with classdata and assemble it into Although the new dex file will not be completely consistent with the original dex file, it also restores the appearance of the split data to a certain extent.

           
                                                                                                                                                                                                                                                             

# Try to avoid using it when possible, and even if necessary, try to restore it only when this class is used.

In addition, there is a lower-level tool called dexhunter. This tool is more avant-garde, but it also has some limitations. For example, some instruction data will be optimized, and the resulting code interface is not very beautiful, etc.

                                                                                                                                                                                                                                                                                              Virtual Machine Hardening A type of reinforcement. The following is a conventional Android system code that has been hardened by a virtual machine.

, mul-int v0, v1, v2, and then perform hardening compilation. After this operation, even if the replaced data is restored, it will not be added-int v0, v1, v2, sub-int The three instructions v0, v1, v2, mul-int v0, v1, v2 are replaced and then reinforced and compiled. After this operation, even if the replaced data is restored, it will not be transformed into the previous bytecode. The safety factor is high.

Virtual machine reinforcement reverse analysis—HOOK JNI interface

Reverse analysis in this way can be implemented through the HOOK JNI interface on the one hand, and it has two implementation methods.

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

GetStaticDoubleFieldSetStaticDoubleField GetDoubleField SetDoubleField …

(byte, object, int,long…)

The second is to reflect the calling class method, such as:

CallVoidMethodACallBooleanMethodA CallShortMethodA CallObjectMethodA…

CallStaticVoidMethodACallStaticBooleanMethodA CallStaticShortMethodA CallStaticObjectMethodA…

(byte, int, long, double …)

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

Realize virtual machine hardening reverse engineering through HOOKJNI interface Analysis

Using the HOOK JNI interface can understand the general calling process of the APP without the need for underlying reverse engineering. However, for complex calling processes, or when there are a large number of virtualization methods, this reverse analysis method will seem confusing; for instructions that do not need to be reflected back to the Java layer for execution, such as arithmetic and logical operations, it cannot be monitored. arrive.

Virtual machine hardening reverse analysis—analyzing instruction opcode mapping

On the other hand, reverse analysis can also be performed by analyzing instruction opcode mapping. The following methods can be used when using the same hardening version or mapping relationship:

                                                                                                                                                                                                                                                  .

                                                                                                                                                                                                                    to .

                                                                                                               

The above is the detailed content of What is the reverse analysis and protection mechanism of Android APP?. For more information, please follow other related articles on the PHP Chinese website!