逆向实战：基于内存态匿名段分析的 DexProtector 检测绕过策略

1. 从内存视角看 DexProtector 的 Frida 检测

大家好，我是老张，在移动安全这个圈子里摸爬滚打了十来年，跟各种加固方案都打过交道。今天想跟大家聊聊一个老对手——DexProtector，特别是它那套让人头疼的 Frida 检测机制。很多朋友一上来就想直接 Hook System.loadLibrary，结果往往是进程瞬间崩溃，连个日志都来不及看。我踩过这个坑，后来发现，问题的关键往往不在你眼皮底下的那个 so 文件里，而在运行时那片“看不见”的内存里。

DexProtector 这类高级加固方案，早就不是简单地把代码藏进 so 文件那么简单了。它的核心检测逻辑，经常是在运行时动态生成，并加载到一片没有名字、没有文件路径的匿名内存段中执行。这片内存，在 /proc/pid/maps 里显示为 [anon:xxxx]，没有对应的磁盘文件，传统的静态分析工具拿它基本没辙。这就好比对手跟你玩“地道战”，主力部队根本不从正面城门走，而是从地下突然冒出来。

所以，我们今天的思路也得变一变。别再死磕那个明面上的 libdexprotector.so，得把目光转向内存态的动态分析。核心目标就一个：定位并分析 DexProtector 在运行时生成的匿名可执行段，并基于此，构建一套能稳定绕过其 Frida 检测的策略。这套方法不仅针对 DexProtector，对于其他采用类似“内存马”技术的加固方案，也有很高的参考价值。

简单来说，我们要做的不是破解一个固若金汤的城堡，而是在它动态构建防御工事的过程中，找到那个转瞬即逝的“脚手架”，并从这里找到突破口。整个过程充满了动态对抗的乐趣，也非常考验对 Android 运行时和内存管理的理解。

2. 环境搭建与样本初探

工欲善其事，必先利其器。为了确保咱们的绕过策略足够稳健，能在不同环境下复现，我搭建了一套相对干净且可控的实验环境。

2.1 实验环境配置

我用的是一台刷了 LineageOS 21 的 Nexus 5X 手机。选择这个组合，一是因为 Nexus 5X 的驱动和源码开放，调试方便；二是因为 LineageOS 相对纯净，干扰少。Root 方案用的是 Magisk 29.0.0，并搭配了 LSPosed 框架。这里有个关键点：为了对抗基于 ptrace 的检测，我使用了 Zygisk Frida Gadget 模块（sucsand 大佬的开源项目），而不是直接运行 frida-server。Frida 版本是 16.5.2，这个版本比较稳定，社区资料也多。

在电脑端，我强烈推荐使用肉丝（r0ysue）大佬制作的 r0env Kali 虚拟机。这个镜像里集成了逆向分析需要的几乎所有工具和环境配置，能帮你省掉大把折腾环境的时间，让你可以更专注于分析本身。

2.2 目标样本分析

这次我们分析的目标是一个国际连锁酒店的官方 App。从 APKMirror 下载到 Hyatt-6.8.0.apkm 文件后，解压得到 base.apk。用 jadx 打开，直奔 AndroidManifest.xml。

首先找到 application 节点的 android:name 属性，这里是 com.Hyatt.hyt.ProtectedTopHyattApplication。这个类名里的 “Protected” 已经暗示了它的加固身份。再看入口 Activity，是 SplashActivity。打开 ProtectedTopHyattApplication 类，关键逻辑一目了然：

protected void attachBaseContext(Context context) {
    super.attachBaseContext(context);
    try {
        s.a((Context) this);
        System.loadLibrary("dpboot"); // 加载引导库
        wxyrq(); // 调用 native 方法
    } catch (Throwable th) {
        b.fooldg(this, th);
    }
}

紧接着下面还有一堆 native 方法声明。很明显，Java 层只是个“传令兵”，真正的“作战指挥部”在 Native 层。一运行 App，如果不启动 Frida，它能正常进入主页（虽然会提示升级）。但只要一用 Frida 去 attach 或者 spawn，进程立刻闪退，检测反应非常迅速。

3. 深入 Native 层：寻找真正的入口

既然知道战场在 Native 层，第一反应可能就是去 Hook System.loadLibrary。但我实测下来，一 Hook 就崩，说明检测的触发点可能比这个函数调用更早。这时候，我们需要把目光再往下沉，沉到 Android 动态链接器（linker）的层面。

3.1 卡位 __loader_android_dlopen_ext

Android 系统加载 so 库的最终落脚点是 linker 里的 __loader_android_dlopen_ext 函数。在这里下钩子，我们能在 so 被真正映射到进程内存空间的第一时间拿到控制权，看到最原始的加载顺序和路径。

我写了一个简单的 Frida 脚本来 Hook 这个函数：

function hook_dlopen() {
    var android_dlopen_ext = Module.findExportByName(null, "__loader_android_dlopen