MFC/C++实现PE文件加壳工具：原理与实战解析

简介：一份面向软件开发者与安全研究人员的MFC PE加壳工具源码工程。基于Windows 10与VS2015开发，核心功能包括向目标PE添加自定义代码、代码段加密压缩后仍可正常运行，并设有密码验证弹框；还实现了重定位修复、花指令混淆、反调试及动态非对称加密，适合用于软件保护或恶意软件防护对抗研究。压缩包共38个文件，以h/cpp源码为主，包含11个头文件与8个C++源文件，另有VS工程文件（sln/vcxproj/filters）、dll/lib运行依赖以及rc资源文件，整体仅448KB，结构清晰便于按模块阅读。目前已有184人学习浏览，适合熟悉C++并希望深入PE结构、壳技术与逆向对抗的读者。通过源码可直观理解壳加载流程与代码段压缩加密的落地方式，配合txt说明能快速搭建编译环境并二次开发，是学习手动加壳、反调试与花指令实战的参考项目。 做软件保护这块也快十年了，说实话，市面上主流的商业保护壳、开源壳我都拆过不少，但要说真正把PE文件格式吃透，还是得自己动手写一个壳。这个“MFC版本PE文件壳实现”的项目，本质就是用MFC/C++写一个完整的加壳工具，把一个正常的EXE或DLL加密重组，运行时可自行还原并跳转到原始入口点。它解决的问题很直接：保护你的程序不被轻易静态分析、反汇编，防止别人拿反编译工具直接扒逻辑。适合对PE结构有基础认识、想深入理解程序加载过程、或者需要给自家软件做轻量级保护的朋友参考。

我先说结论：这个项目做完，你对PE文件的理解会上一个台阶，很多以前看不懂的报错、运行机制会瞬间通透。整个壳的核心就三件事——给目标程序加一个节区、把原来的代码加密藏好、在运行时用一段自己写的代码解密还原并交还控制权。听起来简单，实际操作里有大量细节坑，下面我一步步拆开讲。

1. 项目整体设计与核心思路拆解

1.1 PE文件壳到底在解决什么问题

先理清一个概念：壳（Packers / Protectors）本质上是一段“引导程序”。加壳器把原始程序的代码和数据加密或压缩，然后在PE文件里额外附加一段自己的代码。程序启动时，系统按正常流程加载这个PE，但入口点已经被修改成了壳代码。壳代码先运行，把原始代码还原到内存中，再把控制权交还给程序原本的入口点（OEP，Original Entry Point）。

这个机制能解决什么问题？最常见的是防静态分析。没有壳的程序，用IDA、x64dbg打开直接就能看到逻辑。加了壳以后，静态文件里的代码是加密后的垃圾数据，分析工具直接读出来毫无意义。另外，壳还可以做反调试、反内存转储，但这些属于进阶功能，我这个项目重点实现的是加解密和跳转还原这条主线，先把地基打好。

有人会问：现在市面上有现成的UPX、VMProtect、Themida，为什么还要自己写？这个问题我当初也想过。自己写壳最大的价值在于深度理解——你知道了IAT（导入地址表）、重定位表、节区对齐这些概念在实践中是怎么配合的，以后不管是做逆向分析还是做漏洞研究，基本功都会扎实很多。而且商业壳的特征码明显，有些场景需要自定义壳来避开特征识别，这时候自己写一个基础壳就很有必要。

1.2 为什么用MFC/C++这套技术栈

标题里定了MFC，这里说下我的选型和取舍。MFC在现在的开发圈子里确实不算新潮了，但它做桌面工具确实方便。加壳器本身是个GUI程序，涉及文件选择、进度显示、配置项管理，MFC的CFileDialog、CString、CFile这些类能省大量时间。同时MFC基于Win32 API，和内核打交道的能力一点没丢，读写文件、映射内存、修改PE结构这些操作都可以直接用API完成。

