Android security protection journey---Analysis of several solutions for applying "anti-debugging" operations

1. Introduction

I have introduced many cracking related articles before. In this process, we will inevitably encounter some anti-debugging strategies. At that time, I simply introduced how to solve anti-debugging. In fact, last year I introduced an article about the battle of security reverse protection in Android: Analysis of Android Security Reverse Protection; then this article will summarize in detail several popular anti-debugging solutions at this stage.

2. Analysis of Anti-Debugging Schemes

*** Type: Take the pit first and add it yourself

The code is very simple. Just add this line of code in so: ptrace(PTRACE_TRACEME, 0, 0, 0); where PTRACE_TRACEME means: this process is traced by its parent process. Its parent process should want to trace the child process. Generally, a process can only be attached once. When we are debugging, we will attach the process of the application to be debugged. If we occupy the pit first and the parent process attaches itself, then the subsequent attachment debugging will fail. Let's run this code and see the effect:

When we perform dynamic debugging, we all know that the TracerPid field in the status file of the attached process is the pid of the debugged process. Here, after running the program, we check the status file corresponding to the process and find that the TracerPid value is the pid value of the parent process of the process. Then, if there is a process that wants to attach and debug later, it will fail. This method starts a certain debugging function, but it is not absolutely safe. We will talk about the solution to this anti-debugging solution later.

The second type: signature verification

In fact, signature verification is not an anti-debugging solution, but it is also a security protection strategy. I will mention it here. Signature verification generally has many uses now, and its purpose is to prevent secondary packaging. There are two general solutions:

• ***: Perform protection locally directly. If the signature is found to be inconsistent, exit the application directly.
• Second: Encrypt the signature information in the request parameters. The server will verify the signature and return error data if it fails.

Neither of these two methods is the safest protection, because as long as there is signature verification logic, it can be filtered out locally. Several previous articles have introduced how to filter this signature verification method. Students who are not familiar with it can check: Cracking the signature verification of an application in Android; and the server signature verification and putting the signature verification in so will be introduced separately in the article later.

The third type: debugging status check

This method is purely based on the API in Android for testing. There are two methods:

***: Check whether the application is in debug mode

Directly call the flag attribute in Android: ApplicationInfo.FLAG_DEBUGGABLE to determine whether it is in debug mode:

This is actually to prevent the current crackers from decompiling the application in order to debug the application. In AndroidManifest.xml, add the android:debuggable attribute value and set it to true. Then you can debug it.

After adding this property, we can use the dumpsys package [packagename] command to view the debug status:

So we can check whether the flag field of the application's AppliationInfo is debuggable. However, this method is not perfect. We will introduce how to solve this anti-debugging problem later.

Second: Check whether the application is in debugging state

This is also judged by an API of the system: android.os.Debug.isDebuggerConnected(); This is to judge whether the current application is debugged. After we add this code, according to the previous article: Take off the 360 ​​reinforced protective shell, there is a step to perform jdb connection operation:

jdb -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=8700, when the connection is successful, this method will return true, then we can use this API to determine whether the current application is in debugging state to perform anti-debugging operations. However, this method is not safe, and we will introduce how to solve this anti-debugging problem later.

Fourth: Loop Check Port

When we cracked the reverse before, we needed to use a powerful tool, that is, IDA. When using IDA, we know that we need to start android_server in the device as communication, then this startup will occupy port 23946 by default:

We can view the device's TCP port usage cat /proc/net/tcp:

5D8A is converted to decimal as 23946, and the uid is 0. Since we run android_server as root, the uid must be 0. So we can use the port check method to implement anti-debugging strategy. Of course, this method is not safe. We will introduce how to solve this anti-debugging method in detail later.

Fifth: Loop check TracerPid value

In the first method, we briefly introduced that if the application is debugged, then its TracerPid value is the pid value of the debugging process. When debugging with IDA, it is necessary to start android_server on the device side for communication, then the debugged process will be attached, and this is the pid value of the android_server process:

Check the pid value of android_server:

So we can add a loop in the native layer of our application to check the TracerPid field value in our status. If it is not 0 or not our own process pid (if the first solution is adopted, it is also necessary to filter it); then it is considered to be debugged. Of course, there is another solution, which is to check whether there is an android_server process in the process list, but this method is not safe. Later, we will introduce in detail how to solve this anti-debugging solution.

3. Summary of Anti-Debugging Solutions

Here are a few simple sentences to summarize these solutions:

• ***, attach your own process, occupy the pit first, ptrace (PTRACE_TRACEME, 0, 0, 0)!
• Second, signature verification is an indispensable option, local verification and server verification are two-pronged!
• Third, use the system API to determine the application debugging status and debugging properties, the most basic protection!
• Fourth, check the debugging port information and process information of android_server in rotation, which is an effective way to protect IDA!
• Fifth, check the TracerPid field value in its own status in turn, which is an effective way to prevent being debugged by other processes!

The above briefly introduces several popular anti-debugging strategies for applications. You can use all of these strategies or use a few of them. But remember one thing: if you want to be safer, remember to put the anti-debugging solution in the native layer, the earliest time, usually in the JNI_OnUnload function. For safety, the functions in the native can be manually registered, and the function names can be obfuscated. For details, please refer to this article: Analysis of Android Security Reverse Protection. Now some hardened platforms start protection monitoring between multiple processes for more effective protection, and multiple processes participate in the anti-debugging solution together. This method will increase the difficulty of cracking, but it is not absolutely safe. Each method is mentioned in the article, and none of them is absolutely safe. There are ways to solve them, and this content will be introduced in detail in the next article.

Anti-debugging strategy code download:

https://github.com/fourbrother/android_anti_debug

IV. Conclusion

This article mainly introduces several solutions for anti-debugging and anti-cracking in Android applications. The principle of each solution is analyzed in detail. The code also provides a download address. You can run it yourself to see the effect. However, these anti-debugging solutions are not absolutely safe. Later, we will introduce in detail how to solve these anti-debugging functions. However, for the safety of applications, these solutions cannot be ignored. It is better to have them than not!