APP加固源码和成品防护app|不死鸟资源网

本文摘要：

提供完整源码和已编译的加壳 APK，用户选取待加固 APK、签名文件并选定四档强度，即可生成加密版。核心通过替换 Application 入口、将 classes.dex 用 AES‑GCM 加密后放入 assets、根密钥拆分埋入 .so 并在 native 层内存解密加载，支持可选 Dex2C 将指定方法编译为 C，配合七项防调试检测，实现防反编译。

— 本文部分摘要灵感源自 DeepSeek 深度思考 ✨

一句话结论

这是一套安卓 APK 加固（加壳）工具的完整源码 + 编译好的成品 APK。

作用是：把一个普通的 APK 丢进去，它给你吐出一个「加壳版」APK——原来的代码被加密藏起来，外面套一层壳，让人没法直接反编译看你的源码。

荷花加固.apk（10.4 MB）—— 已经编译好的成品，装到手机上就能用
荷花加固源码/ —— 对应的完整工程源码（Android Studio / Gradle 工程）

一、成品 APK 长什么样（给用户用的界面）

打开后是一个叫 AndroidPacker 的安卓 App，副标题写着 “Enterprise APK Protection Console”（企业级 APK 保护控制台）。操作流程就四步：

点「选择」挑一个要加固的 APK
（可选）选自己的签名文件 .jks/.p12，填密码和别名；不填就用测试签名或「原签名自签」
选加固强度档位
点「开始加固」→ 输出到 Downloads/AndroidPacker/xxx_hardened_时间戳.apk

界面里有四档预设，对应不同的检测开关组合：

档位	说明
均衡模式（默认）	大多数 APK 直接能用
兼容优先	减少高风险检测，保证复杂 APK 能正常启动
严格模式	全部原生检测拉满，发布前需充分测试
自定义	手动勾选下面这些开关

可勾选的 7 个反调试检测项：

开关	检测什么
TracerPid/ptrace	有没有调试器附着在进程上
maps 注入检测	`/proc/self/maps` 里有没有 Frida / Xposed / Magisk 等注入痕迹
LD 环境变量	有没有通过环境变量注入
Hook 符号	内存里有没有 MSHookFunction、DobbyHook 等 Hook 框架符号
调试进程	进程列表里有没有 frida-server、gdbserver、lldb-server
Frida 端口	扫描 Frida 默认监听端口
后台巡检	起一个 native 线程，每 3~7 秒随机循环复查一次

还有一个可选的 Dex2C 开关，需要填「转换规则」（哪些类/方法要转成 C 代码）。

二、技术原理：它到底对 APK 做了什么

这套东西的技术含量不低，不是那种简单的「DEX 整体加密 + 壳」的初级加固。核心逻辑在 PackerEngine.java 的注释里写得很清楚，分五层：

1. 抽壳 —— 换掉 Application 入口

用 stub_template/ProxyApplication.java.tpl 编译出一个 stub.dex 壳，通过 AxmlPatcher 直接改 APK 里的 AndroidManifest.xml 二进制，把原来的 Application 类替换成壳类。

壳类一启动就 System.loadLibrary("core") 加载 native 库，然后把 getClassLoader() 劫持掉，返回自己的加载器。

2. DEX 加密（NPX3）

原来的 classes.dex 被从 APK 里删掉，改成加密后放进 assets/。

加密算法：AES-GCM（带完整性校验，改一个字节就解不开）
每包随机生成一个 Root 密钥
用 HKDF 按不同用途派生子密钥（域隔离）

3. Root 密钥拆成两份，埋在 .so 里

这是比较讲究的一步。Root 密钥不是明文存着的，而是拆成两份 XOR 分片，注入 native 库的两个自定义只读段里：

.rodata.np.k1  →  kRootShareABlock.rodata.np.k2  →  kRootShareBBlock

每份前面有 16 字节的「锚点」（AES-K-ANCHOR-V1 / MAC-K-ANCHOR-V1），加固工具在打包时按锚点定位、把随机密钥 patch 进去。

运行时两份分片异或（XOR）还原 Root，再按域派生工作密钥。静态翻 .so 只能看到一份分片，拼不出完整密钥。

4. 内存加载 DEX，不落盘

这是「壳」最关键的一步，在 inmemory_loader.cpp 里：

