Android 안티디버깅 관련 대응방안

 

참고

mobile-security.gitbook.io/mobile-security-testing-guide/android-testing-guide/0x05j-testing-resiliency-against-reverse-engineering

Android Anti-Reversing Defenses

IDA 원격 디버깅이 가능하여 네이티브 단에서 대응방안이 필요함

 

1. ptrace 선점하는 자식프로세스 생성
2. 시간체크 함수 만들어서 일정시간 이상이면 디버깅 탐지
3. /proc/self/status 에서 tracerPid 값 확인해서 디버깅 탐지

- Using Fork and ptrace
- Timer Checks
- Checking TracerPid

 

Timer Checks

Debug.threadCpuTimeNanos indicates the amount of time that the current thread has been executing code. Because debugging slows down process execution, you can use the difference in execution time to guess whether a debugger is attached.

 

static boolean detect_threadCpuTimeNanos(){

long start = Debug.threadCpuTimeNanos();

 

for(int i=0; i<1000000; ++i)

continue;

 

long stop = Debug.threadCpuTimeNanos();

 

if(stop - start < 10000000) {

return false;

}

else {

return true;

}

}

 

Checking TracerPid

When you debug an app and set a breakpoint on native code, Android Studio will copy the needed files to the target device and start the lldb-server which will use ptrace to attach to the process. From this moment on, if you inspect the status file of the debugged process (/proc/<pid>/status or /proc/self/status), you will see that the "TracerPid" field has a value different from 0, which is a sign of debugging.

Remember that this only applies to native code. If you're debugging a Java/Kotlin-only app the value of the "TracerPid" field should be 0.

This technique is usually applied within the JNI native libraries in C, as shown in Google's gperftools (Google Performance Tools)) Heap Checker implementation of the IsDebuggerAttached method. However, if you prefer to include this check as part of your Java/Kotlin code you can refer to this Java implementation of the hasTracerPid method from Tim Strazzere's Anti-Emulator project.

When trying to implement such a method yourself, you can manually check the value of TracerPid with ADB. The following listing uses Google's NDK sample app hello-jni (com.example.hellojni) to perform the check after attaching Android Studio's debugger:

 

$ adb shell ps -A | grep com.example.hellojni

u0_a271 11657 573 4302108 50600 ptrace_stop 0 t com.example.hellojni

$ adb shell cat /proc/11657/status | grep -e "^TracerPid:" | sed "s/^TracerPid:\t//"

TracerPid: 11839

$ adb shell ps -A | grep 11839

u0_a271 11839 11837 14024 4548 poll_schedule_timeout 0 S lldb-server

You can see how the status file of com.example.hellojni (PID=11657) contains a TracerPID of 11839, which we can identify as the lldb-server process.

 

Using Fork and ptrace

You can prevent debugging of a process by forking a child process and attaching it to the parent as a debugger via code similar to the following simple example code:

 

void fork_and_attach()

{

int pid = fork();

 

if (pid == 0)

{

int ppid = getppid();

 

if (ptrace(PTRACE_ATTACH, ppid, NULL, NULL) == 0)

{

waitpid(ppid, NULL, 0);

 

/* Continue the parent process */

ptrace(PTRACE_CONT, NULL, NULL);

}

}

}

With the child attached, further attempts to attach to the parent will fail. We can verify this by compiling the code into a JNI function and packing it into an app we run on the device.

 

root@android:/ # ps | grep -i anti

u0_a151 18190 201 1535844 54908 ffffffff b6e0f124 S sg.vantagepoint.antidebug

u0_a151 18224 18190 1495180 35824 c019a3ac b6e0ee5c S sg.vantagepoint.antidebug

Attempting to attach to the parent process with gdbserver fails with an error:

 

root@android:/ # ./gdbserver --attach localhost:12345 18190

warning: process 18190 is already traced by process 18224

Cannot attach to lwp 18190: Operation not permitted (1)

Exiting

You can easily bypass this failure, however, by killing the child and "freeing" the parent from being traced. You'll therefore usually find more elaborate schemes, involving multiple processes and threads as well as some form of monitoring to impede tampering. Common methods include

 

 

이하 생략