Unidbg学习笔记(十):库函数层补环境

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

上一篇把你留在了哪里

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

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

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

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

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

先看一段 SO 代码：

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

这是一段经典的 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 层为什么几乎总是赢：

唯一一个 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 框架。它们的能力边界不同，理解差异之后选型就不再纠结。

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
publicvoidpreCall(Emulator<?> emulator, HookZzArm64RegisterContext ctx,
                         HookEntryInfo info){
        Pointer str = ctx.getPointerArg(0);
        System.out.println("[HookZz pre] strlen(" + str.getString(0) + ")");
    }

@Override
publicvoidpostCall(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.WInlineHookFunction(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 略不同（WInlineHookFunction 而非 replace）

适用场景：

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

选型速查

__system_property_get：值得单独一章

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

它是什么

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

int __system_property_get(constchar *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.setProperty("ro.product.model", "MI 10");
propertyHook.setProperty("ro.product.manufacturer", "Xiaomi");
propertyHook.setProperty("ro.product.brand", "Xiaomi");
propertyHook.setProperty("ro.build.version.release", "11");
propertyHook.setProperty("ro.build.version.sdk", "30");
propertyHook.setProperty("ro.build.fingerprint",
"Xiaomi/umi/umi:11/RKQ1.200826.002/V12.5.6.0.RJBCNXM:user/release-keys");

这个 API 的内部魔法：它不是用 HookZz 或 xHook 在 libc 层 hook __system_property_get，而是 hook 了**更底层的 __system_property_find 和 __system_property_read**。原因是：在新版 Bionic 里，__system_property_get 内部走的不是单一函数路径，而是一套“先找属性句柄，再读句柄内容”的两步流程。直接 hook 上层函数不可靠。

理解到这个程度即可 —— 大多数情况你只需要会用 setProperty 这个 API。

三个容易踩的坑

坑 1：忘记调用 addHookListener

某些 Unidbg 版本要求注册完 SystemPropertyHook 之后还要显式 attach：

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

坑 2：在 loadLibrary 之后才注册

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

__system_property_get 可能在 JNI_OnLoad 阶段就被调用。如果你在 loadLibrary 之后才设置属性，等你的 setProperty 生效时，初始化早就结束了。正确顺序：

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

坑 3：分不清 SVC Hook 和 PLT Hook 的层级

如果你尝试自己用 xHook hook __system_property_get，可能会发现 hook 了但没生效。原因是新 Bionic 的 __system_property_get 内部走的不是简单的函数调用，而是用 __system_property_area__ 全局变量加内联汇编 / 直接读共享内存。xHook 拦不到这一层。

这就是为什么 Unidbg 提供了专门的 SystemPropertyHook —— 它在更底层用一种特殊的 hook 机制处理。遇到 system property 问题，直接用内置工具，不要 DIY。

内存管理函数：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.WInlineHookFunction(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) {
thrownew 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_BOOTTIME, &ts) 拿“开机以来的时间”，把这个值拌进签名。Unidbg 默认实现不支持 CLOCK_BOOTTIME，会报错：

java.lang.UnsupportedOperationException: not supported clock_id 7

新手做法：fork Unidbg，在 ARM64SyscallHandler 的 clock_gettime 处理里加 case 7。改完编译，等几分钟，跑一次。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);

// 我们只处理 BOOTTIME, 其它 clock_id 走原函数
if (clockId != 7) {
return HookStatus.RET(emulator, originFunction);
        }

// CLOCK_BOOTTIME = 单调时间 + 一个固定的"开机时长"
// 假设设备已开机 6 小时
long now = System.nanoTime();
long sec = now / 1_000_000_000L + 6 * 3600;
long nsec = now % 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. 精确处理 —— 只拦 CLOCK_BOOTTIME，其他 clock_id 走原函数（避免影响 Unidbg 已经实现好的部分）
3. 自带降级 —— 如果你想完全替换 clock_gettime，去掉 if (clockId != 7) 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 兜底

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

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

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

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

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

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