拿到 DEX 和 ELF，为什么仍还原不出核心算法？御盾 Android 加固四级恢复实测

拿到运行期导出的 DEX 或可解析 ELF，不等于已经还原核心算法。本次实测中，恢复材料分别达到文件生成、格式有效和部分程序结构可读，但没有形成可脱离原应用独立复现关键计算的等价实现，因此不能把“dump 成功”写成“算法已被破解”。

摘要

Android 加固测评中最常见的夸大，不只来自厂商，也可能来自测试方。工具写出一个带 DEX 魔数的文件，报告就写“脱壳成功”；内存里截到一个带 ELF 头的镜像，报告又写“SO 已还原”。这两种说法都跳过了关键的中间检查：文件是否完整、标准解析器能否稳定读取、恢复出来的类与控制流是否可信、native 导出面是否具有业务语义，以及恢复材料能否独立重现原始输入输出。

本次专项沿用一份已经完成干净环境安装、三次冷启动和关键业务路径验证的御盾 Android 加固候选。测试没有停在原包静态反编译，而是依次执行原包基线阅读、标准运行期 DEX 恢复、深度恢复、恢复后再反编译、native 模块映射、连续内存镜像复核、后备载体复核、ELF 结构验证和算法等价判断。结果并非“什么都拿不到”：运行期能够识别并写出 DEX 材料，也能取得可解析的 64 位 ARM ELF；但恢复层级止于类、部分控制流、机器代码和有限导出面，没有得到原始核心运算的等价实现。

文章因此不使用“绝对防脱壳”这类不可证实的措辞，也不把文件数量当作破解结论。它提供一套可以用于 App 加固 PoC 的四级恢复模型：L1 材料生成、L2 格式有效、L3 程序结构恢复、L4 算法等价。只有到达 L4，测试方才有资格说“核心算法已被还原”。

读者对象

本文适合移动安全负责人、Android 架构师、游戏安全团队、金融科技研发、逆向评估人员和正在采购 App 加固产品的团队。尤其适合两类场景：一类是已经拿到某种 DEX/SO 导出结果，却不知道该如何判断实际价值；另一类是供应商只展示混淆截图或“工具报错”，但没有给出从材料恢复到算法等价的完整证据链。

核心结论

• 文件生成只是 L1。恢复工具显示成功、输出目录出现文件，不能证明格式有效，更不能证明文件属于核心业务。
• 标准解析只是 L2。DEX 可被解析、ELF 有完整头部和段信息，只能说明它是有效程序材料。
• 类、控制流和机器代码可见属于 L3。它提高分析可见性，但仍可能缺少状态、调用上下文、动态材料和业务语义。
• 算法还原必须达到 L4：恢复实现能够脱离原应用，对相同输入、关键状态和异常条件产生等价结果。
• 本次标准与深度 DEX 恢复提高了类和部分控制流可见性，核心计算仍跨越桥接与 native 分发，没有形成等价实现。
• 本次取得了有效的 stripped ARM64 ELF，导出面集中在少量桥接与注册类别，反汇编未重建原始 C/C++ 算法。
• 本轮结论是“在已执行工具类别和环境中，核心算法未被等价还原”，不是“任何人永远无法继续分析”。

测评目标与非目标

本轮主目标是回答：当运行期已经产生 DEX 和 native 恢复材料时，测试人员应依据什么证据判断核心算法是否真的被还原。

非目标包括公开真实样本、提供可运行脱壳脚本、披露注入链、枚举内部类或函数、证明所有工具都会失败，以及把 DEX/SO 专项结果外推成 Frida、内存修改、二次打包等其他维度全部通过。不同攻击目标需要独立证据，不能互相代替。

四级恢复模型：先定义“拿到”是什么意思

L1：材料生成

这一层只回答“工具有没有写出东西”。输出可能是完整文件，也可能是内存残片、重复映射、伪头部或扫描误报。L1 的价值是提供后续样本，不提供安全结论。若报告只附一张输出目录截图，它最多证明工具执行过。

L2：格式有效

DEX 需要由标准解析器读取头部、索引区和数据区，并能够在不同工具间得到一致结果；ELF 则需要验证文件类别、目标架构、程序头、段布局和加载信息。仅看到魔数不够。连续内存镜像可能以 ELF 头开始，却因为映射边界、重定位和非连续页导致节信息不完整。

L3：程序结构恢复

这一层关注类、方法轮廓、调用方向、控制流、native 模块、导出表和可分析机器代码。结构恢复能够显著减少分析人员的搜索空间，但仍不意味着拿到了原始业务实现。一个 Java 入口可能只负责参数整理，然后把计算交给 native；一个有效 ELF 也可能已经剥离符号，只保留少量注册入口。

