Obsidium做完保护以后，真正难的不是“能不能启动”，而是要证明反篡改确实生效、误伤可控、交付后用户环境也能稳定运行。官方功能页明确提到，Obsidium会对代码与数据做完整性校验，并且还能在启动时校验一组自定义文件，一旦检测到未授权修改可以拒绝运行；它也说明产品支持32位和64位Windows程序，并兼容DEP、UAC和ASLR这类当前安全机制。

　　一、Obsidium反篡改如何验收

　　这一节的重点是把“反篡改有效”变成一组能重复执行、能留证的验收动作，而不是只看程序有没有崩。

　　1、先做三份样本对照

　　至少准备未保护版、当前可发布保护版、以及本轮待验收保护版三份样本。这样一旦发现异常，你能快速判断问题来自业务代码、历史配置，还是本轮新保护策略。

　　2、先验主程序完整性，再验关联文件完整性

　　官方说明里既有对程序代码和数据的完整性校验，也有启动时校验用户自定义文件列表的能力，所以验收时不能只改主EXE。建议分别验证主程序、关键DLL、配置文件、资源文件被修改后，程序是否按预期阻断或告警。

　　3、篡改动作要分层做

　　至少验证三类场景，第一类是二进制内容被改动，第二类是资源或配置被替换，第三类是非关键文件改动。验收重点不是“全部都拦”，而是要确认哪些该拦、哪些不该误杀，边界清楚。

　　4、验收结果必须留证

　　每一类篡改场景都保留样本哈希、修改方式、运行结果、截图或日志，并记录是否符合预期。这样后面版本升级时，能直接复跑同一批场景，不必重新设计用例。

　　5、把数字签名校验纳入验收

　　Windows的Authenticode本身就用于验证发布者身份和文件完整性，交付前应同时检查签名是否有效、时间戳是否正常。文件属性里的数字签名页，以及PowerShell的Get-AuthenticodeSignature都可用于核验。

　　二、Obsidium交付前验证清单怎么写

　　这一节的重点不是把清单写长，而是让发布前每次都按同一顺序核对，避免今天查签名、明天忘兼容性。

　　1、版本与产物信息

　　写清Obsidium版本、x86或x64产品线、被保护程序版本号、构建日期、主程序与关键DLL文件名。官方下载页当前也是按x86、x64和Lite分别发布，这一步必须和实际交付物一致。

　　2、基础启动与主流程

　　至少覆盖安装、启动、登录或授权、主界面打开、核心功能入口、退出这几步，确认保护后没有把正常流程打坏。

　　3、反篡改场景

　　列出主程序改动、关键DLL改动、配置改动、资源改动四类验证项，并写清每项的预期结果，是拒绝运行、提示异常，还是允许继续。

　　4、兼容性场景

　　按你真实支持的Windows版本、32位或64位环境、普通权限和管理员权限分别验证。官方说明其兼容范围覆盖从Windows XP到Windows 11，并兼容DEP、UAC和ASLR，所以你的清单至少要覆盖当前对外承诺支持的版本集合。

　　5、签名与发布可信度

　　核对数字签名、时间戳、发布者名称、文件哈希，并保留一份签名前后或发布前后的最终记录。微软也提供了开发者提交误报样本的正式入口，所以一旦后续被误判，这部分材料可以直接复用。

　　6、回滚准备

　　清单里必须有“旧版本安装包、旧保护配置、旧发布样本是否已归档”这一项。只要新版本验证不过，就能立即退回上一可用版本，而不是现场重做保护。

　　三、Obsidium验收留痕与放行规则

　　这一节的重点是把验收结果和放行决策绑定，避免测试做完了，但没人能回答为什么这版可以发。

　　1、先做验收台账

　　台账至少包含文件哈希、保护配置版本、签名状态、兼容性结果、反篡改结果、责任人和日期，后续复测时直接沿用。

　　2、放行条件提前写死

　　例如主流程全通过、关键篡改场景结论符合预期、签名有效、目标Windows环境无阻断性问题，这几项没达成就不进入发布。

　　3、误报与异常单独留档

　　如果某一版在杀软或系统策略下有特殊现象，不要只写在聊天记录里，要单独成条目。微软官方本身支持把被错误分类的正常文件提交分析，这类记录应当和版本台账放在一起。

　　4、每次升级都复跑同一套清单

　　Obsidium官网持续更新x86和x64版本，因此后续只要升级保护工具，就应把同一套验收清单完整复跑，保证新版本没有引入新的兼容性或反篡改偏差。

　　总结

　　Obsidium反篡改验收的关键，不是只看“程序能不能跑”，而是要把完整性校验、关联文件校验、数字签名、系统兼容性和回滚准备一起纳入同一套流程。交付前验证清单写得好，后续升级、误报申诉和版本回滚都会轻松很多，也更能说明这份保护结果是经过验证后才放行的。