Kimi K3 模型刚出，听说效果非常的不错，给了老美一点小小的震撼。我也是第一时间入手严肃学习了一下，效果也是非常超出我的预期。几天加班加点的工作后，把这个脱壳系统赶了出来。震撼之感不亚于人生第一次吃麦当劳的薯条，我感觉以后不论是逆向还是工具链开发貌似都没人类什么事了（指工程落地方面）。脱完几个样本后，也是第一时间来分享一下成果。

进入正体，本文讨论的问题很具体：一个已经被公开 7 年的经典思路脱壳，如何借助 AI 的能力，再配合任务拆分与 Loop，把它更快地搬到新系统上，并把中间的代码、输出和修复流程适配甚至优化，整理成一套新的工具链。

这个经典项目就是 FART。FART 是逆向圈非常有名，非常具有代表性的脱壳定制系统项目，但该项目的上一个开源版本还停留在 Android 6/8 时代。

FART 的重点不是简单 dump dex，而是主动触达 Runtime 里的 ArtMethod，使用强制假调用的方式，强迫使二代壳中抽取出来的方法恢复（如偏移修正、方法恢复等），然后在把抽取壳运行时恢复出来的 CodeItem 记录下来。r0dump 做的事情，就是把这条主线迁到 LineageOS 23.2 / Android 16 上，再补上配置、输出、状态、repair 和 Manager。

本次工作的定位很明确：用 AI 作为长程工程协作者，再用 Loop 持续验证和修复 FART 迁移。人工判断路线和边界，工具辅助处理那些费时间、但可以验证的工作，比如读源码、对版本差异、草拟改动、整理日志和文档、patch、编译、remount 替换和测试。

本文只讨论授权设备、授权应用和安全研究场景下的 Android Runtime 脱壳技术。文中工具不针对任何具体厂商或具体业务，不提供样本，不讨论绕过线上风控的操作细节，也不保证覆盖完全 native 化、VMP 化或强对抗样本，本项目亦没有刻意的特征隐藏。

另外请仅在你有权分析的设备、应用和数据上使用相关代码。

另外最重要的一点：刷机前先确认机器的 anti-rollback / bootloader 状态。

当前 patch 的设备集成目标是一加 9（lemonade）。刷机前仍应单独确认 bootloader 与 anti-rollback 状态；本文不把其他机型的降级行为写成通用结论。

不同厂商、不同机型、不同 bootloader 版本的反回滚策略不一样。有些机器一旦升级到带 anti-rollback 的版本，再回刷低版本系统就可能直接变砖。不要拿自己的主力机盲刷，也不要默认“能解锁 bootloader 就一定能回退”。

尤其是最近 Google 推送的 Android 16，几乎所有 piexl 设备升级 Android 16 后无法按照常规手段降级，随意降级极易变砖。

刷机需谨慎！！！
刷机需谨慎！！！
刷机需谨慎！！！

本次 patch bundle 围绕 FART 主线完成了一次面向 LineageOS 23.2 / Android 16 的源码级迁移。除了 ART 侧改动，还补了 framework 触发、Manager 控制台、输出目录、状态文件、repair 和系统集成。也就是 FART 思想在新版本系统上的复刻 + 增强。

当前 patch 归档（见 Github） r0dump_lineage23_original_patches_20260721_225851.zip 从功能上看，这次改动可以分成几块：

能力状态如下：

完整刷机、样本 dump、repair 后静态工具打开这些结果，仍应以对应设备上的测试日志、status 和 manifest 为准。

把 FART 思路迁到 Android 16，麻烦的地方不只是代码量。更烦的是来回切上下文：

这种活很适合交给 AI 做总的上下文理解，再按源码分析、迁移实现、编译验证和结果整理几个阶段推进。我本地提前准备了两类代码：

对 r0dump 这种要同时理解 FART 旧源码、Android 16 多仓库 patch、编译日志和测试截图的任务来说，Kimi K3 超长上下文的价值非常直接：可以少一点来回搬运，多一点连续推理。

实际工作按源码分析、迁移实现、编译验证和结果整理几个阶段推进。AI 主要用于串联这些阶段中的上下文，具体结果仍以代码、日志、设备状态和产物为准。