L4：算法等价

算法等价不是“看起来像”，而是可验证的行为关系。恢复实现应在明确的输入域、状态前置、异常分支和输出格式下，与原实现产生等价结果。若仍依赖原应用的运行时材料、类加载上下文、native 状态或服务端返回，就不能称为独立算法还原。

攻击工具矩阵

为避免把某一种工具的返回值当作最终答案，本次采用多阶段交叉复核。公开表只列工具类别和判定对象，不提供真实目标、参数或执行链。

测评经过：从原包到等价性判断

第一步：建立原始候选基线

恢复测试必须先证明目标在当前环境可正常运行，否则内存里缺少材料可能只是应用没有进入正确阶段。本轮先完成干净安装，连续执行三次冷启动，每次都检查前台窗口和进程存活；随后进入一条关键业务路径，确认操作后应用仍持续运行，且测试时间窗内没有致命崩溃或无响应事件。

第二步：记录原包的静态可见面

原包包含多 DEX、应用级入口代理、native 桥接以及不止一种 native 载体。静态反编译能够生成源码结构，但核心计算没有以完整 Java 算法展开。这里没有直接下“防逆向通过”结论，因为静态不可读可能来自工具兼容问题，也可能在运行期出现更完整材料。

第三步：执行标准 DEX 恢复

在应用已经完成启动与关键路径后，标准运行期搜索识别并写出多组 DEX 候选。文件先做去重，再由独立解析器检查格式，随后进入二次反编译。这个顺序很重要：如果跳过格式和去重，重复映射会让文件数量虚高，损坏候选也会被误计为有效结果。

第四步：扩大到深度恢复

深度搜索确实发现更多候选，但其中既有新增有效材料，也有解析异常的残片。测试没有把“更多文件”自动换算成“更高恢复率”，而是把每一类结果继续送入格式与反编译复核。最终，恢复集合展示出比原包静态阅读更多的类、业务入口轮廓和部分控制流，同时仍保留解析错误。

第五步：检查核心运算归属

恢复后的 Java 结构没有形成原始核心运算的完整等价实现。可见入口仍需要跨越桥接与 native 分发，关键状态也依赖原应用运行上下文。换言之，DEX 恢复把分析从“壳层可见”推进到“部分程序结构可见”，但没有推进到“算法可独立复现”。

第六步：验证 native 映射与连续镜像

运行期模块视角能够定位内存文件形态的 native 载体。直接按连续映射输出的镜像带有 ELF 头，但独立解析时发现结构不完整。这类结果很容易被截图包装成“SO dump 成功”，实际上它只达到 L1：有一个看似正确的文件开头，却不足以支持稳定的装载结构分析。

第七步：复核映射后备载体

从映射后备材料取得的另一份载体能够被标准 ELF 工具稳定解析，目标架构、程序头和加载信息完整，因此达到 L2。该文件已剥离符号，保留常见的 RELRO、NX、PIE 和栈保护属性，对外导出集中在少量桥接与注册类别，没有直接提供业务算法命名。

第八步：执行算法等价检查

最后不再看文件数量，而是看恢复结果能否脱离原应用复现关键计算。检查项包括输入域、状态前置、异常语义、输出格式和上下文依赖。DEX 与 ELF 恢复材料都没有形成满足这些条件的独立实现，因此本轮停在 L3，不能判定原始核心算法已还原。

动态时间线

事实依据与脱敏证据

原始报告事实映射

这里的原始报告是脱敏前的私有验收记录。公开映射只保留测试阶段、观察、判定和范围。

report_evidence:
  measurement_scope:
    - clean_runtime_baseline
    - original_static_decompilation
    - standard_runtime_dex_recovery
    - deep_runtime_dex_recovery
    - recovered_dex_redecompilation
    - native_mapping_and_elf_validation
    - algorithm_equivalence_check
  recovery_levels:
    material_generated: true
    format_validated: "partial_dex_and_valid_native_carrier"
    program_structure_recovered: "partial"
    equivalent_core_algorithm_recovered: false
  public_evidence:
    - "dump_output_is_not_algorithm_equivalence"
    - "parser_validation_precedes_security_conclusion"
    - "classes_and_control_flow_are_not_the_original_algorithm"
    - "valid_stripped_elf_has_limited_direct_business_semantics"
  boundary:
    - no_target_identifier
    - no_tool_command_or_raw_log
    - no_class_symbol_offset_or_address
    - no_reproducible_recovery_chain

现象复核链

