很多朋友在学PE结构的时候前面几张表都能顺下来比如导入表、导出表、资源表到了重定位表这里就开始犯迷糊。之前我在一个脱壳项目中就吃过亏某样本被强制加载到非默认基址后所有跳转乱成一锅粥后来才意识到是重定位表没有正确处理。这篇长文就把这个表从原理到解析一步步拆开结合我自己调试实测的数据把那些教程里没写的坑也一并列出来。如果你正在学逆向基础、准备写PE解析工具或者调试过程中遇到程序一换基址就崩溃的怪问题这篇文章应该能帮你把重定位表彻底啃下来。1. 为什么PE文件里会有一个重定位表从基址冲突说起1.1 程序被加载到错误的地址每个PE文件在编译链接时都有一个默认的加载基址也就是ImageBase。比如32位程序常见的是0x40000064位程序常见的是0x140000000。链接器在生成代码时很多指令里已经写死了绝对地址这些地址全部是基于默认ImageBase算出来的。问题在于程序运行时不一定能加载到这个默认基址。假设你在写一个小程序双击运行时Windows把它加载到了0x400000这没问题。但如果你同时运行两个一样的程序或者加载一个DLL到某个已经被占用的地址空间系统就会把这个模块挪到别的空闲地址去。程序一旦被挪了窝那些写死的绝对地址就全部失效跳转跳到错误位置数据访问也拿到错误内容程序直接崩掉。这种情况在代码里怎么体现呢下面这段伪代码展示了写入绝对地址的场景00401000 E8 8B000000 call 00401090 ; 指令里直接算出目标地址 00401005 A1 00304000 mov eax, dword ptr [00403000] ; 变量地址写死如果这个程序被加载到了0x500000那么call 00401090这个跳转依然会尝试去0x401090执行但那里可能已经不是代码了。崩溃就是这么来的。1.2 为什么编译成相对地址不行有人会问为什么编译链接时不直接用相对偏移非要写死绝对地址呢还要搞一张表来修补这不是多此一举吗答案藏在CPU架构和指令设计里。x86体系中call rel32这种相对跳转经过偏移计算后能表示约2GB范围确实不用重定位。但很多指令的寻址方式是mov eax, [address]这种把绝对地址直接编码进指令的形式在动态加载场景下就必须靠重定位来修正。包括全局变量、静态变量、虚表指针、异常处理结构里的回调地址等都可能被写成绝对地址。链接器在生成PE文件时会把所有包含可修复绝对地址的位置收集起来记录在一张表里就是重定位表。加载器加载模块时如果基址和默认ImageBase不一致就会拿着这张表逐项修复。1.3 重定位的本质一个改基址的动作把重定位的修补公式写出来其实很简单新值 原来的值 - 默认ImageBase 实际加载基址也就是说每个重定位项指向一个内存位置那里存放着一个4字节32位或8字节64位的绝对地址。这个地址原本是基于默认ImageBase算出来的我们把它减去默认ImageBase就得到了一个RVA相对虚拟地址再加上实际加载基址就得到修正后的地址。这个默认ImageBase可以在可选头的ImageBase字段里找到实际加载基址在加载器分配内存时决定。理解了上面这个公式后面的解析过程其实就是在找这个位置上存的地址是多少基于哪个RVA算出来的然后按公式修一遍就行。不过重定位表本身的结构比这个公式要复杂几层下面逐步拆开看。2. 重定位表藏在哪里从数据目录到页块到项的三级结构2.1 数据目录里找到重定位表入口PE文件的可选头Optional Header后面跟着一个数据目录Data Directory它是一组IMAGE_DATA_DIRECTORY每项由VirtualAddress和Size组成。重定位表对应的索引是第6项从0开始编号的话是5宏定义是IMAGE_DIRECTORY_ENTRY_BASERELOC。数据目录给的信息是重定位表在整个模块中的RVA起始位置和总大小。拿到这个RVA再结合节区表才能换算成文件里的偏移位置去读取。这一步和定位导入表、导出表的过程完全一样做过PE解析的人应该熟悉。数据目录[5]: VirtualAddress 0x00017000 ; 重定位表的RVA Size 0x00001000 ; 总大小2.2 一个块Block就是一个4KB页面的重定位集合重定位表不是简单的一串地址而是按页组织的。因为重定位项只记录一个地址在页内的偏移基址按页来划分的话每个项只需要一个WORD就能表示一个重定位点能省不少空间。每个块对应一个4KB对齐的内存页块头是一个IMAGE_BASE_RELOCATION结构八个字节typedef struct _IMAGE_BASE_RELOCATION { DWORD VirtualAddress; // 这一页的起始RVA页对齐 DWORD SizeOfBlock; // 整个块的大小包含块头本身 } IMAGE_BASE_RELOCATION;重点VirtualAddress不是单个重定位点的RVA而是它所在那个内存页的起始RVA。比如0x00017000表示这一块处理的是RVA范围0x17000到0x17FFF之间的重定位项。SizeOfBlock计数的是整块的大小包括这8字节头再加上后面紧跟的一串2字节的重定位项所以后面重定位项的个数可以这样算项数量 (SizeOfBlock - 8) / 22.3 TypeOffset项类型和页内偏移塞在一个WORD里紧跟块头的是一系列TypeOffset每个2字节。它的结构是------------------------------ | 高4位 | 低12位 | ------------------------------ 类型 页内偏移相对于块起始RVA低12位给出的是相对VirtualAddress那一页的偏移也就是说一个重定位点的完整RVA是重定位点RVA 块起始RVA (TypeOffset 0x0FFF)而高4位表示重定位类型。不同类型的含义不同常用的是这几种类型值宏定义含义0IMAGE_REL_BASED_ABSOLUTE仅用于对齐不处理1IMAGE_REL_BASED_HIGH修正地址高16位2IMAGE_REL_BASED_LOW修正地址低16位3IMAGE_REL_BASED_HIGHLOW修正完整32位地址10 (0xA)IMAGE_REL_BASED_DIR64修正完整64位地址x86程序里最常见的是3x64程序里最常见的是10。0是纯占位用的遇到直接跳过就行。2.4 表的结尾标志整张重定位表遍历到头时会出现一个特殊的块VirtualAddress为0同时SizeOfBlock也为0。这是因为重定位表通常按4KB边界对齐存放文件里末尾不足一块的部分会用零填充。我们解析时必须做这个判断否则读到最后越界访问拿到垃圾数据当成重定位项程序直接崩。这里给个经验解析重定位表的终止条件建议同时判断两个条件一是当前块VirtualAddress为0二是SizeOfBlock为0或者小于8。只判断一个可能会因为文件边界尾部的随机数据导致误判。3. 手动解析一遍重定位表把完整流程走通3.1 RVA转文件偏移绕不开的第一步重定位表在数据目录里记录的是RVA但我们在文件里读取数据时需要的是文件偏移。两者之间的关系靠节区表来转。每个节区有VirtualAddress、VirtualSize、PointerToRawData和SizeOfRawData四个关键值。VirtualAddress表示这个节区在内存中的起始RVAPointerToRawData表示它在文件里的起始偏移。偏移量和RVA的差值是一个常数。转换步骤如下1. 遍历节区表找到 RVA 落在哪个节区范围内 2. 偏移差值 该节区的 PointerToRawData - VirtualAddress 3. 文件偏移 RVA 偏移差值如果RVA落在两个节区之间的空洞里或者落在文件末尾之后那就要小心了说明数据目录给的信息有问题或者文件被截断过。拿着一个不存在的重定位表去解析没有意义。3.2 逐个块、逐个项地走完拿到文件偏移后整个解析流程是这样的循环 1. 读取块头 VirtualAddress 和 SizeOfBlock 2. 如果 VirtualAddress 0 且 SizeOfBlock 0退出循环 3. 计算项数量 (SizeOfBlock - 8) / 2 4. 遍历每个TypeOffset - 类型 TypeOffset 12 - 页内偏移 TypeOffset 0x0FFF - 重定位点RVA 块虚拟地址 页内偏移 - 根据类型决定处理方式 5. 跳到下一个块文件偏移 SizeOfBlock这里有个容易想歪的点Step4里TypeOffset 12取的是高4位但TypeOffset本身是16位的右移12位之后剩下的是0到15之间的数。你要是拿typeOffset 0xF000取高四位的话它只是个带权位掩码不等于类型值。正确写法应该是右移不是与运算。3.3 绝对地址计算到底用哪个基址拿到一个重定位点RVA后我们在该地址处读出的4字节是程序原本写死的绝对地址。这个值是基于默认ImageBase算出来的。假设默认ImageBase 0x400000实际加载基址 0x6F0000某个重定位点RVA 0x17020从该重定位点读到的4字节值 0x401030一个全局变量的地址那么修复后的新值计算如下原值的RVA 0x401030 - 0x400000 0x1030 新绝对值 0x6F0000 0x1030 0x6F1030所以要把0x401030改写为0x6F1030这样程序运行到正确位置时取到的地址就是正确的。注意一个细节上面的原值的RVA是我们推算出来的重定位表里记录的是重定位点RVA这两者不是一个东西别混淆。重定位点是存放着绝对地址的那个位置原值的RVA是那个绝对地址本身指向的内容基于默认基址的RVA。修补时改的是重定位点这个位置里的内容不是改重定位点本身。3.4 用一份测试数据走一遍我拿一个简单的32位程序做过一次实际解析重定位表从文件的0x57000处开始第一部分数据如下地址 数据 0x57000 00 70 01 00 ; VirtualAddress 0x17000 0x57004 28 10 00 00 ; SizeOfBlock 0x1028 0x57008 34 30 31 30 ... ; TypeOffset 数组第一块项的个数是(0x1028 - 8) / 2 0x1018 / 2 2060个项每个项2字节正好占了0x1000字节的区域和页大小吻合。我随机挑了其中一个项来分析TypeOffset 0x3034 类型 0x3034 12 0x3 (HIGHLOW32位全地址) 页内偏移 0x3034 0x0FFF 0x034 重定位点RVA 0x17000 0x034 0x17034在文件偏移对应的位置读取4字节得到值0x406010。如果默认ImageBase是0x400000实际加载基址是0x500000那么修正后的值就是0x406010 - 0x400000 0x500000 0x506010这个计算过程在纸上走一遍不难但你真正写代码去解析时会遇到各种各样的坑下一节我把自己的实践过程放上来包括完整代码和验证方法。4. 写一个C解析器从懵圈到跑通4.1 核心数据结构和整体思路我平时解析PE的时候习惯自己先把主要结构定义一遍不依赖别人的头文件这样内存布局自己最清楚。针对重定位表需要这几个结构typedef struct _IMAGE_DOS_HEADER_DATA { WORD e_magic; DWORD e_lfanew; } IMAGE_DOS_HEADER_DATA; typedef struct _IMAGE_FILE_HEADER_DATA { WORD Machine; WORD NumberOfSections; DWORD TimeDateStamp; DWORD PointerToSymbolTable; DWORD NumberOfSymbols; WORD SizeOfOptionalHeader; WORD Characteristics; } IMAGE_FILE_HEADER_DATA; typedef struct _IMAGE_DATA_DIRECTORY_DATA { DWORD VirtualAddress; DWORD Size; } IMAGE_DATA_DIRECTORY_DATA; typedef struct _IMAGE_SECTION_HEADER_DATA { char Name[8]; DWORD VirtualSize; DWORD VirtualAddress; DWORD SizeOfRawData; DWORD PointerToRawData; // 其余字段本解析器用不到 } IMAGE_SECTION_HEADER_DATA;思路很直接先读DOS头拿到e_lfanew跳到PE头再读文件头获知节区数量然后读可选头。可选头里既要取ImageBase还要把数据目录表复制出来。之后用之前说过的RVA转文件偏移方法来定位重定位表。4.2 主循环代码块遍历与项解析先写一个RVA转文件偏移的辅助函数DWORD RvaToFileOffset( const IMAGE_SECTION_HEADER_DATA* sections, int numberOfSections, DWORD rva ) { for (int i 0; i numberOfSections; i) { DWORD vaStart sections[i].VirtualAddress; DWORD vaEnd vaStart sections[i].VirtualSize; if (rva vaStart rva vaEnd) { DWORD delta sections[i].PointerToRawData - sections[i].VirtualAddress; return rva delta; } } return 0; // 没找到就返回0调用方需要检查 }注意这里用了VirtualSize来判断范围而不是SizeOfRawData。因为文件里节区在内存中的有效区域由VirtualSize决定用SizeOfRawData判断的话最后一个节区和文件尾部对不齐时会出错。做完辅助函数主循环代码大概长这样void ParseRelocTable( const char* fileData, DWORD fileSize, DWORD relocRva, DWORD defaultImageBase ) { DWORD fo RvaToFileOffset(sections, nSections, relocRva); if (!fo) { printf(重定位表RVA无效或超出文件边界\n); return; } while (fo 8 fileSize) { DWORD pageRva *(DWORD*)(fileData fo); DWORD blockSize *(DWORD*)(fileData fo 4); if (pageRva 0 blockSize 0) { break; // 表结束 } if (blockSize 8) { printf(非法块大小 0x%X终止解析\n, blockSize); break; } int itemCount (blockSize - 8) / 2; for (int i 0; i itemCount; i) { WORD typeOffset *(WORD*)(fileData fo 8 i * 2); int type typeOffset 12; DWORD pageOff typeOffset 0x0FFF; DWORD relocRvaPoint pageRva pageOff; if (type 3 || type 10) { // 这里要读取重定位点处的值并计算新值 DWORD rva DWORD( fileData ??? // 重定位点还在内存中但当前是文件数据 ); printf(类型%d RVA0x%X\n, type, relocRvaPoint); } else if (type 0) { // ABS项忽略 } else { printf(未知类型 %dRVA0x%X\n, type, relocRvaPoint); } } fo blockSize; } }上面代码里有个关键问题我故意留了???就是重定位点处的数据到底怎么读。如果文件没有被脱壳、没有被修改文件里这个重定位点位置和内存里的内容一致。但如果程序运行后这个地址被自修改代码动过那要以调试器里内存里的实际数据为准。解析静态文件时我们读的是文件数据算出来的是理论上应该存在的内容。4.3 读取重定位点处的值并验证补全那一部分逻辑需要在遍历TypeOffset的时候同时把重定位点的文件偏移也算出来才能读它的值。改写一下核心循环把计算放进去// 重定位点是RVA需要转回文件偏移来读文件数据 DWORD relocPointFo RvaToFileOffset(sections, nSections, relocRvaPoint); if (relocPointFo 0 || relocPointFo 4 fileSize) { printf(重定位点超出文件边界RVA0x%X\n, relocRvaPoint); continue; } DWORD oldValue *(DWORD*)(fileData relocPointFo); DWORD newValue oldValue - defaultImageBase actualImageBase; printf( 块页RVA0x%X 类型%d 页内偏移0x%X 重定位点RVA0x%X 原内容0x%X 修正后0x%X\n, pageRva, type, pageOff, relocRvaPoint, oldValue, newValue );很多人在这一步会漏了重定位点的RVA转文件偏移这一步结果直接拿着relocRvaPoint当文件偏移去读读出来的全是垃圾数据。这个坑我踩过一次最后打印出来的原内容明显不对检查半天才发现是忘了转换。另外提醒一点上面actualImageBase在静态解析时我们是不知道的可以先用0x10000000之类的模拟值做验证或者用调试器动态获取当前模块基址后传入程序里打印对比。4.4 用调试器验证解析结果写完解析器后怎么确认输出是真的正确我的做法是拿一个已知程序做对照。步骤如下1. 用调试器加载同一个程序在入口点断下 2. 查看当前模块基址例如 0x6F0000 3. 在调试器里搜索重定位点RVA对应的内存地址 4. 对比解析器输出的修正后数值是否和内存里实际内容一致举个例子解析器输出某一项重定位点RVA0x17034 原内容0x406010 修正后0x506010假设实际加载基址是0x500000那么内存地址0x500000 0x17034处的4字节内容理论上应该也是0x506010。在调试器的数据窗口里验证一下一致就说明解析逻辑正确。我这样跑过几十个样本结果全部吻合后面才敢把解析函数接入自动分析脚本里用。5. 重定位解析最容易踩的坑一次排查过程的复盘5.1 文件偏移和虚拟地址的换算老是错我最早写解析器的时候图省事直接拿重定位表RVA当文件偏移去读。结果第一个块的头四个字节读出来是00 00 00 00后面跟着一串看似正常的数据解析完整张表全是虚拟地址完全对不上。查了半天才意识到文件里的数据是按照文件偏移排布的而数据目录给的是RVA中间必须经过节区表转换。这事的根因是PE文件在磁盘上和内存中的布局不一致。节区在文件里是连续存放的但映射到内存时按页对齐文件偏移和RVA之间隔了一层映射关系。唯一的办法就是老老实实做下面这步文件偏移 目标RVA - 所在节区虚拟地址 所在节区文件偏移而且前提是目标RVA确实落在某个节区内。如果落在节区外比如数据目录指向的RVA本身就在一个空洞里那很可能是文件被特殊处理过比如EP区被抽取过的加壳程序解析前要能容忍这种情况。5.2 把高4位类型和低12位偏移搞反TypeOffset这个WORD高4位是类型低12位是页内偏移。我一开始写的是int type typeOffset 0xF000; DWORD pageOff typeOffset 0x0FFF;这样取出的type是0x3000这种值而不是3。判断if (type 3)永远不成立导致所有项都被当成ABS结果一张重定位表解析完一个有效项都没有。改成typeOffset 12就正常了。这个问题其实只要打印一次就能发现但写代码的时候很容易顺手就用 0xF000所以专门提出来说一下。还有一点页内偏移这12位舍弃了高4位但有些资料里会说低12位表示相对于页基址的偏移这个相对于页基址不要理解成相对于页内起始地址0x000而是相对于块头里VirtualAddress那个地址。你自己算的时候直接相加就好。5.3 块大小与最后一页的边界SizeOfBlock包括8字节头的整块大小。如果某一块的项数量是奇数那么整个块大小算出来还是对齐到2字节。但块的结束位置并不一定是4字节对齐这个不影响解析因为下一个块直接从fo blockSize读。真正要小心的是最后一页往往不足4KB于是文件内容可能没有填满一个块而SizeOfBlock却显示整个页甚至更大。这种情况下如果文件已经被脱壳或者被截断读到块大小超出文件边界时必须停止解析。我的代码里加了if (fo blockSize fileSize)的检查防止越界。另外还有一个隐性边界问题重定位表在数据目录里给了Size但不代表实际块占据了Size那么大的全部区域。实际有效数据到最后一个块结束就没了后面的零填充区域不算项。遍历的时候唯一可靠的终止标志就是VirtualAddress为0且SizeOfBlock为0而不是用数据目录的Size算总项数。5.4 静态解析与运行时内存的差异静态解析时读的是文件里保存的原始值而程序运行时这些值可能已经被操作系统在加载阶段修改过了。如果你用调试器附加到一个已经运行起来的进程再切入文件去分析重定位表看到的原值可能和文件里的不一样。这个坑我是在分析一个自我保护程序时遇到的。程序加载后把自己代码段做了修改我按文件里的值修复修复完了一运行又崩。后来才明白重定位表在系统加载完模块后它的使命就完成了里面的字段不再有意义。为了更精细地分析就应该静态解析完先记录所有重定位点的RVA然后到调试器里读取这些位置当前的值做修正而不是直接拿文件里的值去算。所以我的建议是如果只是研究PE格式静态解析就行如果真的要为模块打补丁务必同时在内存中验证一遍重定位点的当前值两者经常不一致。5.5 32位和64位重定位项的差异32位程序用HIGHLOW类型3修正一个4字节地址64位程序用DIR64类型10修正一个8字节地址。解析时一定要按类型决定读取长度不能统一读4字节否则64位程序的高4字节会被忽略地址直接错乱。我遇到过一种情况一个64位DLL重定位表里既有DIR64也有ABSABS的类型是0它纯粹是为了把第二项数据填在偶数位置方便对齐。ABS项后面跟着的2字节不是重定位点是填充。解析时必须把ABS跳过否则会误把填充数据当成有效地址打印出来全是奇怪的数值。关于类型的完整列表在最新的WINNT.H里还能看到HIGH、LOW、MIPS_JMPADDR等类型但实际现代Windows加载器主要只处理ABS、HIGHLOW和DIR64三种遇到其他类型直接跳过就行不用做特殊处理。6. 重定位表在实战中的延伸用法6.1 把程序假装加载到错误基址验证自己的解析有一种练习方式我觉得特别适合理解重定位自己修改程序的默认ImageBase然后运行看看会发生什么。具体做法是1. 用十六进制编辑器把PE可选头里的ImageBase从0x00400000改成0x00100000 2. 关闭系统ASLR如果是临时测试可以用链接参数/DYNAMICBASE:NO重新编译一样的程序更干净 3. 运行程序观察崩溃位置如果重定位表是完整的系统加载器会自动把模块加载到新基址并按表修复程序应该能正常运行。反之如果你把重定位表清空再改ImageBase程序一启动就会在第一次跳转时崩掉崩溃的地址往往就在那些被写死的绝对地址附近。这个练习做完你会对没有重定位表会怎样有很直观的认识比我嘴上讲一万句都有用。我做这个实验的时候特意在崩溃点dump了寄存器eip指向的地址永远是0x401xxx附近和预期完全一致。6.2 补丁文件时绝对地址需要同步维护重定位表手动改程序逻辑的时候如果新增的代码里含绝对地址引用比如你想让某个调用跳到新增的补丁区就需要给这个补丁区在新的内存位置留出空间。如果你只是简单地把原来某条指令改成jmp补丁地址并且补丁地址是用绝对地址编码的那这个绝对地址也必须加进重定位表否则程序换基址后补丁区的跳转又会失效。具体操作是在重定位表末尾追加一个新的块块的VirtualAddress设为补丁代码所在页的RVASizeOfBlock设置正确然后追加对应的TypeOffset项。不过这个操作涉及修改文件长度和PE头里的Size字段比写解析器要麻烦不少。实际工作中大多数情况是动态打补丁直接在内存里改完调用约定里的绝对地址反而省事。6.3 重定位表对脱壳和分析脚本的价值脱壳场景里加壳程序经常会破坏或者清空重定位表。这种情况下加载器为了能正常运行只能被迫使用默认基址程序一被强制换基址就会崩溃。如果你在分析某个样本时发现它一加载就崩可以用这个思路去判断看一下模块的重定位表是不是空的或者数据目录里Size是不是0。如果确实为空那崩溃点往往就是壳作者没想到要修的位置比如壳内跳转的绝对地址。写脱壳脚本时重定位表也是一个非常关键的信息源。它能告诉你哪些位置在运行时会被动态修改有些壳的IAT导入地址表处理逻辑会参考重定位信息来定位需要的hook点。我的经验是把重定位表解析结果和导入表、导出表的结果联合起来看经常能找到加壳后残余的明文地址省下不少人工分析时间。6.4 关于压缩重定位表的一些思路作为一个拓展想法既然重定位表里一个页块包含多个项而每个项只有低12位有效、高4位类型还常常重复那么理论上可以做压缩比如用一段连续偏移的差值来记录。某些商业加壳工具就是这么做的它把原始重定位表压缩后藏起来运行前再解压恢复。你如果要做类似的重定位表保护或者体积优化可以按这个思路去设计1. 找出所有重定位点的RVA 2. 按页分组页内按偏移排序 3. 用差值编码代替每次存完整2字节 4. 运行时再重建标准重定位表结构这个方向做深了就涉及壳的重定位修复逻辑了。我在做一个外壳项目时实践过这套流程压缩率通常在30%到50%之间效果还算明显。但必须提醒一句重建重定位表时块的页边界和SizeOfBlock的对齐规则都要对齐否则Windows加载器认不出来。在我自己做调试器的那些日子解析重定位表算是打磨得最频繁的一个功能。每次以为彻底搞懂了结构实际测下来总会在边界情况上翻车——不是忘了过滤ABS项就是把64位程序当32位解析。后来习惯性地把解析器的所有输出都先打日志再用调试器逐项对照验证才慢慢稳定下来。如果你在实战中碰到重定位导致的诡异崩溃建议先用这份日志对比法定位而不是瞎猜。把重定位表这块啃下来后面分析壳、写补丁工具、理解系统加载机制都会轻松很多。
