字节暗面

AI 辅助分析实战：四款 Android APP 静态加固强度对比

2026-08-19 20:06 逆向分析 #AI辅助分析 #加固 #客户端加固

AI 做包体分析的能力，已经比前两年强了很多。以前把 APK 交给模型，它通常只能根据文件名认壳，或者解释几段 readelf、strings 的输出。

现在有本地工具配合，模型可以自己拆包、解析 DEX header、统计类表、计算载荷熵值、检查 ELF，再把分散的特征串成一份完整的静态分析记录。

这次测试用的是 ChatGPT 5.6-Sol 。我把四个 APK 直接交给它处理，样本分别是起点读书、123云盘、汽车街和凤凰视频，对应360加固、爱加密、梆梆安全和腾讯乐固。

整个过程中，我主要复核厂商特征、异常数据和最后的判断口径，基础数据基本由 AI 完成提取和整理。感兴趣的朋友可以按照下面的流程进行复现：

测试对象

APP 样本 版本 加固产品
起点读书 7.9.472 360加固
123云盘 3.2.16 爱加密
汽车街 4.0.5 梆梆安全
凤凰视频 7.40.1 腾讯乐固

厂商归属核对特征

  • 起点读书 / 360加固

  • 包名：com.qidian.QDReader

  • Application：com.qidian.QDReader.QDApplication

  • SO：libjiagu_vip.so、libjiagu_vip_enc.so

  • 123云盘 / 爱加密

  • 包名：com.mfcloudcalculate.networkdisk

  • Application / 壳命名空间：s.h.e.l.l.S、s.h.e.l.l.*
  • SO：libijmDataEncryption.so、libexec*.so

  • assets 载荷：assets/ijiami.ajm、assets/ijiami.dat

  • 汽车街 / 梆梆安全

  • 包名：com.shuxun.autostreets

  • Application / 壳命名空间：com.secneo.apkwrapper.AW、com.secneo.apkwrapper.*
  • SO：libDexHelper.so、libdexjni.so

  • 载荷特征：主载荷追加在 DEX 尾部

  • 凤凰视频 / 腾讯乐固

  • 包名：com.ifeng.newvideo

  • Application / 壳命名空间：StubWrapperProxyApplication、com.wrapper.proxyapplication.*
  • SO 与载荷：libshell-super.com.ifeng.newvideo.so、tosversion、0OO00l111l1l

厂商归属不是根据应用名称猜的。每个包都至少核对了 Application 入口、壳命名空间、SO 文件和 assets 载荷，几个特征能互相对应才算确认。

这些命名会随产品版本和配置变化，单独命中一个文件名并不足以定厂商。这里采用的是多项特征交叉确认，结论只对应本次拿到的四个 APK。

测试方法

这里模型选择的是 ChatGPT 5.6-Sol 推理强度开到高，输入指令：分析四个包体的加固强度并进行对比。

解压 APK 后，先解析 AndroidManifest，确认真实 Application 有没有被壳入口替换。然后遍历 classes*.dex，统计类定义、方法引用和应用自身包名前缀。最后检查可疑 assets 的文件头、体积和熵值，再用 readelf、strings 看壳 SO 的节区、动态符号和反分析字符串。

这里的“加固强度”只指静态业务代码隐藏和第一阶段分析成本。启动性能、Frida 附加、Root/模拟器、内存 Dump、重签名和二次打包对抗都不在本次范围内。

统一结果

样本 / 加固 标准 DEX / 类 / 方法 自有业务类暴露 静态分档
起点读书 / 360 12 / 70,798 / 553,107 高：约 27,739 个 com.qidian.* 类 C+
123云盘 / 爱加密 1 / 4 / 106 未发现 A
汽车街 / 梆梆 1 / 5 / 190 未发现 A
凤凰视频 / 腾讯乐固 3 / 39 / 369 未发现；两个 DEX 为占位类 A-

表中的“类”和“方法”分别指标准 DEX 解析器能够直接读取的类定义数与方法引用数。

如果只看这四个包的静态暴露面，结果大致是：

梆梆样本 ≈ 爱加密样本 > 腾讯乐固样本 > 360加固样本

这个顺序只对应手里的四个包。360样本很可能采用了选择性保护，或者应用侧没有开启完整的 DEX 隐藏，不能拿它代替产品的最高配置。

1. 梆梆安全（汽车街）：DEX 尾部藏载荷，Native 壳裁剪最彻底

汽车街的 Application 是 com.secneo.apkwrapper.AW，包内同时存在 libDexHelper.so、libdexjni.so 和对应的 x86 组件，梆梆特征比较明确。

它的 classes.dex 看起来有30MB，但合法 DEX 结构在大约19KB处就结束了。后面约30.03MB并不属于标准类表，而是直接追加在 DEX 尾部的自定义数据。常规 DEX 工具只能解析出5个壳类和190个方法引用，原应用业务类没有出现。

主业务 DEX 已经整体隐藏，标准解析器也无法把尾部的30.03MB数据还原成业务类关系。负责加载的 libdexjni.so 约6.23MB，已经 stripped，只剩4个 ELF 节区，动态符号为0。字符串中还能看到 /proc/self/maps、Frida、GDB、Hook、ROOT 和 SU。

追加数据的整体熵值约6.16，零字节比例约31.42%，没有爱加密和腾讯载荷那么接近8.0。但这里不能简单理解成“加密更弱”。大量填充、自定义编码和分段结构都会拉低整体熵值，真正影响静态分析的是业务类已经不在标准 DEX 结构里了。