另外还有一个小技巧：多让 AI 提建议，多做“明知故问”，用问答把上下文垫厚。长上下文不是把所有东西一股脑塞进去，而是让模型能够保留决策、约束、失败记录和验证证据。输入越具体，后续的代码修改和结果核对就越容易展开。

接下来先我们先看技术本体。毕竟最终验收的还是人。如果你对 FART 什么都不懂，就只能一路无助地点击“接受，继续下一步”（无助的丈夫.jpg）。FART 的核心思路如果理解错了，模型只会更快地把错误放大。

从这个角度看，AI 带来的变化不是让专业知识失去价值，而是让专业知识的杠杆变大。没必要焦虑“万一我还没学会，AI 就已经超过我了”：模型可以把源码读得很快、把方案写得很漂亮，但路线选择、风险判断和最终验收仍然需要真正懂系统的人来负责。

FART 在 Android 逆向圈不用多介绍，是很经典的 ART 主动调用式脱壳方案。它的价值不只是 dump dex，而是通过主动触达 Runtime 中已经物化出来的 ArtMethod，把抽取壳运行时恢复出来的 CodeItem 记录下来，为后续方法体还原提供依据。

FART 6.0 的改动主要分布在四个地方：

它的主线其实很清楚：Java 层尽量把目标 App 的类和方法枚举出来；ART native 层把反射对象转成 ArtMethod*，再从 ArtMethod 定位 dex 和 CodeItem。

FART 在 ActivityThread.performLaunchActivity() 末尾调用 fartthread()。fartthread() 新起一个线程，默认 sleep(1 * 60 * 1000)，等待 App 先跑起来，然后执行 fart()。

fart() 的核心流程可以概括为：

几个关键点：

所以 FART 里“主动调用”的重点，不是直接执行业务逻辑，而是主动把 Runtime 中能触达的类、构造函数和方法都触达一遍，再把这些反射对象送进 ART。

FART 在 DexFile.java 里新增了一个私有 native 方法：

对应 native 注册在 dalvik_system_DexFile.cc：

native 实现非常短：如果传进来的 method 不为空，就通过：

也就是说，Java 反射层的 Method / Constructor 到这里被转换成了 ART 内部的 ArtMethod*。FART 真正的脱壳点并不在 Java 反射本身，而在后面如何利用这个 ArtMethod*。

FART 在 art_method.cc 里加了两个关键函数：

以及在 ArtMethod::Invoke() 开头增加判断：

这个设计比较巧妙：myfartInvoke() 并不是为了真的执行业务方法，而是故意传入 self == nullptr，让 ArtMethod::Invoke() 走到 FART 新增的 dump 分支。这样，FART 可以复用 Invoke() 这个入口携带当前 ArtMethod，但又避免真正调用目标业务逻辑。

dumpArtMethod() 做的事情包括：

因此，FART 的输出分成两类：

前者是 dump 出来的 dex，后者是方法级 CodeItem 记录。fart.py 会解析 bin 中的 {name, method_idx, offset, code_item_len, ins}，按 method_idx 建表，并把 base64 解码后的方法体和 dex 中原始 code_off 对应的方法体做对照。这个脚本体现的是“用方法级记录还原方法体”的思路；这份源码里的 fart.py 更偏解析和对照，真正产出可用 repaired dex 还需要结合具体修复逻辑处理。

更详细的心路历程和技术介绍可以移步参考寒冰老师的几篇文章：

所以从源码看，FART 真正值得迁移的不是“找个地方 dump 一份 dex”，而是这条链路：

这条链路解决的是抽取壳场景下“dex 结构在，但方法体不完整”的问题。它希望在 Runtime 已经恢复或物化方法体之后，把 CodeItem 以方法粒度记录下来。

Android 16 迁移不只是“把 dumpMethodCode() 搬过去”这么简单。FART 原版实现里很多东西都比较粗：启动时机固定、所有进程都容易被扫、输出路径写死、dex 文件名只按 size 区分、bin 分散在 tid 文件里、缺少 status 和统计，也没有现代 Android 存储模型下的可靠输出策略。r0dump 要做的，就是保留这条主线，同时把工程边界收住。