不过要分清一个边界：MFC只是用来写“加壳器”这个宿主程序，参与实际解密的“壳代码”（也就是塞进目标程序的那段引导代码）反而是用纯C和Win32 API写的，甚至关键部分要手动用汇编控制寄存器。原因很简单，壳代码运行在目标进程里，如果你把一大坨MFC框架代码塞进去，光初始化MFC运行时就得加载一堆依赖，体积大、易错、兼容性差。实践中，壳代码最理想的状态是“位置无关代码”（PIC），尽量只依赖kernel32.dll里少数几个API，用GetProcAddress动态找到需要的函数入口再调用。

这里有个取舍值得展开。开发时，加壳器与壳代码虽然是两个不同程序，但必须放在同一个解决方案里统一编译。编译加壳器时，把壳代码编译成独立的二进制文件（或者直接内嵌为字节数组），加壳器再把这个二进制整体当作数据附加到目标PE的尾部节区里。这种“两段式”结构是这个项目的关键设计之一。我在做的时候把壳代码单独建了一个子项目，配置成不依赖MFC的运行库，生成的机器码全部位置无关，这样拷贝到哪里都能运行。

1.3 整体架构设计

整个项目在架构上分成三个相对独立的模块：

• 加壳器（MFC GUI程序）：加载目标EXE/DLL，解析PE结构，完成加密、添加节区、修改入口点、重建导入表等操作，最后输出新的文件。
• 壳代码（Stub）：编译成独立的二进制，运行时负责解密原始节数据、重建必要的PE数据结构，最后跳转到OEP。
• 公共工具库：负责PE结构体定义、加解密算法、字节流处理等公共逻辑。

这三个模块的依赖关系是单向的：加壳器读取壳代码的二进制数据，把它注入到目标文件里；壳代码不依赖加壳器，独立工作。这种分离让调试变得很方便——你可以先把壳代码编译好，单独在一个测试EXE里验证解密逻辑是否正确，确认无误后再集成到加壳器里。

2. PE文件格式与壳的原理基础

2.1 壳最关心的PE结构组成部分

PE文件格式是Windows可执行文件的标准格式，从偏移0开始的DOS头（IMAGE_DOS_HEADER）以“MZ”标志开场，里面有个关键字段叫e_lfanew，它指向真正的PE头（IMAGE_NT_HEADERS)。这个PE头里包含了文件头（IMAGE_FILE_HEADER）和可选头（IMAGE_OPTIONAL_HEADER），可选头里存放着程序入口点RVA、镜像基址、节区对齐等信息。

然后是节区表（IMAGE_SECTION_HEADER数组）。每个节区都有名字（.text、.data、.rdata等）、虚拟大小（VirtualSize）、虚拟地址（VirtualAddress）、原始数据大小（SizeOfRawData）、原始数据偏移（PointerToRawData）以及节区属性（Characteristics，比如可读、可写、可执行）。这些参数是壳必须处理的——加壳时要把原始节区的数据加密，加密前得先按这些字段定位到文件里的真实字节；运行时壳代码要解密，也得知道每个节区的虚拟范围。

再往下是几个目录表（DataDirectory），位置在可选头的最后。对壳来说最重要的两个目录是导入表（Import Table）和重定位表（Base Relocation Table）。导入表记录了程序用了哪个DLL的哪些函数，加载器靠这个建IAT；重定位表则记录了文件里所有需要修正地址的位置，当程序加载的基址和PE头里声明的ImageBase不一致时要逐项修正。这两个表在壳的实现里最容易踩坑，后面我会专门讲。

忠告：我见过不少新手在写壳时跳过导入表和重定位表的处理，只做加密和跳转，结果程序一运行就崩。原因是壳代码本身用了导入表，或者解密还原后原始IAT映射地址不对。PE结构是一个整体，缺一环都不行。

2.2 加壳与运行时还原的本质流程

把这个流程画在脑子里比任何代码都重要：

加壳阶段（静态，在文件上操作）：

1. 解析目标PE，读取所有节区数据。
2. 对每个节区的原始数据进行加密（我用的是可变密钥的异或算法，密钥和文件大小、入口点等参数混合生成）。
3. 在文件末尾追加一个新节区（比如叫.hes或.sec），这个节区用来存放壳代码和加密后的密钥等数据。
4. 修改PE头的NumberOtSections（节区数目）字段，更新SizeOfImage使其包含新节区。
5. 清空或保留原导入表（如果壳代码自建IAT，可以选择把原导入项转移进壳代码处理区）。
6. 把AddressOfEntryPoint指向新节区里壳代码的偏移。