从 assets/ 读加密 DEX → native 层 AES-GCM 解密 → 得到明文 DEX 字节
用 madvise(MADV_DONTDUMP) 标记这块内存，让 coredump 和简单内存扫描抓不到
Android 9+ 走 InMemoryDexClassLoader(ByteBuffer[], parent) —— 内存直接加载，全程不写文件
Android 8 及以下走反射 DexFile.loadDex 的老路子

配套的 art_helper.cpp（659 行）负责把 ContextImpl、LoadedApk 这些系统内部对象的字段反射替换掉，让系统以为加载的就是原来的 Application。

这一步的价值：常规脱壳工具靠「扫文件系统找释放出来的 dex」就完全失效了。

5. Dex2C —— 把 Java 方法编译成 C

开启后（Dex2cIrEncryptor + dex2c_runtime.cpp），指定方法的 IR 被转成自定义字节码，再：

每个方法体是独立的 AES-GCM 块，各自有独立 nonce 和 HKDF 密钥
方法顺序在打包时随机打乱
操作码映射表每包都不同（opcode randomization）

也就是说，同一个 APK 加固两次，产物字节层面完全不一样，没法靠比对做特征识别。

6. 签名与对齐

用官方 apksig 库签 V1 + V2 + V3，外加邻接的 V4 .idsig
native 库按 16 KB 对齐（-Wl,-z,max-page-size=16384）—— 这是为 Android 15+ 的 16KB page size 要求做的适配
没给 KeyStore 时自动生成一个随机 RSA 2048 测试签名（CN=Android Debug）

编译期安全加固

Android.mk 里 native 库开了不少编译防护：ThinLTO、栈保护（SSP）、FORTIFY_SOURCE=2、隐藏符号、RELRO + NOW、arm64 的 PAC/BTI（-mbranch-protection=standard），还用 version script 白名单只导出 JNI_OnLoad。

有个注释挺有意思，是实机踩坑记录：

不要对 JNI 模块启用 Clang CFI。隐藏符号 + ThinLTO 下，arm64 的 CFI 会给导出的 JNI_OnLoad 生成一个 canonical trap stub（BTI; BRK #0x5502），Android 的 native loader 通过 dlsym 直接调用它会崩。已在 Android 16 arm64 真机复现。

所以在 app/build.gradle 里专门写了个 Gradle 检查任务：反汇编 libcore.so，如果 JNI_OnLoad 开头出现 brk 指令就直接 build 失败。

三、源码规模

部分	规模
Java（加固工具本体，10 个类）	约 4961 行
Native C/C++（壳运行时）	约 3603 行
支持 ABI	arm64-v8a / armeabi-v7a / x86_64 / x86

主要文件：

app/src/main/java/com/x/apacker/
├── MainActivity.java              界面与流程编排
├── PackerEngine.java              核心加固引擎（打壳/加密/重打包/签名）
├── AxmlPatcher.java               二进制 AndroidManifest 改写
├── DexEncryptor.java              NPX3 DEX 加密
├── Dex2cIrEncryptor.java          D2M2 Dex2C 加密容器
├── Dex2cBridgeRewriter.java       Dex2C bridge 重写
├── BuildKeyDerivation.java        HKDF 密钥派生
├── KeyInjector.java               把密钥分片 patch 进 .so
├── ApkSigner.java                 V1/V2/V3/V4 签名
├── PreflightInspector.java        加固前预检
├── NativeDex2cEngine.java
├── PrivateApkLayout.java
└── RuntimeMetadataEncryptor.java

native_core/src/
├── jni_entry.cpp                  JNI_OnLoad + 方法注册
├── keys.cpp                       密钥分片（锚点定位）
├── classloader/inmemory_loader.cpp 内存加载 DEX
├── reflect/art_helper.cpp         ART 内部字段反射
├── hidden_api/exempt.cpp          隐藏 API 豁免
├── anti_debug/anti_debug.cpp      7 项反调试
├── dex2c/dex2c_runtime.cpp        Dex2C 运行时
├── crypto/                        AES / GCM / SHA256 / SHA512 / HKDF
└── storage/                       APK 存储与运行时元数据

四、怎么编译

README.md 里给了标准步骤：

