[Fat Tiger's Reverse Road] 03——Android generation shell shelling method list & practical operation

[Fat Tiger's Reverse Road] 03 - List of Android Unpacking Methods & Detailed Explanation of Unpacking Principles

[Fat Tiger's Reverse Road] 01 - Detailed Explanation of Dynamic Loading and Class Loading Mechanism
[Fat Tiger's Reverse Road] 02 - Detailed Explanation & Implementation of Android's Overall Packing Principle

---

---

foreword

In the above, we have explained the principle and practical operation of the overall Android shelling. Now we will explain the current mainstream unpacking tools and processes. Due to the limited ability of the author, we will try our best to describe the process of the overall . Principle, if there are any mistakes in this article, please correct me, thank you~

---

1. Mainstream shelling methods

1. Tool shelling method

Tool unpacking refers to the use of existing tools for unpacking. Many bigwigs have developed many practical tools, and we can use them directly (hee hee hee)~

1) Frida-DexDump

Thanks to Frida, it is very convenient to search and dump the memory on the computer. Instead of getting the corresponding classes and methods in Dex through cumbersome Xposed code, you only need to focus on how to search for the desired function That’s it, for the complete dex, you can find it by violently searching dex035. As for the dex that wipes the head, it can be found by matching some features~

• Supports fuzzy search for decapitated dex (deep search mode).
• Compatible with all android versions (frida supported).
• One-click installation, no need to modify the system, easy to deploy and use

Project address: https://github.com/hluwa/FRIDA-DEXDump

The method of use has also become much simpler. Here, with the help of a big guy's usage flow chart, you can quickly unpack it

Let's briefly demonstrate, here it is used together with objection

and then open the dex that has been taken off again~

ps: After getting dex, it is recommended to use Jadx for decompilation, dex2jar is a bit outdated...

In addition, an in-depth introduction is attached: In-depth spear and shield in FRIDA-DEXDump

2) Fart

The production process of Fart is a bit cumbersome, mainly because the code of FART is made by modifying a small number of Android source code files. The modified Android source code is compiled into a system image and flashed into the mobile phone. After the mobile phone is started, the Apk can be unpacked ~
Based on this, I prefer to call it a shelling chicken, because the modified Android source code is compiled into a system image and flashed into the phone~

Official introduction:
The automatic unpacking scheme based on active calls in the ART environment, based on Android 6.0, can be transplanted to any system in theory~

Project address: https://github.com/hanbinglengyue/FART

The specific implementation principles and steps are in Kanxue:

• Clearing the clouds and seeing the sun: the essence of Android APP unpacking and how to quickly find the unpacking point under ART
• Dessert before FART meal: several general, simple and efficient dump memory dex methods under ART
• FART: an automatic shelling solution based on active calls in the ART environment

Shelling process:

1. Install the apk to be unpacked, and grant read and write permissions to the sd card in the settings (otherwise the files under the dump cannot be written to the sdcard)

2. Click the app icon to start the fart shelling process

Next, you can filter the logs whose tag is ActivityThread in the logcat, and wait for "fart run over" to appear in the unpacked app process, and the fart active call process ends at this time. Shelled out

Both the dex file and the function body bin file are in the directory of /sdcard/fart/app package name~

The screenshot below shows the running process and unpacking results of fart

Official Ps: Add two different implementations of the frida version of fart, each with its own characteristics. It can be specific to dump all the functions under a certain class or even the CodeItem of a certain function. If you need it, you can experience its powerful shelling ability. (Note, the test environment is pixel Android8.0, frida-server 12.8.0)

3) Youpk

Youpk's ART-based unpacking machine is mainly for dex overall reinforcement and various dex extraction reinforcements, but currently Youpk only supports pixel 1 generation. So you must need a pixel 1 generation mobile phone, and you need to flash into the corresponding system~

The basic process is as follows:

1. dump DEX from memory
2. Construct a complete call chain, actively call all methods and dump CodeItem
3. Merge DEX, CodeItem

Project address: https://github.com/youlor/unpacker

In this address, there are many processes and methods, attention issues, etc., you can take a look if you need it

4) Comparison of commonly used shelling tools

2. Hook shelling method

As we wrote above, as long as the function contains a DexFile object, you can actually get the object through the Hook, and then get the begin and size to unpack it. Currently, the most used Hook frameworks are Xposed and frida. Frida is convenient for many users, here we use frida for demonstration~

First use GDA to identify the packer~

It seems obvious that the overall packer has been carried out. I don’t know if there are other packers. Let’s unpack first.

First find the shelling point~

Open libart.so through IDA, search for DexFile, we can find a large number of unpacking points

Then we write the hook script

