Unidbg学习笔记（十）：库函数层补环境

泡泡以安
0 阅读1分钟

Unidbg学习笔记（十）：库函数层补环境

库函数是系统调用的上层封装。很多看起来“必须改 Unidbg 内核”的问题，在库函数层用一个 hook 就能优雅解决。这一层不仅是补环境的“第四个通道”，还是前面三个通道的瑞士军刀。

上一篇把你留在了哪里

第九篇结尾我反复强调一句话：优先在库函数层 hook，少碰 SyscallHandler。

那一篇没解释清楚 “怎么 hook”。这一篇就是来填这个坑的。读完之后你会明白：

  1. 为什么 libc 层 hook 几乎总是比 syscall 层修改更优
  2. 三大 hook 框架（xHook / HookZz / Whale）各自的能力边界
  3. 为什么 __system_property_get 值得单独拉一章
  4. 为什么 free 和 munmap 在 Unidbg 里有时需要特别处理

这一篇是补环境四篇里最“工程化”的一篇 —— 没有大道理，全是实战姿势。

一个开胃菜：同一个问题，两种解法

先看一段 SO 代码：

int do_check() {
    int fd = openat(AT_FDCWD, "/system/bin/su", O_RDONLY);
    if (fd >= 0) {
        close(fd);
        return 1;  // 检测到 Root
    }
    return 0;
}

这是一段经典的 Root 检测。在 Unidbg 里跑会发生什么？取决于你前面的工作：

情况 A：你按第八篇写了 IOResolver，把 /system/bin/su 拦下来返回 failed。openat syscall 进入 SyscallHandler，handler 通过 IOResolver 拿到 failed，最终返回 -1。SO 拿到 -1，认为没 Root。

情况 B：你忘了写 IOResolver。openat 真的去查宿主机文件系统，可能返回成功也可能返回失败 —— 行为不可预期。

但还有情况 C：

如果我能在 SO 调 openat 这个 libc 函数的入口处直接拦下来，根本不让它进入 syscall 流程呢？

这就是库函数层 hook 的核心想法。来看代码：

// 在 libc 的 openat 入口处直接 hook 替换
Module libc = emulator.getMemory().findModule("libc.so");
Symbol openatSym = libc.findSymbolByName("openat");

IHookZz hookZz = HookZz.getInstance(emulator);
hookZz.replace(openatSym, new ReplaceCallback() {
    @Override
    public HookStatus onCall(Emulator<?> emulator, long originFunction) {
        RegisterContext ctx = emulator.getContext();
        // openat 第二个参数是 path
        Pointer pathPtr = ctx.getPointerArg(1);
        String path = pathPtr.getString(0);

        // 黑名单路径直接返回 -1, 不让请求传到下层
        if (path.equals("/system/bin/su") || path.equals("/sbin/magisk")) {
            return HookStatus.LR(emulator, -1);
        }
        // 其它路径走原函数, 让 IOResolver / 默认 syscall 处理
        return HookStatus.RET(emulator, originFunction);
    }
});

这段代码的威力在于：

  • 不需要写 IOResolver
  • 不需要改 SyscallHandler
  • 不依赖 Unidbg 的内部行为
  • 自带条件分支（“黑名单路径返回 -1，其他路径走原函数”），逻辑清晰

这就是这一篇要讲的方法论：库函数层是补环境的“超级入口”。下面看为什么。

库函数和系统调用的关系

要理解为什么库函数层好用，先看这两层在调用栈上的位置。

库函数层与系统调用层的关系

关键观察：

  1. 同一个动作（“打开一个文件”）在两个层级都能拦截
  2. 两个拦截点拿到的“信息密度”不同：
    • libc 层：能拿到 C 函数的参数（路径字符串），是高级语义
    • syscall 层：只能拿到寄存器值（路径指针、flags、mode），是低级语义
  3. libc 层在更“早”的位置 —— 你可以完全绕过 syscall 流程

用一个比喻：补环境像是给一栋楼的外卖订单做拦截。

  • syscall 层 = 厨房门口拦截。订单已经到厨房了，你只能看到一张订单纸条
  • libc 层 = 大堂前台拦截。客户刚进门，你能看到客户的脸、需求、表情，能做出更聪明的决策

