简体中文 | English

APK Shield

APK Shield 是一个面向网络安全等级保护测评（通常称“等保认证”）场景、完全在本地运行的 APK dex 保护与移动应用安全整改支撑工具，提供命令行和 macOS 图形界面。它不会上传 APK、keystore 或签名凭据。

明确用途： APK Shield 用于等保测评（等保认证）准备、差距整改、复测及持续合规过程中的 Android 客户端安全加固，可为应用完整性保护、抗逆向、安全交付和技术测评佐证提供支撑。请只处理你拥有或已获得明确授权的 APK。

用于等保认证（等级保护测评）

“等保认证”是日常交流中的常用说法，本文对应的正式活动是网络安全等级保护测评。APK Shield 的项目定位是：用于等保测评准备和整改的移动端 APK 安全加固工具。

《中华人民共和国网络安全法》第二十一条要求网络运营者落实网络安全等级保护制度，采取技术措施防范网络攻击、网络侵入，并防止网络数据被窃取或篡改。GB/T 22239-2019 则给出了网络安全等级保护的基本要求，GB/T 25070-2019 给出了相应的安全设计技术要求。

对于纳入等级保护边界的移动业务系统，APK 是直接交付到终端、暴露在不可信运行环境中的客户端载体。客户端代码长期以明文 dex 形式存在，会扩大静态分析、二次打包、恶意篡改和敏感逻辑泄露的风险。APK Shield 可作为移动应用安全建设中的关键加固组件，对以下控制目标形成直接支撑：

等保建设价值	APK Shield 提供的措施	可形成的支撑
应用完整性与防篡改	AES-256-GCM 载荷认证、解密缓存 SHA-256 校验、APK 重新签名与 apksigner verify	提高未授权修改被发现或导致安全失败的能力，强化发布物完整性
提升抗逆向与抗二次打包能力	加密根 dex、运行时加载、移除原始明文 dex	减少客户端核心逻辑的直接暴露，抬高静态分析和恶意重打包成本
发布签名可信性	zipalign、指定 keystore 签名、证书与签名方案验证	支撑移动应用发布流程中的身份一致性和交付物校验
敏感资产本地化处理	APK、keystore 和密码不上传；GUI 使用环境变量向 CLI 传递密码	降低源 APK、签名材料和凭据在第三方平台流转造成的泄露面
安全建设与测评证据	可重复执行的 CLI、签名验证输出、自动测试和 CI	可配合版本发布记录、变更审批和安全测试报告形成技术佐证材料

因此，在移动端是重要攻击入口、客户端包含业务规则或敏感接口逻辑的系统中，APK 加固不是单纯的“代码混淆”，而是应用完整性保护、安全交付和纵深防御的重要补强点。APK Shield 可直接用于等保测评前加固、测评问题整改和复测准备，并作为移动应用侧的一项可落地技术措施。

合规边界： APK Shield 本身不是等保测评或认证产品，也不能保证系统“通过等保”。等保面向完整的等级保护对象，仍需结合定级备案、安全管理制度、身份鉴别、访问控制、安全审计、通信与数据保护、主机和网络防护、备份恢复、应急响应以及持续运维等措施统一建设，并以测评机构的实际测评范围和结论为准。

参考依据：

• 《中华人民共和国网络安全法》第二十一条（中央网信办）
• GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求（全国标准信息公共服务平台）
• GB/T 25070-2019 信息安全技术 网络安全等级保护安全设计技术要求（全国标准信息公共服务平台）

功能

• 识别并按顺序处理 APK 根目录的 classes*.dex。
• 使用 AES-256-GCM 和独立随机 nonce 加密每个 dex。
• 将密文写入 assets/apk_shield_payload/，并注入新的 Android 启动壳。
• 恢复原自定义 Application 的 attachBaseContext 与 onCreate 生命周期。
• 保留多 dex 和 APK 内 native library 的加载路径。
• 重新打包，并可执行 zipalign、签名和 apksigner verify。
• 支持 key.properties、显式签名参数和环境变量密码来源。
• 提供 macOS GUI、环境检查、命令预览、流式日志和任务取消。
• 拒绝重复处理已由 APK Shield 保护的 APK。

