文章总结： 本文详细探讨了在Unidbg模拟器中通过库函数层hook技术进行环境补全的方法。文章指出库函数层作为系统调用的上层封装，能通过hook框架（如xHook、HookZz、Whale）直接拦截函数调用，相比修改syscall层具有信息丰富度高、侵入性低、可移植性强等优势。作者将库函数分为系统调用包装型、环境信息型、外部依赖型和纯计算型四类，并针对每类提出具体处理策略，特别强调环境信息型函数（如__systempropertyget）是补环境的核心场景。文档还对比了三大hook框架的能力边界，并提供了实战代码示例说明如何通过库函数层hook解决Root检测等常见问题。 综合评分： 85 文章分类： 安全工具,技术标准,实战经验,移动安全,逆向分析
Unidbg学习笔记（十）：库函数层补环境
原创
泡泡以安 泡泡以安
泡泡以安
2026年4月24日 10:36 浙江
在小说阅读器读本章
去阅读
库函数是系统调用的上层封装。很多看起来“必须改 Unidbg 内核”的问题，在库函数层用一个 hook 就能优雅解决。这一层不仅是补环境的“第四个通道”，还是前面三个通道的瑞士军刀。
上一篇把你留在了哪里
第九篇结尾我反复强调一句话：优先在库函数层 hook，少碰 SyscallHandler。
那一篇没解释清楚 “怎么 hook”。这一篇就是来填这个坑的。读完之后你会明白：
- 为什么 libc 层 hook 几乎总是比 syscall 层修改更优
- 三大 hook 框架（xHook / HookZz / Whale）各自的能力边界
- 为什么
__system_property_get值得单独拉一章 - 为什么
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，其他路径走原函数”），逻辑清晰
这就是这一篇要讲的方法论：库函数层是补环境的“超级入口”。下面看为什么。
库函数和系统调用的关系
要理解为什么库函数层好用，先看这两层在调用栈上的位置。
库函数层与系统调用层的关系
关键观察：
- 同一个动作（“打开一个文件”）在两个层级都能拦截
- 两个拦截点拿到的“信息密度”不同：
- libc 层：能拿到 C 函数的参数（路径字符串），是高级语义
- syscall 层：只能拿到寄存器值（路径指针、flags、mode），是低级语义
- libc 层在更“早”的位置 —— 你可以完全绕过 syscall 流程
用一个比喻：补环境像是给一栋楼的外卖订单做拦截。
- syscall 层 = 厨房门口拦截。订单已经到厨房了，你只能看到一张订单纸条
- libc 层 = 大堂前台拦截。客户刚进门，你能看到客户的脸、需求、表情，能做出更聪明的决策
libc 层为什么几乎总是赢：
| 维度 | libc 层 hook | syscall 层 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，或者拿到一个空模块。
处理思路：
- 提供这些 SO 的真实文件，让 Unidbg 加载（最干净）
- 或者用
ModuleAPI 创建一个虚拟模块，把符号填充进去，hook 每个符号 - 或者把 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.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 触发的内存管理异常
选型速查
| 我想… | 用哪个 |
| — | — |
| 拦截某个 SO 对外部函数的调用，不影响其他 SO | xHook |
| 全局替换某个 libc 函数 | HookZz replace |
| 看某个函数的输入输出，不改行为 | HookZz wrap |
| Hook free / malloc / munmap | Whale |
| 处理 __system_property_get | SystemPropertyHook （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，因为：
- 比走 JNI 调
Build类快 - 不留 Java 调用栈，反检测时更“低调”
- 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) {
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_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);
}
});
这段代码的优雅之处：
- 零 Unidbg 侵入 —— 全在你的项目代码里
- 精确处理 —— 只拦
CLOCK_BOOTTIME，其他 clock_id 走原函数（避免影响 Unidbg 已经实现好的部分） - 自带降级 —— 如果你想完全替换 clock_gettime，去掉
if (clockId != 7) return RET即可 - 可移植 —— Unidbg 升级时这段代码不需要任何改动
这就是“在库函数层处理比改 syscall 优”的真实意义。
库函数层的五条心法
- 优先库函数层 —— 99% 的“系统调用问题”都能在这里更优雅地解决
- 分清四类库函数 —— 包装型不用动、环境型必须 hook、外部型补虚拟模块、纯计算型几乎不碰
- xHook 拦跨模块调用，HookZz 改全局函数，Whale 处理内存 —— 选错框架是最常见的浪费
__system_property_get用内置 SystemPropertyHook，别 DIY- 加壳 SO 的 free / munmap 异常用 Whale + ReplaceCallback 兜底
总结：四层响应模型走完了
到这一篇为止，你已经完整掌握了第六篇提出的“四层响应模型”：
| 篇 | 通道 | 你的工具 | | — | — | — | | 七 | JNI（90% 工作量） | AbstractJni override | | 八 | 文件（~8%） | IOResolver | | 九 | 系统调用（少量） | 优先在 libc 层 hook | | 十 | 库函数（瑞士军刀） | xHook / HookZz / Whale / SystemPropertyHook |
每一个通道都有自己的入口、自己的处理范式、自己的常见陷阱。任何一个补环境问题，都可以套用这四个通道之一来定位和解决。
但是 —— 我必须提醒你，掌握四个通道只是补环境的“基本功”。真正的高难度问题不是“哪个 case 没补”，而是另一类完全不同的问题：
环境补得完美无缺，函数调用也没有任何报错，但目标函数返回的是空值或者错值。
这就是初始化问题，是从初级到中级补环境工程师的真正分界线。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：泡泡以安 泡泡以安 泡泡以安《Unidbg学习笔记（十）：库函数层补环境》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论