libc 层为什么几乎总是赢：

维度libc 层 hooksyscall 层 patch
信息丰富度直接拿 C 字符串、结构体指针只有寄存器值，要自己解析
修改入侵性项目本地代码，零侵入改 Unidbg 内核或反射 hack
可移植性升级 Unidbg 完全不受影响升级时要重新合并 patch
调试体验Java 代码，加 println 即可隔着一层 backend，难调试
自带条件分支是（基于参数判断）是（基于寄存器判断，但难写）
唯一不能做的拦截 SO 内联的 SVC（不走 libc）-

唯一一个 syscall 层赢的场景：当 SO 不走 libc 包装，而是用内联汇编直接发 SVC 指令。这种情况下 libc 层根本不会被调用。但这种 SO 不多，且你可以用 Frida 提前侦察。

库函数的四种类型：分清才好下手

不是所有库函数都需要补。先把库函数分成四类，每类的处理策略截然不同。

库函数的四种类型与处理策略

类型一：系统调用包装型 — 通常不用动

例子：open、close、read、write、mmap、getpid、gettimeofday

特征：libc 函数体非常薄，几乎只是把参数搬到寄存器然后发 SVC。

为什么不用动：Unidbg 的 SyscallHandler 已经处理好了底层 syscall。SO 调 open → libc 进 syscall → Unidbg 把请求转给 IOResolver / 默认实现 → 返回。整条链路畅通，你不需要插手。

例外：当默认 syscall 行为不对（语义偏差，第九篇类型三），且修 syscall 不方便时，可以在这一层 hook。

类型二：环境信息型 — 高频处理对象

例子：__system_property_get、getenv、gethostname、uname、sysconf

特征：返回值是设备 / 系统环境信息，App 经常用来做设备指纹。

为什么必须 hook：

  • Unidbg 默认实现可能返回空字符串（getenv("HOME") → null）
  • 或者返回不真实的值（__system_property_get("ro.product.model") → 默认 “google_sdk_gphone”）
  • App 拿这些值做指纹时，会得到和真机不一样的结果

这是库函数层最大宗的工作。下面专门用一节讲 __system_property_get。

类型三：外部依赖型 — 需要虚拟模块

例子：AAsset_open（libandroid.so）、ANativeWindow_lock、AHardwareBuffer_create、SLObjectItf_*

特征：函数来自 Android 提供的 native 库（libandroid.so / libGLESv2.so / libOpenSLES.so），不是 libc。

为什么麻烦：这些库 Unidbg 默认不加载。SO dlopen("libandroid.so") 时拿到 NULL，或者拿到一个空模块。

处理思路：

  1. 提供这些 SO 的真实文件，让 Unidbg 加载（最干净）
  2. 或者用 Module API 创建一个虚拟模块，把符号填充进去，hook 每个符号
  3. 或者把 SO 调用改写绕过这些库（侵入 SO 二进制，不推荐）

实际工作量：通常占库函数层工作的 10% 左右，主要是音视频、AR、游戏类 SO。

类型四：纯计算型 — 几乎不用碰

例子：strlen、memcpy、memset、strcmp、malloc/calloc（绝大多数情况）、abs、sin/cos

特征：纯算法，不涉及外部状态。

为什么不用动：Unidbg 直接用 ARM 指令执行 libc 里这些函数的代码，结果和真机完全一致。这一类 hook 是徒劳的。

例外：free 和 munmap 在某些加壳 / 反检测场景会异常，需要特殊处理（稍后讲）。

三大 Hook 框架：选哪一个？

Unidbg 生态里有三个主流的 hook 框架。它们的能力边界不同，理解差异之后选型就不再纠结。

三大 Hook 框架的对比

xHook — PLT Hook 的代表

原理：修改 ELF 文件的 PLT/GOT 表，把对外部符号的调用重定向到你的函数。本质是改“我对你的引用”。

