1.教程 Demo
2.IDEA
3.IDA

系统调用（Syscall）补环境是 Unidbg 模拟执行中一个基础且高级的环节。当原生库（. So 文件）为了性能、对抗或功能需要，绕过标准库（libc）函数，通过 SVC 等底层指令直接向操作系统内核发起请求时，Unidbg 必须能够拦截并模拟这些内核级别的行为。由于 Unidbg 并非一个完整的操作系统，其对内核的模拟是不完备的。如果 so 文件请求了一个 Unidbg 未实现或模拟不完善的系统调用（通过系统调用号 NR 区分），通常会导致模拟流程出错、返回无效数据（如 fstat 对目录返回全零），或进入非预期的逻辑分支，最终使模拟失败或结果失真。因此，系统调用补环境的目的就是识别并接管这些对内核的底层请求，通过自定义 SyscallHandler 提供一个符合目标 so 逻辑预期的模拟行为或返回值，从而“欺骗”so 文件，使其相信自己正与一个真实的 Linux/Android 内核交互。

当 unidbg 遇到一个它无法处理的软中断（SVC）时，通常会打印出如下格式的 WARN 日志：

这个日志包含了定位问题的关键信息：

并且，JNI 调用失败通常会紧跟着抛出 UnsupportedOperationException，并带有清晰的 JNI 方法签名。

解决系统调用问题的通用范式是创建一个继承自 unidbg 原生 SyscallHandler 的子类，并重写或补充其中的方法。
首先，你需要定义一个自己的 SyscallHandler。以 ARM 64 为例：

然后，在构建 Emulator 时，通过 AndroidEmulatorBuilder 将其替换掉默认的处理器。

这是最常见的情况，unidbg 对某个 NR 完全没有实现，直接在 handleInterrupt 处抛出警告。
案例 1：getcpu (NR=168)

在我们的 MySyscallHandler 中，重写 handleUnknownSyscall 方法，捕获未被处理的 NR。

案例 2：statx (NR=291)
statx 是 Linux 中一个现代化的、用于获取文件元数据（metadata）的系统调用。它是 stat, fstat, lstat 的继任者和升级版。

文件的元数据，就是描述文件属性的信息，例如：

statx 相对于旧版 stat 的主要优势：
1.更丰富的信息：statx 可以获取旧版 stat 无法提供的信息，最典型的就是文件的创建时间（birth time, btime）。
2.更高精度的时间戳：旧版 stat 的时间戳只精确到秒。而 statx 可以提供**纳秒（nanosecond）级别的精度，这对于现代文件系统和应用至关重要。
3.更高的效率和灵活性 (Mask 机制)：调用旧版 stat 时，内核会把所有元数据一次性全返回给你，即使你只关心文件大小。statx 引入了一个 mask（掩码）参数，允许调用者明确告诉内核：“我只对文件大小和修改时间感兴趣”。内核就会只获取并返回这些信息，避免了不必要的工作，提高了效率
4.更好的扩展性：它的结构体设计考虑了未来，留有备用字段，方便以后添加新的文件属性而不需要再次设计新的系统调用。
如何填充statx结构:

接下来就是把上面的结构发给 AI 来伪造

Unidbg 实现了该系统调用，但存在缺陷。

案例 1：clock_gettime (NR=113, ARM 64)
clock_gettime(clockid_t clk_id, struct timespec *tp) 用于获取特定时钟的时间。Unidbg 实现了对 CLOCK_REALTIME (clk_id=0) 的处理，但没有实现 CLOCK_PROCESS_CPUTIME_ID (clk_id=2)，导致传入 2 时抛出异常。
解决方案：重写 clock_gettime 方法。

案例 2: sched_getaffinity (NR=123)

有时候，我们会发现某个系统调用的实现在 Unidbg 的父类 ARM64SyscallHandler 中，但该实现方法被声明为 final，导致我们无法像 clock_gettime 那样直接 @Override 它。此外，有些系统调用是在一个巨大的 switch 语句（如 handleSyscall 方法）中处理的，我们只想修改其中一个 case 的行为，同样无法直接重写。

在这种情况下，我们需要在更早的阶段介入。系统调用的最顶层入口是 hook() 方法，它负责接收所有 SVC 中断，解析出系统调用号（NR），然后再分发给具体的处理方法。通过重写 hook()，我们可以在 Unidbg 分发之前“截胡”我们关心的系统调用，实现自定义逻辑。

