PE文件合并节实战：从设计思路到RVA修正与重定位处理

发布时间：2026/10/21 7:42:47

1. 为什么要折腾“合并节”这件事PE文件结构这个话题写过壳、做过逆向、搞过二进制补丁的人都不陌生。但真正到了要动手改节表、合并节区的时候很多人就卡住了——不是不会改而是改完之后程序跑不起来或者杀软直接报毒又或者系统加载器干脆拒绝加载。我自己第一次做节合并是在一个模拟项目里当时的需求很简单把一个可执行文件里两个相邻的节合并成一个减少节表项数量顺便把文件对齐和内存对齐统一一下。听起来不难但实际操作中踩的坑足够写满两页笔记。所谓合并节指的是把PE文件中两个或多个节区Section在保持数据完整性的前提下合并为单个节区同时更新节表中的相关字段、修改数据目录中的RVA指向、修正重定位信息。这件事的核心价值在于减少节区数量可以简化后续的加密、压缩或注入操作在某些场景下还能缩小文件体积消除节间填充对于做二进制特征修改的从业者来说合并节也是绕过某些静态检测手段的常见前置步骤。这篇文章适合谁看如果你已经了解PE文件的基本结构——知道DOS头、NT头、节表、数据目录大概长什么样但还没有亲手做过节合并那这篇内容就是为你准备的。我会从设计思路讲到具体操作再到问题排查把整个流程拆开揉碎。如果你是完全的新手建议先补一下PE基础否则后面讲RVA换算和对齐的时候会比较吃力。提示本文所有操作均在虚拟机环境中对自行编译的模拟程序进行不涉及任何真实商业软件或系统文件。请务必在隔离环境中练习避免对生产环境造成不可逆影响。2. 合并节的整体设计与思路拆解2.1 为什么选择合并而不是重建面对“减少节区数量”这个需求最直接的想法可能是我重新写一个PE文件不就行了把所有节的数据读出来按新的布局重新组装生成一个全新的可执行文件。这个思路理论上可行但实际代价很高。重建意味着你要处理导入表、导出表、重定位表、资源目录、TLS目录、异常处理目录等所有数据目录的RVA转换任何一个环节出错都会导致程序崩溃。而且重建后的文件与原始文件在二进制层面差异巨大如果后续还需要做特征比对或增量修改会非常麻烦。合并节则是在保留原始文件主体结构的前提下做局部修改。你只需要关注被合并的那几个节其他节原封不动。这样改动范围可控出问题时排查也容易定位。我个人的经验是能用局部修改解决的问题绝不推倒重来。合并节就属于典型的局部修改方案。另一个考量是对齐处理。PE文件有两个对齐概念文件对齐FileAlignment和节对齐SectionAlignment。文件对齐决定节在磁盘上从什么偏移开始存放节对齐决定节在内存中从什么RVA开始映射。合并节时如果两个节的文件对齐和节对齐一致合并后只需要处理数据拼接和RVA调整如果不一致就需要额外做对齐转换。选择合并方案时优先选那些对齐参数相同的相邻节能省掉大量换算工作。2.2 合并节的核心约束条件不是任意两个节都能随便合并的。动手之前必须先确认几个硬性条件第一节的属性必须兼容。每个节在节表里都有一个Characteristics字段标记了该节是否可执行、可读、可写、是否包含代码、是否包含初始化数据等。如果把一个只读节和一个可写节合并合并后的节属性怎么定定成可写会改变原只读节的安全语义定成只读又会导致原可写节的数据无法修改。所以最稳妥的做法是合并属性完全相同的节或者至少是属性包含关系明确的节。第二节在文件中的位置最好相邻。如果两个节在磁盘上中间隔着其他节的数据合并时就需要把中间的数据也搬过来或者做复杂的偏移调整。相邻节合并最简单直接把后一个节的数据追加到前一个节末尾然后删除后一个节的节表项。第三数据目录的RVA指向必须能正确修正。比如导入表在节A里重定位表在节B里合并后节B消失了重定位表的RVA就要重新计算。如果漏掉了某个数据目录的修正程序加载时就会找不到对应数据直接报错。第四重定位信息需要同步更新。如果被合并的节包含需要重定位的地址合并后这些地址的RVA变了重定位表中记录的偏移也要相应调整。这一步最容易被忽略也是合并后程序崩溃的常见原因。2.3 合并策略的选择前并后还是后并前实际操作中有两种合并方向把后一个节合并到前一个节里前并后或者把前一个节合并到后一个节里后并前。两种方式各有适用场景。前并后是最自然的做法。假设节A在节B前面把B的数据追加到A末尾然后删除B的节表项。合并后的节沿用A的名称和属性B的原始数据在文件中的偏移变成了A的末尾偏移。这种方式的优点是A的起始RVA不变所有指向A内部数据的RVA不需要调整只需要调整指向B内部数据的RVA把它们加上一个偏移量A的虚拟大小减去B的原始起始RVA与A起始RVA的差值。后并前则相反把A的数据插入到B前面合并后的节以B为基准。这种方式会导致B的起始RVA前移所有指向B的RVA都要调整改动量更大。除非有特殊需求比如希望合并后的节保持B的名称否则一般推荐前并后。我个人的习惯是永远选择前并后并且优先合并那些在文件中物理相邻、属性相同的节。这样改动最小风险最低。3. 核心细节解析与实操要点3.1 节表结构与关键字段解读在动手之前必须把节表项的结构搞清楚。每个节表项占40个字节关键字段包括字段名偏移长度含义Name0x008字节节名称如.text、.dataVirtualSize0x084字节节在内存中的实际大小VirtualAddress0x0C4字节节在内存中的起始RVASizeOfRawData0x104字节节在磁盘上占用的空间大小PointerToRawData0x144字节节在磁盘上的起始偏移Characteristics0x244字节节属性标志合并节时这几个字段的修改逻辑如下VirtualSize合并后节的虚拟大小原节A的VirtualSize 原节B的VirtualSize再按节对齐向上取整。注意这里不是简单相加因为B的起始RVA可能不是紧接A末尾中间可能有对齐填充。VirtualAddress前并后时保持不变沿用A的VirtualAddress。SizeOfRawData合并后节的磁盘大小原节A的SizeOfRawData 原节B的SizeOfRawData再按文件对齐向上取整。PointerToRawData前并后时保持不变沿用A的PointerToRawData。Characteristics取两个节属性的并集但要注意可写和只读的冲突。注意VirtualSize和SizeOfRawData的区别经常让人混淆。简单记VirtualSize是内存里实际用多少SizeOfRawData是磁盘上占多少。由于对齐的存在SizeOfRawData通常大于等于VirtualSize。3.2 RVA换算与数据目录修正合并节最核心的操作是RVA换算。假设节A的起始RVA是RVA_A节B的起始RVA是RVA_B合并后节B的数据被追加到节A末尾新的起始RVA变成RVA_A Align(VirtualSize_A, SectionAlignment)。那么原来指向节B内部某个地址RVA_B offset的引用现在应该指向RVA_A Align(VirtualSize_A, SectionAlignment) offset。这个换算需要应用到所有数据目录项中。具体来说需要检查以下目录导入表Import Table如果导入表描述符或导入地址表位于被合并的节中需要修正RVA。导出表Export Table导出地址表和导出名称指针都需要修正。重定位表Base Relocation Table重定位块中记录的偏移需要重新计算。资源表Resource Table资源目录树中的偏移需要修正。异常处理表Exception Table如果存在其中的RVA需要修正。TLS表TLS回调数组的RVA需要修正。实际操作中我建议写一个脚本来自动扫描所有数据目录逐个检查其RVA是否落在被合并节的范围内。如果是就按公式修正。手动改容易漏而且一旦漏掉就是加载失败。3.3 重定位信息的同步处理重定位表是合并节时最容易出问题的地方。PE文件中的重定位信息以块为单位组织每个块记录一个4KB页面内所有需要重定位的地址偏移。如果被合并的节包含重定位信息合并后这些地址的RVA变了重定位块中的偏移也要相应调整。具体来说假设重定位块原本覆盖的RVA范围是[RVA_B, RVA_B 0x1000)合并后这个范围变成了[RVA_A Align(VirtualSize_A, SectionAlignment), RVA_A Align(VirtualSize_A, SectionAlignment) 0x1000)。那么块头中的VirtualAddress字段需要更新块内每个重定位项的偏移值保持不变因为它们是相对于块起始地址的偏移。但如果合并导致页面边界变化比如原本两个节各自对齐到4KB边界合并后数据连续存放可能会跨越新的页面边界。这种情况下重定位块需要重新划分。处理起来比较麻烦我的建议是如果被合并的节包含大量重定位信息优先考虑不合并或者选择那些重定位信息较少的节进行合并。3.4 文件对齐与节对齐的统一合并节之前先检查两个节的文件对齐和节对齐是否一致。如果不一致需要先统一。统一的原则是以较大的对齐值为准或者以文件头中定义的FileAlignment和SectionAlignment为准。举个例子节A的文件对齐是0x200节B的文件对齐是0x1000。合并时节B的数据追加到节A末尾追加的起始偏移需要按0x200对齐因为整个文件的FileAlignment是0x200。如果节B原本的数据是按0x1000对齐的追加后可能需要重新调整内部填充。节对齐同理。如果节A的节对齐是0x1000节B的节对齐是0x2000合并后节的VirtualAddress需要按0x2000对齐这会导致节A的起始RVA发生变化进而影响所有指向节A的引用。所以强烈建议只合并对齐参数相同的节能避免大量额外工作。4. 实操过程与核心环节实现4.1 环境准备与工具选型动手之前需要准备以下工具十六进制编辑器用于直接查看和修改二进制数据。我常用的是HxD或010 Editor后者对PE结构有专门的模板解析效率更高。PE解析工具如PEview、CFF Explorer用于快速查看节表、数据目录、重定位表等信息。脚本环境Python加上pefile库用于自动化处理RVA换算和数据目录修正。pefile能解析大部分PE结构省去手动解析的麻烦。调试器如x64dbg或OllyDbg用于验证合并后的文件是否能正常加载运行。虚拟机所有操作在虚拟机中进行避免影响宿主机。提示不要用系统自带的记事本或普通文本编辑器改二进制文件一个字符的差异就可能导致文件损坏。十六进制编辑器是必须的。4.2 第一步分析目标文件的节布局先拿一个自己编译的模拟程序做样本。用PEview打开查看节表Name VirtAddr VirtSize RawPtr RawSize Characteristics .text 00001000 0000A000 00000400 0000A000 E0000020 .rdata 0000B000 00003000 0000A400 00003000 40000040 .data 0000E000 00002000 0000D400 00002000 C0000040 .rsrc 00010000 00004000 0000F400 00004000 40000040从表中可以看出.text和.rdata在RVA上是相邻的0x1000 0xA000 0xB000在文件偏移上也是相邻的0x400 0xA000 0xA400。属性方面.text是代码段可执行、可读.rdata是只读数据段可读。两者属性不完全相同但.rdata的只读属性是.text可读属性的子集合并后如果沿用.text的属性.rdata的数据仍然可读只是多了可执行标志。这在某些安全场景下可能不理想但对于功能验证来说可以接受。更稳妥的选择是合并.rdata和.data两者都是数据段属性更接近。但.data是可写的.rdata是只读的合并后如果沿用.data的可写属性.rdata的数据就变成可写了改变了原语义。所以最理想的合并对象是属性完全相同的节比如两个只读数据节。为了演示完整流程我这里选择合并.text和.rdata并在合并后把属性调整为可执行可读去掉可写标志。4.3 第二步计算合并后的节参数根据前面的分析合并后的节参数计算如下VirtualSize.text的VirtualSize是0xA000.rdata的VirtualSize是0x3000。合并后VirtualSize 0xA000 0x3000 0xD000。按节对齐0x1000向上取整结果是0xD000已经是0x1000的整数倍。VirtualAddress沿用.text的0x1000。SizeOfRawData.text的RawSize是0xA000.rdata的RawSize是0x3000。合并后RawSize 0xA000 0x3000 0xD000。按文件对齐0x200向上取整结果是0xD000。PointerToRawData沿用.text的0x400。Characteristics.text是0xE0000020可执行、可读、包含代码.rdata是0x40000040可读、包含初始化数据。合并后取并集并去掉可写标志结果是0xE0000060可执行、可读、包含代码、包含初始化数据。4.4 第三步数据拼接与节表修改数据拼接的操作很简单把.rdata节在磁盘上的数据从偏移0xA400开始长度0x3000复制到.text节末尾偏移0x400 0xA000 0xA400。等等这里发现一个问题.rdata的起始偏移本来就是0xA400正好是.text末尾。所以实际上不需要移动数据只需要修改节表把两个节表项合并成一个并更新相关字段。但这里有个细节.text的RawSize是0xA000.rdata的RawSize是0x3000两者相加是0xD000。而.rdata的起始偏移0xA400减去.text的起始偏移0x400等于0xA000正好等于.text的RawSize。这说明两个节在磁盘上是紧密相邻的没有间隙。这种情况下合并操作最简单直接删除.rdata的节表项把.text的VirtualSize和SizeOfRawData改为0xD000Characteristics改为0xE0000060。节表项数量从4个变成3个。文件头中的NumberOfSections字段需要从4改为3。4.5 第四步修正数据目录接下来检查数据目录看哪些目录的RVA落在.rdata的范围内0xB000到0xE000。用PEview查看导入表RVA0x0000B100落在.rdata范围内需要修正。导出表RVA0x00000000不存在跳过。资源表RVA0x00010000落在.rsrc范围内不需要修正。重定位表RVA0x0000C000落在.rdata范围内需要修正。其他目录均为0或不在.rdata范围内。修正逻辑.rdata原本起始RVA是0xB000合并后数据被追加到.text末尾新的起始RVA是0x1000 0xA000 0xB000。等等这里发现新起始RVA和原起始RVA相同因为.text的VirtualSize正好是0xA000按0x1000对齐后还是0xA000所以.rdata的起始RVA没有变化。这种情况下数据目录的RVA不需要修正。但这只是巧合实际项目中很少遇到这么整齐的情况。如果.text的VirtualSize是0xA100按0x1000对齐后变成0xB000那么.rdata的新起始RVA就是0x1000 0xB000 0xC000比原来的0xB000多了0x1000所有指向.rdata的RVA都要加0x1000。为了演示修正过程我手动把.text的VirtualSize改为0xA100这样对齐后.rdata的新起始RVA变成0xC000。然后修正导入表RVA从0xB100到0xC100重定位表RVA从0xC000到0xD000。4.6 第五步重定位表处理重定位表位于.rdata中原本起始RVA是0xC000。合并后新起始RVA是0xD000。重定位块头中的VirtualAddress字段需要从0xC000改为0xD000。块内的重定位项偏移保持不变。用十六进制编辑器找到重定位表的位置修改块头的VirtualAddress字段。如果有多个重定位块每个块都要改。4.7 第六步验证与调试修改完成后用PEview重新打开文件确认节表只有3个节数据目录RVA正确重定位表RVA正确。然后在虚拟机中运行该程序观察是否能正常启动。如果程序崩溃用调试器附加查看崩溃地址是否落在修正后的RVA范围内。我实测下来第一次修改后程序无法启动调试发现导入表解析失败。原因是导入表描述符中的OriginalFirstThunk和FirstThunk字段指向的RVA没有修正。这两个字段位于导入表描述符内部需要单独处理。修正后程序正常运行。5. 常见问题与排查技巧实录5.1 合并后程序无法加载这是最常见的问题原因通常有以下几种现象可能原因排查方法加载器直接报错提示不是有效PE文件节表修改错误NumberOfSections与实际节表项数量不一致检查文件头中NumberOfSections字段程序启动后立即崩溃数据目录RVA未修正加载器找不到导入表或重定位表用PEview逐个检查数据目录RVA是否指向有效数据程序运行中崩溃崩溃地址在合并节范围内重定位信息未更新地址引用错误用调试器查看崩溃地址对比重定位表程序功能异常但未崩溃节属性设置错误某些数据被错误标记为可写或不可写检查合并后节的Characteristics字段5.2 重定位块跨页问题如果合并导致数据跨越4KB页面边界重定位块需要重新划分。具体表现是原本一个重定位块覆盖0xB000到0xC000合并后数据从0xC000开始但重定位块头仍然记录0xB000导致重定位应用到了错误地址。解决方法重新计算每个重定位块的起始RVA确保块内所有重定位项的偏移都在同一个4KB页面内。如果跨越页面需要拆分成两个块。5.3 节属性冲突的处理合并只读节和可写节时属性冲突无法避免。我的处理原则是优先保证功能正确其次考虑安全语义。如果合并后的节需要被写入比如包含.data就把属性设为可写如果不需要写入就设为只读。但要注意如果原只读节的数据被错误地标记为可写某些安全软件可能会报毒。提示如果合并后的文件需要过某些静态检测建议合并属性完全相同的节避免属性冲突导致的误报。5.4 文件对齐导致的体积膨胀合并节时如果两个节的RawSize之和不等于文件对齐的整数倍合并后需要填充到对齐边界。这可能导致文件体积反而增大。比如.text的RawSize是0xA00.rdata的RawSize是0x600两者相加是0x1000正好对齐。但如果.text是0xA00.rdata是0x700相加是0x1100按0x200对齐后变成0x1200多了0x100的填充。避免方法选择RawSize之和接近对齐边界的节进行合并或者接受少量体积增加。5.5 实操心得与避坑清单备份原始文件每次修改前先复制一份改坏了可以重来。小步验证不要一次性改完所有字段再测试改一个字段就验证一次出问题容易定位。用脚本处理RVA换算手动算容易出错写个Python脚本自动扫描和修正。注意数据目录的嵌套引用导入表描述符内部的RVA、资源目录树中的偏移这些嵌套引用容易被忽略。重定位表是重中之重合并后程序崩溃十有八九是重定位没处理好。在虚拟机中测试不要在主系统上直接运行修改后的文件万一有恶意行为就麻烦了。6. 合并节的扩展应用与进阶思路6.1 多节合并的顺序选择当需要合并三个以上的节时顺序选择变得重要。我的建议是按RVA顺序依次前并后。比如有节A、B、C先把B合并到A再把C合并到合并后的A。这样每次合并都是相邻节合并改动最小。如果节之间不相邻比如A和C相邻但B在中间就需要先把B移到别处或者选择其他合并组合。这种情况下合并的复杂度会大幅上升建议重新评估是否真的需要合并。6.2 合并节与节区加密的配合在做节区加密时合并节可以减少需要加密的节数量简化加密逻辑。比如原本需要分别加密.text和.rdata合并后只需要加密一个节。但要注意加密后的节属性需要调整为可读可写因为解密时需要写入这可能会触发某些安全检测。6.3 合并节对文件特征的影响合并节会改变文件的二进制布局导致哈希值变化。如果目标文件有数字签名合并后签名会失效。如果文件被某些系统组件引用合并可能导致引用失效。所以在做合并之前必须确认目标文件是否允许修改。6.4 自动化合并工具的设计思路如果经常需要做节合并可以考虑写一个自动化工具。核心功能包括解析PE结构、识别可合并的节、计算合并后参数、修正数据目录、更新重定位表、输出新文件。用Python加上pefile库大概两三百行代码就能实现基本功能。关键是要做好异常处理比如遇到不支持的PE格式或异常节表时能给出明确提示。我在实际使用中发现自动化工具能处理80%的常规情况但遇到特殊节布局或非标准对齐时还是需要手动介入。所以工具的设计原则是自动化常规操作保留手动调整接口。最后再分享一个小技巧合并节之后用PEview的校验功能检查一下文件是否仍然符合PE规范。有些修改工具会破坏PE头中的校验和字段虽然不影响加载但在某些严格环境下可能被拒绝。手动把校验和字段清零或重新计算能避免这类问题。