// 用 xHook 拦截 SO 对 strlen 的调用
IxHook xHook = XHookImpl.getInstance(emulator);
xHook.register("libapp.so",  // 在哪个 SO 里查找对 strlen 的调用
               "strlen",
               new ReplaceCallback() {
    @Override
    public HookStatus onCall(Emulator<?> emulator, long originFunction) {
        // 这里只会拦到 libapp.so 里调 strlen 的那些点
        // libapp.so 内部自己实现的 strlen 拦不到
        Pointer strPtr = emulator.getContext().getPointerArg(0);
        System.out.println("[xHook] strlen called with: "
                            + strPtr.getString(0));
        return HookStatus.RET(emulator, originFunction);
    }
});
xHook.refresh();  // 必须 refresh, 否则 hook 不生效

特点：

  • 精确：能指定“只 hook libapp.so 里的调用”，不影响其他 SO
  • 限制：只能拦截跨模块调用（A 模块调 B 模块的符号）。如果 SO 内部调用自己的函数，PLT 表里没有这个引用，xHook 拦不到
  • 不能 hook 系统库的内部调用：例如 SO 调 libc 的 printf，printf 内部又调 write —— xHook 拦不到 printf → write 这一步
  • 必须 refresh：忘了 refresh 是新手最常犯的错

适用场景：

  • 你只想 hook 特定 SO 对外部函数的调用
  • 不想影响其他模块
  • 对应的符号在 PLT 表里能找到

HookZz — Inline Hook 的优秀实现

原理：直接在目标函数的第一条指令处插入跳转，跳到你的处理代码，处理完之后跳回原函数（或者跳过原函数）。本质是改“被调用方本身”。

// 用 HookZz 全局拦截 strlen
IHookZz hookZz = HookZz.getInstance(emulator);
Symbol strlenSym = emulator.getMemory().findModule("libc.so")
                            .findSymbolByName("strlen");

// wrap 模式: 原函数会执行, 你可以在前后做事
hookZz.wrap(strlenSym, new WrapCallback<HookZzArm64RegisterContext>() {
    @Override
    public void preCall(Emulator<?> emulator, HookZzArm64RegisterContext ctx,
                         HookEntryInfo info) {
        Pointer str = ctx.getPointerArg(0);
        System.out.println("[HookZz pre] strlen(" + str.getString(0) + ")");
    }

    @Override
    public void postCall(Emulator<?> emulator, HookZzArm64RegisterContext ctx,
                          HookEntryInfo info) {
        long ret = ctx.getXLong(0);  // ARM64 返回值在 x0
        System.out.println("[HookZz post] strlen returned " + ret);
    }
});

// 或者 replace 模式: 完全替换原函数
hookZz.replace(strlenSym, new ReplaceCallback() {
    @Override
    public HookStatus onCall(Emulator<?> emulator, long originFunction) {
        // 直接返回固定值, 不执行原函数
        return HookStatus.LR(emulator, 42);
    }
});

特点：

  • 全局生效：hook 到 strlen 之后，所有调用 strlen 的代码（包括 libc 内部）都会被拦
  • 能拦内部调用：SO 内部的函数互相调用，只要你知道函数地址，就能 hook
  • 两种模式：
    • wrap —— 原函数照常执行，你只观察 / 修改寄存器
    • replace —— 完全跳过原函数，由你提供返回值
  • 限制：必须能找到目标函数的入口地址（符号或绝对地址）
  • 不需要 refresh

适用场景：

  • 想全局拦截某个函数（不限于某个 SO）
  • 需要看 / 改原函数的输入输出
  • 或者完全用自己的逻辑替换原函数

Whale — 适合内存管理函数

原理：和 HookZz 一样是 Inline Hook，但实现细节更适合 hook free / malloc / munmap 这类内存敏感函数。HookZz hook 这些函数时偶尔会因为 trampoline 申请内存导致循环调用，Whale 在这一点上更稳定。

// 用 Whale hook free, 让它变成空操作
// 适用于加壳 SO 中错误的 free 调用导致 Unidbg 报错的场景
IWhale whale = Whale.getInstance(emulator);
Symbol freeSym = emulator.getMemory().findModule("libc.so")
                          .findSymbolByName("free");
whale.inlineHookFunction(freeSym, new ReplaceCallback() {
    @Override
    public HookStatus onCall(Emulator<?> emulator, long originFunction) {
        // 直接 return, 不执行真正的 free
        // 注意: 这会导致内存泄漏, 但 Unidbg 跑一次就退出, 不是问题
        return HookStatus.LR(emulator, 0);
    }
});