这个样本把 DEX 和加载器两头都收得比较紧。就本次能统一检查的壳 SO 来看，它的第一阶段静态定位成本最高。

2. 爱加密（123云盘）：可见 DEX 最干净，业务载荷独立拆分

123云盘的 Application 为 s.h.e.l.l.S，AppComponentFactory 为 s.h.e.l.l.A。标准 DEX 只有约14KB，里面一共4个壳类、106个方法引用，原应用的业务类没有直接出现。

主要载荷被拆到两个文件里：

  • assets/ijiami.ajm：约11.15MB
  • assets/ijiami.dat：约16.79MB

两个文件都呈现高熵特征。包内还能看到 libijmDataEncryption.so、libexec.so、libexecmain.so 和 libijm-emulator.so，整体是比较典型的“缩壳 DEX + 独立数据载荷 + Native 执行链”。

4个类已经接近纯入口规模。静态工具能认出这是爱加密，也能顺着文件名找到数据处理和执行组件，但原始类关系已经不在标准 DEX 里。libijm-emulator.so 还说明包中集成了模拟器相关模块，至于是否启用、怎么触发，要到运行时才能确认。

它和梆梆很难只靠静态数据硬排先后。爱加密的载荷隔离更规整，梆梆的 Native 壳结构裁剪更彻底。4个类和5个类之间的差距本身没有多少意义，真正决定脱壳难度的是载荷何时解密、怎样回填，以及运行后能不能稳定重建。

3. 腾讯乐固（凤凰视频）：主 DEX 隐藏完整，壳结构留下的信息更多

凤凰视频这个包的 Application 已经被替换成 StubWrapperProxyApplication，主 DEX 中可以看到 com.wrapper.proxyapplication.WrapperProxyApplication、AndroidNClassLoader 和 MultiDexForMemoryDex。包内还有 libshell-super.com.ifeng.newvideo.so、tosversion、0OO00l111l1l 等特征，可以确认是腾讯乐固。

三个可见 DEX 加起来只有约83.8KB：

  • classes.dex：21个包装类、349个方法引用
  • classes2.dex：9个 com.example.helloworld 占位类
  • classes3.dex：9个 com.example.helloworld 占位类

原来的凤凰视频业务类没有出现在标准类表中。主载荷 assets/0OO00l111l1l 约11.77MB，熵值约7.963；另外两个载荷分别约430KB和523KB，熵值都接近7.9996。

真实业务类没有暴露，三个主要载荷也都不是标准 ZIP、DEX 或 ELF 文件头。arm64 壳约562KB，已经 stripped，其中能看到 ptrace、mprotect、dlopen、dlsym、xhook、shadowhook 和 /proc/self/maps。

业务代码已经藏住，较明显的暴露点在壳本身。这个 SO 仍保留25个 ELF 节区、178个动态符号和约1,412条可打印字符串，xhook、shadowhook 及加载流程相关信息都能直接看到。

对于静态分析者来说，第一步仍然拿不到业务 DEX，但比较容易先画出壳的加载、Hook 和内存映射结构。因此它被放在 A-，不是因为主代码隐藏不完整，而是壳入口相对更容易梳理。

4. 360加固（起点读书）：壳组件不松，业务 DEX 却留得很多

起点读书的 Application 继承关系最终指向 com.stub.StubApp，包内能看到 libjiagu_vip.so、libjiagu_vip_x86.so、libjiagu_vip_enc.so 和 com.qihoo.magic，360加固特征没有问题。

单看壳 SO，它并不弱。libjiagu_vip.so 已经 stripped，只保留4个 ELF 节区，动态符号为0；字符串里也能找到 /proc/self/maps、ptrace、mprotect、dlopen 和 dlsym。

问题在于业务代码没有整体拿走。APK 内仍有12个标准 DEX，共70,798个类定义和553,107个方法引用，其中约27,739个类带有 com.qidian.* 前缀。

壳组件本身已经做过明显裁剪，但业务 DEX 暴露得很直接。分析者不必先完成整包脱壳，就能从类名、包结构、SDK 调用和部分实现入手。这个包更像是只保护敏感方法、Native 逻辑或指定模块。

所以这个结果不能写成“360加固最弱”。更准确的说法是：

起点读书这个360加固样本的静态业务代码隐藏程度最低。

同一个产品有不同版本和策略配置。没有原始包和控制台配置，仅凭最终 APK 无法判断大量业务 DEX 是兼容性取舍、应用侧选择，还是只对少量核心代码做了定点保护。

这次结果怎么理解

四个样本里，爱加密、梆梆和腾讯乐固都完成了主业务 DEX 的整体隐藏。差别在载荷怎么放，以及负责恢复代码的 Native 壳留下了多少可供静态定位的信息。

梆梆的 Native 壳裁剪最明显；爱加密的标准 DEX 最干净，载荷拆分也更规整；腾讯乐固同样把主 DEX 藏了起来，但壳中保留了更多 ELF 结构、动态符号和 Hook 框架信息。起点读书所用的360配置则是另一条路线：壳本身处理不差，却没有把大量业务 DEX 从静态面上拿走。

要回答“拿到 APK 后，第一轮静态分析还能看到多少”，这组数据已经够用了。至于哪个产品最终更难脱壳，仅靠这些还不够。

下一步至少还要在同一台设备上补 Frida 附加、调试器附加、Root/模拟器、重签名、内存 Dump 和二次打包测试。业务代码藏得再干净，如果运行后长时间以完整明文留在内存里，仍然可能被拿走；反过来，保留一部分普通业务类，也可能只是把保护资源集中在真正敏感的路径上。

← 返回列表