主因链：为什么恢复了文件，算法仍没有复现

第一层原因是材料与语义不是同一个对象。DEX 文件可以包含加载框架、入口别名和桥接代码，却不一定包含独立的核心运算；ELF 文件可以结构完整，却已经剥离符号并只公开少量注册入口。第二层原因是算法归属跨层：Java 负责入口和参数组织，核心计算进入 native 分发，运行期状态又来自类加载和载体选择，单独恢复任一层都只获得上下文片段。第三层原因是工具输出存在质量差异：标准与深度搜索会同时带来有效材料、重复映射和残片，必须经过格式与反编译复核。最后，算法等价需要可重复的输入输出证明；当前材料仍依赖原应用上下文，无法脱离目标独立复现关键计算，因此只能判定为 L1-L3 的部分恢复。

技术拆解：把验收从截图升级为证据链

一份合格的恢复报告应把每个输出文件依次送过四道门，而不是直接使用工具的成功提示。下面是公开安全的验收伪代码，不包含任何目标定位、注入或导出步骤。

for each recovered_material:
    level = L1 if file_exists_and_deduplicated(material) else NONE
    if level == L1 and standard_parser_accepts(material):
        level = L2
    if level == L2 and two_independent_views_agree_on_structure(material):
        level = L3
    if level == L3 and standalone_behavior_matches_reference_vectors(material):
        level = L4
    record(level, parser_evidence, structure_evidence, equivalence_evidence)

publish "algorithm recovered" only when level == L4

算法等价还要避免“只测一个正常输入”的问题。更稳妥的判定应覆盖正常输入、边界输入、状态变化和错误条件，并明确哪些状态来自服务端或运行时。

equivalent = true
for vector in approved_reference_vectors:
    reference = run_original_in_controlled_environment(vector)
    recovered = run_recovered_implementation_standalone(vector)
    equivalent = equivalent and compare(
        output=reference.output,
        state_transition=reference.state_transition,
        error_semantics=reference.error_semantics
    )

if any_runtime_dependency_is_unresolved:
    equivalent = false

攻防视角

对攻击者而言，L1 和 L2 解决的是“有没有可继续研究的材料”；L3 解决的是“能否缩小定位范围”；L4 才解决“能否复用核心能力”。加固产品的价值不应被描述为让所有文件永久不可见，而是提高从低层材料推进到业务等价实现的成本，并在完整性、二次打包、服务端证据和版本治理上继续收口。

对防守方而言，看到 DEX 或 ELF 被恢复不应立即否定全部加固效果，也不能反过来掩盖恢复事实。更合理的做法是记录恢复层级：哪些类可读、哪些控制流可信、哪些 native 入口可定位、核心算法是否可独立复现。这样才能把下一轮迭代投入到真实暴露面，而不是围绕“工具成功/失败”争论。

对采购方而言，PoC 应要求供应商和测试团队共同提交四类证据：原始候选可运行基线、恢复材料有效性、程序结构恢复程度、算法等价结果。若报告只写“dump 成功”或“工具报错”，都不足以比较产品强度。

工程落地

1. 给每个核心资产定义所有者

先标出高价值算法究竟位于 Java/Kotlin、JNI bridge、native 模块、动态材料还是服务端。没有资产所有者清单，就无法判断恢复材料是否真的覆盖目标。普通界面类被恢复，与核心签名算法被等价重建，风险等级完全不同。

2. 在 CI 中保存可比较的恢复指标

每次候选构建后记录原包静态可见类、标准恢复有效材料、深度恢复异常率、恢复后可读控制流、native 导出面和算法等价测试结果。指标必须绑定同一候选，不能拿旧包的动态结果替代新包。

3. 用参考向量验证算法，不靠人工观感

为允许公开测试的演示算法准备脱敏参考向量，覆盖正常值、边界值和异常语义。恢复实现只有在独立环境通过向量集，才能进入 L4。若仍调用原应用或依赖原运行时材料，结论保持 L3。

4. 把 DEX 与 SO 分开记账

DEX 恢复关注类、方法与控制流；SO 恢复关注 ELF 有效性、符号、导出和反汇编语义。两者最后在算法归属图汇合，但不能用“拿到 SO”替代“恢复 Java 上下文”，也不能用“拿到类”替代“恢复 native 核心”。

5. 将范围写进发布结论

结论应包含候选范围、工具类别、环境、业务路径和判定层级。推荐写法是“在已执行的标准与深度恢复、二次反编译和 ELF 复核中，材料恢复达到 L1-L3，未形成 L4 等价算法”；不推荐写“无法脱壳”“绝对安全”或“已完全破解”。

