[Android_cracker] Android Dex security Attack and battle

First, DEX related basic knowledge

1. What is DEX?
Dex is the abbreviation for Dalvik executable.
The. class file is packaged as a single Dex file and runs on the Dalvik virtual machine.
The Dex file is packaged into the apk file (essentially a jar or zip file).


When installed, the system extracts Dex files for inspection and verification.
During the first run, the system completes the Dex optimization and transforms it into a Odex file.
The Odex file is stored in the/data/dalvik-cache directory and loaded into memory execution when executed.


2. dex file Format (for more information, visit: http://blog.csdn.net/androidsecurity/article/details/8664778)



3. How to view Dex files
The following tools are now available to complete the deserialization of the Dex file.



Ii. ways in which attackers hide software behavior

Attackers often hide the behavior of the software in the following ways:

1. Invoking sensitive APIs using reflection



This approach allows attackers to "hide" sensitive API calls. But this approach only needs to see if it can be easily detected using Java reflection.
The difficulty of automating identification is increased if the code is confused with the technology. Dynamic analysis is easier to deal with this "hidden" approach.

2. Code logic "hiding" in the resource file

You can hide the code logic by modifying the file suffix name, such as:





File suffix shadowing allows you to see whether a file type is easily identifiable with a suffix by using the files command.
We can also do a bit more advanced. The elf executable binary is appended to a valid picture file, and the correct file type is obtained through the file instruction, and the picture can be displayed normally:


This kind of hiding requires more in-depth view of all the resource files. Looking at is a jpg picture file, but not necessarily all (never trust your own eyes).
There may be other, more advanced ways to hide malicious code.

3. Using Dexclassloader Dynamic Loading technology

You can use Android Dexclassloader to complete the dynamic loading of Dex, which can be attached to an assert or raw directory and can be downloaded from the network when it is run.

Third, the Android anti-reverse analysis tour

We can use the Reverse analysis tool to implement the defect to trigger its collapse, so as to achieve the purpose of anti-reverse analysis.

Target of Android anti-reverse analysis:
Baksmali-Using the most extensive Dex anti-compilation tool (APKTOOL/ANTILVL, etc.) (https://code.google.com/p/smali/)
Dex2jar-a tool that can decompile Dex into a jar and then view it through Jd-gui. (http://code.google.com/p/dex2jar/)
IDA Pro-(This is not the introduction!) ) (https://www.hex-rays.com/index.shtml)
Androguard-also more popular. (https://code.google.com/p/androguard/)

1. Build Dex Link section trigger Baksmali tool crash (DEX file structure see http://blog.csdn.net/androidsecurity/article/details/8664778)

Because the Baksmali tool does not support the link section of the Dex file, we can build the DEX link section to trigger the Baksmali tool to collapse. Such as:


This approach is often used by developers to prevent a cracker from analyzing code logic in reverse. This method has been used in lohan+ (ANTILVL)/jcase/and other projects. However, this method also has obvious shortcomings, can be easily based on the exception information repair analysis tools.

2, using 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.
How to build a long class name greater than 255? First, let's look at 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

is to modify before and after comparison:



The modified APK can be installed normally, such as:



This method of modification prevents reverse analysis, such as:



Through the exception we should be able to see why more than 255 characters will be an error.
But the disadvantage of this way is only to deal with Backsmali. IDA, Dex2jar, and Androguard still work properly.
This method is easy to detect and resolve, and when class name length >255 be wary of the application.

3. Insert invalid bytecode instruction causes reverse tool crash

Since most of the reverse tools are linear read bytecode and parse, when invalid bytecode is encountered, it will cause the anti-compilation tool bytecode parsing failed.
We can insert invalid bytecode into the Dex file, but make sure that the invalid bytecode will never be executed (or your program will crash!). ）。

[Java] View plaincopy
1201//Load 0 into V1
3801 0300//A conditional jump which should all succeed, jumps over
Next bytes
FFFF//Bad opcodes
Install an APK file that inserts invalid bytecode. Such as:



However, when executing the program, the error is reported as follows:


How can you make an error when running?
The Dalvik virtual machine does not skip the invalid bytecode as we expected, and it verifies that the bytecode of the class on all call sequences is valid before executing.
The question now is how can you bypass code validation for Dalvik virtual machines?
If we insert invalid code on a class that is never called, we can bypass the Dalvik runtime code validation!
Look at the following insert operation results:


Haha, successfully run, and then let us look at the way the reverse effect of it!


(unfortunately Backsmali has fixed the bug in version 2f81aec886d2, which is invalid)


Dex2jar validation is possible.


Androguard validation is possible (unfortunately Androguard fixes the bug soon)



Ida Verification not successful!


Ded Tool Verification Success! Before you kill the tool process, it will always run in the class processing of invalid bytecode.

The disadvantage of this method is that it is easy to be repaired by tools. When the tool is deserializing code, Backsmali, Androgurad has fixed the bug as long as it ignores the processing of invalid bytecode.
This way and very easy to be automated monitoring, if you encounter invalid code will be vigilant!
The reverse analyst should try to use the latest version of the tool.

4. Insert a valid bytecode directive but followed by an invalid data reference

Inserting invalid bytecode directives The tool is now working, but what if we insert a valid bytecode instruction, but followed by an invalid data reference?

[CPP] View plaincopy
1201//Load 0 into V1
3801 0300//A conditional jump which should all succeed, jumps over
Next bytes
1a00 FF00//Load const-string at index 255 (doesn ' t exist)
This time we still bypass the Dalvik runtime bytecode instruction validation, but we replace the "invalid bytecode directive" with the legal bytecode directive


Backsmali Verification Success!


Dex2jar Verification Success!


Androguard validation succeeds, but only the method of inserting the "valid bytecode directive" in the anti-compilation error is used.


Ded Verification Success!


Ida validation failed!

This approach is also easily repaired by tools, as long as the reverse tool does not blindly parse a nonexistent index.

5. Attack against Java anti-compiler flaw
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:


6, for Backsmali to file header processing defects
Did we just talk about the bug that Baksmali was dealing with link section, and a similar crash point? The Backsmali code shows:


When Dex Header size is not equal to 0x70, Backsmali will also throw an exception to exit!
Header_size The current value is normally equal to 0x70


Building this Dex file is easy to implement.
You need to fix the offset of each table entry in the file header.
The modified header size equals 0x78


But this approach is only for Baksamli tools. And it's easy to fix the bug with a tool.
This method can also be used to hide data and code in the Dex header.
We can hide another Dex data at the Dex file header and load the Dex data at run time.
Build a non-canonical Dex file


Call the Dexfile class method by reflection to load the accompanying Dex data (android4.0 above is the method we need http://blog.csdn.net/androidsecurity/article/details/9674251)



Opendexfile method that actually calls Dexfile by reflection


This allows us to parse Dex data through byte[] without having to store the Dex data in a file on the device.
We can read DEX data from installation apk files, memory, or Dalvik-cache.
The packaged Dex file looks like this:


This approach poses a problem for automated analysis tools that automate tools to process Dex files in DEX format without processing the accompanying Dex data. Requires a specific tool, 16 editor, or manually extracting embedded Dex data.
We can use different ways to increase the difficulty of extracting embedded data, such as:
Encrypt embedded DEX data;
Embedded DEX data is encrypted after it is compressed in zip;
Use native code to decrypt and load directly from memory;
...... Wait a minute

The hidden way can be determined by determining whether the head length of Dex file is greater than 0x70 detection.

7, big-endian small end reversal theory
There is currently no Android reverse tool to implement DEX file-side inversion (perhaps Ida support).
The Dalvik virtual machine detects if the Dex end mode is appropriate for the current device during the Dex optimization process, and if not, reverses the Dex file-side mode.
What we need to do is transform the Dex file into all byte-end structures, and the inverted Dex file can break the reverse tool but still be able to run on the device.
This type of attack is theoretically feasible. We can refer to the Android source code implementation of the reverse side, the specific code is located in/dalvik2/libdex/dexswapandverify.cpp

Four, anti-virtual machine technology

How do I detect if the app environment is a QEMU virtual machine? We can get relevant information through Getprop, Getprop many properties are different on QEMU virtual machines and mobile devices. Like what:



There is no public interface in the Getprop Android SDK, but we can call through Java reflection.


V. Related references
http://code.google.com/p/smali/
http://code.google.com/p/androguard/
http://code.google.com/p/dex2jar/
http://siis.cse.psu.edu/ded/
Http://hex-rays.com/products/ida/index.shtml
Http://source.android.com/tech/dalvik/dex-format.html

English Original: Http://www.strazzere.com/papers/DexEducation-PracticingSafeDex.pdf
The article is published in Black Hat 2012, although the content is not fresh enough, perhaps a lot of methods are now invalid, but still will give us a lot of anti-reverse aspects of the apocalypse!

[Android_cracker] Android Dex security Attack and battle