Menu
闭源依赖源码恢复——把闭源 jar / war / class / dll / so / 混淆包反编译成可读源码，归集到 `shared/decompiled/`。本能力不做漏洞判定。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
白盒建模——一次深度建模产出五张共享模型：项目架构（技术栈/分层/框架自有封装/闭源依赖位置）、 入口点（路由/中间件信任边界）、认证与权限（会话/角色/多租户/归属字段）、业务（实体/流程状态机/ 业务不变量/高价值资产）、全局威胁（攻击面×漏洞类别的适用性映射，供下游逐一全测）。本能力不做漏洞判定，为后续 漏洞维度分析建立共享底图。
OS 命令注入综合检测——覆盖直接命令拼接 / shell 元字符 / 参数注入 / 间接 RCE，按回显 / 时间 / 带外通道分诊。 流量中参数值含主机名 / URL / 文件名 / 命令片段、响应里出现 shell 错误关键字（`/bin/sh` / `cmd.exe` / `command not found`）、注入 `sleep N` 耗时增加、上传后异步处理链路时使用。
文件上传多策略综合检测——覆盖扩展名 / MIME / 魔术数 / 解析漏洞 / 上传链组合（LFI / Zip Slip / SVG XSS / SVG XXE）。 流量含 multipart/form-data 上传、响应回显落盘路径、上传后文件可被 GET 解析、上传字段含 filename / path 可控时使用。
IDOR 水平越权检测 — 通过替换资源标识符（ID/UUID/路径）访问他人资源的风险；适用于用户资料、订单、文档、租户隔离场景。
检测路径穿越和本地文件包含（LFI）风险；当目标存在文件读取/下载/预览功能且含路径参数时触发；适用于文件下载、日志查看、模板加载等场景。
黑盒建模 — 迭代式攻击面建模，按站点级 / 页面级 / 功能级三粒度推进；进入新页面即触发一次页面级建模、切换新身份各刷新一次，产出端点账本与页面语义模型，为后续漏洞维度的适用性判断提供依据。
| name | dependency-decompile |
| description | 闭源依赖源码恢复——把闭源 jar / war / class / dll / so / 混淆包反编译成可读源码，归集到 `shared/decompiled/`。本能力不做漏洞判定。 |
| when-to-use | 当代码审计需要分析一个无可读源码、落在关键路径（入口点/信任边界/污点必经路径）上、且不看内部无法定论的依赖（编译 jar/war/class、二进制库、混淆代码），它不是行为已知的常见公共库、又无法直接读到源码时——主闸门是是否在关键路径 + 决策点（安全/sink 决策在依赖内 (b) 还是在调用方 (a)），归属只调节处置：同厂商自有→反编译主战场；第三方异厂商商业→落 (a) 决策在调用方的标准化通道可免、落 (b) 决策在依赖内（含 OEM/低代码平台承载鉴权路由、自称标准协议的闭源鉴权 SDK）说不清则反编译并标法律。典型触发面：SCA 盘点出关键路径上的无源码依赖、入口点/中间件逻辑落在无源码依赖里、数据流污点进入无源码依赖 |
| allowed-tools | bash,read_file,list_files,rg |
| user-invocable | true |
| argument-hint | [artifact_path] [--lang java|python|js|dotnet|native] |
| arguments | ["artifact_path","lang"] |
本能力是 Cat-B-Cross 反编译工具能力——接 dependency-audit 标记的闭源 / 关键路径依赖，提供源码恢复能力供 dataflow-analysis / 入口点审计接力。本能力的产物是"可分析的源码 + 来源 / 不确定性标注"，不做漏洞判定——判定交回触发它的上游 skill。
按"上游触发面 + 制品类型 + 攻击面可见性"维度识别本能力命中场景。
.pyc / .pyo 已编译模块推论：对同厂商自有闭源，"用消费侧 import 证明它不在关键路径"是循环的——不打开就证不了。
~/.m2/~/.gradle 已有 -sources.jar、包目录里有未压缩源、随附 source map 或调试符号）——直接读源码，优先级高于反编译产物本能力 n/a（原因：反编译工具不针对单漏洞，无成因可写。本能力只是"解除无源码盲区"，漏洞成因由触发它的上游 skill 承担——SQLi 看对应 SQL 注入审计 skill / dataflow-analysis；鉴权绕过看 business-logic-auth-review；以此类推）。
本能力 n/a（原因：反编译只恢复源码，不做数据流追踪——跨函数 / 跨文件 / 跨依赖的 source-to-sink 追踪由 dataflow-analysis 接力。本能力的产物是"反编译后的可读源码"，作为 dataflow-analysis 的新 SSA IR 加载源）。
本能力 n/a（原因：反编译工具不针对漏洞分类。攻击变体属于具体漏洞的属性，由对应漏洞维度 skill 列出）。
本能力的"入口点"是"需反编译的制品"——按制品类型 + 关键路径维度判优先级。
下列制品类型 / 项目栈仅作类似示例 不限于此；以目标实际栈为准。
| 制品类型 | 典型位置 | 工具与产物 |
|---|---|---|
| Java jar / war / aar | WEB-INF/lib/*.jar、~/.m2/repository、私服坐标 | jadx / CFR / Procyon / Fernflower → .java 源 |
| Android APK / dex | APK 包外层 + 内嵌 classes*.dex | apktool 解资源 + JADX 反编译 dex → .java 源 |
| .NET DLL / EXE | 项目 bin/、IIS 部署目录、packages/ | ILSpy / dnSpy → C# 源 |
| Go 编译产物 | 单个可执行文件（含符号 vs 已 strip） | 含符号表：go-decompile 系工具 + Ghidra；已 strip：Ghidra + 手工签名识别 |
| Native so / dylib / dll | lib*.so / *.dylib / *.dll，应用打包目录或系统库 | Ghidra / IDA Pro / Binary Ninja → 反汇编 + 反编译伪代码 |
Python .pyc / .pyo | __pycache__/、site-packages | uncompyle6 / decompyle3（强依赖字节码版本） |
unzip -o app.war -d app_war，关注 WEB-INF/lib/*.jar（依赖）与 WEB-INF/classes/（自身字节码）；嵌套 fat-jar 同理逐层 unzipfile 看产物类型与是否 strip，strings / nm -D / objdump -d 做符号与反汇编速查本能力对每个制品按下列维度排优先级（详细 triage 见 references/triage-decision.md）：
unknown + 在关键路径 → 偏放行当候选本能力 n/a（原因：反编译针对二进制制品而非框架代码模式——反编译工具按字节码格式 / 制品类型选择，与"该制品是 Spring / Django / Gin 还是 Express"无关。反编译产物里的代码 pattern 由触发它的上游 skill 按对应漏洞维度的跨框架变体表去识别）。
加载本能力时按这些问题思考：
--deobf 还是要标 static-unknown## 产物契约 落 shared/decompiled/<package>-<version>/只对"关键路径 + 闭源 + 可达性不可静态判定"的依赖反编译。详细 triage 决策树（包括决策点 (a)/(b)、归属调节、捷径边界四闸门）见 references/triage-decision.md。
主要分支概述（顺序仅作建议，可按现场调整）：
~/.m2、~/.gradle、包目录、source map、调试符号rg import / 包名前缀 / pom.properties / MANIFEST.MF / javap -p 单类速看按制品类型选定工具，先探本机可用性（command -v <tool>）：
| 语言 / 制品 | 主要工具 | 备选 / 交叉验证 |
|---|---|---|
| Java jar / war / class | jadx（首选，可读性好） | CFR / Procyon / IntelliJ Fernflower（交叉对照时用） |
| Java 单类速查 | javap -p -c -constants Target.class（签名 / 字节码 / 常量池） | javap -v（常量池 + 注解，破 starter 盲区） |
| Android APK / dex | apktool（解资源）+ JADX（反编译 dex） | dex2jar + jadx 兜底 |
| .NET DLL / EXE | ilspycmd Target.dll -o out_src（ILSpy 命令行） | dnSpy（GUI 复核） |
| Go 含符号表 | go-decompile 系 + Ghidra 辅助 | Ghidra analyzeHeadless |
| Go 已 strip / Native so / dylib / dll | Ghidra headless（analyzeHeadless） | IDA Pro / Binary Ninja（深挖时） |
Python .pyc / .pyo | decompyle3 / uncompyle6（与字节码版本强相关） | 失败回退：在包目录找随包 .py 源 |
dependency:get -Dclassifier=sources → pip download 取 sdist → npm registry tarball），sources 失败再取 plain jar 反编译；详细取件路径与防误拉闸门见下「按坐标网络取件」--deobf）jadx --no-res --no-imports -j <核数> -d out app.jar（跳资源、多线程，大 jar 快数倍）；混淆 jadx --deobf 自动给 a.b.c 生成稳定名unzip x.jar 'com/foo/Target.class' 单取出来再喂反编译器；大 jar 几千类整包全是噪音sha256sum，与 SCA 阶段记录的 hash 比对；不一致 → 标"供应链可疑"## 产物契约 落 shared/decompiled/<package>-<version>/ 目录，与项目源码分离本地翻遍都没有 jar/源码、且该依赖须看内部时，按坐标去取——sources 优先（拿到官方 sources 即 0 反编译且可信）：
groupId:artifactId 是否命中本 reactor 某个兄弟 module？是 → 直接 read 源码，禁止拉 jar 反编译（why：源码比反编译产物可信、且免外联）。例外：现场产物（war/jar）可能打包旧版/不同 build 的该模块 → 以产物为准mvn help:effective-pom 解平展（裸读 pom 会拿到假版本，是最常见取错件的坑）；Gradle 用 build.gradle(.kts) / gradle.lockfile~/.m2/settings.xml / 项目 <repositories> / Gradle repositories{}；本能力不解析 URL、不回显 / 不记录凭证mvn dependency:get -Dartifact=g:a:v -Dclassifier=sources；私服没进 settings.xml 时显式补 -DremoteRepositories=id::default::https://<私服>/...（解 dependency:get 的仓库盲区——单跑时通常只认 settings.xml 的 repo/mirror）pip download 取 sdist（机制不同：不走 mvn，口径一致——先本地、本地无再按坐标取，源码优先）-sources.jar 与现场部署的 .class 未必同源同版本——对 (b) 类关键件，sources 来源 / 版本存疑时与实际 class（javap/字节码）抽样交叉核对；SNAPSHOT 件标快照时间## 产物契约 留 needs_review + 显式缺口并写明原因，不直接结束反编译后把产物路径告知 dataflow-analysis，作为新的 SSA IR 加载源——rg 在反编译输出目录里定位上游关心的类 / 方法 / 调用链（source、sink、鉴权、过滤、加解密等），按需 read_file 精读。
以下是已知的检查角度，作为基线起点而非必检硬清单。结合目标制品动态调整，按三态标注（
[x]/[-]/[+]）处置。
--deobf）shared/decompiled/<package>-<version>/ 目录，未与项目源码混入needs_review + 显式缺口，未直接判"无法分析"留空why：反编译产物是下游 dataflow-analysis / 上游审计 skill 的接口，结构 / 命名 / 来源标注缺失会让下游无法回溯源头、无法判断混淆不确定性、无法与项目真实源码区分。这是审计可追溯的硬底线，属交付契约不属检查建议。
目录结构：
shared/decompiled/<package_name>-<version>/ 目录<groupId>-<artifactId>-<version>；第三方件以 Maven 坐标为准src/）物理分离，避免与项目源码混淆manifest 落行：每次反编译 append 一行 metadata 到 shared/decompiled/manifest.jsonl：
{
"package": "com.example.foo-bar",
"version": "1.2.3",
"artifact_sha256": "...",
"decompiler": "jadx 1.4.7",
"decompiled_at": "<ISO8601 timestamp>",
"key_path_reason": "同厂商自有闭源，归属即触发；入口点封在 jar 内、消费侧不可观测"
}
字段约束：
package 与 version 必填，对应取件坐标或现场制品标识artifact_sha256 填原制品 hash（反编译前 sha256sum 取得），用于供应链一致性校验decompiler 填实际工具名 + 版本key_path_reason 写为什么这件值得反编译——具体到触发面、归属判定、决策点 (a)/(b) 结论；不写"看起来该反"之类模糊表达<私服/中央仓> 坐标 g:a:v 的 sources"或"反编译自 app.war!WEB-INF/lib/foo.jar，工具 = jadx"取证完整性：引用反编译代码做证据时遵循 common/closure-verification.md §取证完整性——不在此复述，按 §6.4 引用：
发现接回上游：
shared/coverage-ledger/findings/dependency-decompile.jsonl（避免双重记账）id 带 dec- 前缀全局唯一；status ∈ confirmed | needs_review | not_vulnerable | false_positive | superseded；source / file_location 标注反编译来源（含产物路径与工具）；混淆环境下 confidence 酌情降级本能力 n/a（原因：反编译不做漏洞判定，无 confirmed / suspected / not_vulnerable 三态。漏洞判定的闭环由触发它的上游 skill 承担——上游引用 common/closure-verification.md。本能力的"交付契约"是 ## 8 产物契约 段的目录结构 + manifest 落行 + 来源标注，不在此重复闭环判定语义）。
本能力 n/a（原因：反编译工具不针对单漏洞，FP / FN 由具体漏洞维度 skill 列出。本能力的"失败模式"在 §11 静态分析边界统一表达——混淆 / 加壳 / native AOT / 取件失败等情形必须标 static-unknown 或 decompile-incomplete，不能默认为安全）。
反编译的能力上限是还原可分析的源码，不是"看清所有代码"。下面这些情形反编译质量受限，必须明确标注，不允许默认为"该制品无问题"或 not_vulnerable。
代码混淆（Proguard / R8 / ConfuserEx 等）
a.a.a、方法名 o0Oo、字符串常量加密 / 缺失static-unknown + 标注混淆等级；开 --deobf 自动给稳定名但语义仍不可信；改按结构、字符串常量、调用关系、常量池识别语义，不要拿混淆名当语义证据激进优化级别
-O3 编译后内联 / 循环展开 / 死代码删除，反编译伪代码与源码结构差距大decompile-incomplete + 标注优化级别；反编译产物只能作"辅助参考"，不作单独定论依据加密 / 加壳
needs_review 而非"无法分析留空"native 代码（C / Rust 编译后无符号）
.so / .dylib / .dll 编译产物，无调试符号、无 RTTIstrings / nm -D / objdump -d）取件失败 / 反编译器不可用
javap -p、MANIFEST.MF、strings），显式声明 decompile_available: false + 已尝试手段 + 仍缺失部分；不留空、不伪造、不直接结束跨制品边界（递归触发面）
不假装看到看不到的代码。本能力的可观测能力到反编译产物的可读源码为止——混淆名不是语义、伪代码不是真源、取件失败不等于安全。
needs_review，写明"已覆盖 X、未覆盖 Y、缺失原因"，把未覆盖目标当作缺口交回上游本能力 n/a（原因：反编译工具不针对漏洞，无修复路径可写。各漏洞修复路径由对应单漏洞维度 skill 给出——例如 SQLi 修复参对应 SQL 注入审计 skill / pentest 链路上的 §12；鉴权绕过参 business-logic-auth-review §12；以此类推）。