一、先分清：能力分级与安全验证标准
“基础、标准、增强、专业”常被用来描述加固能力，但不同产品的名称和组合并不相同。本文沿用本站的 L1–L4 工程分层，便于比较保护机制与投入；这些标签不代表国家认证、统一行业认证，也不能直接换算成其他厂商的等级。
移动应用的安全验证可以参考 OWASP MASVS，按威胁模型选择控制与测试。它覆盖认证、存储、网络、密码学等方面；其中 MASVS-RESILIENCE 讨论逆向与篡改防护。这里的 L1–L4 不能与 OWASP 的测试配置直接对应。
二、四档加固分别解决什么问题
| 工程分层 | 主要保护机制 | 效果与边界 |
|---|---|---|
| L1 基础 | 标识符混淆、资源名混淆、字符串处理，减少直接可读的信息。 | 提高阅读和定位成本；方法体通常仍可分析。改名、加密字符串都不等于把业务逻辑移出 DEX。 |
| L2 标准 | 在基础层上加入整体 DEX 加密装载、签名与完整性校验、反调试等防护。 | 增加静态提取和重打包成本；运行时仍要执行代码，解密后的 DEX 可能成为动态分析对象。具体校验对象和覆盖范围必须核实。 |
| L3 增强 | 保护关键方法的执行逻辑，例如方法虚拟化或原生转换，配合指令映射、反注入、Hook 检测与运行时检查。 | 选中方法的原始实现不再直接留在原 DEX 方法体中，恢复逻辑需要分析运行库与保护数据；未选中或被跳过的方法仍需单独评估。 |
| L4 专业 | 面向具体威胁定制多层保护与评估，可能结合白盒密码、复杂控制流、设备端密钥保护、远程密钥策略和持续风控。 | 需要密钥生命周期、客户端与服务端协同、持续对抗测试及故障处置。单独增加某个功能，不能证明达到了专业级保护。 |
表中的机制会跨档组合。例如运行时检查并非只在 L4 才能出现，完整性校验也可以与方法虚拟化同时使用。比较时应要求能力清单和测试证据，不能只数功能开关。
“调用原生层”不等于同一种保护
方法虚拟化（VMP）把选中方法的逻辑交给虚拟机运行；DEX 转原生代码（Dex2C）走的是另一条转换路线。两种产物都可能呈现原生调用入口，但恢复路径和性能代价不同。金铠甲的方法保护采用原生运行库执行 VM 数据的路径，不能仅凭看到一个 native 方法就判断保护强度。
三、看报告：等级、范围和覆盖率要一起读
金铠甲当前的 L3 增强报告标签，描述的是规则选中、进入转换流程的方法未出现不兼容指令导致的 VM 跳过；出现这种方法级降级时，报告会标为 L2 并说明数量或比例。这个标签不表示整个 APK 的所有方法都已经虚拟化。
- 全包方法覆盖率：报告的“VM 方法数 / 总方法数”，帮助你了解整个包中实际完成 VM 保护的范围。
- 选中范围内的未保护比例：用于判断转换是否符合规则预期，分母与全包覆盖率不同。要逐项检查未保护明细和跳过原因。
- 关键业务是否命中：授权判断、付费权益、核心算法等目标方法，要在覆盖明细里确认，不能用全包百分比代替。
- 其他功能是否生效：整体 DEX 加密、字符串处理、名称混淆和环境检测，要分别看应用结果与兼容性说明。
构造方法、抽象方法、已有原生方法等有各自的处理边界；不参与 VM 转换的方法也会影响全包覆盖率。不要把“没有发生不兼容指令降级”理解为“没有任何代码保留原状”。
四、按业务风险选择投入
| 业务场景 | 优先保护什么 | 选择思路 |
|---|---|---|
| 工具、内容展示 | 发布包的基础信息、接口使用方式与重打包风险。 | 先做好发布构建混淆；按风险补充完整性和签名校验。没有敏感本地逻辑时，不必为了等级标签扩大 VM 范围。 |
| 订阅、授权、商业算法 | 本地授权决策、协议处理和具有商业价值的算法。 | 优先选择可核对方法范围的增强保护，并把最终权益验证保留在服务端。逐步扩大范围，观察性能和兼容性。 |
| 游戏与易被滥用的业务 | 易被修改的判断路径、客户端状态与异常运行环境。 | 结合关键逻辑保护和运行时检测；服务端仍需验证结果、限制异常行为。客户端检测可作为风险信号，不能独立承担全部风控。 |
| 高敏感或有专项要求 | 敏感交易、密钥生命周期、身份与设备可信度。 | 先明确适用要求和攻击模型，再定制客户端、服务端与密钥方案，安排独立安全评估。普通 L3 加固不能替代专项验证。 |
这张表是工程选择建议。最终需要保护的是具体资产和业务路径；同一个应用可以对少量高价值方法使用增强保护，对其他代码保留成本更低的处理方式。
五、强度之外，确认三类工程代价
1. 兼容性
检查最低 Android 版本、目标 ABI、反射、JNI、第三方 SDK、组件初始化和动态加载路径。名称混淆需要保留依赖字符串查找的入口；Android 官方的 R8 keep 规则说明也强调了反射与 JNI 的间接引用问题。
整体 DEX 内存装载有独立的版本条件。在金铠甲当前 APK 流程中，minSdkVersion 为 24–25 时，整体 DEX 加密会退回方法 VM 模式；低于 24 且请求该功能时会报不支持。AAB 有独立的模块处理与降级规则，应以对应产物报告为准。这个兼容性结果与方法级 L2/L3 标签分别报告。不要为开启一个开关而直接提高最低版本，先确认现有用户设备范围。
2. 体积与性能
运行库、保护数据和加载流程都会带来成本。方法虚拟化可能增加调用与执行开销，尤其要测频繁执行的热点路径。无损压缩可以减少存储体积，却不能消除 VM 的执行代价；包更大也不能直接证明保护更强。
3. 故障定位与持续维护
把规则、原包、加固报告、混淆映射和签名版本一起保存。每次更新第三方 SDK、Android 版本或保护规则后，重新验证安装、启动、授权、支付回调和异常恢复，并保留可回滚的发行版本。
六、签名与验收决定能否交付
推荐使用金铠甲 Windows 客户端在本地自签名。签名密钥不上传云端，平台不代签。加固输出完成后，还要按实际分发渠道的签名规则检查安装和更新；自有渠道通常需沿用已有签名身份，使用 Play App Signing 时则应按其应用签名密钥与上传密钥流程处理。可参考 Android 官方应用签名说明。
- 做静态对比：确认目标方法的原始实现已按预期转换，敏感字符串和保留代码的范围清楚。
- 做完整性验证：对产物中实际启用的完整性与签名校验，在授权测试环境中测试相应的 DEX、签名或保护数据修改是否触发预期处理；APK 与 AAB 的校验范围分别核对。
- 做真机业务回归：覆盖目标 Android 版本与 ABI，测试冷启动、核心业务、后台恢复、安装更新，以及耗时、内存和包体变化。
- 核对交付文件：使用完整配套的加固工具与运行库生成新产物，再本地签名。测试通过后分批发布，并持续观察崩溃与误拦截。
七、金铠甲的定位与选择入口
金铠甲面向需要保护核心 Android 逻辑的团队，定位为增强级（L3）：以方法 VM、任务相关指令映射、加密保护数据以及完整性与运行时检查提高分析成本。普通软件模式的密钥材料随运行库分发，不能宣称白盒密码强度，也不能保证在完全受控设备上永远不被绕过。
选择时，先列出核心方法并提交一个可回归的包，再结合任务报告和真实设备结果调整范围。具体功能、支持组合与边界见加固能力说明；想了解静态工具的视角，可阅读加固前后反编译对比。
用自己的核心方法验证保护效果
从保护范围、任务报告和真机运行结果开始选择。