基于Xposed绕过某加固的检测

背景

Xposed框架是一款可以在不修改app的前提下（它是全局注入修改的），影响程序运行的框架服务，通过基于xposed框架可以进行开发定制出非常多的强大功能模块，并且在功能不冲突的情况下同时运行。同时xposed框架也是众多APP重点检测对抗的目标对象。

在分析某营业厅app（版本号7.4.0）后，通过加载Xposed模块，某营业厅APP会触发应用崩溃（app crash事件）。

通过分析android的dex代码和Tombstone日志找到检测点，再通过编写Xposed模块绕过堆栈检测。

Xposed框架进行hook功能的时候有几个必须用到的关键函数findAndHookMethod、beforHookedMethod、afterHookedMethod。

日志分析

过滤Error级别的日志，得到以下信息：

导出/data/tombstones/tombstone_18到电脑，查看内存（方法栈）（也可以用MT管理器直接在模拟器或者手机上查看）：

首先通过java.lang.Thread.currentThread获得当前线程对象，然后调用getStackTrace获得StackTraceElement数组，遍历该数组，调用getClassName，再判断是否包含xposed

定位xposed检测

通过Xposed框架进行hook这个app中的Thread.getStackTrace，打印调用栈（函数返回值）：

（如果需要Hook这个app的StackTraceElement.getClassName，打印返回值即可）

打印的日志如下：

通过日志信息，可以看到调用者是java.lang.Runtime.nativeLoad，即so加载时调用（在Native层通过JNI方式进行调用getStackTrace）

分析dex文件

通过使用JEB反编译（也可以用androidkiller、jadx等工具反编译dex文件）classes.dex，通过字符串 的关键信息可以定位到com.secneo.apkwrapper.AW.attachBaseContext：

可以看到加载的是libDexHelper.so（旧版本是在加载，现在改到attachBaseContext了）

由so的加载流程可知，在so中的检测函数的调用要么是在JNI_OnLoad，要么是在.init或.init_array区段。

通过使用IDA动态调试APP，发现该加固是在JNI_OnLoad中调用检测函数（这里怎么用ida动态调试apk就不细分析）。

由于最终还是要调用Java层的getClassName方法，考虑到通用性，可以编写Xposed模块，绕过堆栈检测xposed框架

检测的绕过

XposedHookStackTraceElement.getClassName方法，判断是否包含xposed，如果包含则替换返回值为android.os.Handler

注意：需要在DexHelper加载前Hook，因为该加固是在JNI_OnLoad中调用检测函数。

上面代码是简单的xposed的hook代码功能。

参与借鉴文章

https://bbs.pediy.com/thread-269678.htm

原文始发于微信公众号（哆啦安全）：基于Xposed绕过某加固的检测