程序被修改后，有时出现“文件损坏”提示，有时只是启动失败，两者不能混为一谈。本文围绕“Themida怎么配置程序完整性检查Themida检测到文件被修改后如何验证保护效果”，介绍选项设置和对照测试方法。操作名称采用Themida英文界面。

　　一、Themida怎么配置程序完整性检查

　　磁盘文件被修改与进程中的代码被修改，检查方式不同。先处理磁盘文件检测；有源码且需要检查运行时代码时，再考虑SDK宏。

　　1、选好输入文件，另设输出位置

　　原始程序与未修改的保护产物都要保留，修改测试另用副本。

　　①打开【Application Information】，通过【Input Filename】选择待保护程序。

　　②取消【Same as Input】，在【Output Filename】中填写另一条输出路径。

　　③核对程序版本，保存当前项目配置，避免下次误用其他工程的设置。

　　2、开启文件修改检测并设置提示

　　磁盘上的受保护程序被外部改动，对应的选项是【Anti-File Patching】。检测触发后使用MSG_ID_FILE_CORRUPTED消息，测试时可以给它设置明确的文字。

　　①打开【Protection Options】，勾选【Anti-File Patching】。

　　②切换到【Customized Dialogs】，双击【MSG_ID_FILE_CORRUPTED】，修改提示内容。

　　③需要多语言提示时，右键消息，点击【Add Language】，同时检查默认语言内容。

　　④保存配置，进入【Protect Now】生成保护文件，确认处理成功后再开始验证。

　　3、需要检查内存代码时加入宏

　　CHECK_CODE_INTEGRITY检查的是运行时的代码段，并非外部文件夹或全部资源。它需要按SDK示例接入，不能仅靠界面勾选完成。

　　①在源码中选择会被实际执行的位置，按当前SDK支持的语言加入CHECK_CODE_INTEGRITY。

　　②每次调用前，将结果变量初始化为不同于预期常量的值；调用后比较结果，并在测试构建中记录执行情况。

　　③重新编译、保护，在【Protection Macros】检查标记识别情况，再验证对应业务路径。

　　④测量检查耗时，避免放入高频循环；正常运行也报告修改时，检查是否有组件主动改写代码段。

　　二、Themida检测到文件被修改后如何验证保护效果

　　正常、修改和还原后的样本放在一起比较，才能更清楚地判断失败原因。

　　1、确认正常样本可以运行

　　未经修改的产物应先通过功能测试。它本来就打不开时，先排查保护兼容性和运行依赖。

　　①将保护产物复制到测试目录，保持内容不变，执行启动、主要功能和退出测试。

　　②DLL通过原有宿主加载，核对加载结果及关键接口。

　　③将通过测试的文件留作基准，记录完整路径、版本、文件摘要及使用的Themida项目。

　　2、只修改测试副本

　　随机删掉文件头或入口代码，很可能让系统先拒绝加载。这样的样本即使无法运行，也没有说明保护检查是否执行。

　　①从基准文件另复制一份，使用十六进制编辑器进行等长修改。

　　②记录文件偏移、修改前后的值，避开文件头、节表等关键加载结构；根据预定校验范围选择测试位置。

　　③保存修改副本，在相同环境、相同依赖和相同启动参数下运行。

　　④记录提示原文、出现时间及程序是否继续执行，对照【Customized Dialogs】确认是否属于预设的文件修改消息。

　　3、区分保护拦截与普通错误

　　看到预设提示，比单纯闪退更有判断依据。压缩数据、机器指令或程序自身数据损坏，也可能造成退出，不能一律写成“保护验证成功”。

　　①出现系统加载错误或普通崩溃时，检查修改位置是否破坏了程序运行所需内容。

　　②将测试字节还原，确认文件摘要与基准相同，再重复原来的启动操作。

　　③需要进一步定位时，另做一份关闭【Anti-File Patching】的对照构建，采用相同类型的修改进行比较；新构建重新定位，不能直接套用旧偏移。

　　4、单独验证运行时检查

　　磁盘文件检测通过，并不等于CHECK_CODE_INTEGRITY已经执行。内存检查需要独立的测试记录。

　　①运行未修改样本，确认程序到达宏所在位置，结果变量得到预期值。

　　②在受控测试构建中改变被检查的内存代码，再触发检查，核对结果及应用处理分支。

　　③检查异常分支是否按设计停止相关操作；只返回异常值、应用却没有处理，不能算完成了保护逻辑。

　　三、Themida完整性检查怎样接入发布流程

　　文件验证完成后，还要走一遍实际发布过程，检查后续处理是否造成变化。

　　1、核对签名、安装和更新顺序

　　数字签名与Anti-File Patching有兼容支持；额外压缩、资源替换等处理则不能直接照搬这个结论。安装器自身的校验，也应与主程序检查区分开。

　　①按“编译程序、Themida保护、数字签名、生成安装包”的顺序准备候选版本。

　　②安装后检查实际程序，比较安装前后的内容，并运行主要功能。

　　③发布更新时，重新生成完整保护产物；差分更新应还原出经过验证的目标文件，不能留下中间修改状态供用户运行。

　　2、保留可以复查的测试记录

　　只留下“测试通过”，下次换版本时很难比较。具体样本、项目设置和观察结果，应能对应到同一次测试。

　　①一起保存原始程序、保护基准、项目配置及修改记录，给不同样本标明用途。

　　②记录系统环境、提示内容和功能表现；调整保护选项或依赖组件后，重新执行对应测试。

　　总结

　　希望“Themida怎么配置程序完整性检查Themida检测到文件被修改后如何验证保护效果”这篇文章能帮到大家。软件从开发走到交付，背后有不少容易被忽略的工作，保护也是其中一部分。对开发者而言，投入的时间和技术成果值得认真维护；对使用者而言，稳定、顺畅的体验同样重要。两方面都照顾到，产品才更适合长期使用和持续更新。熟悉工具的过程可以慢慢来，项目中积累的经验会让以后的选择更有依据。希望大家学有所用，把这些认识带到实际工作中。如果有Themida相关需求，欢迎联系我们咨询。