Native 加固推荐方案

1. 平台拆分

Native 产物在不同平台上的格式、加载器、签名机制差异很大，保护选项和验证方法也不同。本文只保留通用原则，具体操作请进入对应平台文档：

本文是推荐方案与经验总结，不是功能承诺。具体可用选项、授权范围和支持的文件类型，以当前客户端版本和购买页为准。特殊产物形态建议先与技术支持确认再落地。

2. 公共能力

不同平台的可选项略有差异，但核心能力一致：

性能影响（务必评估）

• 函数虚拟化会让被保护方法的运行速度明显变慢。 单个函数通常慢数倍到数十倍，调用越频繁、函数越复杂越明显。对热循环、每帧回调、高频接口全量虚拟化，会直接拖垮性能。
• 压缩保护和文件校验会拖慢启动。 程序启动时需要解压、校验整个产物，文件越大耗时越长；同样的选项，100 MB 的客户端和 1 GB 的游戏，启动开销不是一个量级。
• 越大越慢。 可执行文件、.so、.dylib 体积增长时，压缩、校验、加载的耗时都会上升，不要只看小样本的测试结果。
• 先用未保护产物记录基线，再逐项开启保护；如果启动或关键路径不达标，优先缩小虚拟化范围，或关闭压缩 / 校验。

同一份产物不要叠加多个压缩 / 加壳工具。压缩层与虚拟化层叠加可能互相破坏，表现为启动崩溃或运行时随机异常。

3. 通用推荐档位

3.1 基础档：兼容性优先

适用于内部工具、需要频繁调试的版本，或首次接入保护的产物。

目标：先确认保护流程不会破坏程序，再逐步增加强度。

3.2 标准档：商业发布

3.3 强化档：高价值目标

适用于授权校验严格、破解收益高的产品。强化档必须配套完整的回归测试。

档位越高，被虚拟化的函数越多，运行开销越大；压缩与文件校验的开销则随产物体积增长。选择强化档前，先确认性能预算能覆盖启动与热路径。

4. 函数选择策略

4.1 优先保护

• 授权激活、许可证校验、试用期判断
• 支付、订单、发票相关逻辑
• 协议签名、加密解密、密钥派生
• 反作弊、风控判定、设备指纹
• 核心算法与业务规则（例如计费、排产、图像处理）

4.2 谨慎保护

• 启动阶段执行的函数：会放大冷启动耗时
• 异常处理、SEH、C++ 异常密集的函数：可能影响栈展开
• 高频热循环、实时音频 / 视频处理：虚拟化开销明显
• 与外部插件、COM、跨语言运行时交互的边界函数
• 驱动、内核模块、受系统签名约束的组件：当前不建议修改

4.3 不建议保护

• CRT / STL 模板实例、编译器生成的安全检查（如 __security_check_cookie）
• 只做参数转发的 thunk
• 第三方静态库中未验证的代码
• 已经由其他工具虚拟化或加密的代码

4.4 数量建议

• 首次：5–10 个函数，全部混淆，观察兼容性。
• 第二次：把授权与支付函数改为虚拟化。
• 后续：每次增加 5–10 个函数，跑完整回归后再进入下一批。

5. 性能预算

建议记录以下基线，并在最大产物、最低配置设备上验证：

• 冷启动时间（P50 / P95）
• 首次打开核心功能耗时
• 峰值内存
• 安装包 / .so / .dylib 体积
• 关键接口延迟与帧率
• 虚拟化函数的调用频率

上表是定性经验，实际数值与编译器、函数复杂度、保护选项、文件体积强相关。建议给启动和关键路径设明确门槛（例如冷启动增幅不超过 10%–20%，按业务调整），超过就回退保护范围。

再次强调：虚拟化影响的是“被选中的函数”运行速度，压缩和校验影响的是“每次启动”。两类开销的优化方向不同——前者减少虚拟化函数，后者缩小文件或关闭压缩 / 校验。

6. 通用验证清单

• 原始产物在目标环境可正常运行
• 保护后冷启动、热启动正常
• 所有导出函数、插件与动态库加载正常
• 授权、支付、更新链路正常
• 异常与崩溃路径能正常提示
• 目标架构（x86 / x64 / ARM64）与系统版本均覆盖
• 主流杀毒软件与 EDR 不误报
• 最大体积产物的冷启动已单独实测
• 被虚拟化函数的调用延迟 / 帧率已对比基线
• 性能指标与基线对比在可接受范围
• 已保留原始产物与符号文件

7. 平台选型速查

8. 相关文档

• Windows PE 加固推荐方案
• Linux ELF 加固推荐方案
• macOS Mach-O 加固推荐方案
• Android Native ELF 加固推荐方案（JNI .so）
• 移动加固推荐方案