特点：

  • 能稳定 hook free / malloc / munmap
  • 用法和 HookZz 类似
  • API 略不同（inlineHookFunction 而非 replace）

适用场景：

  • HookZz hook free / munmap 时不稳定
  • 加壳 SO 触发的内存管理异常

选型速查

我想...用哪个
拦截某个 SO 对外部函数的调用，不影响其他 SOxHook
全局替换某个 libc 函数HookZz replace
看某个函数的输入输出，不改行为HookZz wrap
Hook free / malloc / munmapWhale
处理 __system_property_getSystemPropertyHook（Unidbg 内置，下面讲）

__system_property_get：值得单独一章

这个函数在补环境工作中出现频率极高，高到 Unidbg 专门为它做了一套独立的 hook 机制。

它是什么

__system_property_get 是 Bionic libc 提供的接口，用来读 Android 系统属性：

int __system_property_get(const char *name, char *value);
// 例: __system_property_get("ro.product.model", buf) -> buf 里写入 "MI 10"

App 在 Java 层 Build.MODEL 背后，最终就是调这个 C 函数。Native SO 想拿设备信息时，经常直接调它而不走 JNI，因为：

  1. 比走 JNI 调 Build 类快
  2. 不留 Java 调用栈，反检测时更“低调”
  3. App 加壳后 Java 层符号可能被混淆，C 层的 __system_property_get 不会变

结论：你写一个补环境项目，几乎一定会遇到它。

Unidbg 默认行为为什么不够用

Unidbg 内部其实有一份默认的 system property 表，里面填充了一些常见值：

ro.build.version.sdk = 23
ro.product.brand = google
ro.product.model = google_sdk_gphone
...

问题是：

  • 模型号是 “google_sdk_gphone”，直接告诉 SO 这是模拟器
  • 很多关键属性默认是空字符串
  • 你想伪造的值（比如某个真机的指纹特征）默认表里没有

所以你必须 hook 这个函数，按 SO 请求的 name 返回伪造的 value。

SystemPropertyHook：Unidbg 的“快捷通道”

Unidbg 提供了 SystemPropertyHook 这个内置工具，专门绕过普通 hook 框架的复杂 API：

// 在创建 emulator 之后, loadLibrary 之前注册
emulator.getSyscallHandler().addIOResolver(new MyIOResolver());

// 注册 system property hook
SystemPropertyHook propertyHook = new SystemPropertyHook(emulator);
propertyHook.setPropertyProvider(new SystemPropertyProvider() {
    @Override
    public String getProperty(String key) {
        switch (key) {
            case "ro.product.model":         return "MI 10";
            case "ro.product.manufacturer":  return "Xiaomi";
            case "ro.product.brand":         return "Xiaomi";
            case "ro.build.version.release": return "11";
            case "ro.build.version.sdk":     return "30";
            case "ro.build.fingerprint":
                return "Xiaomi/umi/umi:11/RKQ1.200826.002/V12.5.6.0.RJBCNXM:user/release-keys";
            default: return null;   // 返回 null = 让原函数走默认值
        }
    }
});
emulator.getMemory().addHookListener(propertyHook);   // 必须 attach 到 Memory 才生效

这个工具的内部机制：它走的是 Unidbg 的 HookListener 链路 —— 在 dlsym 解析符号时就把 libc 的 __system_property_get / __system_property_read 重定向到自己的 SVC handler，然后在 handler 里调 propertyProvider.getProperty(key) 取值。这比 xHook（PLT）或 HookZz（inline）都更底层。

选这个层级有两个好处：

  1. 不受 Bionic 版本差异影响。新版 Bionic 里 __system_property_get 走 "找属性句柄 → 读句柄内容" 的两步流程，PLT / inline hook 顶层函数都可能漏拦；SVC 级 hook 把 _get 和 _read 都盖住了
  2. provider 返回 null 自动降级。你只覆盖想伪造的几个 key，其它 key 让 Unidbg 默认表响应 —— 不用一次写完所有属性

三个容易踩的坑

坑 1：忘记 addHookListener

光 new SystemPropertyHook(emulator) 不会生效 —— 它只是把对象构造出来，必须 attach 到 Memory 的 HookListener 链上才会真正拦截符号解析：

