初学安卓安全，记一次android 12的过isDebuggerConnected反调试过程。

函数在native层有两处实现，未附加调试器时用的是这个函数

附加jdb后被替换为这个函数

所以在ida 调试的时候，在libart.so中找到的是图1的函数，实际上在jdb附加后并不会走。我没找到图2的符号......
理论上方法挺多的
1：frida在java层劫持这个android.os.Debug.isDebuggerConnected，返回false。应该是最方便的方法了，但是每次重新调试都要改，还要依赖frida。
2：找到java方法对应的native函数地址，或者映射关系。找到实际的函数地址下断点。
3：修改源码过反调试。
其实还有静态patch，写artloader劫持jni的方式

我最后还是选择了3，修改源码。编译源码，刷机搞了好久...

失败的尝试
先是直接改了 external/oj-libjdwp/src/share/back/vmDebug.c 的
VMDebug_isDebuggerConnected(JNIEnv* env, jclass klass)
让其返回false，但是发现waiting for debugger窗口关不掉。后来发现原因是waitForDebugger函数也是会调用isDebuggerConnected检测调试器是否附加, 因为让其永远返回false，所以这里不会return，它会认为一直没附加调试器，所以等待调试窗口关不掉。

成功的方式
修改安卓sdk调用的isDebuggerConnected 函数的实现，让其直接返回false，并且伪造一个真正的isDebuggerConnectedReal函数提供给waitForDebugger函数使用。

再修改下引用这个函数的地方：

重新编译、刷机，发现调试恢复正常了，反调试也过了。虽然这种反调试比较好过，但是牵扯的东西还是不少的。再往外延伸思考下，frida提供动态hook的平台，伪装sdk接口实现 做的事情其实是相同的。

初学安卓，花费时间比较多在环境搭建、源码编译上。过isDebuggerConnected反调试网上说的很多方法都比较老或者不适用高版本安卓了。原理不怎么复杂，看没人发过，就记录下。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课