r0dump 没有把 FART 原封不动搬到 Android 16，也不是简单堆 dump point (当然堆 dump point 也很重要)。它保留的是 FART 最关键的 Method/Constructor -> ArtMethod -> CodeItem 主线，但把原来比较粗放的触发、输出和后处理方式，改造成一个受控的 Runtime dump 工具链。

FART 原始路径比较直接：在 ActivityThread.performLaunchActivity() 附近启动线程，延迟后获取当前 App 的 ClassLoader，遍历 dex 中的 class name，反射出构造函数和普通方法，再调用 DexFile.dumpMethodCode()。

r0dump 保留这条主线，但在 ActivityThread 侧加了一层运行时控制，并同时支持 APP_CREATE 和 ACTIVITY_CREATE 两个 App 启动触发点。内置系统应用 Manager 负责写入 Settings.Global，framework 负责读取这些 key 后决定当前进程是否应该启动 dump。r0dump.dump.* 命名空间保留下来，用于兼容已有 Manager/runtime 配置；新增用户界面方便调试。

关键配置包括：

这样改把脱壳行为从一上来全量触发，收成一次针对目标包、目标进程、目标类前缀和目标策略的受控实验。对 Android 16 上的真实样本来说，这一点比盲目增加 hook 点更重要，因为主动 load class、主动反射和主动触达 Runtime 都可能带来崩溃、卡顿或业务副作用。

经常做工程的朋友应该都知道，反复调试很费时间。有了 AI 辅助，把这些配置、日志和失败路径收进一个用户页面，可以明显提高调试效率；模型负责把反馈串起来，人负责决定下一轮到底改什么。

ART 侧还是围绕 FART 最关键的思路来做：Java 反射对象进入 native 后，通过带 executable、cookie 和 class name 的 dumpMethodCode() 重载，把 cookie 里的候选 DexFile 交给 native 选择，再通过 ArtMethod::FromReflectedMethod() 拿到 ArtMethod*，最后从 ArtMethod 找到所属 dex、method_idx、CodeItem offset 和长度，把 dex 与方法体记录输出出来。

不同的是，r0dump 不再依赖 FART 原版 myfartInvoke(self == nullptr) 这个技巧作为唯一分发路径，而是把 dumpMethodCode() 直接接到统一的 dump 策略、状态和输出逻辑中处理。

在这个基础上，r0dump 主要补了几类工程能力：

重复 dex 抑制用于控制 I/O 和产物噪音。多策略或多时机可能反复看到同一个 dex，如果不做去重，产物目录会很快膨胀，后续 repair 也难判断哪份 dex 才是同一来源的代表文件。文件名里的 hash / checksum / strategy 用来降低误判风险。

Android 6 时代 FART 直接写 /sdcard/fart/<process>/ 这类外部存储路径。到了 Android 16，直接写外部存储顶层路径并不稳定，尤其是在 App 进程、scoped storage 和系统权限边界下更容易失败。

r0dump 的处理方式是：

对脱壳工具来说，dump 本身只是第一步；如果输出路径不可预测，后续 repair、复测和样本对比都会变成手工考古，没有心算 md5 能力的朋友估计胜任不了这项工作。

这次 Manager/framework 配置路径的默认策略是：

这里的 baseline 已经不是旧文章里的两个策略位：APP_CREATE 覆盖更早的 App 创建时机，ACTIVITY_CREATE 保留 FART 风格的 Activity 触发，IN_MEMORY_DEX 和 DEFINE_CLASS 则覆盖内存 dex 与类定义路径。更广的 FORCE_BACKFILL、oat/vdex、JIT、反射和 instrumentation 入口仍然需要显式配置，避免把实验性行为混入默认结果。

ART 侧这次保留的核心策略位包括：

当前 ART patch 的策略位已经扩展到 32 个入口，另外还包括 OPEN_COMMON、oat/vdex、verify、class init、interpreter、JIT、reflection、instrumentation、Java ClassLoader / Java DexFile route、oat register 和 image-space dex 等观察点。它们是可独立统计的实验入口，不等于每个入口都在本次设备运行中完成了覆盖验证。