风险边界

本次专项证明的是当前候选、当前工具类别和当前测试环境中的阶段性结果。它不证明未来工具无法扩大恢复面，也不证明更高权限环境无法获得更多材料。相反，本轮明确观察到运行期 DEX 和有效 ELF 可以被恢复，因此防守方仍应继续收敛材料生命周期、映射后备载体、符号与诊断信息，并通过服务端证据降低单点客户端暴露的影响。

本文没有公开真实包名、签名、设备、进程、命令、日志、类、函数、符号、偏移、地址或恢复文件。公开的伪代码用于建立验收门槛，不包含可运行的提取、注入或绕过流程。

发布与运维清单

• 原始候选已在干净环境完成安装、三次冷启动和关键业务路径。
• 标准与深度恢复结果分别去重，不混用文件数量。
• 每个 DEX 候选经过格式解析与恢复后反编译。
• 每个 native 候选经过 ELF 结构、架构和加载信息复核。
• 连续内存镜像与映射后备载体分开记录。
• 类与控制流恢复程度和算法等价结果分开记账。
• 算法等价使用参考向量、状态和异常语义验证。
• 报告写明已执行范围，不使用绝对安全措辞。
• 敏感目标、工具链和恢复材料只保留在私有证据包。

常见误区

误区一：文件名是 .dex 就是有效 DEX

深度搜索可能把残片或伪阳性写成文件。没有标准解析与二次反编译，扩展名不具备证明力。

误区二：看到 ELF 头就等于 SO 脱壳完成

内存映射可能不连续，节与重定位信息也可能不在同一输出中。至少要验证程序头、加载信息和标准工具可解析性。

误区三：恢复很多类就等于核心算法回来了

类数量说明可见面扩大，不说明核心运算归属。入口、参数整理、桥接和业务算法应分别判断。

误区四：stripped 等于不能分析

剥离符号会提高定位成本，但机器代码仍可分析。正确结论是符号语义有限，而不是绝对不可逆向。

误区五：工具报错就是加固成功

工具版本、传输、格式兼容和权限都可能导致报错。应修正工具链并用独立视角复核，不能把工具故障记为产品能力。

误区六：未还原等于永远无法还原

本轮未达到 L4 只说明当前证据边界。专业报告必须保留候选、环境与工具范围，避免不可证实的全称结论。

FAQ

运行期能导出 DEX，是否说明御盾加固已经失效？

不能这样判断。导出 DEX 说明运行期存在可识别材料，需要继续治理暴露窗口；是否失效取决于材料有效性、恢复出的程序结构、核心算法是否等价，以及篡改后的应用能否形成业务闭环。本轮 DEX 恢复提高了类与部分控制流可见性，但没有得到核心算法等价实现。

取得可解析 ELF，是否等于 SO 算法被还原？

不等于。可解析 ELF 只达到格式有效。还要检查符号、导出、反汇编语义、状态依赖和输入输出。本轮 ELF 已剥离符号且导出面有限，没有重建原始 C/C++ 算法。

为什么不能只使用一种脱壳工具？

不同工具对内存搜索、映射边界、格式容错和去重的处理不同。单一工具既可能漏报，也可能把残片算作成功。标准恢复、深度恢复、独立解析和二次反编译应形成连续复核链。

算法等价最少需要什么证据？

至少需要可独立运行的恢复实现、经过批准的参考输入、关键状态前置、输出对比和异常语义对比。仍依赖原应用进程或原运行时材料的调用，不能算独立还原。

这篇文章是否证明全部七维防护都通过？

不是。本文只讨论 DEX/ELF 材料恢复与算法等价判定。二次打包、注入、内存修改、危险环境和兼容性均有各自证据门槛，不能由本专项代替。

企业做 App 加固 PoC 时应要求什么？

要求同一候选的运行基线、工具矩阵、恢复材料有效性、程序结构差异、算法等价结果和公开边界。采购结论应依据证据层级，而不是截图数量或绝对宣传语。

相关页面

• 御盾 App 加固产品页
• App 加固 PoC 验收指南
• Android/iOS App 加固选型页
• 三类篡改重签包跨环境闭合实测
• 御盾性能与兼容性中心

外部参考

• OWASP MASVS：移动应用安全验证标准
• OWASP MASTG：Android 逆向与篡改测试知识库
• Android Developers：应用完整性说明
• Android NDK：原生代码安全建议

西安守界御盾信息安全技术有限责任公司将御盾 Android 加固的公开结论限定在实际复核范围内：文件恢复、结构恢复和算法等价分别判定，避免用工具提示替代工程事实。