获课：999it.top/15441/

手撕Unidbg源码：揭开SO加载与链接的“黑盒”秘密

在逆向工程的江湖里，Unidbg是无数分析师的“神兵利器”。它能让我们在PC上轻松模拟运行Android的SO文件，绕过加密、还原算法。但你是否想过，当你调用loadLibrary的那一刻，Unidbg内部究竟发生了什么？为什么有些SO一加载就报错“符号未找到”，而有些却能丝滑运行？今天，我们就试着“手撕”Unidbg源码，一探SO加载与链接的底层秘密。

第一步：搬运工——SO文件的加载

一切始于loadLibrary。在真实Android系统中，这一步由 linker（动态链接器）完成，它负责从磁盘读取SO文件，映射到内存。而在Unidbg中，这个过程被“虚拟化”了。

当你传入一个SO路径，Unidbg首先会像一个细心的图书管理员，检查文件是否存在，然后将其二进制数据完整读入内存。关键在于内存布局。真实的SO文件包含代码段（.text）、数据段（.data）、只读数据段（.rodata）等。Unidbg会模拟ARM或x86的内存页属性，将这些段映射到模拟器内存的特定地址。此时，SO文件虽然“住进”了内存，但它还是一盘散沙，内部的函数调用地址大多是相对的，甚至很多外部函数（如libc里的printf）还不知道在哪里。

第二步：牵线人——符号解析与重定位

这是最核心、也最易出错的环节：链接（Linking）。

SO文件之间、SO与系统库之间，存在着千丝万缕的依赖关系。比如你的加密SO调用了openssl的AES_encrypt函数。在编译时，这个函数的地址是未知的，编译器会在SO文件中留下一个“占位符”（重定位表）。

Unidbg在加载时，会遍历这张重定位表。它的逻辑非常清晰：

1. 查找依赖：先看这个SO依赖哪些其他库（DT_NEEDED标签）。
2. 递归加载：如果依赖库没加载，先递归加载依赖库。
3. 符号搜索：在所有已加载库的全局符号表中，寻找目标函数（如AES_encrypt）的地址。
4. 地址填充：一旦找到，Unidbg会直接修改内存中“占位符”的位置，填入真实的模拟内存地址。

这就是为什么我们在写Unidbg脚本时，经常需要手动loadLibrary("libcrypto.so")。如果你不提前加载依赖库，Unidbg在遍历重定位表时找不到对应符号，就会抛出经典的UnsatisfiedLinkError。源码中，这一过程通常由ElfLoader类主导，它精细地管理着符号表（Symbol Table）和哈希桶，确保每一次函数调用都能精准跳转。

第三步：欺骗艺术——系统调用的拦截

加载和链接完成后，SO认为自己在真实手机上运行了。但一旦它试图访问文件、获取设备信息或进行网络请求，就会触发系统调用（Syscall）。

这时，Unidbg的另一个核心机制——Syscall Handler登场了。源码中定义了庞大的拦截器列表。当SO执行svc #0（ARM下的系统调用指令）时，CPU模拟器会陷入异常，Unidbg趁机接管控制权。它会查看调用号（如open、read），然后跳转到对应的Java实现方法。

例如，SO想读取/proc/self/cmdline，Unidbg不会真的去读宿主机的文件，而是从内存中构造一个伪造的字符串返回。这种“指鹿为马”的欺骗，正是Unidbg能成功运行复杂SO的关键。如果某个系统调用未被实现，SO就会因无法处理异常而崩溃，这也是我们需要不断补充SyscallHandler实现的原因。

结语

从文件映射到符号重定位，再到系统调用拦截，Unidbg通过精妙的源码设计，在用户态构建了一个微型的Android运行时环境。理解这一过程，不仅能帮我们快速排查“加载失败”的报错，更能让我们在面对加壳、混淆等高级对抗时，知道该在哪个环节下断点、该伪造哪个内存结构。

手撕源码，不是为了成为编译器专家，而是为了在虚拟与现实的边界上，拥有更敏锐的洞察力。下次当你的SO顺利跑通时，不妨在心里向那个默默工作的ElfLoader致敬。