PEB-动态解析API
在 Windows 平台的安全研究与恶意代码分析中，「动态解析 API」是一类频繁出现的技术：程序不在导入表（IAT）里静态声明它要调用的系统函数，而是在运行时手工在内存中定位系统 DLL、解析导出表、算出目标函数地址后再调用。理解它的原理，既是逆向与二进制安全的基础，也是蓝队识别无导入表样本、加固终端的重要切入点。本文从机制层面梳理这一过程，并补充检测与加固视角，不给出可直接运行的加载器代码。
一、PEB 与 TEB：进程和线程的「档案卡」
PEB（Process Environment Block，进程环境块） 是操作系统在用户态为每个进程维护的一块内存结构，记录了进程运行期的关键全局信息，例如进程参数、可执行文件路径、加载器数据，以及是否处于调试状态等标志。
TEB（Thread Environment Block，线程环境块） 与 PEB 关系最密切，它是「每线程一份」的结构，而 PEB 是「每进程一份」，线程通过 TEB 指向其所属进程的 PEB。
一个直观类比：内核（Ring0）像公司管理层，用户态（Ring3）像部门员工；为了共享「部门在哪、加载了哪些资源、是否正被审查」等信息，系统为每个进程建立了一份存放在用户态的档案，这就是 PEB。
二、为什么需要 PEB 动态解析
正常业务代码不需要关心 PEB——GetModuleHandle、GetProcAddress 等 API 已经在底层封装好了按导入表调用函数的路径。
而动态解析 API 的场景则相反：调用方希望在不依赖导入表、不调用常规定位 API 的前提下，仅凭内存结构找到系统 DLL 并取出函数地址。这类需求的合法用途包括壳/加壳程序自定位、某些运行时链接器与研究性代码；同时在恶意代码里，它被用来隐藏真实导入项、规避基于导入特征的静态检测——这正是安全人员需要理解其结构的原因。
三、PEB 里的加载器数据（Ldr）
PEB 中与「已加载模块」相关的核心字段是 Ldr，它指向 PEB_LDR_DATA 结构，其中维护了三条双向链表，从不同维度记录进程加载的 DLL：
- InLoadOrderModuleList（按加载顺序）：记录 DLL 被映射进内存的先后顺序。典型次序为 主程序 EXE →
ntdll.dll→kernel32.dll/kernelbase.dll→ 其他 DLL。 - InMemoryOrderModuleList（按内存顺序）：设计初衷是按模块基址高低排序，但在现代 Windows 上其实际次序已与加载顺序高度接近。
- InInitializationOrderModuleList（按初始化顺序）：记录模块真正执行入口/DllMain 的先后。由于主程序要等底层依赖初始化完毕才执行自身代码，该链表首位通常是
ntdll.dll，随后是kernel32/kernelbase。
这三条链表是「当前进程加载了哪些模块」的最原始入口，也是动态解析时遍历定位目标 DLL 的数据来源。
四、访问 PEB 的寄存器约定
动态解析通常先从 TEB 反查 PEB，而 TEB 的获取与位数相关：
- x86：
FS段寄存器指向 TEB，其偏移0x30处通常是 PEB。 - x64：
GS段寄存器指向 TEB，其偏移0x60处通常是 PEB 指针。
五、动态解析的整体流程（概念层）
把上述结构串起来，解析过程可拆为「找 DLL」和「找函数」两步，这里只描述逻辑骨架：
第一步：定位目标模块基址。 经由 TEB→PEB→Ldr，选取某条模块链表（常见为按内存顺序的链表）遍历节点，读出各模块的基址与名称，从中挑出所需系统 DLL（如 kernel32）在内存中的基地址。
第二步：把该模块当作一个内存中的 PE 文件来解析导出表。
- 从基址读取 DOS 头，据其定位 NT 头；
- NT 头的可选头中带有数据目录表（Data Directory），导出表通常位于目录首项，可用它拿到导出目录的 RVA；
- 导出表内含三个核心数组：
AddressOfNames（函数名数组，存放导出的函数名字符串）；AddressOfFunctions（函数地址数组，存放函数入口的偏移/RVA）；AddressOfNameOrdinals（序号数组，把名字索引与地址索引对应起来）；
- 遍历函数名数组进行字符串比对，命中目标函数后，经序号数组换算出它在函数地址数组中的位置，最终用「模块基址 + 函数 RVA」得到真实内存地址。
得到地址后即可像普通函数指针一样调用——整条路径没有经过导入表，也没有显式调用常规的模块/函数定位 API。
六、检测视角（蓝队）
理解机制后，可从以下特征识别此类行为：
- 导入表异常：样本导入表极小甚至为空，但运行时却大量调用系统功能，是显著信号。
- 结构遍历行为：对
GS:[0x60]/FS:[0x30]之类 TEB/PEB 约定位置的读取、对模块链表的连续遍历、手工解析导出表三个数组并做字符串比对，均是可 Hook / 可观测的典型指令序列。 - API 地址来源异常：调用目标函数的地址并非来自 IAT，而是运行时计算得出；ETW、内存取证与行为监控可据此发现可疑控制流。
- 结合上下文研判：单独的 PEB 访问并不必然恶意（壳、保护库、研究代码都会用），需与网络外联、进程注入、持久化等行为关联综合判定。
七、加固与缓解
- 开启并依赖现代 Windows 的安全特性（如 CFG、ASLR、控制流相关缓解），降低「运行时计算函数地址再调用」这类手法被滥用的收益。
- 用 EDR / 行为监控采集模块链表遍历、导出表手工解析、空导入表等特征，纳入检测规则。
- 对来路不明的可执行文件与脚本严格落地管控与执行策略（如应用白名单），削弱免杀类加载器的投递价值。
- 研究/教学环境下，将相关实验隔离在独立虚拟机中，避免影响生产系统。
本文技术内容仅用于安全研究、逆向教学与防护检测之目的。请在授权范围内开展分析，遵守《中华人民共和国网络安全法》及相关法律法规，不得用于任何未经授权的攻击、免杀投递或破坏行为。