sched_getaffinity 用于检测当前进程可以运行在哪些 CPU 核心上，这常被用于环境检测或设备指纹生成。
解决方案： 在 hook() 方法中，抢先处理目标 NR，然后“屏蔽”它，避免父类重复执行。

案例 3：fstat (NR=80)

fstat 和 statx 的核心目标都是获取文件元数据，但它们在设计、功能和使用方式上存在显著差异。简单来说，statx 是 fstat 的现代、功能更全面的“超级升级版”。

对照着实现，并伪造一些模拟数据

有些库函数（如 popen）的实现依赖一整套复杂的系统调用（vfork, pipe2, dup2 / dup3, execve, wait4 等），这些都和进程创建、IPC（进程间通信）相关，是 unidbg 的弱项。尝试逐个修复这些系统调用会陷入泥潭。
因此，我们采用一种更高级、更高效的“组合拳”策略：在高层 Hook 函数意图，在底层伪造结果。

案例：修复 popen
popen 函数会执行一个 shell 命令，并创建一个管道，返回一个文件流指针，后续代码可以通过 fread 等函数从这个文件流中读取命令的输出结果。

**第一步：使用 xHook 拦截 popen 调用意图

使用 unidbg 的 Hook 功能（如 xhook），通过 xHook 拦截对 popen 的调用，主要目的不是替换它，而是获取它将要执行的命令字符串，并将其存入 Unidbg 的上下文中，供后续的底层 SyscallHandler 使用。

第二步：在 SyscallHandler 中伪造关键系统调用的结果
当原始的 popen 函数执行时，它会触发一系列系统调用。我们不需要全部实现它们，只需要伪造其中最关键的几个，形成一个逻辑闭环即可。
1. 伪造 pipe2 (NR=59) - 创建通信管道
popen 首先会调用 pipe2 来创建一个管道，这个管道包含一个“读”端和一个“写”端。这是我们注入伪造结果的最佳时机。

2. 伪造 fork - 创建子进程

popen 接着会调用 fork 来创建子进程。在 Unidbg 中，我们无需真的创建一个进程。fork 系统调用的特点是：在父进程中返回子进程的 PID（一个正整数），在子进程中返回 0。由于 popen 的后续流程在父进程中，我们只需要让它以为子进程创建成功了即可。

通过以上组合拳，popen 的执行流程被我们完美地“欺骗”了：
1.它调用 pipe2，得到了两个文件描述符。
2.它调用 fork，得到了一个看似成功的子进程 PID。
3.接下来，父进程会关闭管道的写端，然后从读端 read_fd 读取数据。
4.当它读取 read_fd 时，实际上读取的是我们预设在 ByteArrayFileIO 中的 stdout 字符串。
最终，so 获取到了我们想让它获取的任何结果，而我们完全没有涉及复杂的多进程模拟。

案例 2：补 gettid
gettid 函数详解
在 Linux 内核中，每个线程都有一个唯一的标识符，即线程 ID（TID）。gettid 函数是应用程序获取这个底层 ID 最直接的方式。
1. 它是做什么的？
gettid 是一个 Linux 特有的 C 函数，原型如下：

2. 为什么它在补环境中如此重要？
gettid 是风控和反调试检测的“常客”，因为它能揭示程序运行的线程环境，而 Unidbg 的线程模型与真实设备有本质区别。检测点通常包括：

如果不修补 gettid，Unidbg 环境下的返回值很可能无法通过上述校验，导致 so 认为自己运行在异常线程或模拟器中，从而改变执行路径或直接退出。

3. 修补方法
对于 gettid，最直接有效的修补方式就是使用 Dobby 进行 Inline Hook，强制它返回一个我们期望的值。通常，我们会让它返回当前的进程 ID（PID），以完美模拟“主线程”的行为。

小结:
深入探讨了 Unidbg 中三种高级 Hook 技术以应对复杂的模拟挑战。首先，介绍了针对不同场景（如 final 方法）的系统调用 Hook 策略，通过重写顶层 hook() 方法实现精准拦截。演示了通过高层函数 Hook（xHook popen）与底层 Syscall 伪造（pipe2, fork）相结合的“组合拳”策略，高效模拟复杂调用链。最后，展示了如何应用 Dobby 直接修补 C 库函数（gettid）以绕过环境一致性检测。

放点gemini-2.5-pro的key给表哥们玩玩

完整代码:
ChallengeTenThree:

MySyscallHandler:

百度云
阿里云
哔哩哔哩
教程开源地址
PS: 解压密码都是 52 pj，阿里云由于不能分享压缩包，所以下载 exe 文件，双击自解压

白龙unidbg教程

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！