The reason why begin plus a pointer here is because we said earlier that dexfile contains a virtual function address, so add a pointer offset

Then start the additional process of frida_server in the mobile phone

to dump, here we exist under the sdcard, so we need to grant read and write file permissions in advance

It can be seen from the figure that the unpacking has been successful here~

Then use jadx to open the corresponding dex to view

At this time, it means that we have succeeded in unpacking as a whole, but the application still looks like there is still a shell to be extracted. After extracting the shell, a separate article will be opened for recording~

3. Stake shelling method

The method of plugging and unpacking is to locate the corresponding unpacking point in the Android source code, then insert the corresponding code, recompile the source code to generate a system image, and finally use the customized system for unpacking~

Its principle feels similar to that of youpk. How to compile the source code will not be repeated here. Friends who need it can read this article~
Source Code Compilation (1)——Android6.0 Source Code Compilation Detailed Explanation

Then let’s explain it with the help of the picture that the boss has already completed. Similarly, to locate the shelling point, we still randomly locate a shelling point LoadMethod and then insert the stake

//add
char dexfilepath[100]=0;
memset(dexfilepath,0,100);
sprintf(dexfilepath,"%d_%zu_LoadMethod.dex",getpid(),dex_file.Size());
int dexfd = open(dexfilepathm,O_CREAT|O_RDWR,666);
if(dexfd>0){
    
    
    int result = write(dexfd,dex_file.Begin(),dex_file.Size());
    if(result>0){
    
    
        close(dexfd);
        LOG(WARNING)<<"LoadMethod"<<dexfilepath;
    }
 
}
//add

In the same way, we also insert this code in execute, and finally compile it, and the compilation is successful

Then authorize the program with sdcard permission, start the application again, and you can see that the extracted dex file is saved in the sdcard directory

Then use jadx, open dex, you will get the same result as above~

Ps: Since this method needs to modify and compile the Android source code, the author of this article has not implemented it. If you have any questions, please feel free to communicate (I will compile again if there is a problem)

4. Stake shelling method

My own understanding of reflection shelling is to use reflection to get a series of classloaders, and finally get the DexFile structure, and then get the two attributes of the variable mCookie&mFileName to get the dexFile memory pointer, and then convert the pointer to dexfile, and then use findClassDef to match the search dex, and finally dump into the file~
With the summary of the predecessors, the process is as follows:

Then let's do a demonstration~
mCookie is the pointer of the dexfile in the native layer, and then we use the reflection principle to get the mCookie, and then we can unpack it. Here we still use frida for code demonstration~

Write hook code ing

print out the relevant value

You can see the dex of the same size

Then use jadx to open it, and found that the same interface appeared again!

5. Dynamic debugging unpacking method

The core principle of the dynamic debugging method is to obtain the starting address and size of DexFile, but all methods are different. If the above is to modify the code to get some values, then the next step is to use the IDA tool to obtain the corresponding starting address and Size, and then dump through the script~

Please enjoy!
First choose a shelling point, we still choose DexFile::DexFile

and then start the android_servcer on the phone, remember to start with Root

and then use IDA to attach the process

Then ida started to intervene

and then we opened libart.so and located DexFile::DexFile

Then set a breakpoint in the function, and then F9 come over to have a look

Here you can clearly see that X1 is the starting address of DexFile, and X4 is the offset value

Then use Frida to dump~

Just run run directly and

then use gda to view the local dump.dex file

It can be found that this is actually a proxy class. The comparison size is not the dex we want. F9 again, you can see that the address has changed again, and the calculation is combined with the length again. After several attempts, it still doesn’t come out. It feels that it can be obtained, and it doesn’t waste too much effort as a demonstration~

6. Special API debugging method

Special API debugging means to obtain Dex through the API methods provided by the Android system. Android 7.0 and below systems provide the two APIs getDex and getBytes, so if we want to obtain objects, we can directly call these two APIs ~

But in the actual test, it is found that the getBytes method of Dex still exists in the higher version of Android, but the getDex method in the core Class class has disappeared~

Write the hook code:

Operating procedures:

Then we look at the class object of the program, just dump a class object

After getting the dex, we use the jadx tool to open it again~

If you find it, you can successfully dump~

2. Experimental summary

This article summarizes some commonly used unpacking schemes for the current dex overall shelling, and reproduces them, but here it is only used as an experiment to deepen my understanding (it is not so simple to get the source Dex at present), but there are Friends who are interested can go through the whole process like me to deepen their understanding~

3. References

https://bbs.kanxue.com/thread-273293.htm#msg_header_h2_6

The pictures mentioned in the article are partly taken from the article, Shuan Q~