Dynamic way to crack apk advanced articles (IDA debugging so source code)
Source https://blog.csdn.net/qq_21051503/article/details/74907449
Let's talk about the dynamic debugging of Android so in IDA and the operation of breakpoints under the three levels of so.
Questions:
1. The role of dynamic debugging and the difference from the shelling we often say?
2. The principle of IDA's next breakpoint debugging?
3. Is there any difference between the steps of anti-debugging? And the principle?
4. What is the difference between anti-debugging and anti-attachment?
5. What are the three levels when IDA dynamically debugs so? And how to set a breakpoint?
Note: There are many similarities in the steps of dynamic debugging of so and unpacking. About unpacking, the development process of packing and unpacking will be introduced in detail later.
Answer the principle:
first question:
Said: Dynamic debugging has two functions:
One: dump memory, that is: find the right time to dump the correct decrypted file;
Second: Check the status of each step and further analyze the correct logic;
Unpacking is just after we debug the .so file at the system level, we find the right time to dump the correct and real .so file, and dynamic debugging is just a manifestation of manual unpacking.
second question:
Said: (Because the teacher said that he likes to ask questions during the interview, it is listed here)
The principle of the next breakpoint:
Since the next breakpoint has hardware breakpoints and software breakpoints, we only talk about the software breakpoint principle in IDA here:
The X86 series processors provide an instruction specially used to support debugging, namely INT 3. The purpose of this instruction is to make the CPU break (break) to the debugger, so that the debugger can perform various analysis on the execution scene.
When we set a breakpoint on a line of code in IDA, that is: F2, the debugger will first save the first byte of the original instruction here, and then write an INT 3 instruction, because the INT 3 instruction The machine code is 11001100b (0xCC). When running to this, the CPU will catch an exception, turn to handle the exception, the CPU will retain the context, and then interrupt to the debugger. Most debuggers are interrupted by the debugger. When the debugger is used, all the instructions whose breakpoint positions are replaced by INT 3 will be restored to the original instructions, and then the control will be given to the user. So we can happily start debugging. As shown in the following figure, it is also a schematic diagram of writing a debugger:
Third question:
Said: let's talk about anti-counterfeiting debugging first:
1. adb push d:\android_server (under the dbgsrv directory of IDA) /data/local/tmp/android_server (this directory can actually be placed anywhere, some anti-debugging will detect this)
2.adb shell
3.su (must have root privileges)
4.cd /data/local/tmp
5.chmod 777 android_server (execute permission to be given)
6. Open another cmd
adb forward tcp: 23946 tcp: 23946 (port forwarding, debugging a process on the phone must have a protocol to support communication)
7. Open the application to be debugged and you can debug it happily
Then there is anti-debugging:
Said: In many cases, we encounter anti-debugging and use the above steps, and then exit directly after attaching it. There are countless examples of this, that is, anti-debugging provoked goods.
That's when we need to change our debugging strategy.
On the basis of the above:
1. Start android_server;
2. Port forwarding adb forward tcp:23946 tcp:23946;
3. adb shell am start -D -n package name/class name;
(Note: Start in startup mode, stop before loading the so file, registration can be found in the AndroidMainfest file)
4. Open IDA, attach the corresponding process, set the timing of load so in IDA, set it in the debug options, and there will be an actual combat part later;
5. adb forward tcp:8700 jdwp: process number; (jdwp is the protocol of the jdb debugger behind, which is converted to the specified application to be debugged);
6.jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=8700 (jdb attaches);
7. You can happily set the breakpoint and start debugging;
Fourth question:
Said: Anti-debugging is a means to prevent you from performing dynamic debugging. In the next article, we will explain the anti-debugging methods in detail and how to solve them.
Anti-attachment, the important thing here is to say the anti-attachment of jdb. In many cases, jdb will not be attached, that is, there will be a problem of "cannot attach to the target VM". That is because under each application, there is this android :debuggable="true" can only be debugged, because of space problems, we will find all the current solutions for anti-attachment in the next article.
Fifth question:
Say: We know that there is this process when so is loaded:
.init->->.init array->->JNI_Onload->->java_com_XXX;
In addition, we will set breakpoints in some system-level .so in the process of unpacking, such as: fopen, fget, dvmdexfileopen, etc.
And .init and .init_array are generally used as the entry point of the shell, so we simply call it a shell-level .so file
Here are three categories:
Application level: java_com_XXX;
Shell-level: JNI_Onload, .init, .init_array;
System level: fopen, fget, dvmdexfileopen;
For the application-level and system-level, it is relatively simple and easy to understand. It is also emphasized in the implementation chapter. Seeing the loading and execution process of .so above, we know that if the anti-debugging is placed at the shell level .so file, we will encounter the embarrassment that the program exits at the breakpoint of the application-level core function. In fact, most of the anti-debugging will be placed here, so after anti-debugging, we must set breakpoints in these places, then we will The focus is on how to handle breakpoints in .init_array and JNI_Onload.
Implementation articles:
Here we will take a sample of Ali's one-year competition and put it in the attachment.
Breakpoint method 1 at JNI_Onload: (double-open positioning)
1. Start android_server;
2. Port forwarding and debug mode startup: as shown in the figure:
3. Open IDA, set
4. After attaching the corresponding process, as shown in the figure:
5. This step is very important. Select these three options under the Debugger option (stop at each interface of load so)
6.jdwp protocol port forwarding
7.jdb attach
8.F9 execute, ignore the prompt box; this time run to the linker, as shown in the figure:
9. Find the absolute address of JNI_Onload at this time:
base address + relative address;
The base address is: ctrl+s is displayed as:
The relative address can be obtained by statically analyzing libcrack.so with IDA:
The absolute address is: 4151E000+1B9C=4151FB9C
Press the "G" key to enter 4151FB9C
As shown in the figure: Press F2 to set the breakpoint, and then press F9 to execute to the breakpoint, you can debug happily
Set a breakpoint at JNI_Onload Method 2: (simple and easy to use)
1. First, pull the libcrackme.so file to be analyzed into IDA and set a breakpoint at JNI_Onload where the breakpoint is to be set as shown in the figure:
2. Start android_server as above;
3. Port forwarding and debug mode startup: as shown in the figure
4. First set the Debugger as shown in the figure
5. IDA attaches the process and returns to the IDA interface of the previous static analysis of libcrackme.so. Click Debugger -> Process options to configure debugging information. Here, you only need to configure the hostname as localhost, and keep the default settings for the rest.
6. Click Debugger -> Attach to process to attach the process
7.jdwp forwarding (of course, this step is not required to open DDMS) jdb attachment
8. F9 executes all the way to cancel and it is OK, as shown in the figure:
Is not it simple? ?
Set a breakpoint at .iniy_array (same as method 2 above)
The result obtained is:
OK, it's done
Set a breakpoint at JNI_Onload Method 3: (suitable for shelling)
1. You can find one point according to the source code, corresponding to different versions of the system source code, as follows in the vm/Native.cpp path:
2. Let's look in reverse, first pull out the libdvm.so a db in the system, and pull it into IDA for analysis;
Find JNI_Onload for analysis: F5 can see that firstly, V20 searches for the "JNI_Onload" symbol, and at the same time, there is a call to V20 in V23.
Going back to the ARM instruction, you can see the following:
0x50008 is the offset, at this time we start to break:
After loading the APK to be debugged, find the base address of libdvm.so, add 50008, and set a breakpoint. If you can't see the assembly, then P, and a breakpoint, this is more suitable for unpacking.
Attachment: Click to open the link
=======================================Reference 1
1.adb push d:\android_server (under the dbgsrv directory of IDA) /data/local/tmp/android_server (this directory can actually be placed anywhere, some anti-debugging will detect this)
2.adb shell
3.su (must have root permission)
4.cd /data/local/tmp
5.chmod 777 android_server (execute permission is required)
6. Open another cmd
adb forward tcp:23946 tcp:23946 (port forwarding, debugging a process on the phone must be The protocol supports communication)
7. Open the application to be debugged and you can debug it happily
=======================================Reference 2
2. Preliminary preparations
2.1 Install the sample program
adb install AliCrackme_2.apk
2.2 Upload the android_server file
adb push android_server /data/local/tmp/
adb shell chmod 777 /data/local/tmp/android_server
3. Debugging step
3.1 Start android_server and monitor port 23946 , communicate with IDA pro
adb shell /data/local/tmp/android_server
adb shell android_server
3.2 Set up local port forwarding
adb forward tcp:23946 tcp:23946
3.3 Start the program in debug mode
adb shell am start -D -n com.yaotong.crackme /.MainActivity
3.4 Start IDA pro, click Debugger->attach->Remote ARMLinux/Android debugger, enter localhost, and select the process to be debugged.
================================= Implement it yourself
adb forward tcp:8008 tcp:8008
http://127.0.0.1:8008/#To
use the logcat function, you need to forward the port to the local first.
adb forward tcp:8887 tcp:8887
================================= Implement it yourself
1 android_server
adb push d:\android_server /data/local/tmp/
adb shell chmod 777 /data/local/tmp/android_server
2 Put the android_server configuration file in /system/xbin
3.1 statr
Open android_server, listen on port 23946, and communicate with IDA pro
3.2 Set up local port forwarding
adb forward tcp:23946 tcp:23946
3.3 Start the program in debug mode
adb shell am start -D -n com.yaotong.crackme/.MainActivity
adb shell am start -D -n com.yaotong.crackme/com.yaotong.crackme.MainActivity
3.4 Start IDA pro, click Debugger->attach->Remote ARMLinux/Android debugger, enter localhost, and select the process to be debugged.
3.5 After adding the program successfully, select, Debugger option, check
suspend on process entry point
suspend on thread start/exit
suspend on library load/unload
three items, then press f9 to run the debugger, at this time IDA pro hangs