emulator.getMemory().addHookListener(propertyHook);  // 别忘

坑 2：在 loadLibrary 之后才注册

// 错误顺序!
DalvikModule dm = vm.loadLibrary(file, false);
SystemPropertyHook propertyHook = new SystemPropertyHook(emulator);  // !!!
propertyHook.setPropertyProvider(provider);
emulator.getMemory().addHookListener(propertyHook);
dm.callJNI_OnLoad(emulator);

__system_property_get 经常在 JNI_OnLoad 里就被调用。如果你在 loadLibrary 之后才注册 hook，JNI_OnLoad 里那波查询已经走了默认值 —— 伪造无效。正确顺序：

// 1. emulator + vm 创建
// 2. 注册 SystemPropertyHook + setPropertyProvider + addHookListener
// 3. loadLibrary
// 4. callJNI_OnLoad

坑 3：xHook 的 PLT 层级假设

xHook 拦的是 SO 通过 PLT 跨模块调用 __system_property_get 的那一刻。两种情况下 hook 失效：

  1. SO 用 dlsym 自取符号地址绕过 PLT —— 这时切到 HookZz 或 Whale 的 inline hook 即可（直接 patch 函数入口，与是否走 PLT 无关）
  2. SO 完全不调 __system_property_get，自己 mmap prop_area 读内存 —— 这就是下一节"四档对抗"里的高/顶档场景，__system_property_get 这个符号本身根本没被使唤，hook 谁都没用，要走"退路 A/B"

遇到 system property 问题，先用内置 SystemPropertyHook——它在符号解析阶段把 _get 和 _read 两个函数同时盖住，新 Bionic 内部的"找属性句柄 → 读句柄内容"两步流程不会漏拦。只有当侦察发现 SO 不调这两个库函数时，才考虑下一节的退路。

当 App 绕过库函数直读内存：SystemPropertyHook 的失效场景

上一节的结论有个隐含前提：App 确实在调 __system_property_get 这个库函数。一旦它不调了，SystemPropertyHook 就彻底没用 —— provider 里 return 再漂亮的值、hook 日志再多，App 根本不走这条路。

现代反检测 App 的四档对抗：

档位App 的做法SystemPropertyHook
低直接调 __system_property_get生效
中调 __system_property_find + 自己 read_callback部分生效（看 hook 打哪层）
高open("/dev/__properties__/...") + mmap + 自己解 trie全废
顶经 __system_property_area__ 符号直接拿 prop_area 指针读内存全废

高档和顶档就是常被抱怨"hook 没软用"的场景。

为什么会变成这样

Bionic 的 property 存储并不是靠函数调用实现，而是一块跨进程 mmap 的共享内存：

/dev/__properties__/properties_serial     ← 全局 serial
/dev/__properties__/u:object_r:xxx_prop   ← 按 SELinux context 分片的 prop_area

每个 prop_area 内部是一棵 trie（prop_bt + prop_info），name/value 直接存在里面。__system_property_get 只是一个"找节点 → 读 value"的便利包装。

Unidbg 启动时会构造一份简化版的 prop_area，填了一些 stub（google_sdk_gphone 之类）。SystemPropertyHook 的 provider 改的是上层 hook 回调的返回值 —— 并不同步写回底层那块内存。

于是会遇到一种 debug 到崩溃的现象：

  • provider 里给 ro.product.model 配了 MI 10
  • 日志显示 hook 被触发了几次，返回 MI 10
  • 但 App 签名结果还是对不上
  • 最后发现它走了另一条路直读 prop_area 内存，拿到的仍是 google_sdk_gphone
先侦察，不要瞎猜路径

三条退路成本差异很大，动手之前先在真机上用 Frida 看 App 走哪档：

// 1. 看它调了哪些 property 库函数
["__system_property_get", "__system_property_find",
 "__system_property_read", "__system_property_read_callback"].forEach(function(name) {
    var addr = Module.findExportByName("libc.so", name);
    if (addr) Interceptor.attach(addr, {
        onEnter: function(args) { console.log(name, "called"); }
    });
});

// 2. 看它有没有直接 open properties 文件
Interceptor.attach(Module.findExportByName("libc.so", "open"), {
    onEnter: function(args) {
        var path = args[0].readCString();
        if (path.indexOf("__properties__") >= 0) console.log("file:", path);
    }
});

