技术文档中心

第一次加固，只需四步

1. 注册开发者账号：进入注册页面，填写账号信息完成注册。
2. 登录控制台：使用开发者账号登录控制台。
3. 上传 SO 文件：进入左侧菜单「ELF加密」，上传待加固的 .so 文件（支持 armeabi-v7a 与 arm64-v8a）。
4. 下载加固包：加固任务完成后，在任务列表中下载加固后的 SO 文件，替换回工程重新打包即可。

加固后自测清单

• 真机安装运行，验证核心业务功能是否正常；
• 覆盖主流架构与 Android 版本（建议至少 armeabi-v7a / arm64-v8a 各一台真机）；
• 如启用了反调试，确认正常用户路径不会误触发退出。

进入控制台开始加固

什么是 VMP 虚拟化

VMP（Virtual Machine Protection）将函数的原生指令翻译为一套随机生成的私有虚拟指令，并由内置解释器在运行时执行。攻击者拿到的不再是可读的 ARM 指令，而是无公开规范的字节码——每次加固的指令集互不相同，无法复用分析成果。

如何选择要虚拟化的函数

• 优先保护：许可校验、加密算法、协议封包、核心风控与关键业务逻辑；
• 谨慎选择：每帧调用的渲染循环、高频热点函数（虚拟化会带来一定执行开销）；
• 无需选择：普通工具函数交由整体加固壳保护即可，无需逐一虚拟化。

注意事项

• JNI 入口函数（如 JNI_OnLoad）可以虚拟化，注册流程不受影响；
• C++ 异常与内联汇编密集的函数建议先在测试包验证；
• 虚拟化函数数量不设上限，按需勾选，控制台会给出体积与性能评估。

加固壳做了什么

• 整体加密压缩：原始代码段加密存储，磁盘上不存在明文指令；
• 运行时装载：自定义 loader 在内存中按需解密还原，用后即焚；
• 结构混淆：抹除/伪造节表与符号信息，IDA、Ghidra 打开即失真；
• 动态防护：内置反调试（ptrace / Frida / Xposed 检测）与代码段完整性校验。

集成注意事项

• 加固后的 SO 直接替换原文件即可，包名、导出符号、加载方式均不变；
• 若工程内存在多个 SO 相互依赖，建议全部加固，或保证被依赖方先于依赖方加载；
• 加固会带来一定的体积变化，实际增量以控制台任务详情为准；
• 混淆器（ProGuard/R8）作用于 Java/Kotlin 层，与 ELF 加固互不冲突，可同时使用。

命令行加固（企业接入）

除网页控制台外，支持以 CLI / API 方式将加固步骤编排进 CI/CD 流水线，出包即加固：

$ huian-cli protect -i libcore.so -o libcore_protected.so
[1/4] 解析 ELF 结构 ................. done
[2/4] 函数 VMP 虚拟化 (12 funcs) .... done
[3/4] 整体加壳与字符串加密 ......... done
[4/4] 完整性签名 ................... done
✓ 加固完成 libcore_protected.so（耗时 47s）

接入方式

• 在控制台「账号余额」页确认套餐权限后，联系平台管理员开通自动化接入；
• 凭 API 凭证提交加固任务、轮询任务状态、拉取加固产物；
• 建议在流水线中将「加固 + 自动化冒烟测试」串联，保证每个出包版本可用。

支持哪些架构与平台？

当前支持 Android 平台的 ELF 共享库（.so），覆盖 armeabi-v7a 与 arm64-v8a 主流架构。

是否支持 APK 整体加固？

我们专注 ELF/SO 层加固，暂不提供 APK 整体加密。Native 层是逆向攻防的主战场，把 SO 保护好，往往比笼统的 APK 壳更有效。

加固对性能影响有多大？

加固壳的运行时开销主要发生在加载阶段，稳态运行几乎无感；VMP 虚拟化函数存在执行开销，因此建议只对低频高价值函数启用。发布前请以真机实测为准。

加固后崩溃或功能异常怎么排查？

优先缩小范围：先只启用加固壳验证，再逐步增加 VMP 函数；确认崩溃点后在控制台任务详情反馈任务 ID，平台会协助定位。

加固会改变我的发版流程吗？

不会。加固发生在「编译产出 SO」与「打包 APK」之间，只是替换文件；接入 CLI/API 后可完全自动化，无需人工介入。