这些策略不是“越多越强”，盲目开启过多脱壳点反而还会大幅降低效率。默认路径用于建立可复现 baseline；实验策略用于回答更细的问题，例如动态 dex 是否在注册时出现、某些方法是否在 resolve / load 阶段才具备有效 CodeItem、force backfill 前后 hash 是否变化。

Manager UI 里还暴露了这些实验策略位，便于按问题逐项打开；文章应把“代码中存在 hook / 策略位”和“设备上已验证有效”分开描述。

Manager 承担了以下几个功能：

Manager 是 r0dump 的一部分，不只是附带 UI。没有 Manager，r0dump 仍然可以通过 adb 配置；有了 Manager，测试流程更接近一个可交付工具链。

r0dump 落盘的东西并非终点。真正有分析价值的，是 repair 之后的 dex 文件。这次 patch bundle 中的 Manager 内置 repair flow：

修复逻辑会读取 methods_<pid>.jsonl，按 dex key / hash / checksum 找到对应 dex，把 code_item_b64 解码后回填到 code_item_offset。完成后生成 repaired dex，并输出一个 manifest，说明总输入、成功修复、跳过记录、重复 md5 和最终 zip 等信息。对启用 raw mirror 的产物，Manager 还会读取 methods_raw_<pid>.jsonl 和 header snapshot，重建或规范化 dexdata_*.bin。最后，所有修复并去重后的 dex 文件会压缩到一个 zip 中，方便直接拖入 jadx 等工具分析。

这次 patch 相比旧版 FART 主线，真正新增的工程能力主要集中在四个方向：

这些增强让 r0dump 从“把 FART 的主动 class walk 搬过来”变成了“有多个可观测入口的运行时导出管线”。其中 raw mirror 默认关闭，应该根据样本和验证目标按需启用。

下面是当前项目的三组测试对比，三个软件均使用 DexProtector 保护，分别是 com.vietinbank.ipay、com.vnpay.bidv 和 com.VCB。下文中的“未脱壳”指原始受保护 APK 对照，“r0dump repair 后”指 Manager repair flow 处理后产生的 dexfixed_*.dex 产物。

本节的核心验收标准是运行时是否成功 dump 出有效 dex、方法记录和 repair 产物；JADX 截图只是用来展示产物已经能够被加载和继续分析。完整覆盖率仍应结合 methods_<pid>.jsonl、status、manifest 和实际运行结果判断。

图中打开的是原始 APK 的 AndroidManifest.xml 和受保护应用结构，可以看到 ProtectedIPAYApplication、ProtectedAppComponentFactory 以及大量组件声明。这张图作为未脱壳基线，记录样本进入 r0dump 处理前的静态可见形态。可以看到右侧展示的 Activity 均不在左侧的类列表中，这些类目前还被以加密的形式存储在二进制文件中。

图中代码区显示从 dexfixed_..._CLASS_WALK_... 产物加载出的 BookingHistoryActivity，已经可以看到原始包名、import、Kotlin metadata、字段和方法体。这个结果与文章前面描述的 DEFINE_CLASS / fixed dex 输出和 Manager repair flow 对应。

这是 com.vnpay.bidv 的独立测试样本。原始 APK 对照图中可以看到 ProtectedMainApplication、native 方法以及签名校验和字节处理逻辑；repair 后截图则显示 com.vnpay.bidv_r0dump_repaired 已经加载到 JADX，并展开到 ConfirmSmartCounterActivity 等业务包类。

repair 后截图中的 JADX 信息显示产物来自 dexfixed_..._CLASS_WALK_...，代码区能够看到 com.vnpay.bidv.presentation.confirm.smart_counter 包、AndroidX/业务层 import、Kotlin metadata 和 ConfirmSmartCounterActivity。

原始对照图对应 com.VCB 的原始 APK，可以看到 ProtectedMainApplication、ProtectedAppComponentFactory 以及原始 APK 的类结构。repair 后截图对应 com.VCB_r0dump_repaired，已经展开到 com.VCB.ui.activities.accountlink 包下的 RegisterAccountLinkActivity，并显示了业务层相关 import。