侦察结果决定走哪条：

  • 调了 _find + _read_callback → 中档，改用 HookZz 手动 hook __system_property_find，不需要退路
  • 调 open("/dev/__properties__/...") → 高档，走退路 A
  • 既不调库函数也不 open，直接访问 __system_property_area__ → 顶档，走退路 B 或 C

经验上 80% 的"绕过"其实只是中档。你误以为是顶档花时间去折腾 prop_area —— 侦察这一步能省掉一大半无效工作。

退路 A：IOResolver 伪造 properties 文件

适用于 App 直接 open properties 文件然后 mmap 的场景。思路是在 IOResolver 里拦截 /dev/__properties__/ 下所有路径，返回你自己构造的 trie 二进制：

// 注意: FakePropArea 是示意性 API, unidbg 没有官方提供.
// 你需要自己按 bionic/libc/system_properties/prop_area.cpp 实现序列化,
// 或参照本节末尾"模板复用法"从真机 dump 一份现成的 prop_area 二进制
emulator.getSyscallHandler().addIOResolver(new IOResolver<AndroidFileIO>() {
    @Override
    public FileResult<AndroidFileIO> resolve(Emulator<AndroidFileIO> emu,
                                              String pathname, int oflags) {
        if (!pathname.startsWith("/dev/__properties__/")) return null;

        // 按 Bionic 的 prop_area 格式构造 trie
        byte[] propArea = FakePropArea.build()
            .add("ro.product.model", "MI 10")
            .add("ro.product.manufacturer", "Xiaomi")
            .add("ro.build.fingerprint", "Xiaomi/umi/...")
            .serialize();   // 自己实现, 参考 bionic prop_area.cpp

        return FileResult.success(new ByteArrayFileIO(oflags, pathname, propArea));
    }
});

坑点：prop_area 的 trie 是个 memory-mapped 结构，不是简单的键值对序列化 —— App mmap 之后按偏移读指针。要么一比一复刻 bionic/libc/system_properties/prop_area.cpp（工作量不小），要么从真机把一份真实的 prop_area dump 下来作为模板，只替换关键字段的 value（工程上更省事）。

封装一次可以全项目复用，是最值得沉淀的退路。

退路 B：直接伪造 prop_area 内存

适用于 App 不 open 文件、而是通过 __system_property_area__ 符号或硬编码地址直读内存的场景。思路是找到 Unidbg 内部那段 prop_area 内存，按 trie 格式原地插入节点：

// 从导出符号拿 prop_area 指针
Symbol paSym = libc.findSymbolByName("__system_property_area__");
UnidbgPointer paPtr = UnidbgPointer.pointer(emulator, paSym.getAddress());
UnidbgPointer propArea = paPtr.getPointer(0);

// 按 prop_bt / prop_info 布局把节点写进去
// 细节参考 bionic prop_area.cpp 的 find_prop_bt / find_prop_info

这一步的复杂度和退路 A 里那个 FakePropArea.build() 等价 —— 都是在实现"trie 序列化"，区别只是写到文件 vs 内存。

为什么还要单独讲它：如果 App 完全不走任何 libc 函数、也不 open 文件，退路 A 覆盖不了。这时退路 B 是唯一的物理兜底 —— 只要 App 最终从内存里读值、而那块内存是 Unidbg 控制的，你就能让它读到任何东西。

代价也真实：需要真的理解 prop_area 的内存布局，新手在这条路上翻车是常态。

退路 C：放弃属性层，直接 hook App 的解析函数

适用于你不想啃 Bionic 的 trie 格式、或 App 的解析函数有明显特征（大函数、一次处理多个属性、返回结构体）的场景。

既然 App 自己写了解析逻辑，那个解析函数就是普通 SO 函数，用 HookZz replace 掉它：

// 假设静态分析定位到 libxxx.so 的 sub_12340 是它的 property 解析入口
// 签名: int parse_prop(const char *name, char *out_value)
Module libxxx = emulator.getMemory().findModule("libxxx.so");
long parseAddr = libxxx.base + 0x12340;

