JADX 看不到算法之后，公开脱壳工具还能走多远：一次御盾加固 APK 实测

原文承接页：JADX 能不能还原原始算法？御盾加固 APK 的静态还原难度实测

这篇稿按看雪读者的习惯写：先给目标，再给过程，再给失败边界。结论不是“不可逆”，而是普通静态反编译没有还原原始算法，公开运行态 dump 工具也没有产出可用 DEX。测评继续走到了动态层，但没有把未验证的启动、二次打包和危险环境写成通过。

看雪版本重点保留工具链过程和失败尝试。它不会给出可复现 dump 步骤，但会说明为什么这轮不是只看原始 DEX。

测评目标与非目标

本轮不是泛扫 APK，也不是把“反编译看不到”直接包装成安全结论。目标被限定为：在常规静态反编译之后，继续使用公开工具和隔离运行环境，观察是否能进一步还原原始算法或形成可用 DEX dump。

这个目标矩阵的作用，是防止报告把“安装成功”“入口被拉起”“JADX 没有源码”混成一个大结论。每一行都只回答自己能回答的问题。

证据与测评依据

这些证据的共同点是：可以支撑“公开工具链未直接还原原始算法”，但不能支撑“所有动态对抗都完成”。这就是公开技术文章必须保留的边界。

攻击工具矩阵：本轮覆盖了什么，没有覆盖什么

这次补充的关键，不是把更多工具名堆上去，而是把攻击者的常规路线按阶段排清楚。每个阶段都要回答三个问题：这类工具想拿什么、这轮观察到了什么、为什么还不能写成最终通过或最终失败。

这张表解决的是“知识面太窄”的问题：文章不再只围绕一个反编译器和一个 dump 工具，而是把脱壳、注入、调试、重打包、危险环境全部放进攻击路径。已经执行的写结果，没执行的明确写成后续专项，避免伪造事实。

测评经过

这轮测评重新补上了上一版缺失的内容：不是只看原始 DEX，也不是只跑 JADX 就收工。流程先做容器枚举，再做 JADX 和 apktool；随后进入隔离运行环境完成干净安装；最后尝试公开 dexdump 工具。最终结论也因此变得更克制：安装阶段成立，公开工具未产出可用 DEX dump，启动后进入 native 快速闭合，所以不能写稳定启动结论。

现象复核链：看到效果以后，至少再核实一次

上一版的问题是：看到一个现象后很快跳到下一步，没有解释它是否被复核。本版把每个现象都拆成“首次观察、复核动作、仍然不能证明什么”三段。

这条复核链把“看到效果”变成“看到现象、复查一次、收住结论”。真正专业的测评不是每一步都赢，而是每一步都知道自己能证明什么。

原始报告事实映射

动态时间线

攻防逻辑

攻击者做低成本还原，通常不会一开始就写复杂工具。他会先用 JADX 看 Java 面，再用 apktool 看 smali 和 Manifest，然后检查 native、assets 和字符串面。如果这些都没有直接给出算法，才会进入运行态 dump、Hook、Gadget、内存提取或定制环境。

本轮走到了公开工具的运行态尝试，而不是停在 JADX。这个差别很关键：只说“JADX 看不到”，懂行的人会认为证据很薄；写清楚 JADX、apktool、安装、Frida、frida-dexdump 的实际结果，才像真实测评记录。

这里的“好话”不是硬夸，而是只写被验证的正向事实：静态源码面没有直接还原、公开 dump 工具未形成结果、安装阶段成立、运行边界被如实保留。没有证据的好话不写。

主因链：为什么没有复现出原始算法和可用 dump

本轮现象可以收束成一条主因链，而不是散点结论：

1. 普通 Java 反编译没有直接恢复原始算法，说明核心逻辑没有以低成本源码面完整暴露。
2. smali 面能看到较大体量的壳层、桥接、装载和控制结构，但它更像“运行态材料调度层”，不是业务算法明文层。
3. Manifest 代理链、ClassLoader 类别、native bridge 类别和大体量 assets 共同指向同一件事：关键材料被放到跨 DEX、native、assets 和运行态加载路径里。
4. 干净环境安装成功以后，入口拉起进入 native 快速闭合，说明动态分析不能只依赖普通 attach 时机。
5. 公开 dump 工具没有产出可用 DEX，更可能是“可见 Java 面不足 + 运行态窗口短 + native/asset 载体参与 + 完整性/闭合路径介入”共同导致，而不是某一个工具单点失败。

所以，本轮最准确的结论是：常规静态还原无法直接复现原始算法；公开运行态 dump 工具在这个运行窗口下没有拿到可用 DEX；后续若要继续推进，必须把目标拆成 DEX dump 抗性、native 调试抗性、二次打包闭合和危险环境矩阵四个专项。文章不应该把这四个专项提前写成已通过。

public_evidence:
  measurement_scope:
    target: "static recovery plus public runtime dump attempt"
    non_goal:
      - "no claim of full business startup"
      - "no claim of completed dynamic unpacking"
      - "no claim of repackaging closure"
  observations:
    jadx_java_files: 43
    jadx_errors: 2
    apktool_smali_files: 43
    smali_volume: "about 92k lines"
    container_shape: "two DEX, two native carriers, multiple asset carriers"
    install_result: "clean install succeeded"
    runtime_result: "native fast closure after launch"
    public_dexdump_result: "no usable DEX dump produced"
  publish_boundary:
    allowed:
      - "tool categories"
      - "redacted counts"
      - "measurement sequence"
      - "supported positive observations"
    private:
      - "package identifiers"
      - "local paths"
      - "raw commands"
      - "class and component names"
      - "logs, stacks, symbols, offsets"

defensive_assessment_flow:
  1. classify_sample_without_publishing_identifiers
  2. run_static_decompiler_and_record_visible_surface
  3. run_resource_and_smali_decoder_for_shell_structure
  4. inspect_native_and_asset_carriers_without_naming_them
  5. install_in_clean_environment
  6. observe_startup_boundary
  7. attempt_public_runtime_dump_tooling
  8. publish_only_supported_positive_findings
  9. keep raw operational details private

过程证据行

平台化写法说明

看雪读者通常会追问：有没有跑动态？有没有跑 dump？有没有解释失败？本稿把这三件事放在正文核心位置。安装成功只写安装成功，运行期闭合只写闭合，frida-dexdump 未产出就写未产出。这样的文字不如“全都通过”好看，但更接近专业测评记录。

结论边界

这篇平台稿只发布可验证的正向事实：普通静态反编译没有直接还原原始算法，公开 dexdump 工具没有形成可用 dump，干净安装阶段成立，运行期边界被保留。它不发布未验证结论，不把安装成功写成稳定业务通过，不把工具未产出写成绝对不可还原，也不提供任何可复现脱壳或绕过步骤。

下一步适合拆成四个专项：DEX dump anti-repair、二次打包 fail-closed、危险环境矩阵、SO 载体分析。每个专项都需要单独目标、单独证据和单独边界，不应混在同一篇里。