1. 装 Android SDK + NDK
2. 复制 local.properties.example → local.properties，填 sdk.dir
3. gradlew.bat testDebugUnitTest     # 跑单元测试
4. gradlew.bat buildNativeCore       # 编译 native 壳
5. gradlew.bat assembleDebug         # 出 APK

或者直接双击 run_compile.bat，它会自动找 JDK（优先 JAVA_HOME，其次 Android Studio 自带的 JBR）。

工程本身是 Gradle 8.x + AGP 8.3.2，minSdk 26（Android 8.0）、compileSdk 34。

依赖里能看到技术选型：smali-dexlib2（DEX 操作）、apksig（签名）、BouncyCastle（证书）、Guava。

目录里还附了 AIDE Pro_2.9.1.apk（61 MB），是安卓端的 Java IDE，用来在手机上改这个工程、直接编译出 APK——也就是说这套东西是设计成「手机上就能完成加固」的，不需要电脑。

五、这东西能用来干什么

正经用途：

保护自己开发的 APK 不被轻易反编译、篡改、二次打包
学习 APK 加固 / 壳技术的完整实现（这套代码质量不错，注释详实，特别是那些实机踩坑记录很有参考价值）
对比研究商业加固（360 加固、腾讯乐固、梆梆）的技术路线差异

需要提醒你注意的：

加固 ≠ 安全。 加壳只提高逆向成本，挡不住有心人。真正的密钥、接口凭证、核心算法不要靠加固来保护。
加固后的 APK 兼容性风险很高。 特别是：

用了热修复、插件化、跨进程、加固过的第三方 SDK 的 APK，套壳后大概率起不来
严格模式（全部检测拉满）容易误杀正常环境，必须真机充分测试再发
可以先从「兼容优先」档试，能正常跑再往上加

反调试在开发阶段会挡住你自己。 开了 TracerPid 检测后，你自己挂调试器会直接崩。开发期建议关掉反调试，出包时再开。
签名问题最容易翻车。 用「测试签名」出的包，用户装不上（和原 App 签名不一致会被系统拒绝覆盖安装）。用「原签名自签」的话，输出的是未签名 APK，必须你自己拿原私钥重新签 v2/v3 才能装。
上架应用商店要谨慎。 部分渠道对加固后的包有额外审核要求；另外加固会改 Manifest 和 DEX 结构，某些渠道的自动化检测可能误报。
别拿它加固别人家的 APK。 对第三方 App 加壳再分发，属于侵权甚至违法。这个包自带的免责声明也是这个意思。

六、和你的业务有什么关系

结合你在做的方向，这套东西有几处可以直接用得上：

CordysCRM 移动端（Capacitor 打包的 Android APK）：如果是要交付给客户的产品包，加固可以防止客户方或第三方直接反编译拿 H5 源码和接口地址。但要注意 Capacitor 的 WebView + 插件机制比较特殊，套壳后要重点测 WebView 加载、JS Bridge、文件访问这几块。
源码站内容：这套资源本身是很典型的「高价值工具类源码」，素材质量和完整度都够（源码 + 成品 + 编译说明 + AIDE 手机编译方案），适合做技术科普向的公众号文章。
安全审计视角：这套源码里 native 层的密钥分片、内存加载、反调试检测清单，反过来也是一份很好的「加固 App 怎么分析」的对照教材。

附：目录清单

APP加固源码和成品防护app/
├── 荷花加固.apk                      10.4 MB   编译好的成品，装机即用
├── 荷花加固源码/                               完整工程源码
│   ├── app/                                    Android App 模块
│   ├── native_core/                            C/C++ 壳运行时
│   ├── stub_template/                          壳模板（编译成 stub.dex）
│   ├── gradle/  gradlew  gradlew.bat           构建工具
│   ├── build.gradle  settings.gradle           构建配置
│   ├── run_compile.bat                         一键编译脚本
│   ├── local.properties.example                SDK 路径配置样例
│   ├── README.md                               编译说明
│   ├── AIDE Pro_2.9.1.apk           61 MB      手机端 Java IDE（配套工具）
│   ├── 【必看】狗凯之家提醒.txt
│   ├── 免责声明.txt
│   ├── 更多实用资源.html
│   └── 防失联.jpg
└── README.txt                                 源码站标准免责声明

本站文章部分内容可能来源于网络,仅供大家学习参考,如有侵权,请联系站长📧ommind@qq.com进行删除处理!

THE END

APP加固源码和成品防护app