程序经过Themida保护后，文件大小、哈希值和内部结构发生变化并不意外。真正需要查清的是，这些变化是否来自当前保护设置，以及程序的版本信息、接口和运行行为是否符合交付要求。对比时先保留原始文件，再逐项查看，比直接判断“文件变大了是不是出错”更容易找到原因。

　　一、Themida怎么对比加壳前后的文件信息

　　原始文件应当是本次保护实际使用的输入文件。若拿不同构建批次的程序比较，编译器、资源和依赖变化也会混进结果中。

　　1、确认输入与输出文件

　　①在【Application Information】中检查【Input Filename】，确认指向本次编译生成的程序。

　　②检查【Output Filename】，将保护结果输出到独立目录，并保留输入文件。

　　③查看【File Size】和【File Information】，核对载入文件的大小、类型及识别信息。

　　④保存当前保护工程，记录Themida版本、输入文件路径和保护时间。

　　若通过构建脚本执行保护，还要检查命令行指定的输入与输出路径。命令行参数可以覆盖工程中的路径，只查看界面里保存的设置，未必能确认脚本处理了哪个文件。

　　2、记录大小、版本和哈希

　　①在资源管理器中分别右键两份文件，进入【属性】，记录以字节表示的文件大小。

　　②打开【详细信息】，比较文件版本、产品版本、产品名称等内容。

　　③使用PowerShell的Get-FileHash分别计算SHA256，将结果与对应文件路径一起保存。

　　“占用空间”受文件系统分配方式影响，不适合直接判断保护增加了多少内容。哈希则用于确认文件内容是否一致：加壳前后哈希不同属于正常现象，不能据此认定文件损坏。

　　3、查看PE头和资源信息

　　①使用能够读取PE格式的工具，分别载入原始文件与保护文件。

　　②对照Machine、入口点、节数量、SizeOfImage及导入导出信息，记录发生变化的项目。

　　③检查图标、版本资源和manifest；对于DLL，额外核对宿主使用的导出名称及序号。

　　磁盘文件大小与SizeOfImage含义不同，后者反映映像加载到内存时的大小。两者不必相同，也不适合互相替代。

　　二、Themida输出文件与原始文件存在差异如何分析

　　差异需要结合用途判断。入口点变化通常与保护启动过程有关，而版本号错误、签名验证失败或接口无法调用，则需要继续查配置与发布流程。

　　1、文件大小增加或缩小

　　Themida会加入保护所需的代码与数据，压缩又可能减少原有内容的体积，因此输出文件既可能增大，也可能缩小。

　　①回到【Protection Options】，检查【Compress and Encrypt】相关设置。

　　②查看【XBundler】是否嵌入了DLL或数据文件，并检查是否加入了自定义插件等内容。

　　③保持输入文件相同，每次只调整一类设置，分别输出测试文件，比较大小变化。

　　小程序加入保护后，增幅比例可能比较明显。判断是否异常时，应与同一输入文件、同一组配置的历史结果比较，不能用一个固定增长比例衡量所有程序。

　　2、入口点、节和导入信息变化

　　①确认输出文件的处理器架构与原始程序相符，排除选错输入文件或查看了旧输出的情况。

　　②将入口点、节布局和导入信息的变化，与已启用的保护、压缩设置对应起来。

　　保护后的程序需要先执行相应初始化，入口点和内部布局可能变化。静态工具显示的导入列表，也不一定完整反映程序运行时会使用的全部依赖。此时应继续测试启动和业务功能，避免仅凭某个静态字段变化就修改PE头。

　　3、图标、版本或权限表现不同

　　①对照两份文件【属性】→【详细信息】中的版本内容，确认原始程序是否已经包含正确资源。

　　②进入【Extra Options】，检查【Add Manifest from File】等设置，确认是否额外加入了manifest。

　　③若只在资源处理后出现异常，单独调整资源压缩相关选项重新保护，观察差异是否消失。

　　manifest会影响程序的运行权限及部分兼容行为。出现管理员权限提示变化时，应检查其中的权限声明，并核对后续打包工具是否又修改了资源。

　　4、数字签名消失或验证失败

　　①在文件【属性】中查看【数字签名】；若存在签名，继续检查签名详细信息。

　　②使用SignTool按Authenticode策略验证最终文件，区分内容校验、证书信任及时间戳等问题。

　　③将保护、签名和打包流程的产物分开保存，确认异常最早出现在哪一步。

　　原始文件的签名不能直接证明修改后的文件有效。通常应先完成保护及其他内容处理，再对最终程序签名。Themida官方说明，保护后的应用可以使用SignTool签名；签名后仍应重新验证交付文件。

　　三、Themida文件差异如何形成可复查的结论

　　静态信息只能解释一部分变化。对交付程序，还需要把文件检查结果与运行测试对应起来。

　　1、保留每个处理阶段的文件

　　①分别保存原始程序、保护输出、签名文件和安装包中的程序，记录大小与SHA256。

　　②若安装后的文件与签名阶段记录不一致，继续检查安装包是否装入旧文件，以及打包流程是否执行了资源修改。

　　③记录每次测试使用的完整路径，避免通过快捷方式启动了另一份程序。

　　这样可以区分保护产生的变化与后续发布流程产生的变化，也方便重新构建时找到对应产物。

　　2、验证受影响的使用场景

　　在相同系统、依赖和权限条件下，分别运行原始程序与保护版本，测试启动、主要功能和退出过程。DLL还应由实际宿主加载并调用接口。若问题只在某项设置启用后出现，可回到已验证的工程配置，逐项恢复设置，保留能够稳定复现异常的文件与操作记录。

　　总结

　　Themida加壳前后的文件本来就可能存在多处差异，检查时应先确认比较的是同一构建版本，再结合保护设置解释大小、结构和资源变化。哈希用于追踪具体文件，签名用于验证发布身份与内容完整性，运行测试则用来确认功能是否受到影响。把这些结果放在一起，才能判断差异是否需要处理。希望这些方法能帮助大家更清楚地核对保护输出，减少版本混用和重复排查。如果您有相关需求，也欢迎与我们联系咨询。