找到 1 篇与 加固 相关的结果
-
APP加固源码和成品防护app 一句话结论 这是一套安卓 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-serverFrida 端口扫描 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 行支持 ABIarm64-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 里给了标准步骤： 装 Android SDK + NDK 复制 local.properties.example → local.properties，填 sdk.dir gradlew.bat testDebugUnitTest # 跑单元测试 gradlew.bat buildNativeCore # 编译 native 壳 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 源码站标准免责声明 资源下载 隐藏内容，请前往内页查看详情 本资源售价9.9元，购买后即可查看下载地址。如有问题请联系站长。