hookZz.replace(parseAddr, new ReplaceCallback() {
    @Override
    public HookStatus onCall(Emulator<?> emulator, long originFunction) {
        RegisterContext ctx = emulator.getContext();
        String name = ctx.getPointerArg(0).getString(0);
        Pointer outPtr = ctx.getPointerArg(1);

        String value = fakeProperties.getOrDefault(name, "");
        outPtr.setString(0, value);
        return HookStatus.LR(emulator, value.length());
    }
});

为什么它在实战里最常用：

  1. 不需要管 Bionic 内部怎么实现
  2. 一个 hook 覆盖 App 的所有属性查询（App 的解析入口一定是统一的）
  3. Frida 侦察时顺手就能定位到这个函数 —— 它必然出现在调用栈里
  4. 稳定 —— App 再怎么绕 Bionic 也要回到自己的代码

缺点是每个样本都要单独做一次静态分析，不像退路 A / B 那样能沉淀出通用组件。

三条退路选型
侦察到的现象推荐路径
调 _find + _read，不走 _getHookZz hook _find，不用退路
open("/dev/__properties__/...")退路 A（可沉淀为通用组件）
读 __system_property_area__ 或硬编码地址，不 open 文件退路 B（没得选）
App 有明显的自定义解析函数退路 C（最省事）
只做一个样本退路 C
做批量样本、想复用退路 A + 通用 FakePropArea

一句话总结：SystemPropertyHook 不是银弹，它的前提是 App 调库函数。当 App 下沉到内存层，你的防御线也要跟着下沉 —— 文件层用 IOResolver、内存层伪造 prop_area、逻辑层 hook 自定义 parser，三条线按需上。

内存管理函数：free 和 munmap 的特殊处理

库函数层最后一类需要专门处理的，是内存管理函数。它们属于“类型四：纯计算型”的例外。

为什么会出问题

正常情况下 free / malloc / munmap 在 Unidbg 里跑得很好，因为 libc 的 ARM 实现能直接执行。问题出在两类特殊场景：

场景 1：加壳 SO

很多商业加固方案（爱加密、梆梆、360 加固）会在 SO 加载阶段做大量内存分配 / 释放。其中某些 free 调用的指针可能不是堆指针（而是栈指针或常量地址），在真机上 libc 会容忍这种异常调用，但 Unidbg 的 malloc 实现更严格，会抛异常：

java.lang.IllegalStateException: free unknown ptr=0x12340000

场景 2：munmap 异常

类似地，加壳 SO 在解壳后可能会 munmap 一段它自己映射的内存。Unidbg 的 munmap 实现可能因为找不到对应的 region 而报错：

java.lang.IllegalStateException: munmap addr=0xXXXX, length=0xXXXX

处理思路

方案 A：用 Whale 把 free 替换成空操作

// 让 free 直接 return, 不做任何事
IWhale whale = Whale.getInstance(emulator);
Symbol freeSym = emulator.getMemory().findModule("libc.so")
                          .findSymbolByName("free");
whale.inlineHookFunction(freeSym, new ReplaceCallback() {
    @Override
    public HookStatus onCall(Emulator<?> emulator, long originFunction) {
        // 完全跳过原 free, 直接返回
        // 副作用: 内存泄漏 - 但 Unidbg 跑一次就退出, 不影响结果
        return HookStatus.LR(emulator, 0);
    }
});

方案 B：注释 Unidbg 源码里的 throw

如果你的项目允许 fork Unidbg，可以在 MallocImpl.java / MMapBlock.java 等文件里把 throw new IllegalStateException(...) 改成 return -1 或 log.warn(...)。

// 修改前
if (block == null) {
    throw new IllegalStateException("free unknown ptr=0x"
                                     + Long.toHexString(addr));
}

// 修改后
if (block == null) {
    log.warn("free unknown ptr=0x" + Long.toHexString(addr));
    return;  // 容忍, 不抛异常
}

两个方案的取舍：

  • 方案 A 零侵入，但要识别每一个出问题的函数（free / munmap / realloc 各 hook 一次）
  • 方案 B 一劳永逸，但要 fork Unidbg

实战建议：先用方案 A 看看够不够。99% 的加壳 SO 用方案 A 都能搞定。

实战：用 hook 优雅地解决一个困扰两天的问题

把这一篇所有东西串起来，看一个真实场景。