一句话概括：

FART 的贡献是把脱壳推进到 Runtime 方法级 CodeItem；r0dump 这次的贡献，是在 Android 16 上保留这条核心路径，并把它改造成可配置、可观测、可修复、可打包的工程化工具链。

经常写逆向工具的朋友一眼就能看出 AI 在本案例中的价值：它把“理解一个跨多个 Android 仓库的迁移任务”从一次性的问答，推进成了可以持续跟踪、持续验证的工程过程。

如果只看最后的代码改动，很容易低估中间过程的成本。真正耗时间的不是“写几行 hook”，而是不断确认：旧项目的核心到底是什么，新系统里哪个入口还能用，哪些策略会带来副作用，哪些输出能作为证据，哪些结果不能写过头。(逆向工具开发中的各种坑，谁踩谁知道)

这次迁移里，AI 真正减少的是几类很耗人的体力活：

人工主要负责：验收、以及指出 AI 干活期间犯的一些愚蠢错误。

AI 在这类迁移里的定位很简单：

它更适合辅助整理已经想清楚的技术路线，把工作拆成可以逐项推进、最后还能对账的工程任务，而不是凭空发明技术路线。

在这次迁移里，人负责决策层；AI 负责保持长链路上下文，辅助完成源码阅读、版本差异整理、改动草拟、实现和验证材料整理。模型没有替我做逆向判断，但它确实降低了把判断变成工具链的成本。

AI 再强，也不是输入一句话就能自动交付完整工程。真正让结果落地的是后面的 Loop：编译失败就看日志，运行异常就看 status 和 trace，dump 结果不对就回到策略和输出链路继续修。模型负责加速每一轮，人负责确认每一轮到底有没有接近可用。

而在这个环节，人的作用是不可或缺的。毕竟人是这个项目的最直接消费者。工程好不好，怎么调整，还得是人来起作用。AI 能把排查速度拉起来，但如何评判 dump 是否成功、哪些策略应该收住、哪些结果可以写进文章，仍然由使用者的专业素养决定。

FART 的价值在于提出了主动调用式 ART 脱壳思路：通过触达 Runtime 中的 ArtMethod，记录抽取壳运行时恢复出来的真实 CodeItem，把脱壳粒度从 dex 文件推进到方法体。

r0dump 做的事情，是把这条思路迁移到 LineageOS 23.2 / Android 16，并补齐现代 Android 环境下必须面对的工程问题：配置、作用域、存储、状态、日志、修复、Manager 和产品打包。

AI 在这里放大了逆向分析和系统开发能力。对个人研究者来说，这才是最值得重视的变化：经典技术路线仍然要人理解，风险边界仍然要人判断，但迁移、整理和验证这些耗时间的环节，可以拆成更小、更快、更容易复查的任务交给模型，再由人把关。

我直接用，最直白，最直接，最不绕弯子的话告诉各位我的感受：AI 没办法替你产生安全研究里的核心判断，但它可以帮你更快地把判断变成代码、产物和文档，拓展一个人的工程边界，甚至给你一些思路上的启发。

另外我还想探讨一些 AI 发展相关的问题：

很多朋友对 AI 这样的模型感到焦虑，实际大可不必。它越擅长长程工程，越需要有人能提出正确问题、识别错误结果，并为最终系统负责。

我们研究专业问题的大可不必因为 AI 而焦虑，因为我们做的是专业性问题，即便 AI 完全有能力替代我们的技术，但到了具体场景，还是要有人来拍板担责。

注：本项目代码和文章都在 AI 等 AI 工具辅助下完成，并经过作者精心审阅和调整，感谢 r0ysue 老师的指导和 hanbing 老师的开源 fart 项目。

请仅在授权设备、授权应用和合法安全研究场景中使用相关技术。本次 patch bundle 的设备集成目标是一加 9（lemonade）；其他机型刷机和降级行为请单独核验 anti-rollback / bootloader 状态。

[内核课程]《Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。