运行阶段（动态，内存中操作）：

1. 系统正常加载PE，映射节区到内存，然后从入口点开始执行。
2. 控制权落在壳代码首条指令，壳代码定位自己的位置（通过call/pop技巧或当前位置计算）。
3. 壳代码逐步完成：解密密钥，遍历原始节区，把各节区数据按“存储位置 -> RV地址”写回内存。
4. 重建IAT：调用LoadLibrary/GetProcAddress把API地址写回导入表指向的地址区域。
5. 处理重定位表（如果基址变了），把每个需要重定位的字段加上基址差值。
6. JMP到OEP，原始程序开始正常执行。

这个流程最反直觉的地方在于第3步：加壳器加密的是“文件里的字节”，而壳代码解密后要放回的是“内存映射后的位置”。文件偏移和虚拟地址是两个坐标系，中间隔着节区偏移差。代码里必须时刻用RVA和文件偏移的换算公式：文件偏移 = RVA - 节区VirtualAddress + 节区PointerToRawData。这个公式写错，要么解密出来的数据是错的，要么直接写入非法内存地址。

3. MFC环境下PE壳的实操实现

3.1 搭建加壳器框架与文件处理

我用VS2013 + MFC的对话框程序作为加壳器宿主，界面很简单：一个“选择文件”按钮、一个“开始加壳”按钮、一个进度条、一个编辑框显示日志。MFC的好处在这里体现得很快，CFileDialog几行代码就能调起文件选择窗口，CString处理路径字符串也很方便。

这里会碰到一个MFC新手都绕不开的问题，就是热词里那个“CString转char”。MFC在VS2013里默认使用Unicode字符集，CString实际是CStringW，但PE文件解析和文件读写API（比如CreateFileA/CreateFileW）在字符集上的要求很严格。我统一用CStringA与CString的转换逻辑：CString strPath; CStringA strPathA(strPath); 然后把strPathA传递到ANSI版的API里。注意，MFC项目属性里如果设置了“使用Unicode字符集”，CString就是宽字符，直接用CreateFile会匹配到CreateFileW，没有什么问题，但如果你的代码里混用了char*，一定要转成CStringA再用，否则中文路径会变成乱码。

文件读取我用CFile类，一次性读入整个文件到一个BYTE缓冲区里。对小文件（几十MB以内）这种做法简单直接，不容易出错。读取后立刻校验DOS头MZ标志和PE签名，不是合法PE就弹窗提示并终止。

3.2 关键的PE解析与加密过程

拿到了文件缓冲，紧接着就是按结构体强转解析PE。解析的代码很枯燥，核心就是获取几个关键指针：

PIMAGE_DOS_HEADER pDos = (PIMAGE_DOS_HEADER)pFileData; PIMAGE_NT_HEADERS pNt = (PIMAGE_NT_HEADERS)(pFileData + pDos->e_lfanew); PIMAGE_FILE_HEADER pFile = &pNt->FileHeader; PIMAGE_OPTIONAL_HEADER pOpt = &pNt->OptionalHeader; PIMAGE_SECTION_HEADER pSec = IMAGE_FIRST_SECTION(pNt);

IMAGE_FIRST_SECTION是个宏，它会根据可选头的大小精确计算出第一个节区表的位置，强烈建议直接用这个宏而不是自己手动算偏移。接下来遍历所有节区，分别处理名称、VirtualSize、VirtualAddress、PointerToRawData、SizeOfRawData这些字段。

加密这个环节我选择了异或（XOR）算法，原因很务实：速度极快、实现简单、加解密是同一个操作。密钥是从目标文件本身派生的——取文件大小、入口点RVA、PE时间戳三者混合，经过一个简单的线性变换生成若干字节的密钥流。这样每个文件加壳后的加密结果都不同，避免一钥走天下的尴尬。代码大致是这样：

