技术文档

文档定位

技术文档回答三个问题：

1. 这个产物应该选择哪些保护能力？
2. 哪些函数或模块值得保护，哪些不要动？
3. 发布前如何验证没有引入兼容性问题？

本文是推荐方案与经验总结，不是功能承诺。具体可用选项、授权范围和支持的文件类型，以当前客户端版本和购买页为准。任何加固都会改变产物体积、启动耗时和运行行为，必须先在测试环境验证。

先判断产物形态

分层加固模型

单点保护很容易被绕过。推荐按“静态 → 动态 → 业务”三层组合：

1. 静态层：压缩、符号移除、字符串加密、控制流混淆、方法体加密、虚拟化。
2. 动态层：反调试、内存校验、完整性校验、Root / 越狱 / 模拟器检测。
3. 业务层：授权校验、支付校验、协议签名、关键算法下沉到受保护函数。

加固的目标不是“无法逆向”，而是把攻击成本提高到不值得，同时保持正常用户无感。

平台能力总览

下表是当前客户端中与保护直接相关的选项。— 表示该平台不适用或当前版本不提供。

macOS Mach-O 与 Android Native ELF 的可用选项、签名与打包约束分别见对应平台文档；表中只列出当前客户端已明确的 PE / ELF / .NET / Android 主流程能力。

选型速查

桌面 / 服务端

移动端

通用原则

性能提醒（所有平台通用）

• 函数虚拟化会让被保护方法的运行速度变慢，通常慢数倍到数十倍；调用越频繁越明显。不要全量虚拟化，热循环、每帧回调、高频接口尤其要避开。
• 压缩保护与文件校验会拖慢启动，因为启动阶段要解压、校验整个产物；文件越大越慢。
• 先在未保护产物上测基线，再逐项开启保护；启动或关键路径不达标时，优先缩小虚拟化范围或关闭压缩 / 校验。详细预算见 Native 加固推荐方案 · 性能预算。

少即是多

• 不要全量勾选虚拟化。虚拟化适合少量核心函数，全量会让被选中的函数慢数倍到数十倍，并带来明显的体积和性能开销。
• 不要同时启用互相冲突的保护。例如外层已有加壳工具时，再叠加压缩可能导致启动失败。
• 反调试、Root 检测、模拟器检测属于“环境检测”，对合法测试、无障碍工具和部分厂商系统可能误判，发布前要做兼容性回归。

先测量再扩大

1. 选 5–10 个核心函数，开启保护。
2. 在测试环境跑启动、登录、核心业务流程和异常路径。
3. 记录启动耗时、内存占用和关键接口延迟。
4. 逐步扩大范围，每次只增加一个变量。

保留原始产物与符号

• 原始未保护产物必须存档，便于回滚和对比。
• Native 函数级保护依赖 PDB（Windows）或未剥离符号（ELF）。
• .NET 方法级保护依赖程序集元数据，混淆过的程序集再次保护可能失败。

发布前验证清单

• 冷启动、热启动均正常
• 登录、授权、支付等核心链路通过
• 异常分支、降级逻辑和错误提示正常
• 自动更新 / 增量升级可用
• 安装包签名与证书链正确
• 主流杀毒软件与 EDR 不误报
• 目标操作系统版本、CPU 架构均覆盖
• 性能指标在可接受范围
• 回滚包与回滚流程已准备

合规提示

• 加固不应收集与业务无关的设备信息。
• Root / 越狱检测、设备指纹等功能需符合隐私政策和应用商店规则。
• 不要用加固规避平台审核或隐藏违规行为。

下一步

• Native 加固推荐方案
• .NET 加固推荐方案
• 移动加固推荐方案