问题描述：

某 App 的 libsign.so 调 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts) 拿"进程消耗的 CPU 时间"作为签名熵源（高频签名场景常用，CPU 时间和墙钟解耦，更难复现）。Unidbg 实现了 0/1/4/6/7 五个 clock_id，唯独没实现 case 2/3/5，会报错：

java.lang.UnsupportedOperationException: clk_id=2

新手做法：fork Unidbg，在 ARM64SyscallHandler 的 clock_gettime 处理里加 case 2。改完编译，等几分钟，跑一次。OK 了。但 Unidbg 升级时这个 patch 没了，你又得重新合并。

老手做法：在 libc 层 hook clock_gettime：

Module libc = emulator.getMemory().findModule("libc.so");
Symbol clockGettimeSym = libc.findSymbolByName("clock_gettime");

IHookZz hookZz = HookZz.getInstance(emulator);
hookZz.replace(clockGettimeSym, new ReplaceCallback() {
    @Override
    public HookStatus onCall(Emulator<?> emulator, long originFunction) {
        RegisterContext ctx = emulator.getContext();
        int clockId = ctx.getIntArg(0);
        Pointer tspecPtr = ctx.getPointerArg(1);

        // 我们只处理 case 2/3 (CPUTIME), 其它 clock_id 走原函数
        // (Unidbg 已经实现了 0/1/4/6/7, 不要重复)
        if (clockId != 2 && clockId != 3) {
            return HookStatus.RET(emulator, originFunction);
        }

        // CLOCK_PROCESS_CPUTIME_ID / CLOCK_THREAD_CPUTIME_ID
        // 用 JMX 拿 JVM 当前线程累计 CPU 时间作为近似值
        long cpuNanos = ManagementFactory.getThreadMXBean()
                                          .getCurrentThreadCpuTime();
        long sec = cpuNanos / 1_000_000_000L;
        long nsec = cpuNanos % 1_000_000_000L;

        // 写入 timespec 结构体
        tspecPtr.setLong(0, sec);   // tv_sec
        tspecPtr.setLong(8, nsec);  // tv_nsec

        // 返回 0 表示成功
        return HookStatus.LR(emulator, 0);
    }
});

这段代码的优雅之处：

  1. 零 Unidbg 侵入 —— 全在你的项目代码里
  2. 精确处理 —— 只拦 case 2/3，其他 clock_id 走原函数（避免影响 Unidbg 已经实现好的 0/1/4/6/7）
  3. 自带降级 —— 如果你想完全替换 clock_gettime，去掉 if (clockId != 2 && clockId != 3) return RET 即可
  4. 可移植 —— Unidbg 升级时这段代码不需要任何改动

这就是"在库函数层处理比改 syscall 优"的真实意义。

库函数层的五条心法

  1. 优先库函数层 —— 99% 的“系统调用问题”都能在这里更优雅地解决
  2. 分清四类库函数 —— 包装型不用动、环境型必须 hook、外部型补虚拟模块、纯计算型几乎不碰
  3. xHook 拦跨模块调用，HookZz 改全局函数，Whale 处理内存 —— 选错框架是最常见的浪费
  4. __system_property_get 用内置 SystemPropertyHook，别 DIY
  5. 加壳 SO 的 free / munmap 异常用 Whale + ReplaceCallback 兜底

总结：四层响应模型走完了

到这一篇为止，你已经完整掌握了第六篇提出的“四层响应模型”：

篇通道你的工具
七JNI（90% 工作量）AbstractJni override
八文件（~8%）IOResolver
九系统调用（少量）优先在 libc 层 hook
十库函数（瑞士军刀）xHook / HookZz / Whale / SystemPropertyHook

每一个通道都有自己的入口、自己的处理范式、自己的常见陷阱。任何一个补环境问题，都可以套用这四个通道之一来定位和解决。

但是 —— 我必须提醒你，掌握四个通道只是补环境的“基本功”。真正的高难度问题不是“哪个 case 没补”，而是另一类完全不同的问题：

环境补得完美无缺，函数调用也没有任何报错，但目标函数返回的是空值或者错值。

这就是初始化问题，是从初级到中级补环境工程师的真正分界线。

avatar
文章
阅读
粉丝