最近又找了几个APP，让 ChatGPT 配合本地工具做了一轮静态分析。这次测试用的是 GPT-6.1 Sol 。我把四个 APK 直接交给它处理，样本分别是起233乐园、万年历、墨迹天气和有道翻译官，对应腾讯ACE、梆梆安全、爱加密和网易易盾。
通过比较这几个 APK 在静态层面的加固强度，使用AI辅助分析，是否能直接读到业务代码。整个过程中，我主要复核厂商特征、异常数据和最后的判断口径，基础数据基本由 AI 完成提取和整理。感兴趣的朋友可以按照下面的流程进行复现：
测试对象
| APP 样本 | 版本 | 加固厂商判断 |
|---|---|---|
| 233 乐园 | 4.88.0.0-4888767 | 腾讯 ACE/TP 特征 |
| 万年历 | 7.5.6 | 梆梆 / SecNeo |
| 墨迹天气 | 9.0948.04 | 爱加密 / Ijiami |
| 有道翻译官 | 4.3.47 | 网易易盾 / Yidun |
厂商归属核对特征
| 样本 | 入口与配套文件 |
|---|---|
| 233 乐园 | MetaApp 继承 com.ace.gshell.AceApplication，加载 libtprt.so 并调用 native 初始化 |
| 万年历 | com.secneo.apkwrapper.AW；libDexHelper.so、libdexjni.so、libdatajar.so |
| 墨迹天气 | s.h.e.l.l.S；assets/ijiami.dat、assets/ijm_lib/*/libexec.so |
| 有道翻译官 | com.netease.nis.wrapper.MyApplication；libnesec.so、libdexvmp.so、nedata.db |
表里的厂商归属，是把 Application 入口、壳命名空间、SO 和载荷布局对起来核实的，只对应这四个版本。
测试方法
这次模型使用的是 GPT-6.1 Sol，推理强度开到高。分析时允许模型调用本地工具，读取 APK、执行解析脚本。
四个原始 APK 一起上传，输入的原始测试口令是：
分析四个包体的加固强度并进行对比
具体过程是先核对样本 SHA-256 和 Application，再遍历根目录 classes*.dex，统计类定义、方法引用，以及带主应用包名前缀的类。接着检查可疑载荷的大小、熵和明文类型描述符，壳 SO 则统一取 ARM64 版本看 ELF 结构。用到的工具有 Androguard、pyelftools 和 APKiD，规则识别结果还要与包里的实际结构对照。
统一结果
| 样本 | 标准 DEX / 类 / 方法引用 | 主包可见类 | 静态特征指数 |
|---|---|---|---|
| 墨迹天气 | 37 / 49,524 / 369,036 | 0 | 90 |
| 万年历 | 1 / 5 / 168 | 0 | 85 |
| 有道翻译官 | 1 / 30 / 598 | 0 | 85 |
| 233 乐园 | 12 / 111,143 / 664,251 | 18,676 | 10 |
“主包”指 APK 自身包名前缀，不等于全部自研代码；方法引用数也不是实际方法体数量。
分数是在基础分析完成后补的，方便把已经查到的保护特征放在一起比较。我按本轮自定义规则分了三项：标准 DEX 中的主业务代码隔离占 40 分，所查范围的类型元数据隐藏占 30 分，核心壳 ELF 结构处理占 30 分。
| 样本 | 代码隔离 / 40 | 元数据 / 30 | 壳结构 / 30 |
|---|---|---|---|
| 墨迹天气 | 40 | 30 | 20 |
| 万年历 | 40 | 15 | 30 |
| 有道翻译官 | 40 | 15 | 30 |
| 233 乐园 | 0 | 0 | 10 |
- 代码隔离：大量业务代码可直接读取，记 0；主包和所查组件定义均移出标准 DEX，且有壳与载荷证据，记 40。
- 元数据隐藏：直接可读、载荷内仍有明文、所查载荷未检出指定业务前缀，分别记 0、15、30。
- 壳结构处理：结构常规、部分受处理、关键结构受处理，分别记 10、20、30。
1. 爱加密（墨迹天气）：37 个 DEX，主包类定义却没出现
墨迹天气保留了约 62.91 MiB 标准 DEX，单看体积，容易觉得代码留得不少。可按主应用包名前缀去找，一个类定义都没找到；Manifest 中检查的 80 个主包 Activity/Provider，也都没有在这些 DEX 中出现定义。SDK 等代码虽然可见，还不能因此算出主业务暴露了多少。
主载荷 ijiami.dat 为 26,374,884 B，熵约 7.994，里面没有检出所查 Lcom/moji/ 前缀的类描述符。在这轮检查的主载荷里，它留下的明文业务类型名称更少。熵接近 8 只作辅助参考，压缩或数据混合也能得到高熵，不能靠这个数判断加密强度。
加载器仍有可分析的信息。ARM64 libexec.so 的节结构经过处理，但从动态段还能枚举符号。主业务暂时读不到，仍然可以先从加载器入手。
2. 梆梆（万年历）：类表只剩壳，载荷里的名称还在
万年历的标准 DEX 只有 17,624 B，一共 5 个壳类。主包下 64 个组件的定义都没出现，用普通解析器打开，先看到的就是这点入口包装代码。
不过，libdatajar.so 里还留着不少名称。这个约 59.03 MiB 的容器能检出 3,617 个 Lcom/youloft/calendar/ 类描述符。到这一步还没恢复方法体，但已经能借这些类型名称定位业务了。
负责加载的 libDexHelper.so、libdexjni.so 对 ELF 元数据做了处理，常规的动态符号枚举在这里受阻。工具给不出可靠的导出计数，还得沿着程序段和加载过程继续看。
3. 网易易盾（有道翻译官）：大 DEX 主要是尾部载荷
有道的 classes.dex 有 67,391,740 B。我按头部的 data_off + data_size 算了一下，标准数据区只到 63,964 B，后面另有 67,327,776 B 数据。大头都在尾部载荷里，不能把整个文件大小当成可见业务代码量。
实际能从类表解析出来的只有 30 个类，主要是壳代码。尾部仍能检出 10,878 个 Lcom/youdao/ 描述符，说明类型元数据没有全部藏住。
libnesec.so 的主要可执行区域经过重组，包里还能找到 libdexvmp.so 和 nedata.db。VMP 相关模块的线索是有的，具体覆盖了哪些原业务方法，这轮还没确认。
4. ACE/TP 特征（233 乐园）：壳在，业务指令也在
顺着 233 乐园的入口，可以确认这条调用关系：
MetaApp → AceApplication
→ loadLibrary("tprt")
→ native initialize(...)
com.meta.box 下仍有 18,676 个类定义、84,854 个带指令的方法。88 个主包组件里，87 个能直接找到定义。这批方法包含约 6.07 MB 指令数组，类名之外，方法体也留了下来。
放在这四份样本里，它的主业务静态隐藏程度最低。至于是只保护了指定路径，还是应用侧做了兼容性取舍，仅凭最终 APK 判断不了。这份包也代表不了 ACE 的最高配置。
这次结果怎么理解
我比较在意的是两处差别。233 乐园的大量主业务指令可以直接读，另外三个包得先处理壳与载荷。再往载荷里找，万年历和有道都还留着大量明文类型名称，墨迹天气在本轮所查主载荷中露出来的更少。至于指数差的那 5 分，还说明不了谁实际更难脱壳。
后面要补的是真机运行：代码恢复后以什么形式存在，能不能稳定转储，启动和兼容又要付出多少代价。手里没有加固前的同版本基线，这些账现在还算不了。分析者恢复核心逻辑得多花多少工夫，应用侧为保护承担了多少工程成本，两边都测过，才好谈这套方案值不值。