前段时间用 jadx-ai-mcp 分析 APK，跑了几个小时，体验确实不错。Claude 能自己调 tool 读反编译代码、看导出组件、跟调用链，省了不少手动翻代码的功夫。
有一天晚上我想把 APK 丢到服务器上跑，本地 Claude 连过去用——本地风扇太吵了。结果发现不行。jadx-ai-mcp 的 Python MCP server 要通过 HTTP 连 JADX 插件的 API，而那个 API 只有在 JADX GUI 启动后才存在。
我当时觉得这很正常——JADX 本来就是个桌面工具。但后来仔细想了想：JADX 的反编译引擎 JadxDecompiler 是一个纯 Java 类，new 出来就能用。它根本不依赖 GUI。那为什么 MCP server 非得挂在 GUI 上？
这个念头改变了一切。如果 MCP server 能跟反编译引擎在同一个进程里跑，不经过 GUI，那整个工具链的形态就完全不同了。这就是 DECX 的起点。
jadx-ai-mcp 的架构是三层串联，这存在一个核心问题：MCP 协议层和反编译能力被 GUI 进程边界隔开了，MCP 离不开 GUI。
DECX 的做法是把所有能力放进一个独立的 decx-core 模块里。这个模块不依赖任何 UI 组件，只需要一个 JadxDecompiler 对象就能提供完整的反编译能力。所有代码——API 接口、Service 实现、MCP Tool 定义——全在core中实现
decx-core 是一切的根基。它提供了一套与传输层无关的 API/Services/MCP 实现，不管你是通过 JADX 插件、独立jar、还是 TypeScript CLI 来用，底下的逻辑完全相同。
这层关系用 Kotlin 代码表达就是 Decx 的全局对象：
同一个 Decx.mcpServer(api, port)，在 JADX 插件里调用和在 standalone jar 里调用，返回的是同一个类、同一套 29 个工具、同一种 MCP 协议实现。
DecxRoutes 定义 HTTP 路由，McpToolRegistry 定义 MCP tool。两者通过 routePath 一一对应：
由于核心架构和上层分离，我们能够直接使用 Decx 的独立 Jar，也可以使用 Jadx Plugin 的方式，为了方便使用，我也提供了几种方案。
decx-server 打成 fat jar 后，不需要 JADX GUI，不过建议还是使用 Cli / Plugin ，会更方便。
这是最简单的使用方法了，打开 Jadx ，在插件列表里找到 Decx，安装即可。
decx-cli 是 TypeScript 写的，管理 standalone server 的生命周期。通过 --help 命令能够看到怎么使用，当然，也可以直接安装对应的 decx-cli skill 来使用。
这里稍微讲一下decx ard framework run ，这是是 DECX 独有的能力——从连接的 Android 设备自动采集整个框架相关的代码并打包整合分析：
整个过程包括四步流水线：
这样，针对厂商魔改的框架代码，就能够去进行整合性分析，而这套流程的前提就是 decx-core 能脱离 GUI 独立运行。没有这个前提，CLI 没法自动启动 server；没有 server，framework jar 只能手动丢进 JADX GUI。
既然已经做到这里了，那不如更近一步，做一些用来处理真实漏洞挖掘和分析的 skill 吧！
这里必须要感谢 fe4K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6G2M7X3W2@1k6i4u0S2i4K6u0r3b7$3q4A6M7X3^5`. 给了我启发——能不能将漏洞挖掘的过程做成一整套skill，但是不局限于漏洞知识，而是发挥模型本身的能力。
这可能是五个 skill 里最核心的一个。它做的不是"用 AI 搜一下有没有漏洞"这种笼统的事，而是一套严格的 subagent 委托 + 证据图 流程。
主 agent 不碰代码。它的工作只有五件事：初始化项目、启动 DECX session、把具体的分析意图委托给 subagent、读取 subagent 的 JSON 摘要、按风险矩阵决定是否升级为正式漏洞。主 agent 跑 decx code 或读源码是违规的——所有分析都在 subagent 里完成。
subagent 收到一个 intent goal（比如"收集攻击面：导出组件、deep link、AIDL、动态 receiver" 或 "跟踪某个 entrypoint 到 sink，证明 5-tuple"），自己创建 intent、跑 decx code 查询、写 fact 和 edge 到证据图、solve 后返回结构化 JSON 摘要。subagent 不能"推理"出漏洞——必须通过 decx code 读到源码，用源码行作为 evidence。validate*、check* 这类方法名不算证据（可能只是命名习惯，不代表真的有校验逻辑）。
证据门要求 5 种事实全部存在且由 proves 边连接才能升级为正式漏洞：
复合漏洞链由五种边组合：enable（A 创建 B 需要的入口）、carry（A 传输数据给 B）、amplify（A 放大 B 的影响）、bypass（A 打穿 B 的保护）、observe（A 让 B 的影响可见）。
漏洞模式覆盖 30+ 种应用层场景：Intent 重定向、Bundle/key 失配、WebView JS bridge、Provider 数据泄露/SQL 注入/路径穿越、broadcast 劫持、PendingIntent 滥用、fragment 注入、task hijack、动态 dex 加载、跨 app 数据通道等。
[内核课程]《Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。
