A brief talk on Android Application Protection (ii): Anti-analysis Methods and tools

This article is translated from foreign literature, the original link please see the article at the bottom

As mentioned before, application developers are pinning their application's security on some mechanism in order to protect their applications from being analyzed and manipulated by others. There are many mechanisms that can be used to protect applications, and the effect and difficulty of implementation are characteristic. There is a class of application protection methods called Counter Tools (Anti-analysis).

Against the reverse tool, the simple point is to use the reverse tool itself or the unique mechanism of Android, so that the application of reverse analysis tools in the work process failure or error crashes, the analysis process can not continue to implement. So as to achieve the purpose of protecting the application.

The advantage of this way of protecting your application is that it is simple to implement and does not need to touch the code of the application itself, simply by adding a simple "malicious" code to implement the purpose of the Crash Reverse debugging tool. At the same time, as an unconventional application protection method, the idea is flexible, often can produce unexpected effect. The disadvantage is also obvious, the reverse tool will be in the new version to fix these vulnerabilities and flaws, the researchers can easily analyze the implementation of the method, and then to a targeted break.

Here are a few ways to protect your app from being reversed with an "attack" reverse tool.

first, annoying "pseudo-encryption"

The Android platform app file. apk file is essentially a ZIP archive package. Therefore, the general application of reverse analysis is to change the. apk file suffix. zip, the tool to extract the Lib files and Dex files, and further analysis. But suddenly one day, when extracting the zip file, suddenly found that the APK file is encrypted.

At this time, a lot of people will feel very strange, no way, do not know what to do next, even think of the demolition of the password, the failure to give up after the analysis. Thus, the application achieves a certain degree of security protection.

The implementation of this principle is: Modify the zip header, the file's encryption flag is set to ture, but does not really encrypt the data inside the package. Restore sets the encryption flag to false. Using the android processing zip file does not judge the head of the encryption information, other compression software, Java default implementation of the ZIP API has to detect the encryption information in the ZIP header. For this method to protect the APK, directly with the bluebox of this script can be done.

https://github.com/blueboxsecurity/DalvikBytecodeTampering/blob/master/unpack.py

second, learn from the known Jar hack method

Since APK is essentially a Zip/jar package, we can also take advantage of the known jar hack method.

The length of the jar on the file name is not present, but the operating system requires that the file name cannot be greater than 255, and we can achieve the reverse by constructing a long class name greater than 255 characters.

We can do this based on the format of the Dex Class DEF item.

We can build long class names greater than 255 in the following ways:

1. Add a string greater than 255 in the source code.

2, compile the source code, modify the Dex file header, modify the class descriptor_id to string a string_idx.

The effect is as follows:

The affected tools are: Ida,dex2jar, Androguard, Baksmali

inserting an invalid bytecode instruction or invalid pointer causes the reverse tool to crash

1. Insert Invalid instruction

Since most of the reverse tools are linear read bytecode and parse, when encountering invalid bytecode, it will cause the anti-compilation tool bytecode parsing failure, if the reverse tool does not take into account this point, did not properly handle the reported errors, it will crash directly.

We can insert invalid bytecode into the Dex file, but make sure that the invalid bytecode is never executed. Implementation method:

Put a code similar to this:

Insert into the app that we don't care about in the class, and then recompile the build apk.

The effect is as follows:

Baksmali has been broken (fixed in version 2f81aec886d2 7/28).

The Dex2jar also collapsed. (This is easy to fix, but not fixed in the current public version)

The dynamic analysis tool Androguard also collapsed. (The new version has been fixed).

Ida is unaffected and can be used normally. This is because IDA does not parse the Dex file using a linear scan, but instead uses a somewhat more "advanced" recursive descent disassembly method.

2. Insert Invalid data pointer

This method and Method 1 is not very different, the main principle is to insert can analyze the tool crash code, data, pointers. The app developer then guarantees that the malicious code, the data is in an area that will never be executed.

The effects of this method are reversed tools including Baksmali, Dex2jar, Androguard, IDA (partially valid). A more practical way to insert an invalid pointer than to insert an invalid instruction is that this invalid pointer can be more tightly combined with the code, can be cleverly inserted into the code that will be executed, and thus lead to IDA using recursive settlement disassembly.