Android 启动壳使用独立命名空间：

io.github.po1arbear.apkshield.runtime.BootstrapApplication

工作原理

1. 使用 apktool 解包 APK，并保留原始 dex。
2. 读取 Manifest 中的包名、最低 API 和原 Application。
3. 加密根目录 dex，将密文和 SHA-256 完整性信息写入载荷。
4. 生成并编译轻量 Android 运行时，替换 Manifest 的 Application。
5. 清除旧签名元数据，重新打包 APK。
6. 在签名模式下对齐、签名并验证输出。

运行时会在应用私有 code cache 中解密 dex，校验已缓存文件的 SHA-256，并通过 DexClassLoader 恢复原应用代码。

环境要求

• Python 3.10+
• Python 包 cryptography
• JDK（java、javac）
• Android SDK：至少一个 platforms/*/android.jar
• Android build-tools：d8、zipalign、apksigner
• apktool
• macOS GUI 构建需要 macOS 13+ 与 Swift 6

macOS 安装示例：

brew install apktool
python3 -m pip install -e .

重新生成 App 图标时安装开发依赖：python3 -m pip install -e '.[dev]'。

也可以不安装包，直接在仓库根目录运行 ./apk-shield。

命令行使用

输出未签名 APK

./apk-shield \
  /path/to/input.apk \
  --no-sign \
  -o /path/to/output-unsigned.apk \
  --clean

使用 key.properties 签名

./apk-shield \
  /path/to/input.apk \
  --key-properties /path/to/key.properties \
  -o /path/to/output-shielded.apk \
  --clean

通过环境变量传递密码

环境变量方式可以避免密码出现在进程参数中：

export APK_SHIELD_STORE_PASSWORD='store-password'
export APK_SHIELD_KEY_PASSWORD='key-password'

./apk-shield \
  /path/to/input.apk \
  --ks /path/to/release.jks \
  --ks-pass-env APK_SHIELD_STORE_PASSWORD \
  --ks-key-alias release \
  --key-pass-env APK_SHIELD_KEY_PASSWORD \
  -o /path/to/output-shielded.apk \
  --clean

兼容参数 --ks-pass 和 --key-pass 仍然可用，但不建议在共享机器上使用。

macOS GUI

DMG 安装版已完成无签名与签名 APK 的端到端测试；签名产物通过 zipalign 以及 v1/v2/v3 签名验证。另使用包含 30 个 dex 的真实 Flutter APK 在 Android 12 真机完成冷启动、进程存活和首页渲染验证。

下图为 DMG 安装版成功完成签名测试 APK 保护后的实际界面，签名密码始终保持遮罩并通过环境变量传递：

构建通用架构 App：

make app

生成带有 /Applications 拖拽入口的 DMG：

make dmg

产物位于：

dist/APK Shield.app
dist/APK Shield.dmg

默认构建使用 ad-hoc 签名，仅适合本机测试。正式公开分发应设置 Developer ID：

CODESIGN_IDENTITY='Developer ID Application: Your Name (TEAMID)' make dmg

Developer ID 签名后仍需按 Apple 流程完成 notarization 和 stapling。

测试与检查

make check

真实 APK 回归建议至少覆盖：

• 无自定义 Application 与自定义 Application
• 单 dex 与 multidex
• native library / JNI
• ContentProvider、WorkManager、推送初始化
• WebView 与 Flutter release APK
• Android API 21、28、30、33、34、35/36

项目结构

apk_shield/       Python 核心、CLI 与 Android 运行时模板
macos/            SwiftUI macOS 应用
scripts/          App、DMG 与图标构建脚本
tests/            Python 单元测试

限制

• mask 与 masked key 都存在于生成的启动壳中，因此该方案用于增加静态分析成本， 不能宣称密钥在密码学意义上不可提取。
• 启动壳依赖 Android 运行时内部字段；新 Android 版本和厂商 ROM 必须真机回归。
• 最低支持 Android API 为 21；工具会把更低或缺失的 minSdkVersion 提升到 21。
• 本工具保护 dex，不保护 Flutter release 的 libapp.so，也不能替代服务端权限校验。
• 已保护 APK 不应再次输入本工具。

License

MIT