void EncryptSection(BYTE* pSectionData, DWORD dwSize, DWORD dwKey) { DWORD key = dwKey; for (DWORD i = 0; i < dwSize; i++) { pSectionData[i] ^= (BYTE)(key & 0xFF); key = (key * 1103515245 + 12345) & 0xFFFFFFFF; // LCG伪随机序列 } }

加密后要顺手把节区Characteristics设定成可信状态（去掉写权限或执行权限的冲突组合），避免自定义节区出现不必要的属性，同时也能干扰一些粗浅的PE分析工具识别记忆中的文件布局。

3.3 壳代码的编写与入口跳转

壳代码是这个项目的灵魂。我把它设计成一段位置无关的汇编/C混合代码，给它单独开一个编译单元。它的核心任务回顾一下：解密原始节区、重建IAT、处理重定向、跳OEP。

在MFC工程里混写壳代码有一点要注意：不要把壳代码编译进加壳器的代码段，因为加壳器运行时壳代码根本不会执行，它只是作为数据被注入到目标文件里。我现在是这样做的：用一个独立的C++源文件写壳逻辑，但用__declspec(allocate(".stub"))把关键数组放到自定义节区，再在加壳器里用链接器选项把这个数组导出成二进制字节流。或者更简单一点的方案，直接用#pragma section和#pragma comment(linker, "/SECTION:.stub,R")把壳代码放到命名的节区，然后加壳器运行时通过GetModuleHandle + GetProcAddress找到该节区地址，把内存内容作为字节数组写入目标文件。不同编译器处理细节略有差异，但思路一致。

壳代码里获取API地址有套固定流程：

// 通过FS段寄存器获取PEB，再拿ImageBase，解析导入表找kernel32.dll的GetProcAddress __asm { mov eax, fs:[0x30] // PEB mov eax, [eax + 0x0C] // LDR mov eax, [eax + 0x14] // InMemoryOrderModuleList mov eax, [eax] // 第二个模块，通常是ntdll // ... 遍历模块列表找kernel32 }

这段汇编的逻辑是：Windows所有进程的PEB（进程环境块）在FS段寄存器的0x30偏移处，里面有一个加载模块链表的头指针，遍历链表就能拿到kernel32.dll的基址。拿到模块基址后，再解析它自己的导出表，找GetProcAddress，然后一切都好办了，后续API都通过GetProcAddress动态取地址。这套东西第一次写会觉得很绕，但我把它做成了一个固定函数，之后复用很稳。

当壳代码完成所有还原动作后，最后一步是跳转OEP：

// 压入OEP地址，然后ret出栈实现跳转 __asm { mov eax, dword ptr [oepAddress] jmp eax }

别忘了跳转之前要把寄存器环境恢复成原始程序启动时的样子，尤其是EAX等寄存器最好归零或恢复原始值。我在这里栽过跟头，原始程序一启动就崩溃，后来发现是壳代码运行后寄存器状态不对。标准的做法是在壳代码入口先备份上下文，跳OEP前先恢复。但有一种更精细的修复思路：让原程序入口从初始化的“壳代码入口处”执行，OEP只需要对齐EIP，不用刻意还原寄存器，因为原始程序自己的启动代码本来就会初始化寄存器。不过为了稳妥，我依然保留了pushad/popad的完整备份还原逻辑。

3.4 完整联调：从加壳到运行验证

联调是暴露问题最多的环节。我的做法是这样：先用一个用MFC写的“最简测试程序”（一个对话框，显示“OK”按钮）作为加壳目标。这个测试程序很小、逻辑简单，加壳后出问题容易定位。加壳前先记录它原始入口点，加壳后用x64dbg打开加壳后的文件，单步跟踪壳代码的每一步：走到壳代码入口时看寄存器是否符合预期、解密循环结束看内存数据是否恢复成原始代码、IAT重建完检查API地址是否有效。

整体加壳集成代码的主流程我用伪代码说明：

// 1. 读取目标PE到缓冲区 BOOL bSuccess = ReadPeToBuffer(targetPath, &pFileBuf, &dwFileSize); // 2. 解析PE头，获取各节区信息 PIMAGE_SECTION_HEADER pSections = IMAGE_FIRST_SECTION(pNt); WORD wOldNumSections = pNt->FileHeader.NumberOfSections; // 3. 对每个节区数据加密 for (WORD i = 0; i < wOldNumSections; i++) { DWORD dwRawOffset = pSections[i].PointerToRawData; DWORD dwRawSize = pSections[i].SizeOfRawData; EncryptSection(pFileBuf + dwRawOffset, dwRawSize, deriveKey(i)); } // 4. 在文件末尾追加壳代码二进制 AppendData(pFileBuf, &dwFileSize, g_stubData, g_stubDataSize); // 5. 新增节区表项 PIMAGE_SECTION_HEADER pNewSection = &pSections[wOldNumSections]; ZeroMemory(pNewSection, sizeof(IMAGE_SECTION_HEADER)); strncpy_s((char*)pNewSection->Name, ".hes", 5); pNewSection->VirtualAddress = 上一个节区VirtualAddress + ALIGN_UP(上一个节区VirtualSize, pOpt->SectionAlignment); pNewSection->SizeOfRawData = ALIGN_UP(g_stubDataSize, pOpt->FileAlignment); pNewSection->PointerToRawData = ALIGN_UP(dwFileSize, pOpt->FileAlignment); pNewSection->Characteristics = IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_EXECUTE | IMAGE_SCN_CNT_CODE; // 6. 更新PE头与入口点 pNt->FileHeader.NumberOfSections++; pOpt->SizeOfImage += ALIGN_UP(...); pOpt->AddressOfEntryPoint = 新节区RVA + 壳代码入口偏移; // 7. 写回文件 WriteFileFromBuffer(outputPath, pFileBuf, dwFileSize);

一系列调试完成后，我的加壳器实际跑通了一整套加壳流程：目标测试程序从双击运行到弹出OK框，整个过程不超过一秒。壳代码在OD/x64dbg里单步走完全程，顺利跳回OEP，测试程序后续的逻辑和UI都保持正常。那一刻真的比较有成就感，这篇文章开头我说它带来的提升，也正是在这里体会到的。

4. 常见问题与排查技巧实录

4.1 加壳后程序无法启动

症状通常是双击没反应，任务管理器里闪一下进程就消失。第一步先别急，用x64dbg加载加壳后的文件，看入口点是否落在了新节区。如果停在了0xCC填充区或空指令区，说明入口点算错了。最常见的错误是新节区RVA计算时没有按节对齐值向上对齐。SectionAlignment在多数PE里是0x1000，如果你的新节区VirtualAddress没有对齐到0x1000的整数倍，加载器就会报“无效的PE文件”。

另一个高频原因：写完新节区表项后忘了更新SizeOfImage。SizeOfImage是PE加载器决定映射多大内存的总量，如果新节区扩展了却没有更新它，系统按旧大小映射内存，壳代码一跑就访问越界，直接访问违例。记住，SizeOfImage要把新节区的大小按SectionAlignment向上取整，加到旧SizeOfImage上。

4.2 壳代码运行到一半崩溃

这种问题要分情况看。如果崩溃在解密循环里，大概率是文件偏移算错了，读到了错误位置的数据。检查你的节区遍历逻辑：指针遍历节区时，不能简单用ImageFirstSection + i就默认连续排列了，每个节区都有各自的PointerToRawData，要逐个拿到偏移再去文件缓冲区定位。

如果崩溃在IAT重建环节，常见原因是对原始程序的导入表理解有偏差。MFC程序依赖大量DLL和API，壳代码如果直接清空原始IAT再重新构建，很容易漏掉某些按需加载的模块。我的经验是：初次实现壳时不要动原始导入表，让加载器正常处理旧IAT，壳只负责解密代码和跳转；等到原理彻底吃透了，再考虑自己接管IAT做进一步保护。先能跑起来，再追求极致，这种推进节奏能省下大量调试时间。

另外，如果你在壳代码里用了局部变量，记住壳代码运行时的栈是正常的（系统在入口前已经把栈设置好），但别依赖C编译器生成栈帧的那些函数序言。壳代码最稳的写法是全部用全局/静态数组和寄存器传参，或者在进入核心逻辑前手动设定ESP指向一个壳内预留的缓冲区。

4.3 加壳后被杀毒软件误报

这是所有壳作者都会遇到的问题。新写的壳没有任何合法签名，行为上又是解密代码和动态获取API，被杀毒软件怀疑成恶意行为实属正常。我的处理办法是：一是给加壳器加数字签名提高可信度，二是壳代码里的字符串常量全部手工加密，避免出现明显的危险字符串特征（比如敏感API名、加密循环特征），三是谨慎处理API获取方式，尽量用一步一步解析导出表的方式，而不是直接调用有名API，这样能降低很多误报率。

要注意，国产杀软的云查杀引擎尤其敏感，同样的壳可能在测试机上一路通过，换台装了360或火绒的机器就直接查杀。我一般会用多引擎在线扫描服务（比如VirusTotal）做个交叉验证，确认没有明显的行为特征后再发给别人测试。这个环节不是壳本身的bug，但不处理会严重影响用户的使用体验。

4.4 常见问题速查表

我把自己实际踩过坑的问题整理成一张表，方便你对照排查：

4.5 调试壳代码的几个独家技巧

壳代码调试本质上就是“在没有源码的环境里看汇编”。我分享几个我在实际调试中摸索出的技巧：

首先，在壳代码里故意加一个“软件断点陷阱”帮助定位。在关键步骤（比如解密集满入口、IAT重建完成、准备跳OEP）前插入一条0xCC指令。加壳后的程序一运行，调试器会停在第一处0xCC处，你就能在这逐步观察每一步的状态。不过要记得：发布版本里这些断点必须全部去掉，否则目标程序跑起来会持续触发断点。我的做法是把这些断点放在一个临时配置里，发布时用宏切换关闭。

其次，用“对比原始文件调试”的方式找逻辑差异。我写了一个辅助脚本，能把原始程序和加壳程序在同一个调试器里同时打开。壳跳OEP之前，把加壳程序的寄存器、栈、关键内存地址和原始程序刚启动时的状态做diff，差异一目了然。这个方法尤其适合定位“壳运行完破坏了原始上下文”的疑难杂症。

最后，建议把加密算法和壳代码做成可以在命令行独立运行的小工具。这样你可以在纯控制台环境里先验证加解密逻辑，写点单元测试，确认无误后再集成到MFC界面里。命令行工具调试效率远高于GUI加壳器，这个经验用在工作上也是一样的道理。

5. 项目收获与后续扩展方向

写完这个MFC版本的PE文件壳，我对Windows程序加载机制的理解比看十本书都扎实。以前看PE结构觉得就是背表格，现在再看这些字段，脑子里会自动浮现加载器运行时的处理逻辑：系统怎么从MZ找到PE头，怎么按节区映射内存，怎么把导入表变成IAT，重定位表又在哪里修正。这种“知其所以然”的感觉，是做纯应用层开发很难获得的。

我更想说的是，壳和脱壳其实是同一个硬币的两面。写完壳，你自然能看懂脱壳的思路。比如调试器里常见的“内存断点法”“运行脱壳法”，本质都是在壳代码解密完成后、跳OEP前那一瞬间把内存dump出来。理解了壳的原理，你会发现所谓脱壳就是在找那个“解密完毕、控制权还没交还”的窗口。这个认知让我在分析恶意样本时也获得了很大帮助。

这个项目后续可以扩展的方向不少。想在保护强度上继续做，可以加模拟执行或虚拟机保护（VM思路），把关键代码翻译成自定义字节码，让静态分析工具彻底看不懂；想在体积优化上做，可以引入ZLIB/LZMA压缩算法，让壳不仅有加密功能还有压缩能力，类似UPX的模式；想提升兼容性，那就必须适配x64——64位程序没有FS:[0x30]的PEB访问方式，改用GS段，寄存器数量也更多，处理逻辑要整体调整。

最后再分享一个实际使用中的小心得：加壳后的程序建议在干净的系统环境（虚拟机）里测一遍，再在装了各种杀软的真实环境里测一遍，两边的行为都要正常才能交付。壳这个东西，本质是给软件穿上“铠甲”，但铠甲做太重会影响行动，做太薄又起不到防护作用，怎么在体积、兼容性和防护强度之间取得平衡，是接下来慢慢要根据实际需求优化的事。

本文还有配套的精品资源，点击获取