These 2 kinds of reverse tool "attack" repair methods are relatively easy, on the one hand the tool to update the code, for non-expected input to do a good job of filtering, on the one hand, the reverse analyst can write a script, fixed point to clear the apk file malicious code.

3. Some tips

Now that you want the reverse tool to crash, you should let the reverse tool crash as soon as possible. If you plug a malicious bytecode into the end of a Dex file, it doesn't make sense that the analysis tool has finished working before it crashes.

Although malicious bytecode can be fixed-point cleanup, the reverse tool can also be encountered when the malicious bytecode error errors do not crash, directly around the past to deal with the back, resulting in a way to analyze the entire Dex file. However, this part of the code block that contains the malicious bytecode is not parsed (either purged or bypassed). Therefore, it is very meaningful to embed such malicious bytecode in critical processes, even if the entire Dex file is not protected and several key functions are protected.

Iv. attacks against Java anti-compiler flaws

No matter how high-tech the Dex Anti-compilation tool is, it is not perfect to decompile back from Dex bytecode to the readable Java code of a small white attacker. The main reason is that Android is using Dx.jar to optimize the initial class file when it is packaged, so that the generated Dex file is no longer a standard JVM executable, but a DVM executable file. The DVM and JVM are based on registers and one stack-based on the schema. Therefore, in the process of conversion, there must be a loss of information. Since the conversion is imperfect, there is a place for us to use.

The dex2jar+ (Jd-gui or JAD) combination tool is a frequently used tool for reverse analysis. Dex2jar is used to convert a DEX file into a Java bytecode jar file, Jd-gui or jad is used to translate Java bytecode into Java source code.

We can achieve the purpose of anti-reverse analysis for Java Jd-gui or jad tool defects. The effect achieved is as follows:

Dex2jar + Jd-gui has been unable to correctly parse the corresponding code in the APK.

Ida's analysis of the process has also been problematic.

Reference 1 proposes a code similar to this, embedded in any method, that can reproduce the error that appears on (Dex2jar+jd-gui). But this code does not take effect in another good-performing commercial anti-compiler, Jeb.

At the same time, I also found that as long as the try-catch in the TRY statement block to add a complex return statement, the general can also achieve the above error. This is probably because the implementation of the Try-catch statement is related to the stack, while the register-based DVM has some special operations when converting. Even Jeb, when dealing with try-catch statements, often has problems.

v. anti-analysis of native library files

For so file analysis, is Ida's strengths, especially the online has been circulated for a period of time ida6.5pro+f5 cracked version, basically all the way F5 down, you can put a so inside the code inverse almost. Therefore, the anti-analysis method for IDA is also very necessary.

In the head of the so file format (that is, the elf file format), the E_shoff field is the offset of the Knuckle Area (section) table, calculated in bytes, if not, can be 0. Compile the link period, each segment includes (corresponding) which sections, the linker has done, during the load, linker only need to follow the segment loading OK. So when the real so file is loaded, it is not concerned with the header section related fields. But Ida,readelf and objdump such so file analysis tools are going to parse this field. Assigning an incorrect data to this field can result in errors or even crashes for these tools.

Objdump Error: File truncated

All the readelf resolved is FFFFFF.

This anti-analysis way is easier to fix, while ida,objdump,readelf can fix this problem in the new version. On the other hand, the analyst can also repair the Sht related malicious data in the so file manually.

Vi. Summary

The Anti-analysis method described above is a method that has been published very early and used by many applications. This level of attack and defense is not further development, because this level of confrontation is not particularly large, there is not much "dry". The protection application is not the reverse attack function pinned on the shortcomings of the reverse tool, after all, the pattern. After knowing the principle, the basic can be broken in seconds. According to the development of the Android platform application attack and defense, this level of attack and defense is no longer subject to too many people's attention. Now more people are taking the field of confrontation to the Dalvik and native layers of code. These two levels of confrontation will be covered in the next two articles.

on Android Application Protection series review

Talking about Android Application protection (0): starting point and background

A brief talk on Android Application Protection (a): Basic methods and demos for Android application reverse

References:

Http://www.strazzere.com/papers/DexEducation-PracticingSafeDex.pdf

http://books.google.com.hk/books?id=-LZpAgAAQBAJ&printsec=frontcover&hl=zh-CN#v=onepage&q&f= False

More technical dry, access to the Ali Poly Security Blog

A brief talk on Android Application Protection (ii): Anti-analysis Methods and tools