Themida做文件保护时，完整性校验主要用来判断保护后的程序有没有被再次修改。这个功能对普通EXE、DLL比较实用，但也容易和程序自身的CRC检查、安装包封装、后续压缩或其他修改操作发生冲突。比较典型的情况是程序保护前运行正常，经过Themida处理后也能生成文件，但再次改动输出文件后，启动时直接提示文件损坏。处理这类问题时，先分清是Themida检测到了磁盘文件变化，还是原程序自己的完整性逻辑被保护过程影响，排查会省不少时间。

　　一、Themida怎么设置文件完整性保护

　　Themida针对磁盘文件修改提供Anti-File Patching选项。启用以后，保护程序运行时会检查文件状态，如果输出文件在保护完成后又发生变化，就可能触发文件损坏处理。

　　1、打开文件完整性相关选项

　　配置前先保留未经处理的原始程序，后面测试失败时可以直接进行前后对照。

　　①、打开【Themida】并载入需要保护的【EXE】或【DLL】。

　　②、进入【Protection Options】。

　　③、找到【Anti-File Patching】。

　　④、启用该保护选项。

　　⑤、确认当前【Input Filename】和【Output Filename】。

　　⑥、保存【Themida Project】。

　　2、生成保护后的测试文件

　　①、确认原始【EXE】能够正常启动。

　　②、返回当前【Themida Project】。

　　③、执行【Protect】生成保护文件。

　　④、不要再使用其他工具修改生成的【Output File】。

　　⑤、直接运行保护后的程序。

　　⑥、检查启动和主要功能是否正常。

　　Anti-File Patching针对的是保护完成后的文件变化。如果后面还要继续做外部压缩、补丁处理或者修改PE内容，这项保护就可能把正常改动判断为文件变化。

　　3、区分磁盘文件和内存代码检查

　　①、磁盘文件防修改使用【Anti-File Patching】。

　　②、需要检查运行中的代码段时使用【CHECK_CODE_INTEGRITY】。

　　③、不要把两种检查结果当成同一种异常。

　　④、调用【CHECK_CODE_INTEGRITY】时避开高频执行位置。

　　⑤、分别测试文件启动和运行阶段的检查结果。

　　CHECK_CODE_INTEGRITY主要检查程序运行后内存中的代码段，和Anti-File Patching的磁盘文件检测用途不同，而且频繁调用会增加执行开销。

　　二、Themida完整性校验失败导致程序无法启动如何处理

　　程序保护以后无法启动，先不要同时修改大量保护参数。比较实用的办法是留着原始文件，从完整性保护开始逐项缩小范围，再判断问题是不是来自外部修改或者原程序自己的校验逻辑。

　　1、先关闭Anti-File Patching做对照

　　①、复制当前【Themida Project】作为测试工程。

　　②、进入【Protection Options】。

　　③、关闭【Anti-File Patching】。

　　④、重新执行【Protect】。

　　⑤、运行新的【Output File】。

　　⑥、记录程序是否恢复正常启动。

　　如果关闭以后程序能够启动，问题基本可以继续沿着文件修改、二次封装和自身CRC校验去查，不必先动虚拟化宏。

　　2、检查保护完成后有没有再次修改文件

　　①、确认测试的是刚生成的【Output File】。

　　②、检查后续流程有没有再次压缩文件。

　　③、检查是否存在修改PE结构的工具。

　　④、确认安装制作流程有没有重新写入程序内容。

　　⑤、取消这些修改后重新生成保护文件。

　　⑥、再次测试启动情况。

　　Themida官方说明中，Anti-File Patching开启后，如果受保护文件在外部被修改，会触发文件损坏处理；准备在保护完成后继续使用其他压缩或修改工具时，不适合直接保留这一选项。

　　3、排查程序本身已有的CRC或自校验

　　有些软件自己就会计算主程序CRC，Themida保护过程会改变原始文件结构，这种自校验可能因此失败。

　　①、运行未保护的【Original File】确认原功能正常。

　　②、检查程序是否带有自己的【CRC】或文件校验逻辑。

　　③、暂时关闭应用内部的自校验测试。

　　④、重新编译新的【Original File】。

　　⑤、再次使用【Themida】完成保护。

　　⑥、运行保护版本比较结果。

　　安装程序尤其容易遇到类似情况，因为很多安装包本身会校验整体文件，保护过程修改文件后就可能让原有CRC失效。Oreans建议通常先保护真正的应用程序，再把保护后的程序放入最终安装包。

　　4、完整性选项关闭后仍然无法启动

　　①、关闭【Entry Point Obfuscation】后重新保护。

　　②、仍异常时检查【Encrypt Strings in VM macros】。

　　③、继续测试【Advanced API-Wrapping】是否存在兼容问题。

　　④、项目使用【XBundler】时暂时关闭该功能。

　　⑤、重新生成程序并逐项测试。

　　Themida官方给出的原生程序兼容性排查也是按照逐项关闭高影响选项的方式进行，这样更容易找到具体冲突位置。

　　三、Themida文件完整性保护恢复后怎么验证

　　程序重新能够启动以后，还要确认完整性保护本身仍然符合项目需求。最省事的方法，是保留一个正常版本，再人为区分“未修改文件”和“经过正常发布流程的文件”进行测试。

　　1、重新验证发布流程

　　①、重新生成新的【Protected File】。

　　②、直接运行一次确认程序正常。

　　③、完成项目实际需要的签名或发布操作。

　　④、再次启动最终【Release File】。

　　⑤、确认没有出现【MSG_ID_FILE_CORRUPTED】。

　　⑥、保存这套已经跑通的处理顺序。

　　2、保留稳定的工程配置

　　①、保存当前【Themida Project】。

　　②、记录【Anti-File Patching】状态。

　　③、保留对应的【Original File】。

　　④、记录保护后的文件处理顺序。

　　⑤、后续修改保护配置前另存工程副本。

　　总结

　　Themida文件完整性保护比较适合已经确定最终输出流程的程序。如果保护完成以后还要继续改文件、重新压缩，或者程序自身本来就带CRC检查，几个校验机制很容易互相影响。碰到启动阶段直接报文件损坏时，先关闭Anti-File Patching做一次对照，再检查输出文件有没有被二次修改，通常比一开始就调整很多保护参数更容易找到原因。把最终能够正常发布的处理顺序留好，后面升级程序版本时也能少走一些重复排查的弯路。