reverse-skills-max: initial public release (restored, redacted, hardened)

2026-10-20 02:17:15 +03:00
commit da24c2bd20
2227 changed files with 443931 additions and 0 deletions
--- a/vendor-new/rev-skills/.claude/skills/re-analyze/references/analysis-contract.md
+++ b/vendor-new/rev-skills/.claude/skills/re-analyze/references/analysis-contract.md
@@ -0,0 +1,129 @@
+# 分析契约
+
+分析全流程的三条契约：分析前（上下文清单 + 调查预算）、分析中（数据传递字段）、分析后（复核格式）。所有网关与原子技能执行分析时遵循本契约。
+中途再路由：证据触发按 [[rerouting]] 双轨执行（轨 1 网关完成必查 / 轨 2 证据出现即查），命中即调对应技能。
+
+## 一、分析上下文清单（分析前）
+
+分析一个目标前，先收集以下上下文再动手。**通用四项按目标域展开**（域字段见第三节 3.2），不套用文件域字段：
+
+- 目标标识：标识符（路径 / 端点 / 设备 / 包名 / 模型文件）、哈希（sha256）、大小
+- 结构信息（**按域取**）：文件域 = 架构/格式/节表/导入导出；协议域 = 端点/端口/帧样例；车载域 = 仲裁 ID/周期/DLC；射频域 = 中心频率/采样率/调制；模型域 = 格式/张量清单；TEE 域 = TA/会话/SMC 号；取证域 = 来源设备/时间线
+- 关联信息（**按域取**）：文件域 = xrefs/caller/callee/引用字符串；协议域 = 请求-响应配对；模型域 = 层间依赖与算子序列；取证域 = 跨数据源的同一记录
+- 已知线索：已命名/已恢复的结构（符号表、struct/字段语义、协议字段名）、本会话已得出的结论（跨环节传递）
+
+收集不到的项目记「未知」，不阻塞开工——但禁止跳过收集直接分析。
+
+## 二、调查预算（分析中）
+
+- **软预算，不是硬上限**：主动申请额外证据（xrefs/反编译/内存读取等工具调用）**8 次为一档**——**到档必须重新评估**（当前假设是否还成立、下一步的证据增益是否还值得），**而不是禁止继续**。复杂目标（大型固件 / 内核 / 协议 / 混淆程序）评估通过后进入下一档
+- **到档评估三选一**：继续（写明新的证据假设）/ 换路（按 pivot 链）/ 收束（交付部分结论 + 置信度）。评估结论记录在案，便于复核
+- 同参数重复 ≥2 次无新证据 → 换思路；单命令 ≥3 次无进展 → 停下评估
+- 证据预载优先：上下文清单一次给足，减少来回调用
+
+## 三、数据契约（分析中，环节间传递）
+
+链式编排（入口 → 域环节 → 后续环节）的传递字段，**分两层：核心字段（所有域必带）+ 域扩展字段（按目标域选用）**。此前本表只有文件域一套字段，对其他域（协议/射频/车载/模型/TEE/取证）不适用——按域取字段，不硬套。
+
+### 3.1 核心字段（所有域）
+
+| 字段 | 含义 | 产出环节 |
+|---|---|---|
+| target_id | 目标标识（路径 / 端点 / 设备 / 包名 / 模型文件） | 入口 / [[re-triage]] |
+| sha256 | 目标哈希（证据存档键；非文件目标用等价指纹——pcap 哈希、固件镜像哈希、模型文件哈希） | 入口 / [[re-triage]] |
+| evidence | 证据链（路径 + 哈希 + 命令输出位置） | 各环节 |
+| findings | 结论列表（每条带等级 confirmed / supported / hypothesis 与置信度，见第四节） | 各环节 |
+| unverified | 本环节无法确认的部分（对应复核格式的「未验证项」） | 各环节 |
+
+### 3.2 域扩展字段（按目标域选，代表技能仅示例）
+
+| 域 | 扩展字段 | 代表产出技能 |
+|---|---|---|
+| 文件 / 二进制（PE/ELF/Mach-O/固件） | arch、format、entropy、sections、imports_exports、strings_refs、base_addr、symbols_known | [[re-triage]]、[[re-format-pe]] / [[re-format-elf]] / [[re-format-macho]]、[[re-imports]]、[[re-ghidra]] |
+| 网络 / 协议 | endpoints（五元组与会话）、frames（帧样例与字段偏移）、state_machine（状态转移）、crypto_layer（加密层与密钥来源） | [[re-netcap]]、[[re-proto-rev]]、[[re-tls]] |
+| 总线 / 车载（CAN 等） | arbitration_ids（ID/周期/DLC）、signals（字节序与位布局）、diagnostic_sessions（UDS 服务序列）、seed_key（算法与密钥来源） | [[re-automotive]]、[[re-ics]] |
+| 射频 / SDR | center_freq、sample_rate、modulation、sync_words（帧同步字）、demod_chain | [[re-sdr]] |
+| AI 模型（文件级） | model_format、tensors（名/形状/dtype）、graph_ops（算子序列）、watermark_evidence（权重/metadata 异常） | [[re-ai-model]] |
+| AI 模型（行为级 / 仅 API） | api_endpoints、query_budget、behavior_fingerprint（响应一致性）、extraction_evidence | [[re-ai-attack]] |
+| 移动 / 托管代码 | package、components（Activity/Service）、sandbox_paths、jni_map（native 方法 ↔ 地址）、bytecode_units | [[re-apk]]、[[re-android-native]]、[[re-dotnet]]、[[re-java]] |
+| TEE / 可信执行 | ta_uuid、smc_ids、secure_storage_items、key_derivation | [[re-tee]]、[[re-hardware-io]] |
+| 取证 / 情报 | device_source、timeline（时间/动作/来源）、integrity（哈希链与分区摘要）、iocs | [[re-mem-forensics]]、[[re-disk-forensics]]、[[re-mobile-forensics]]、[[re-ioc]] |
+| 沙箱 / 行为 | process_tree、persistence、network_behavior、attck_mapping | [[re-sandbox]]、[[re-behavior]] |
+
+### 3.3 传递规则
+
+- **核心字段必带**（收集不到记「未知」，不阻塞）；**域扩展字段按目标域选填**——不要求跨域填充（CAN 目标不需要 sections，模型目标不需要 base_addr）
+- 每个环节**只增不改**：后续环节追加字段与原字段并存；冲突以新证据为准并记录更正
+- 输出形态：JSON 或结构化表格；下一环节直接消费，不重新扫描
+
+## 四、复核格式（分析后）
+
+结论交付前做**独立复核**：换视角重读结论与证据（换模型/换工具/间隔后重读均可），逐条核对：
+
+1. 每条结论有对应证据（文件路径 + sha256），无证据的结论等级为 hypothesis
+2. 结论与证据矛盾 → 以证据为准，修正结论
+3. 标注**证据等级**（RE 中推断常见，等级必须标注）：
+   - `confirmed`：直接证据可复现（字节级比对 / 调用链 / 官方文档）
+   - `supported`：多源间接证据一致（字符串 + 行为 + 时序互相印证）
+   - `hypothesis`：推断 / 单源弱证据（无证据的结论即此级）
+   高 / 中 / 低置信度保留为辅助维度（与等级并存）
+
+复核输出格式：
+
+```
+结论：<一句话>
+证据：<路径 + sha256 / 命令输出位置>
+等级：confirmed / supported / hypothesis
+置信度：高 / 中 / 低
+未验证项：<复核时无法确认的部分，留空表示无>
+```
+
+示例：
+
+```
+结论：样本连接固定 C2
+证据：字符串（c2.example.com，xref 至 connect 调用）+ socket 调用链
+等级：supported
+置信度：中
+未验证项：C2 是否仍在线
+```
+
+### 通用方法论索引（全库适用，按需引导激活）
+
+以下方法论内容在各域技能中沉淀，全库通用——任何技能遇到对应场景时引导到出处激活：
+
+| 方法论 | 位置 | 适用场景 |
+|---|---|---|
+| 分析方法论（入口/调用/内存/API/混淆/动态调试/深层/情报与初勘/反汇编方法/验证/知识获取，11 组） | [[re-binary-core]]「分析方法论」 | 一切二进制分析的通用手法（静态为主） |
+| 反调试方法论（基础检测/异常机制/时间检测/环境特征/硬件痕迹/线程与调试对象/自修改断点/深层检测/方法论，9 组） | [[re-anti-analysis]]「反调试方法论」 | 任何动态分析遭遇反调试时（gdb/x64dbg/mobile/沙箱） |
+| 反虚拟化方法论（指令级/时间硬件/环境评分/虚拟化通道，4 组） | [[re-anti-analysis]]「反虚拟化方法论」 | 沙箱/虚拟机对抗（检测与绕过） |
+| 平台经验（跨 OS 安装与行为差异） | [[platform-tips]] | 所有工具准备与跨平台执行 |
+
+### 单函数深分析顺序
+
+逐函数深分析是**收敛循环**，不是单向流水线——实际形态是「粗反编译拿线索 → 恢复类型/常量/调用形状 → 重新反编译 → 直到定点」：
+
+```
+初次反编译（先拿粗结果：字段使用、调用形状、switch 形态、分配大小）
+   → types / constants / vtables / function identity 四类信息交替恢复
+   → 重新反编译
+   → 复核对齐；仍有冲突则回到上一步
+```
+
+**禁止的是"只反编译不复核就交付"，不是"先看反编译"**——类型恢复常常需要先有一次粗反编译才有线索（field-use / call-shape / switch / allocation size）。四类要恢复的信息：
+
+1. **types——类型定义**：还原参数/返回类型与结构体字段。找什么：参数与局部变量引用的 struct、switch/比较中的 enum 值、函数指针类型（回调签名）
+2. **constants——常量定义**：识别魔数与加密常量。找什么：疑似 #define 的数字字面量、位掩码及其构成的 flag、有语义的 magic number（如 ELF 魔数——**字节序列是 `7f 45 4c 46`**，写成 C 字面量即 `"\x7fELF"`；按 u32 读时注意字节序：小端得 `0x464c457f`、大端才是 `0x7f454c46`）、协议专用常量、用作 key/标识符的字符串常量
+3. **vtables——虚表恢复**：定位虚表，反推类关系与调用点。找什么：thunk 到 vtable 分发的虚方法、读/初始化 vtable 指针、对象构造/析构序列、多条分发路径
+4. **function identity——函数名与签名**：对照已命名符号表/导入导出/调用点证据定名。找什么：import/export 的 demangled 符号名、调用点分析推出的调用约定、callee 引用推出的参数个数与类型、返回值使用分析推出的返回类型
+5. **收敛判据（定点）**：**四类同时满足才算收敛**——类型全部解析（无裸 ID）、常量已替换为有意义名字、虚调用目标已识别、最终签名带参数名。**每一轮改动都要重新反编译核对**，避免"改了类型但没验证"；仍有冲突说明还没到定点，回到对应类别继续
+
+每步发现记录 provenance（哪个证据支撑哪条结论）。工具不绑定：各步在 Ghidra / IDA / radare2 中有等价操作。
+
+### 负面结论标准
+
+下「不存在 / 未发现 / 不支持」类结论前，最少做 **3 次不同尝试**（换工具 / 换视角 / 换参数），并在复核输出中列出尝试清单。负面结论的置信度默认「中」，除非尝试清单覆盖了全部合理路径。
+
+### pivot 提示链
+
+分析卡住时按链换路：反调试对抗 → 打补丁/硬件断点 → 混淆 → 动态追踪 → 脱壳；每换一次记录原因（与调查预算联动：同参数重复 ≥2 次即换思路）。
--- a/vendor-new/rev-skills/.claude/skills/re-analyze/references/anti-dynamic-workflow.md
+++ b/vendor-new/rev-skills/.claude/skills/re-analyze/references/anti-dynamic-workflow.md
@@ -0,0 +1,57 @@
+# 动态分析对抗工作流（通用）
+
+适用于任何带反分析/反调试/加固目标的动态分析（移动、桌面、固件均可）。方法为核心，插桩工具可替换（Frida / objection / Xposed / GDB / LLDB）。
+
+## 崩溃迭代法（静态定位 → 定点脚本 → 崩溃日志驱动）
+
+不预置通用 bypass 全家桶，按循环走：
+
+1. **基线崩溃检测**：先跑原样目标（spawn/启动早期，`--pause` 或等价停在早期代码前），抓崩溃日志判四类：
+   - Java/托管崩溃（FATAL EXCEPTION + 异常类名）
+   - native 崩溃（SIGABRT / SIGSEGV / SIGBUS / SIGFPE / SIGILL）
+   - ANR
+   - 反分析指示（日志含 security / tamper / root / frida / xposed / magisk / substrate / debug / hook 关键字）
+2. **崩溃特征 → 保护机制对照**：
+
+| 崩溃特征 | 指向 | 定位手段 |
+|---|---|---|
+| System.exit(0) 在栈中 | 反分析自杀 | 搜 System.exit / Process.killProcess |
+| SecurityException | 权限或完整性检查 | 搜异常类 |
+| SIGABRT（native） | native 反篡改（插桩检测、库完整性） | 看 .so，搜 dlopen / ptrace / frida 字符串 |
+| 启动即关闭无崩溃 | finish() 或早期入口内 System.exit | 读入口 Activity/函数的条件分支 |
+| root/完整性 SDK 日志（RootBeer/SafetyNet/Play Integrity） | root/完整性 SDK | 搜 SDK 包名 |
+| ssl/certificate/pin 日志 | 证书固定挡抓包 | 搜 CertificatePinner / TrustManager |
+| frida/xposed/substrate 日志 | 插桩检测 | 搜进程名 / 端口 / 模块检查 |
+
+3. **定点绕过**：
+   - 布尔检查方法 → 返回 false
+   - native 函数 → `Interceptor.replace` 等价物 + NativeCallback 返回 0
+   - 未知检查 → hook 自杀函数（System.exit 等）打印调用栈定位来源
+   - 后台线程持续检查 → hook `Thread.start()` 或对应 Runnable
+4. 迭代 3-5 层检查是常态；插桩默认端口被探测 → 换端口启动
+
+## 高频检测面清单（检测与绕过共用同一面）
+
+- **文件系统**：插桩 server 路径、su 路径（20+ 常见位置）、`/proc/self/status` 的 TracerPid
+- **端口**：插桩默认端口（如 27042-27045）、调试器端口
+- **线程名**：插桩运行时线程名特征（GumJSLoop / GumJS-Worker / coordinator 类）
+- **内存布局**：`dlopen` 插桩库路径、`mmap` PROT_EXEC、maps 里特征字符串
+- **系统属性/环境**：`ro.debuggable`、`ro.kernel.qemu`、`LD_PRELOAD` / `DYLD_INSERT_LIBRARIES`
+- **时间**：sleep / GetTickCount / RDTSC（检测沙箱加速执行）
+- **ptrace**：PTRACE_TRACEME 自我跟踪检测调试器
+
+## 裸系统调用检测
+
+目标自实现系统调用（绕过 libc）时，基于 libc 符号的 hook 与检测全部失效——svc 指令级捕获：
+
+- **架构分支**：arm64 SYS_OPENAT=56（无 open 系统调用）、svc 机器码 `01 00 00 D4`，路径参数在 x1（x0 是 dirfd）；arm SYS_OPEN=5、`00 00 00 EF`，路径在 r0
+- **手法**：遍历可执行段（r-x）过滤 .so → 特征码扫描命中 → 回读 svc 前一条指令取系统调用号（arm64 读 `mov x8` 立即数位、arm 读 r7）→ 系统调用号等于目标（如 SYS_OPEN）才 attach → 打印文件名与返回值
+- **注意**：arm64 参数索引按系统调用约定核对（openat 路径参数在 x1，x0 是 dirfd，不照搬经验值）；系统调用号表按目标内核/Android 版本核对
+
+## 实现教训（内化）
+
+- 返回值只能在 **onLeave 用 `retval.replace()`** 改，onEnter 改不了
+- 同类 hook 多次赋值会**静默覆盖**（缓存问题）——相关 hook 合并进一个
+- 保存 original 引用后必须带原 `this` 调用
+- 输出优先判可打印 ASCII 再回退 hex；字符串常量缓存；选择性 hook 用完 detach
+- 客户端 hook 无法伪造**服务端** attestation 结论（Play Integrity 等）——服务端校验的结论只写「无法绕过」，不写伪成功
--- a/vendor-new/rev-skills/.claude/skills/re-analyze/references/capabilities.md
+++ b/vendor-new/rev-skills/.claude/skills/re-analyze/references/capabilities.md
@@ -0,0 +1,98 @@
+# 能力注册表（Capability Layer）
+
+能力层解决技能边界漂移：技能按**能力**（可执行的分析动作）声明，域技能 = 能力组合。新增技能先声明能力，路由按能力匹配，不依赖领域名。
+
+## 标签清单（validate.mjs 校验值必须在此清单内）
+
+- `triage` — 文件初勘（file/哈希/熵/strings/架构识别）
+- `address-translation` — 地址空间换算（PIE/ASLR 基址、RVA/VA、loader offset、跨工具地址对齐）
+- `elf-parser` — ELF 格式解析（头/节/动态链接/符号）
+- `pe-parser` — PE 格式解析（DOS/NT 头/节表/导入导出）
+- `macho-parser` — Mach-O 解析（LC_*/segment/dyld）
+- `dex-parser` — DEX 解析（opcode/结构/混淆）
+- `bytecode-parser` — 托管字节码解析（Java/.NET/WASM/pyc/CAP 等）
+- `binary-diffing` — 二进制变体/补丁对比
+- `decompilation` — 反编译（Ghidra/IDA/Binary Ninja 等）
+- `debugging` — 交互调试（断点/单步/内存读写）
+- `tracing` — 系统调用/函数跟踪
+- `memory-dump` — 进程内存转储与定向提取
+- `memory-forensics` — 整机内存取证（Volatility）
+- `emulation` — 模拟执行（Unicorn/Qiling/QEMU）
+- `symbolic-execution` — 符号执行
+- `constraint-solving` — 约束求解（Z3）
+- `unpack` — 脱壳（压缩壳/强壳/加固 DEX）
+- `deobfuscation` — 反混淆（花指令/平坦化/脚本混淆）
+- `crypto-identification` — 加密算法识别（常量表/指纹）
+- `crypto-decryption` — 加密数据还原（定位解密函数/写解密脚本）
+- `key-extraction` — 密钥与口令提取（硬编码/内存/资源）
+- `protocol-recovery` — 协议状态机重建
+- `network-capture` — 流量捕获与过滤（tcpdump/tshark）
+- `tls-analysis` — TLS/加密流量分析（指纹/密钥导出）
+- `jni-analysis` — JNI 注册与 native 方法还原
+- `frida-instrumentation` — Frida 插桩（hook/脚本生成）
+- `firmware-extraction` — 固件提取与解包
+- `rtos-analysis` — RTOS 任务表/内核对象还原
+- `hardware-interface` — 硬件接口（JTAG/UART/flash/读卡）
+- `rf-analysis` — 射频信号采集与解调
+- `malware-behavior` — 恶意行为分析（持久化/注入/ATT&CK）
+- `threat-intel` — 威胁情报关联与归因
+- `license-analysis` — 授权验证逻辑分析（定位校验点/算法还原）
+- `fuzzing` — 覆盖率引导模糊测试
+- `shellcode-analysis` — Shellcode 提取与解码
+- `kernel-analysis` — 内核模块/驱动逆向
+- `stego-detection` — 隐写检测与提取
+- `document-malware` — 恶意文档分析（PDF/Office）
+- `evasion-analysis` — 检测规避对抗分析（AMSI/ETW）
+- `game-analysis` — 游戏逆向（Unity/Unreal/脚本引擎）
+- `console-analysis` — 主机/复古平台容器与 ROM
+- `drm-analysis` — DRM 实现分析
+- `automotive-analysis` — 汽车总线（CAN/ECU）
+- `ai-model-analysis` — AI 模型逆向与攻击
+- `blockchain-analysis` — 链上字节码（EVM 等）
+- `web-assembly` — WASM 逆向
+- `browser-extension` — 浏览器扩展逆向
+- `sdr-analysis` — 软件无线电协议恢复
+- `chip-analysis` — 芯片物理层（decap/侧信道）
+- `tee-analysis` — TEE/TrustZone 可信应用
+- `uefi-analysis` — UEFI/BIOS 固件
+- `mobile-forensics` — 移动设备取证（备份/应用数据）
+- `arch-analysis` — 架构相关逆向（ARM/MIPS/RISC-V：调用约定、指令集特性、裸机入口）
+- `lang-runtime-analysis` — 语言运行时产物逆向（Go/Rust/Swift/Zig/Nim/Haskell：符号、ABI、运行时结构）
+- `disk-forensics` — 磁盘/文件系统取证（删除恢复、时间线、未分配空间）
+- `ebpf-analysis` — eBPF 程序逆向（指令集、progs/maps 关联、跟踪与对抗）
+- `electron-analysis` — Electron 桌面应用逆向（asar/主渲染进程/CDP）
+- `hypervisor-analysis` — 虚拟化逆向（VT-x/SVM、VMCS/VMCB、嵌套与检测）
+- `jailbreak-analysis` — iOS 越狱环境与 tweak 分析（检测绕过、Theos/LLDB 远程）
+- `hybrid-app-analysis` — 跨平台框架产物逆向（Flutter/Dart AOT、Hermes/RN）
+- `exploit-development` — 利用开发（ROP/堆利用/载荷构造）
+- `binary-patching` — 二进制补丁（字节级修改、指令重写）
+- `plugin-development` — 逆向工具链扩展（Ghidra/IDA 插件工程化）
+- `sandbox-setup` — 沙箱与隔离环境搭建（动态分析前置）
+- `sample-acquisition` — 现场样本采集（异常执行内存定位、运行时捕获与提取，跨 OS 观测模型）
+
+## 标注规范
+
+- frontmatter 声明 `capabilities: [tag1, tag2]`（YAML list；单值可写 `capabilities: [tag]`）
+- 语义：本技能**提供**这些能力（一技能可多能力）
+- 网关/入口：声明其聚合能力；不提供分析能力的元技能（如 re-feedback）可省略字段
+- 未知标签、非 list 写法 → validate.mjs 报错
+- **标签不得悬空**：注册表里的标签必须至少被一个技能声明（validate.mjs 检查）——新增标签与声明它的技能同批提交
+- **原子技能必须声明**：未声明即 `npm test` 失败；入口（re-analyze）与不提供分析能力的元网关（re-feedback）可省略
+
+## 能力索引（声明 → 消费的查询表）
+
+- `capability-index.md`：能力 → 技能反查表，**机器生成**（`node bin/capindex.mjs`），含"尚未被声明"清单与覆盖率计数
+- 任何 `capabilities` 声明变更后必须重跑生成并提交，否则 `npm test` 报索引过期
+- 路由/检索按索引反查（不必按领域名猜）；索引同时是可查的覆盖率看板（标签覆盖 + 技能覆盖两个口径）
+
+## 路由按能力匹配
+
+- `triage.md` 目标表与 `rerouting.md` A 表都带「需要能力」列，技能列由 `capability-index.md` 反查——新增/修改路由行时先定能力标签，不按领域名硬编码
+- CI 校验（`npm test`）：路由能力列标签须在注册表内；路由标称能力须被本行技能声明
+
+## 网关选择树的能力标注
+
+- **格式**：`[[re-<技能名>]]（能力：`tag1`、`tag2`）`——必须带显式「能力：」前缀；无前缀的括号是普通说明（如 `[[re-x64dbg]]（`minidump` 命令）`），两者不可混
+  - 写作占位符时用 `[[re-<技能名>]]` / `[[<文件名>]]`——尖括号形式不会被解析成真链接，避免文档示例触发断链报错（validate 只校验实际链接）
+- **范围**：`## 何时用哪个原子技能（选择树）` 段内**所有技能链接强制标注**；完整工作流段同样格式（非强制）
+- **CI 校验**（`npm test`）：选择树内技能链接缺标注 → 失败；标注的能力须在注册表内、且被被标注技能真的声明；非技能链接（references 文档如 [[platform-tips]]）豁免
--- a/vendor-new/rev-skills/.claude/skills/re-analyze/references/capability-index.md
+++ b/vendor-new/rev-skills/.claude/skills/re-analyze/references/capability-index.md
@@ -0,0 +1,78 @@
+# 能力索引（机器生成，勿手改）
+
+> 生成：`node bin/capindex.mjs`｜校验：`npm test`（过期即失败）
+> 用途：路由与检索按能力反查技能——能力层的查询表（声明侧见 capabilities.md）
+
+## 已声明能力（标签 65/65｜技能 120/122）
+
+| 能力 | 说明 | 提供技能 |
+|---|---|---|
+| `address-translation` | 地址空间换算（PIE/ASLR 基址、RVA/VA、loader offset、跨工具地址对齐） | re-address-space |
+| `ai-model-analysis` | AI 模型逆向与攻击 | re-ai-attack, re-ai-model |
+| `arch-analysis` | 架构相关逆向（ARM/MIPS/RISC-V：调用约定、指令集特性、裸机入口） | re-arm, re-mips, re-riscv |
+| `automotive-analysis` | 汽车总线（CAN/ECU） | re-automotive |
+| `binary-diffing` | 二进制变体/补丁对比 | re-variant |
+| `binary-patching` | 二进制补丁（字节级修改、指令重写） | re-patching |
+| `blockchain-analysis` | 链上字节码（EVM 等） | re-blockchain |
+| `browser-extension` | 浏览器扩展逆向 | re-browser-ext |
+| `bytecode-parser` | 托管字节码解析（Java/.NET/WASM/pyc/CAP 等） | re-dotnet, re-harmonyos, re-java, re-javacard, re-managed, re-python |
+| `chip-analysis` | 芯片物理层（decap/侧信道） | re-hw-chip |
+| `console-analysis` | 主机/复古平台容器与 ROM | re-console |
+| `constraint-solving` | 约束求解（Z3） | re-ctf, re-vuln, re-z3 |
+| `crypto-decryption` | 加密数据还原（定位解密函数/写解密脚本） | re-crypto-decrypt, re-protocol |
+| `crypto-identification` | 加密算法识别（常量表/指纹） | re-android-crypto, re-crypto-id, re-protocol, re-ransomware, re-tls, re-whitebox |
+| `debugging` | 交互调试（断点/单步/内存读写） | re-binary-core, re-crash-triage, re-gdb, re-ghidra, re-ida, re-lldb, re-windbg, re-x64dbg |
+| `decompilation` | 反编译（Ghidra/IDA/Binary Ninja 等） | re-binary-core, re-binaryninja, re-cpp-abi, re-ghidra, re-ida, re-radare2 |
+| `deobfuscation` | 反混淆（花指令/平坦化/脚本混淆） | re-anti-analysis, re-deobfuscate, re-managed, re-script-deob |
+| `dex-parser` | DEX 解析（opcode/结构/混淆） | re-apk, re-mobile |
+| `disk-forensics` | 磁盘/文件系统取证（删除恢复、时间线、未分配空间） | re-disk-forensics |
+| `document-malware` | 恶意文档分析（PDF/Office） | re-doc-malware, re-malware |
+| `drm-analysis` | DRM 实现分析 | re-drm |
+| `ebpf-analysis` | eBPF 程序逆向（指令集、progs/maps 关联、跟踪与对抗） | re-ebpf |
+| `electron-analysis` | Electron 桌面应用逆向（asar/主渲染进程/CDP） | re-electron |
+| `elf-parser` | ELF 格式解析（头/节/动态链接/符号） | re-address-space, re-binary-core, re-format-elf, re-imports |
+| `emulation` | 模拟执行（Unicorn/Qiling/QEMU） | re-emulation, re-firmware, re-fw-emulate |
+| `evasion-analysis` | 检测规避对抗分析（AMSI/ETW） | re-anti-analysis, re-evasion, re-malware |
+| `exploit-development` | 利用开发（ROP/堆利用/载荷构造） | re-exploit, re-pwn |
+| `firmware-extraction` | 固件提取与解包 | re-firmware, re-fw-extract, re-fw-rootfs |
+| `frida-instrumentation` | Frida 插桩（hook/脚本生成） | re-frida, re-frida-script-author, re-mobile |
+| `fuzzing` | 覆盖率引导模糊测试 | re-fuzzing, re-vuln |
+| `game-analysis` | 游戏逆向（Unity/Unreal/脚本引擎） | re-game |
+| `hardware-interface` | 硬件接口（JTAG/UART/flash/读卡） | re-firmware, re-hardware-io |
+| `hybrid-app-analysis` | 跨平台框架产物逆向（Flutter/Dart AOT、Hermes/RN） | re-flutter, re-hybrid-app |
+| `hypervisor-analysis` | 虚拟化逆向（VT-x/SVM、VMCS/VMCB、嵌套与检测） | re-hypervisor |
+| `jailbreak-analysis` | iOS 越狱环境与 tweak 分析（检测绕过、Theos/LLDB 远程） | re-ios-jb |
+| `jni-analysis` | JNI 注册与 native 方法还原 | re-android-native, re-mobile |
+| `kernel-analysis` | 内核模块/驱动逆向 | re-anti-cheat, re-kernel |
+| `key-extraction` | 密钥与口令提取（硬编码/内存/资源） | re-android-crypto, re-crypto-keys, re-malware, re-protocol, re-whitebox |
+| `lang-runtime-analysis` | 语言运行时产物逆向（Go/Rust/Swift/Zig/Nim/Haskell：符号、ABI、运行时结构） | re-fp-runtime, re-go, re-nim, re-rust, re-swift, re-zig |
+| `license-analysis` | 授权验证逻辑分析（定位校验点/算法还原） | re-cracking, re-keygen, re-license |
+| `macho-parser` | Mach-O 解析（LC_*/segment/dyld） | re-binary-core, re-format-macho, re-ios, re-macos |
+| `malware-behavior` | 恶意行为分析（持久化/注入/ATT&CK） | re-behavior, re-fileless, re-loader, re-malware, re-ransomware |
+| `memory-dump` | 进程内存转储与定向提取 | re-binary-core, re-memdump |
+| `memory-forensics` | 整机内存取证（Volatility） | re-forensics, re-mem-forensics |
+| `mobile-forensics` | 移动设备取证（备份/应用数据） | re-forensics, re-mobile, re-mobile-forensics |
+| `network-capture` | 流量捕获与过滤（tcpdump/tshark） | re-netcap, re-protocol |
+| `pe-parser` | PE 格式解析（DOS/NT 头/节表/导入导出） | re-binary-core, re-format-pe, re-imports |
+| `plugin-development` | 逆向工具链扩展（Ghidra/IDA 插件工程化） | re-plugin-dev |
+| `protocol-recovery` | 协议状态机重建 | re-ics, re-iot-proto, re-proto-rev, re-protocol |
+| `rf-analysis` | 射频信号采集与解调 | re-sdr |
+| `rtos-analysis` | RTOS 任务表/内核对象还原 | re-firmware, re-rtos |
+| `sample-acquisition` | 现场样本采集（异常执行内存定位、运行时捕获与提取，跨 OS 观测模型） | re-sample-acquire |
+| `sandbox-setup` | 沙箱与隔离环境搭建（动态分析前置） | re-sandbox |
+| `sdr-analysis` | 软件无线电协议恢复 | re-sdr |
+| `shellcode-analysis` | Shellcode 提取与解码 | re-ctf, re-shellcode |
+| `stego-detection` | 隐写检测与提取 | re-ctf, re-stego |
+| `symbolic-execution` | 符号执行 | re-angr, re-vuln |
+| `tee-analysis` | TEE/TrustZone 可信应用 | re-tee |
+| `threat-intel` | 威胁情报关联与归因 | re-attribution, re-forensics, re-hunting, re-ioc, re-malware, re-ti |
+| `tls-analysis` | TLS/加密流量分析（指纹/密钥导出） | re-protocol, re-tls |
+| `tracing` | 系统调用/函数跟踪 | re-tracing |
+| `triage` | 文件初勘（file/哈希/熵/strings/架构识别） | re-ai-triage, re-triage |
+| `uefi-analysis` | UEFI/BIOS 固件 | re-firmware, re-uefi |
+| `unpack` | 脱壳（压缩壳/强壳/加固 DEX） | re-anti-analysis, re-mobile-pack, re-packer-id, re-unpack-advanced, re-unpack-simple |
+| `web-assembly` | WASM 逆向 | re-wasm |
+
+## 尚未被声明（0）
+
+（无——注册表标签全部有技能声明）
--- a/vendor-new/rev-skills/.claude/skills/re-analyze/references/cross-system-models.md
+++ b/vendor-new/rev-skills/.claude/skills/re-analyze/references/cross-system-models.md
@@ -0,0 +1,226 @@
+# 跨系统运行模型与误判总表
+
+**用途**：任何"现象看起来异常"的时刻，先过这张表。它的价值不在于介绍系统，而在于**阻止把某个系统的正常机制判成 bug / hook / dead code / 恶意**。
+
+**前置**：本文件假设你已经知道"这是哪个系统"。**认不出目标时先走 [[system-fingerprints]]**（载体格式 → 家族 → 系统 → 易混淆对 → 负判据）。两者配合使用：先定身份，再查该身份允许哪些"正常异常"。
+
+判定顺序（本文件的核心主张）：
+
+```
+观察异常现象
+  → 识别目标的运行模型（哪个系统、哪个构建、哪个阶段）
+  → 判断该模型允许哪些"正常异常现象"
+  → cross-view / 配置核对 / 运行时验证
+  → 最后才判定：损坏、恶意，或真的是 bug
+```
+
+## 一、十类高频误判（先怀疑，再排除）
+
+| 观察到的现象 | 不要直接推断 | 必须先排除 |
+|---|---|---|
+| 函数 0 xref | dead code | linker set、generated registry、callback、IPC dispatch、RTE、init table、AST、exception table |
+| 地址变化 | hook / 不同 binary | KASLR、KARL、relocation、PAC、GPA/HPA、local handle |
+| 同一个整数 | 同一个对象 | CPtr、Zircon handle、endpoint、fid、grant ref、event port、capability name |
+| driver 没有 syscall / IRP handler | 没有 I/O | framework callback、user-space driver、miniport、resource manager、DDF、scheme |
+| thread READY 却不运行 | scheduler bug | partition window、budget、SC、safety class、上层 scheduler、调度器被禁用 |
+| 文件存在但代码没运行 | loader bug | activation state、AuxKC、Function Group、module load stage、按需发现 |
+| disk code ≠ runtime code | rootkit | livepatch、ftrace、jump labels、kernel collection、runtime relocation、init 段已释放 |
+| IPC 没有 syscall trace | 没发生通信 | shared-memory channel、local transport、co-located driver、VMBus、grant table |
+| memory access fault | 内存坏了 | MPU zone、capability rights、cell/partition 归属、IOMMU、当前特权级 |
+| 服务突然换 PID / endpoint | 劫持 | restart / live update / reincarnation / 按需加载 |
+
+## 二、共同规律 A：本地句柄 ≠ 全局标识
+
+跨进程、跨分区、跨域建图之前，**必须先恢复 `本地标识 → 命名空间/表 → 真实对象`**，再谈关系。
+
+| 系统 | 本地标识 | 恢复方式 |
+|---|---|---|
+| seL4 | CPtr | 各自的 CSpace 映射 → kernel object |
+| Fuchsia/Zircon | handle 整数 | 进程 handle 表 → 对象 + rights |
+| MINIX 3 | endpoint / grant ID | label 解析、grant 表条目 + 序列号 |
+| Genode | capability 局部名 | PD 局部命名 → session/对象 |
+| Plan 9 | 9P fid | 连接 + walk 历史 + qid |
+| Xen | grant ref / event port | grant 表条目；`shared_info` 位掩码（远端端口才稳定） |
+| Bao | —— | 共享对象 identity 是配置里的 `shmem_id`，不是地址 |
+| ACRN / Jailhouse | —— | 共享区归属由配置/前缀（`dm:/` vs `hv:/`）决定 |
+
+## 三、共同规律 B：ready 不是"有资格现在占用 CPU"的充分条件
+
+分区/安全系统（ARINC 653、PikeOS、INTEGRITY、Deos、XtratuM、LynxSecure、Jailhouse、Bao、Quest-V）**共用一条经验**：
+
+```
+资源资格（budget/quota）
+  → 分区/域资格（当前窗口、调度计划、CPU 归属、safety mode）
+  → 本地调度器资格
+  → 线程优先级
+```
+
+**不能简化为"最高优先级 READY 者运行"。** 分析时先对齐分区级时间线，再看线程级。
+
+## 四、共同规律 C：没有内核入口 ≠ 没有 I/O
+
+用户态驱动/服务形态各异，但结论相同——**在 kernel 里找不到 dispatch 是常态**：
+
+resource manager（QNX）、DriverKit/System Extension（macOS）、driver host（Fuchsia）、DDF（HelenOS）、scheme（Redox）、user-space service + RS（MINIX 3）、user-space file server（Plan 9）。
+
+## 五、共同规律 D：没有 CFG 边 / 没有 syscall ≠ 没发生
+
+- **注册式**：linker set（FreeBSD `set_*`）、iterable section + `SYS_INIT`（Zephyr）、generated RTE（AUTOSAR）、配置生成的 task/handler（TOPPERS、RTEMS）、autoconf（OpenBSD）、按需 autoload（NetBSD）
+- **回调式**：framework callback（Windows 各模型）、SDK callback（VxWorks io-pkt、`nw_pthread_create`）
+- **异步控制流**：AST（OpenVMS）、SRB（z/OS）、fault handler（seL4）
+- **异常边**：`__ex_table`（Linux exception fixup）
+- **共享内存式**：PV ring（Xen）、driver runtime local transport（Fuchsia）、grant（MINIX）、VMBus（Hyper-V）、VirtIO/共享页
+
+## 六、共同规律 E：信任边界不能从指令形态推导
+
+**在 capability / 沙箱 / 多版本 / live-update 型驱动系统里**（覆盖 seL4、Genode、Fuchsia、多内核系统、分区 hypervisor、用户态驱动 OS 等）：
+
+```
+不从 CPL、地址、直接调用或 MMIO 指令推导信任边界
+```
+
+先恢复 **domain、capability、mapping、device ownership、version、lifecycle topology**，再解释控制流。四条推论：
+
+| 看起来像 | 实际可能是 |
+|---|---|
+| 直接 call | 跨逻辑组件的调用（同地址空间 ≠ 同组件；同组件也可能跨隔离域） |
+| 直接 MMIO | 被授权的设备映射（**"能访问 MMIO" ≠ "有整机内核权限"**） |
+| 同特权级 | 靠 MMU 隔离的独立域（**Ring 0 → 全内核可寻址** 在这类系统上是 invalid assumption） |
+| 整数句柄 | capability / 共享页偏移 / domain-local 标识（跨域比较无意义） |
+
+配套要求：内存取证要区分 **VA / PA / backing frame / capability / owner domain / mapped domain**；共享内存指针要带域语义（`{domain, cap, mapping, offset, length, rights}`），否则数据流分析会把合法跨域流错误合并。具体系统分支见 [[re-kernel/hic]]、[[re-kernel/sel4-kernel]]、[[re-kernel/zircon-kernel]]、[[re-kernel/genode]]。
+
+## 七、共同规律 F：磁盘上的 ≠ 正在跑的
+
+livepatch / ftrace / jump label（Linux）、AuxKC 与 Kernel Collection（macOS）、runtime relocation 与 `__init` 释放（Linux）、live update（MINIX 3）、动态模块替换（Nucleus、OSE）、按需发现（Haiku）。
+
+**动手比较前先对齐三份身份**：磁盘版本 / 加载集合中的版本 / 当前真正在跑的版本。
+
+## 七、跨系统异常处理树
+
+```
+看到"异常"
+│
+├─ 函数没有 caller
+│   ├─ callback registration
+│   ├─ linker set
+│   ├─ generated RTE / config
+│   ├─ IPC dispatch
+│   ├─ AST / SRB
+│   ├─ exception table（__ex_table）
+│   └─ init / iterable section
+│
+├─ 地址不一致
+│   ├─ KASLR / KARL
+│   ├─ PE / ELF relocation
+│   ├─ PAC
+│   ├─ GPA / HPA
+│   ├─ local handle namespace
+│   └─ runtime KC / image
+│
+├─ driver 没有内核入口
+│   ├─ user-space driver
+│   ├─ resource manager
+│   ├─ DriverKit
+│   ├─ Fuchsia driver host
+│   ├─ Redox scheme
+│   ├─ HelenOS DDF
+│   └─ MINIX service
+│
+├─ thread 不执行
+│   ├─ partition window
+│   ├─ budget / quota
+│   ├─ SC donation
+│   ├─ safety class
+│   ├─ Hwi/Swi scheduler 被禁用
+│   ├─ partition mode（未进 NORMAL）
+│   └─ 上层 scheduler
+│
+├─ IPC 没有 syscall
+│   ├─ shared-memory ring
+│   ├─ polling
+│   ├─ co-located transport
+│   ├─ VMBus / GPADL
+│   ├─ grant table
+│   └─ hypervisor channel
+│
+├─ memory access fault
+│   ├─ capability rights
+│   ├─ MPU zone
+│   ├─ task isolation
+│   ├─ cell / partition assignment
+│   ├─ IOMMU
+│   └─ runtime privilege level
+│
+├─ binary 存在但没运行
+│   ├─ AUTOSAR Function Group / Machine State
+│   ├─ System Extension activation
+│   ├─ boot / module stage
+│   ├─ partition mode
+│   └─ on-demand driver discovery
+│
+└─ runtime 与 disk 不同
+    ├─ livepatch
+    ├─ jump-label / ftrace
+    ├─ AuxKC / kernel collection
+    ├─ dynamic module relocation
+    ├─ init code 已释放
+    └─ live update / restart
+```
+
+## 八、使用方式
+
+1. 现象命中上表任一行 → **先按"必须先排除"逐项核对**，不要跳到结论
+2. 需要某个系统的细节 → 按 [[rerouting]] A 表或 [[capability-index]] 反查对应技能与分支
+3. 核对手段统一是三样：**cross-view**（多视图交叉）、**configuration**（配置/清单/计划文件）、**runtime verification**（运行时状态而非磁盘内容）
+4. 只有在排除完该模型允许的正常机制之后，才写"损坏 / 恶意 / bug"的结论——并在报告里写明**排除了哪些可能性、依据是什么**
+
+## 九、异常速查表（按现象直查）
+
+| 现象 | 优先考虑 |
+|---|---|
+| AUTOSAR binary 存在但 process 不存在 | Function Group State / Execution Manifest |
+| AUTOSAR service 暂时发现不到 | 服务发现允许空结果 / 可用性回调生命周期 |
+| AUTOSAR process 无 crash 却重启 | 平台健康监控 → 状态管理 |
+| AUTOSAR 更新后仍旧数据 / 数据消失 | Persistency 更新策略（keep / overwrite / delete） |
+| 分离内核里找不到 runtime 配置器 | 静态配置 + 无动态系统修改 |
+| guest 直接操作真实 MMIO / IRQ | 静态 direct assignment（I/O 被导出到 guest） |
+| 分区 RTOS 里高优先级 READY 不执行 | 时间窗 / 调度域资格 |
+| 分区 RTOS 多出 CPU 时间 | slack 回收 |
+| 分区 RTOS 的 major frame 起点缓慢漂移 | 外部时钟同步类机制（需在具体型号文档确认） |
+| 认证 RTOS 里同一地址权限不同 | per-task MPU/MMU 区域 |
+| 认证 RTOS 里句柄不像指针 | 间接对象 ID + 交叉引用表 |
+| ISR 唤醒了 task 却不切换 | 嵌套 ISR / ISR 退出协议 / 调度器锁 |
+| task 被唤醒但没有资源 | 中止等待路径（唤醒 ≠ 获取成功） |
+| 线性地址下仍存在隔离 | 线性映射 + entitlement（不是每进程独立 VA） |
+| module 无 reboot 被替换 | 动态 reload / restart / update |
+| 遇到 "partition" 一词 | 先分：空间隔离域 vs 固定块内存池 |
+| 高优先级 task READY 不跑（TI SYS/BIOS） | 禁用 Swi 调度会连带禁用 Task 调度 |
+| Swi 的栈看起来像 ISR 栈 | Swi 本就运行在系统/ISR 栈上 |
+| ISR 里调用的 API 效果延后 | ISR FIFO 延迟队列 |
+| 同一对象不同线程权限不同 | Safety Class / MPU 保护域 |
+| plan switch 延迟生效 | 普通切换要等当前计划/MAF 结束 |
+| plan 瞬间切换 | 健康监控切维护计划 |
+| 采样端口"丢中间值" | latest-value 覆盖语义 |
+| Service VM 里设备消失又回来 | 设备所有权移交给 post-launched VM |
+| 共享内存设备各自正常却互不相通 | 两种实现（dm-land / hv-land）不互通 |
+| 小整数被当地址（Hyper-V） | GPADL 是句柄 |
+| 删除 GPADL 时卡住 | server 仍映射，阻塞直到解除 |
+| packet 回调返回但资源未释放 | 完成调用可延后 |
+| 取外部数据返回"待决" | 需要分页；稍后可能在不同 IRQL 再次回调 |
+| 网络 VMBus 流量突然消失但网络正常 | SR-IOV VF 直通路径切换 |
+| ring 更新却没有通知（Xen） | 通知抑制（阈值未越过） |
+| event unmask 行为奇怪 | pending / masked / FIFO 语义 |
+| 迁移后 domid / 端口变化 | 协议需要重新协商 |
+| 同一 build 里事件记账布局不同 | 两套 ABI，解析器不能混用 |
+| 0 xref 的 init 函数（Unikraft） | 多级初始化表（构造/早期/平台/库/rootfs/系统/晚期） |
+| 同名 syscall 出现多个符号 | libc 风格 / raw-error 风格 / shim 三层包装 |
+| 缺 syscall 返回 ENOSYS 但应用照跑 | 可选 syscall 桩 |
+| 同一源码的 I/O 完全不同（MirageOS） | 构建目标决定 backend |
+| 全部"线程"一起卡死 | 协作式线程不让出（饿死事件循环） |
+| 后台任务异常没有直接杀系统 | 异步异常处理策略 |
+
+## 十、版本与代际提示
+
+- **按目标做版本指纹再套条目**：规范与手册存在代际差异——例如某平台规范已推进到新版本而多数公开细节来自上一版；某 hypervisor 最完整的公开手册属于某一代（如 XM-4），**不要无条件套到其他代际**
+- 同一系统的不同产品线（安全认证版与基础版）**也不是同一份二进制/内核**，机制可选项不同
--- a/vendor-new/rev-skills/.claude/skills/re-analyze/references/platform-tips.md
+++ b/vendor-new/rev-skills/.claude/skills/re-analyze/references/platform-tips.md
@@ -0,0 +1,125 @@
+# 平台经验知识库
+
+> 跨大类共享的实战经验。所有技能的工具准备与操作步骤按 OS 分支执行。
+> 原则：**先给最轻的可行方案**（Wine 直读 > 用户态仿真 > 全系统虚拟化 > 物理机）。
+
+## 最高原则：默认沙箱
+
+一切动态分析/运行样本默认在沙箱中执行（强制前置）：虚拟机快照 / 容器（Docker、firejail）/ 专用沙箱（Cuckoo/CAPE）；网络隔离（INetSim、fake DNS、断网）。静态分析可免沙箱，一切动态执行默认在沙箱内，分析结束后恢复快照。此原则优先于本文件所有其他条目。
+
+## 平台分支
+
+### 所有平台
+- 动态分析默认沙箱（见上）。
+- **入口之前执行点**：PE 的 TLS 回调与 ELF 的 `.preinit_array`/`.init_array`/`__libc_start_main` 的 init 参数都在入口点/main 之前执行——只断入口会漏掉入口前逻辑；动态断点设在 `ntdll!LdrpCallInitRoutine`（Windows）与 `__libc_start_main`（Linux）。
+- **工具解析 ≠ 加载器视图**：损坏/歧义的头字段没有唯一正确解析，恶意样本利用解析器差异规避工具——工具报错 ≠ 文件损坏，先手工核对关键头字段，结论对照真实加载器语义复核。
+- **反汇编函数边界有误差**：线性反汇编对 PE（代码节内联跳转表等数据）准确率约 99%，函数边界识别在主流工具中也有 20%+ 误判（尾调用/非标准序言/内联导致）——反编译结论需交叉验证，别全信工具的函数列表。
+- **32 位程序**：gdb 架构切换影响 ABI/寄存器集/调用约定——调 32 位目标先确认调试器架构模式与目标一致；Windows 侧 32 位目标对应 x32dbg；Wine 跑 32 位 PE 用 wine32 前缀（WINEARCH=win32）。
+
+### Linux
+- 分析 Windows PE 程序：**Wine 直读进程内存**——wine 运行 PE → `gdb attach` 或读 `/proc/<pid>/mem`，无需整机虚拟化；脱壳/读内存直接对 Wine 进程操作。
+- 跑非本机架构程序：QEMU 用户态仿真（`qemu-<arch>`）优先，全系统仿真仅必要时用。
+- **attach 权限不是非黑即白**：ptrace_scope=1 限制子进程/父子关系/PR_SET_PTRACER——同属主不一定能 attach，还需父子关系或目标声明 PR_SET_PTRACER；root 也可能受限；容器内 CAP_SYS_PTRACE 影响 attach 能力。
+- **QEMU 用户态仿真的主要差异**：QEMU 用户态最大问题=syscall ABI/kernel feature/指令扩展（非 libc）——程序跑不起来先按这三点排查，别只补库。
+
+### Linux 内存转储极端段
+- `[vsyscall]`（固定地址 `0xffffffffff600000`，只执行 `--xp`）、`[vdso]`/`[vvar]`：`/proc/<pid>/mem` 读取失败、gdb 访问报错均属正常。
+- 转储前必须按 `/proc/<pid>/maps` 过滤这些段（只 dump `r--p`/`rw-p` 可读映射），否则 dump 含垃圾页、脱壳/分析全被污染。
+- 识别特征：`maps` 中 `[vsyscall]`/`[vdso]`/`[vvar]` 名称、地址落在 `0xffffffffff6xxxxx` 高段、无文件路径的匿名 `00:00` 映射。
+
+### Windows
+- 读目标进程内存：需装 Sysinternals 套件（`procdump`）/ `DumpIt` 做内存转储 + Volatility 分析；attach 需要管理员权限。
+- 常用工具链：x64dbg、Process Explorer（替代 System Informer）、APIMonitor。
+- **attach 失败先区分权限与 PPL/保护进程**：管理员解决普通限制，PPL 取决于 Signer Level 等级（EDR 常见 PPL-Windows TCB/Antimalware），需对应级别调试能力。
+- **Windows 读 Linux 样本**：静态无平台限制，动态需匹配运行环境——静态分析可在 Windows 侧直接进行，要运行样本则准备匹配的 Linux 环境（VM/容器）。
+
+### macOS
+- attach/调试：SIP 与 TCC 限制，调试工具需授权（Developer Tools 权限），`lldb` attach 前检查。
+- **attach 失败层次**：task_for_pid entitlement/SIP/Hardened Runtime——Developer Tools 授权之外，调试器自身需 task_for_pid entitlement，目标启用 Hardened Runtime 时调试 API 受限。
+
+### 沙箱
+- **容器调试缺 SYS_PTRACE**：容器内 attach 受限来源=SYS_PTRACE 能力、/proc 挂载、seccomp、Yama 限制——先确认容器配置（如 `--cap-add=SYS_PTRACE`）再判断"环境限制"还是"程序不可分析"。
+- **沙箱隔离≠分析环境伪装**：时间/硬件/输入检测是环境指纹，完整 VM 也会被检测——隔离保证安全，不保证"像真实环境"；环境指纹对抗单独处理。
+
+### WSL
+- WSL 无法直接 attach Windows 进程——跨边界分析走 Windows 侧工具，WSL 内只做文件/静态分析。
+
+## 原则：分析前确认（动态分析前置）
+
+动态分析前先确认目标 ABI、执行环境、权限模型，否则调试失败不代表程序不可分析——失败先归因（架构/环境/权限），再决定换方案还是下结论。
+
+## 原则：静态优先（大型样本）
+
+静态与动态不是替代关系，大型样本静态定位先行、动态验证在后——先静态缩小范围，动态按需补充。
+
+## 原则：模拟执行优先（能跑就不逆向）
+
+目标含官方原生库（签名算法/加密例程/混淆 VM）时，**模拟执行官方代码比逆向算法快一个数量级**——数周逆向 vs 一天模拟。适用场景：目标库可加载（依赖可满足）、调用方是 JNI/导出函数、只需"结果"不需"原理"。判定信号：算法复杂度高（轮数多/查表大/混淆深）、有现成库可加载、社区有同类模拟先例。
+- 常用载体：unidbg（Android so + JNI 模拟，Java）、QEMU 用户态（`qemu-<arch>` + sysroot）、Qiling/Unicorn（单函数隔离）
+- 模拟执行产出"看起来正常"的结果不等于正确——**真实环境/服务器响应才是唯一裁判**（模拟环境可能被检测并返回诱饵结果），先用低风险路径验证（白名单命令/非敏感操作），再决定是否触碰高价值目标
+
+## 原则：JNI 导出名 = 协议契约路标
+
+Java 层逆向时，`Java_包名_类名_方法名` 导出是**天然接口文档**——函数名直接给契约（encodeRequest/parseData/setAccountKey 一眼分工）；stripped 的 so 也保留 JNI 导出（JVM 运行时需要）。原生库逆向永远从 `nm -D` 列 JNI 导出开始。
+
+## 原则：序列化/反序列化函数对互证
+
+帧/包格式读 serialize 函数拿布局，再用 deSerialize 验证——**两个方向对上了才是真的**。协议类库通常同时含打包/解包函数（serialize/parse、encode/decode），互为对照。
+
+## 原则：社区逆向成果先搜再挖
+
+同类目标的开源项目是**前人逆向成果的沉淀**——协议结构、密钥表、算法还原、模拟器回调集都在里面。自挖之前先搜（GitHub 镜像/码云/codeload、相关生态项目）；即使版本/目标不同，**结构、模式、回调清单可移植**。自己从零解析的时间成本通常是移植的 10 倍。
+
+## 工具链避坑（实测）
+
+- **IDA interr（decompiler bug）**：`create_stkvar` 类内部错误硬崩溃且无法跳过——换 Ghidra，别硬刚
+- **Ghidra 脚本 API 版本差异**：MemoryBlock 的权限查询方法名随版本变动（getPermissions/isExecute/getExecute 各版本不同）；脚本编译失败先查当前版本 javadoc
+- **dex 解析细节**：opcode 是 **u16 低字节**（高字节是寄存器位）；`fill-array-data` 是 **0x26**（31t）、goto 是 **0x28**（0x24 是 filled-new-array）；string_data_item 有 **uleb128 长度前缀**；code_item 的 `insns_size` 在 **+12**（+4 是 outs_size）
+- **GitHub 下载不稳**：`codeload.github.com` 比 `github.com` 稳（git clone 被重置时 curl codeload 可通）
+
+## 「直读 vs 转储」决策（默认转储优先）
+
+一次转储获得完整内存布局 + 寄存器/线程状态（ELF notes），可导入 Ghidra/IDA、可存档复现；后续所有定向提取（密钥搜索、脱壳段、DEX 挖掘）都从转储产物里做。
+
+| 场景 | 方案 |
+|---|---|
+| 默认（任何需要读内存的任务） | **转储** `gcore` → ELF core；取证/存档用全量转储 + manifest |
+| 需要完整布局 + 寄存器/线程（导入调试器、事后复现） | **转储** `gcore`（含 ELF notes） |
+| 进程已死 | 直接分析已有 core（`kernel.core_pattern` / systemd-coredump / 容器 runtime dump） |
+| ptrace 被禁 / 沙箱容器 / attach 失败 | 转储兜底（不依赖 `/proc/<pid>/mem` 权限路径） |
+| 特例①：进程必须保持运行、实时交互调试 | **直读** `/proc/<pid>/mem`：先读 maps 定址 → SIGSTOP 防竞态 → chunked `pread` 只取目标区段 |
+| 特例②：只需极小特定区段且性能敏感 | **直读** 单区段，同上流程 |
+
+**关键经验**：转储时机——由目标明文/代码的 materialization 决定，经典单层壳在真实 OEP 附近转储通常合适，但 OEP 不是通用完成判据（多阶段 loader / 按需解密 / 虚拟化保护 / 反射加载 / 进程注入 / fake OEP 按「写→执行转移 + 内存保护变化 + payload 头/导入恢复」定 dump 点，必要时多时点快照）；直读前必须先查 maps；dump 前过滤 `[vsyscall]`/`[vdso]`。
+
+## 来源（Task 15 调研，2026-08）
+
+按查询分组的检索链接（WebSearch 实测结果）：
+
+- TLS 回调 / init_array / 入口之前执行点：
+  - DShield: How Malware Defends Itself Using TLS Callback Functions — https://secure.dshield.org/diary/How+Malware+Defends+Itself+Using+TLS+Callback+Functions/6655
+  - Mandiant: Newly Observed Ursnif Variant Employs Malicious TLS Callback Technique — https://cloud.google.com/blog/topics/threat-intelligence/newly-observed-ursnif-variant-employs-malicious-tls-callback-technique-achieve-process-injection/
+- ELF vs PE 分析误区：
+  - USENIX Security 2016 (Andriesse): 函数边界/线性反汇编误差 — https://www.usenix.net/sites/default/files/conference/protected-files/security16_slides_andriesse.pdf
+  - HAL 论文: PE 解析无唯一正确解（解析器差异规避） — https://hal.science/hal-04611598v1/file/publi-6603.pdf
+  - CSDN 文库: Linux ELF 思维在 PE 上的 19 个符号假设性错误（__libc_start_main 幻觉/.interp 缺失误判） — https://wenku.csdn.net/column/38b5um95xq
+  - inventivehq: Understanding PE, ELF, and Mach-O — https://inventivehq.com/blog/executable-file-formats-guide
+  - binutils 邮件列表: COFF vs ELF 未定义符号处理差异 — https://www.sourceware.org/pipermail/binutils/2025-June/142006.html
+  - CyberChallenge 2024 课件: 伪造 ELF 头字段使 readelf 报错 — https://cyberchallenge.it/assets/data/workshop/2024/files/CCIT2024%20-%20Workshop%20-%20Keynote%20-%20Van%20Eeden.pdf
+- 进程内存取证 vsyscall/vdso：
+  - StackOverflow: What are vdso and vsyscall（固定地址/ASLR/auxv） — https://stackoverflow.com/questions/19938324/what-are-vdso-and-vsyscall/19942352#19942352
+  - DEF CON 23 (O'Neil): Advances in Linux Forensics (ECFS，core 低分辨率与重建) — https://infocon.org/cons/DEF%20CON/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEF%20CON%2023%20-%20Ryan-O%27Neil-Advances-in-Linux-Forensics-ECFS.pdf
+- 恶意持久化（注册表/WMI/计划任务）：
+  - win-persistence-checker（注册表 ASEP 检测工具） — https://github.com/cwsecur1ty/win-persistence-checker
+  - analyzing-malware-persistence-with-autoruns — https://github.com/mukul975/anthropic-cybersecurity-skills/blob/main/skills/analyzing-malware-persistence-with-autoruns/SKILL.md
+  - RootGuard knowledge-base: persistence TA0003 技术库（隐藏计划任务 SD 删除） — https://github.com/andranglin/RootGuard/blob/master/knowledge-base/mitre-aligned-threat-dectection/persistence-ta0003-techniques.md
+  - Blue-Team-Scripts: Malware Persistence Mechanisms — https://deepwiki.com/jwardsmith/Blue-Team-Scripts/6.2-malware-persistence-mechanisms
+- 进程注入检测：
+  - detecting-t1055-process-injection-with-sysmon（Sysmon 事件 8/10/7/25） — https://github.com/seikaikyo/dash-skills/blob/main/external/anthropic-cybersecurity-skills/skills/detecting-t1055-process-injection-with-sysmon/SKILL.md
+  - detecting-process-injection-techniques — https://github.com/mukul975/Anthropic-Cybersecurity-Skills/blob/main/skills/detecting-process-injection-techniques/SKILL.md
+  - Hexnode: What is Process Injection（mavinject 等 LOLBin 滥用） — https://www.hexnode.com/blogs/explained/what-is-process-injection/
+- YARA 规则最佳实践：
+  - Trail of Bits: yara-rule-authoring（atom 质量/条件顺序/模块取舍） — https://github.com/trailofbits/skills/blob/e8cc5baf9329ccb491bfa200e82eacbac83b1ead/plugins/yara-authoring/skills/yara-rule-authoring/SKILL.md
+  - performing-threat-hunting-with-yara-rules — https://github.com/seikaikyo/dash-skills/blob/main/external/anthropic-cybersecurity-skills/skills/performing-threat-hunting-with-yara-rules/SKILL.md
+  - VMware Security Blog: Hunting IcedID and unpacking automation（针对壳结构写规则） — https://blogs.vmware.com/security/2021/07/hunting-icedid-and-unpacking-automation-with-qiling.html
+  - Google GTI: YARA-X Livehunt 规则编写 — https://security.googlecloudcommunity.com/google-threat-intelligence-3/agentic-google-threat-intelligence-query-to-help-write-yara-x-rules-for-livehunts-7242
--- a/vendor-new/rev-skills/.claude/skills/re-analyze/references/preferences.md
+++ b/vendor-new/rev-skills/.claude/skills/re-analyze/references/preferences.md
@@ -0,0 +1,52 @@
+# 偏好询问：分级问题集与默认值
+
+入口在执行任务编排前，按**分级**处理偏好，结果存入会话状态，贯穿本次分析全程。
+
+## 分级规则
+
+- **Level 0 快速入口（默认）**：目标明确为「初步分析/这个文件干什么的」或目标未明确时——**不逐项询问**，直接采用默认值开始：
+  | 项 | 默认值 |
+  |---|---|
+  | 目标 | 初步分析（判定类型/恶意性/入口/关键行为） |
+  | 反编译器 | Ghidra |
+  | 深度 | standard |
+  | 报告 | 要 |
+  | 平台 | auto |
+- **Level 1 深度任务**：用户目标明确属于深度任务（脱壳、漏洞挖掘、协议逆向、恶意样本深度分析、破解、取证等）或用户主动要求配置时——完整询问以下 5 项。
+
+## 必答问题（Level 1 第一项）
+
+### 1. 分析目标（自然语言，必答）
+想达成什么？示例：
+- 判定这个样本是否为恶意、会不会回连
+- 脱壳后提取干净样本
+- 找到密钥/注册码/算法
+- 还原某函数逻辑
+- 确认是否存在漏洞
+
+目标不明确时追问，直到可执行。目标决定 triage.md 的选择路径。
+
+## 选择问题
+
+### 2. 反编译器选择
+| 选项 | 依据 |
+|---|---|
+| Ghidra（默认推荐） | 免费开源、跨平台、Linux 最顺 |
+| IDA | 商业付费（有免费版 IDA Free：x86/x86-64 限定、无 SDK/IDAPython、非商用）、Windows 生态最强、插件丰富；用户明确选或目标为 Windows 闭源软件时推荐。**版本代际不在此写死**（避免漂移），需要时以官方发布为准 |
+| radare2/rizin | 命令行轻量、终端友好、脚本化强；内存紧张或 CLI 工作流 |
+
+内存 <4GB → 提示 Ghidra 可能吃力，建议 radare2 或先加内存。
+**推荐依据与已装工具无关**（通用场景默认未装任何工具）。
+
+### 3. 分析深度
+- 快速结论 / 标准分析 / 深度报告
+
+### 4. 输出报告
+- 要（走报告流程：IOC/YARA 等）/ 不要
+
+### 5. 平台确认
+- 自动识别（有文件时按文件格式）/ 手动指定
+
+## 状态传递
+
+探测结果（probe.sh）与上述答案存入会话变量：`RE_OS`、`RE_ARCH`、`RE_MEM_GB`、`RE_TOOLS`（HAVE/MISS 列表）、`RE_GOAL`、`RE_DECOMPILER`、`RE_DEPTH`、`RE_REPORT`、`RE_TARGET_PLATFORM`。被调用技能读取这些变量（如 `RE_DECOMPILER=ghidra` → 反编译步骤直接走 re-ghidra；某工具 `MISS` → 先执行其「工具准备」安装步骤）。
--- a/vendor-new/rev-skills/.claude/skills/re-analyze/references/probe.sh
+++ b/vendor-new/rev-skills/.claude/skills/re-analyze/references/probe.sh
@@ -0,0 +1,53 @@
+#!/bin/sh
+# probe.sh — 环境探测：OS 平台 / CPU / 内存 / 已装逆向工具
+# 输出约定：OS: / ARCH: / CORES: / MEM_GB: / HAVE:tool（逐个）/ MISS: tool tool …（汇总一行）
+#   —— HAVE 是"优先用什么"的依据，逐个列出；MISS 只作提示，汇总成一行避免刷屏
+# 工具清单由登记表生成（见下方 GENERATED-TOOLS 块），不要手改
+# 通用原则：空白环境（无任何工具）也必须正常输出，绝不中断。
+
+echo "== ENV =="
+if command -v uname >/dev/null 2>&1; then
+  case "$(uname -s)" in
+    Linux)
+      if grep -qi microsoft /proc/version 2>/dev/null; then
+        echo "OS: WSL-Linux"
+      else
+        echo "OS: Linux"
+      fi
+      ;;
+    Darwin) echo "OS: macOS" ;;
+    MINGW*|MSYS*|CYGWIN*) echo "OS: Windows(msys)" ;;
+    *) echo "OS: $(uname -s)" ;;
+  esac
+  echo "ARCH: $(uname -m)"
+  if command -v nproc >/dev/null 2>&1; then echo "CORES: $(nproc)"; else echo "CORES: unknown"; fi
+  if command -v free >/dev/null 2>&1; then
+    # 必须固定 LC_ALL=C：本地化的 free 会把 "Mem:" 译成"内存："等，awk 匹配不到（曾导致该项恒为空）
+    echo "MEM_GB: $(LC_ALL=C free -g 2>/dev/null | awk '/^Mem:/{print $2}')"
+  else
+    echo "MEM_GB: unknown"
+  fi
+else
+  echo "OS: Windows"
+  echo "ARCH: unknown"
+  echo "CORES: unknown"
+  echo "MEM_GB: unknown"
+fi
+
+echo "== TOOLS =="
+# >>> GENERATED-TOOLS（源：docs/audit/tool-register.json；改清单请改登记表后跑 node bin/probelist.mjs）
+# shellcheck disable=SC2034
+PROBE_TOOLS="aapt2 adb afl-clang-fast afl-cmin afl-fuzz afl-tmin apksigner apktool arm-linux-gnueabi-readelf atos binwalk blkls canbusload candump cansniffer capinfos class-dump codesign cpuid cramfsck defaults dexdump diec docker dotnet dotnet-dump dpkg-deb driverquery eu-stack ffprobe firejail flashrom fls fltmc frida frida-dexdump frida-trace fsstat gcore gdb gdb-multiarch Get-WinEvent ghc hackrf_transfer hbc-decompiler hbc-disassembler hbc-file-parser icat idevicebackup2 iproxy iptables jadx jar java javap jdb js-beautify jtool2 keytool ld64.lld lipo lldb llvm-nm llvm-objdump llvm-readobj logman ltrace mactime mitmproxy mmls modprobe mono mp4dump netron nm npx objcopy objdump ocamlc ocamlobjinfo ocamlopt olevba one_gadget openocd openssl otool palera1n panoramix pdf-parser pdfid.py photorec picocom powershell procdump pwsh pycdc pyinstaller qemu-arm qemu-system-arm qemu-system-mips qemu-system-x86_64 readelf rg rizin ROPgadget ropper rr rtfobj rtl_sdr rz-diff rz-pm schtasks sdkmanager spctl strace sysctl systemctl tcpdump testdisk tshark tsk_recover uefiextract ueifind unblob unsquashfs upx VBoxManage vmrun vol wasm-decompile wasm-objdump wasm2wat wasm3 wasmtime yara zig zipalign zsteg"
+# <<< GENERATED-TOOLS
+MISS_LIST=""
+for t in $PROBE_TOOLS; do
+  if command -v "$t" >/dev/null 2>&1; then
+    echo "HAVE: $t"
+  else
+    MISS_LIST="$MISS_LIST $t"
+  fi
+done
+[ -n "$MISS_LIST" ] && echo "MISS:$MISS_LIST"
+
+echo "== HINT =="
+echo "已装工具(HAVE)优先使用；未装工具(MISS)按对应技能的「工具准备」章节引导安装，不中断分析流程。"
--- a/vendor-new/rev-skills/.claude/skills/re-analyze/references/rerouting.md
+++ b/vendor-new/rev-skills/.claude/skills/re-analyze/references/rerouting.md
@@ -0,0 +1,115 @@
+# 中途再路由触发表
+
+运行时证据触发的唯一事实源（区别于 triage.md 的入口「目标→路径」决策表）。分析过程中按双轨使用：
+
+- **轨 1（网关完成必查）**：每网关完成后对照 A/B 表检查新证据
+- **轨 2（证据出现即查）**：每产出新证据类型（字符串/节表/行为/加密特征）立即对照 A 表
+- **未命中** → 按 B 表约束行动，禁止自行硬琢磨
+
+**A 表按能力匹配**：证据特征先映射到「需要能力」，再经 `capability-index.md` 反查提供该能力的技能——技能列是索引结果，不是领域名硬编码；`npm test` 校验「能力列标签在注册表内」且「本行技能确实声明了该能力」。
+
+## A 表：证据特征 → 需要能力 → 触发技能
+
+| 证据特征（分析中看到） | 需要能力 | 触发技能（索引反查） |
+|---|---|---|
+| 节表异常（UPX0/.aspack）、熵 >7.0 | `unpack` | [[re-packer-id]] → [[re-anti-analysis]] |
+| 未知加密算法、S-box/常量指纹、加密流量 | `crypto-identification` | [[re-crypto-id]] |
+| 硬编码密钥/口令、内存中的 key | `key-extraction` | [[re-crypto-keys]] |
+| 解密函数已定位、密文可还原 | `crypto-decryption` | [[re-crypto-decrypt]] |
+| 反调试/反 VM 特征（ptrace、CPUID、时间检测） | `evasion-analysis` | [[re-anti-analysis]] / [[re-evasion]] |
+| 动态注册 JNI、so 函数级加密 | `jni-analysis` | [[re-android-native]] |
+| 混淆（CFF/花指令/字符串加密） | `deobfuscation` | [[re-deobfuscate]] |
+| 网络回连/信标/C2 特征 | `network-capture` | [[re-netcap]] → [[re-behavior]] |
+| 持久化/注入/进程树异常 | `malware-behavior` | [[re-behavior]] |
+| 崩溃/段错误/ASAN 报告 | `debugging` | [[re-crash-triage]] |
+| Python 打包特征（PyInstaller/PyArmor） | `bytecode-parser` | [[re-python]] |
+| 加固商特征（Android 加固壳） | `unpack` | [[re-mobile-pack]] |
+| RTTI/异常表（.pdata/.xdata）密集 | `decompilation` | [[re-cpp-abi]] |
+| PDF/Office 宏/钓鱼文档特征 | `document-malware` | [[re-doc-malware]] |
+| 补丁/N-day 对比需求（修复前后/变体） | `binary-diffing` | [[re-variant]] |
+| 文件尾附加/图片异常（隐写怀疑） | `stego-detection` | [[re-stego]] |
+| 白盒加密特征（大查表 + 编码网络） | `crypto-identification` | [[re-whitebox]] |
+| 内核驱动/rootkit 结构 | `kernel-analysis` | [[re-kernel]] |
+| 内存区被改成可执行（W→X / RWX）、无背书区域在执行 | `sample-acquisition` | [[re-sample-acquire]] |
+| 服务端动态注册的组件无对应类文件（内存马特征） | `sample-acquisition` | [[re-sample-acquire]] → [[re-java]] |
+| 整机内存镜像（LiME/崩溃转储） | `memory-forensics` | [[re-mem-forensics]] |
+| 磁盘镜像/未分配空间/分区表异常 | `disk-forensics` | [[re-disk-forensics]] |
+| 越狱检测/tweak（dylib 注入）特征 | `jailbreak-analysis` | [[re-ios-jb]] |
+| Flutter/RN 引擎特征 | `hybrid-app-analysis` | [[re-hybrid-app]] / [[re-flutter]] |
+| Go buildinfo/pclntab 特征 | `lang-runtime-analysis` | [[re-go]] |
+| Rust/Swift/Zig/Nim 产物特征 | `lang-runtime-analysis` | [[re-rust]] / [[re-swift]] / [[re-zig]] / [[re-nim]] |
+| MMIO 外设区 + Thumb 特征（嵌入式裸机固件） | `arch-analysis` | [[re-arm]] |
+| RISC-V 压缩指令/MIPS 延迟槽特征 | `arch-analysis` | [[re-riscv]] / [[re-mips]] |
+| VT-x/SVM 指令（VMXON/VMREAD）或 VMCS 结构 | `hypervisor-analysis` | [[re-hypervisor]] |
+| BPF ELF section（.maps/.BTF/.rel*，kprobe/tracepoint 命名节） | `ebpf-analysis` | [[re-ebpf]] |
+| VxWorks/QNX 特征串（任务表符号/内核对象命名） | `rtos-analysis` | [[re-rtos]] |
+| 进程注册了 pathname 并循环收消息、无内核模块却控制硬件 | `rtos-analysis` | [[re-rtos]]（QNX 资源管理器模型） |
+| 驱动既不是独立进程也不是内核模块（在网络栈进程内加载） | `rtos-analysis` | [[re-rtos]] → [[re-rtos/qnx]] |
+| init/设备对象没有直接 xref、一段规则排列的结构体（链接期注册） | `rtos-analysis` | [[re-rtos/zephyr]] |
+| 独立模块大量 unresolved symbols、同版本系统之间行为不一致 | `rtos-analysis` | [[re-rtos/vxworks]] |
+| dlopen 语义不像 Unix 共享库、设备分派看不到 file_operations | `rtos-analysis` | [[re-rtos/rtems]] |
+| 跨阶段数据结构找不到 producer、runtime 地址与固件地址对不上 | `uefi-analysis` | [[re-uefi/pi-stages]] |
+| handle 数值跨进程比对无效、传送后原值失效、同驻驱动有 IPC 无系统调用 | `kernel-analysis` | [[re-kernel/zircon-kernel]] |
+| init 函数没有调用者、一段指针数组所在 section 名为 set_* | `kernel-analysis` | [[re-kernel/freebsd-kernel]] |
+| 驱动入口为 _init/_fini/_info + modlinkage/dev_ops/cb_ops 骨架 | `kernel-analysis` | [[re-kernel/illumos-kernel]] |
+| 同版本内核每次启动布局都不同、两份二进制逐字节不一致 | `kernel-analysis` | [[re-kernel/openbsd-kernel]] |
+| 模块自己出现/消失却没有加载者、模块加载失败但文件正常 | `kernel-analysis` | [[re-kernel/netbsd-kernel]] |
+| 服务名相同却像连到不同对象、capability 数值被当全局 ID、配额与系统剩余内存矛盾 | `kernel-analysis` | [[re-kernel/genode]] |
+| 驱动进程消失又出现、IPC 里的整数疑似 grant、更新期出现两个相同实例 | `kernel-analysis` | [[re-kernel/minix3]] |
+| 同名路径访问到不同对象、目录内容像多层叠加、出现不依赖内核模块的新文件系统 | `kernel-analysis` | [[re-kernel/plan9]] |
+| PV 设备找不到寄存器窗口、grant ref/event-channel port 被当地址与 IRQ | `hypervisor-analysis` | [[re-hypervisor/xen]] |
+| guest 的 MMIO/BAR 与真实硬件对不上、跨 VM 共享区通不了、越权访问后程序突然停住 | `hypervisor-analysis` | [[re-hypervisor/qnx-hypervisor]] / [[re-hypervisor/jailhouse]] / [[re-hypervisor/acrn]] / [[re-hypervisor/bao]] |
+| 同一 API 在不同样本里形态完全不同（极短函数 + 立即 trap）、地址权限时有时无 | `rtos-analysis` | [[re-rtos/nuttx]] |
+| ISR 里混用 task 版 API、访问权限随运行阶段变化（MPU） | `rtos-analysis` | [[re-rtos/freertos-context]] |
+| 大量「填 request ID → 跳公共 dispatcher」、代码地址落在模块内存区之外 | `rtos-analysis` | [[re-rtos/threadx-modules]] |
+| ISR 只清状态位就返回、没有线程入口却被反复调用的函数 | `rtos-analysis` | [[re-rtos/ecos]] |
+| 高优先级线程不运行且无竞争、采样/队列语义混淆、固定地址的 APEX 服务表 | `rtos-analysis` | [[re-rtos/partitioned-rtos]] |
+| 无 caller 的 runnable、隐式访问读到旧值、服务返回 E_OS_ACCESS | `automotive-analysis` | [[re-automotive/autosar-classic]] |
+| 二进制已安装但进程不存在、进程清单与模型清单对不上 | `automotive-analysis` | [[re-automotive/autosar-adaptive]] |
+| 一个 OS thread 内出现大量"线程切换"（内核调度对不上） | `kernel-analysis` | [[re-kernel/helenos]] |
+| read/write 落到的东西不是文件系统、两侧句柄对不上 | `kernel-analysis` | [[re-kernel/redox]] |
+| 驱动启动时不在、访问某设备后才出现 | `kernel-analysis` | [[re-kernel/haiku]] |
+| 执行地址属于另一个地址空间、无调用者的例程却有行为 | `kernel-analysis` | [[re-kernel/zos]] / [[re-kernel/openvms]] |
+| 对象地址不像 DRAM 指针、存储抽象与 POSIX 不符 | `kernel-analysis` | [[re-kernel/ibmi]] |
+| 找不到 user→syscall→kernel 边界、syscall 没有特权切换 | `kernel-analysis` | [[re-kernel/unikraft-mirageos]] |
+| 中断尾部发生切换、task 就绪不切换、ISR 里调用未立即生效 | `rtos-analysis` | [[re-rtos/ucos-sysbios]] / [[re-rtos/safertos-rtx5]] |
+| 同一地址在不同 task 下可访问性不同、句柄不像指针 | `rtos-analysis` | [[re-rtos/safertos-rtx5]] |
+| 服务调用在任务里合法、在中断里被拒 | `rtos-analysis` | [[re-rtos/tkernel-toppers]] |
+| 消息/信号的对端找不到（疑似跨节点） | `rtos-analysis` | [[re-rtos/ose-oseck]] |
+| 小整数句柄被当地址、网络流量中途消失但功能正常 | `hypervisor-analysis` | [[re-hypervisor/hyperv-vmbus]] |
+| 找不到资源分配的重配置代码、计划切换不立即生效 | `hypervisor-analysis` | [[re-hypervisor/xtratum]] |
+| VM-exit 很少却没有隔离缺失、跨域时间戳对不上 | `hypervisor-analysis` | [[re-hypervisor/questv]] |
+| 找不到动态重配置/管理入口、内核里没有驱动与 I/O 栈 | `hypervisor-analysis` | [[re-hypervisor/lynxsecure]] |
+| 二进制在但进程不存在、服务发现空结果、无 crash 却重启、更新后数据保留或消失 | `automotive-analysis` | [[re-automotive/autosar-adaptive]] |
+| 线性地址下仍有隔离、同一地址权限随任务变、"partition" 一词含义不明 | `rtos-analysis` | [[re-rtos/nucleus]] |
+| 软件定时器回调里出现阻塞等待、任务被唤醒却没有资源 | `rtos-analysis` | [[re-rtos/ucos-sysbios]] |
+| 小整数句柄被当地址、删除句柄时阻塞、回调返回但资源未释放 | `hypervisor-analysis` | [[re-hypervisor/hyperv-vmbus]] |
+| ring 前进却没有通知、event unmask 行为异常、迁移后端口与 domid 变化 | `hypervisor-analysis` | [[re-hypervisor/xen]] |
+| 同一源码在不同构建下 I/O 完全不同、全部任务一起卡死 | `kernel-analysis` | [[re-kernel/unikraft-mirageos]] |
+| 模块带自描述元数据（UUID/端点/资源/依赖/签名）、IPC 呈入口页+位图+失败分支形态 | `kernel-analysis` | [[re-kernel/hic]] |
+| 程序属性导致栈行为相反（栈方向/栈指针偏置）、AMODE/RMODE 不匹配、dump 里控制块对不上 | `kernel-analysis` | [[re-kernel/zos]] |
+| 对象/指针分两套（系统指针 vs 空间指针）、静态数据归属不清、产物压缩态 | `kernel-analysis` | [[re-kernel/ibmi]] |
+| 异常走"处理器链"而非抛出-捕获、共享镜像与预期不符 | `kernel-analysis` | [[re-kernel/openvms]] |
+| 信号号不唯一需次级 id、缓冲区落在别的池、跨 DSP 行为不一致 | `rtos-analysis` | [[re-rtos/ose-oseck]] |
+| 同一源码不同配置产物差异极大、异常去向不固定、构造函数被覆盖 | `rtos-analysis` | [[re-rtos/ecos]] |
+| .NSO/.NPDM 容器结构（Switch 加密分区） | `console-analysis` | [[re-console]] |
+| asar 结构（resources/app.asar + 内部 files 树） | `electron-analysis` | [[re-electron]] |
+| CAP 内 Header 组件魔数（DE CA FF ED，文件整体为 ZIP，Java Card 12 组件） | `bytecode-parser` | [[re-javacard]] |
+| HarmonyOS hap/hsp 包结构、ArkTS .abc 字节码 | `bytecode-parser` | [[re-harmonyos]] |
+
+## B 表：卡住信号 → 换路
+
+| 卡住信号 | 换路 |
+|---|---|
+| 同参数重复 ≥2 次无新证据 | 对照 A 表重查 / 换工具视角（[[analysis-contract]] 调查预算） |
+| 单命令 ≥3 次无进展 | 停下评估，重跑 re-analyze 第二步（任务识别）或换网关 |
+| 分析跨目标累计超 30 次工具调用无结论 | 回退到最近有产出的环节，按 [[analysis-contract]] 复核格式交付部分结论 |
+| 目标行为与静态结论矛盾 | 动态侧 [[re-sandbox]] / [[re-tracing]] 对照 |
+| A 表命中的技能不适用（如目标形态不符） | 查 `capability-index.md` 同一能力下的其他技能（能力相同、形态不同） |
+
+## 使用规则
+
+1. 每产出新证据类型 → 查 A 表，命中即调用对应技能，完成后回到轨 1 继续
+2. 每网关完成 → 查 A+B 表
+3. 未命中任何表项 → 按 B 表约束行动（换思路/回退/交付部分结论）
+4. 新增 A 表行时：先定「需要能力」（注册表标签），再用 `capability-index.md` 反查技能填入——**不要只写领域名技能**（`npm test` 会校验能力与技能声明是否对得上）
--- a/vendor-new/rev-skills/.claude/skills/re-analyze/references/system-fingerprints.md
+++ b/vendor-new/rev-skills/.claude/skills/re-analyze/references/system-fingerprints.md
@@ -0,0 +1,253 @@
+# 系统识别指纹表
+
+**用途**：从证据判断**目标属于哪个系统**。[[cross-system-models]] 解决"看到异常先怀疑什么"，本文件解决它前面的一步——**"我在看的是什么东西"**。
+
+**判据来源**：本文件不引入新断言，判据全部取自本库已核验的技能分支（各分支文末的"工具与验证"节）。
+
+## 判据的两维标注（重要）
+
+**一条判据有"多独特"和"多容易看见"两个互相独立的属性**，混为一谈会直接把结论带偏：
+
+| 维度 | 取值 | 含义 |
+|---|---|---|
+| **特异度** | `独有` | 只有该系统有 |
+| | `高` | 少数系统共有，需配合排除 |
+| | `弱` | 只能收窄到家族 |
+| **可观测性** | `稳定` | 剥离符号后通常仍可见（结构内魔数、容器魔数、必需导出名） |
+| | `视构建` | 取决于是否 strip / 是否保留字符串 / 配置是否随产物 |
+| | `仅运行期` | 只能从运行中的系统、流量或运行时接口获得 |
+
+**标注形如 `独有·稳定`。** 典型误用：把 `独有·视构建` 的判据（如模块名后缀）当成"一定能看到"，于是对一个 strip 过的产物得出"不是该系统"的错误结论——**看不见不等于不存在**。
+
+## ⓪ 先定证据归属（evidence_scope）
+
+**同一个字符串，归属不同的对象，指向完全不同的结论。**
+
+| scope | 含义 | 典型来源 |
+|---|---|---|
+| `container` | 容器本身 | 固件封装、磁盘镜像、升级包 |
+| `executable` | 当前正在分析的执行体 | 主二进制 |
+| `embedded payload` | 容器内的嵌入载荷（**可能属于另一种系统**） | 固件里嵌的 rootfs、MCU blob |
+| `guest` | 虚拟化/分区下的客体 | VM 镜像、分区镜像 |
+| `dependency` | 被链接或依赖的组件 | 静态库、第三方 `.a`、sysroot |
+| `toolchain artifact` | 工具链产物（不是运行时主体） | 编译器 sysroot、示例配置、调试符号 |
+| `documentation` | 文档/注释/示例 | README、示例配置 |
+
+**规则：先判"这条证据属于谁"，再判"它是哪个系统"。**
+
+固件里同时存在 Linux rootfs、一个 MCU blob、一个 guest 镜像与编译期 sysroot 时，找到 `procnto`、ARXML、`seL4_*`、FreeRTOS 特征串中的**任何一个**，都**不能**回答"当前正在逆向的主体是什么系统"——**证据为真、归属错误**，是这类目标上最常见的翻车方式。
+
+**做法**：
+
+```
+1. 列出容器内全部可辨认对象，逐个标 scope
+2. 确定分析主体（用户的目标）属于哪个 scope
+3. 只在【同 scope 内】做指纹比对
+4. 跨 scope 的命中只记为"存在性"，不作为主体身份依据
+```
+
+**指纹表越丰富，这条越重要**：判据多了以后，跨 scope 的假命中会同步变多。
+
+## 一、四层流程
+
+```
+① 载体与格式：我拿到的是什么（模块 / 镜像 / 配置 / 转储 / 流量）
+② 超家族收敛：几条问题把它归到某一族
+③ 家族内指认：按该族的表逐行排除
+④ 易混淆对与负判据：命中易混对时按专项判据；用"看到 X 就不是 Y"收尾
+```
+
+**顺序不能颠倒**：先定 scope、再定格式、再定家族、最后定系统。跳过前几层直接猜系统，会得到一连串"似曾相识但都对不上"的结论。
+
+## 二、超家族：载体与格式
+
+| 载体 | 结论或下一步 |
+|---|---|
+| ELF 且类型为 **ET_REL** | **[弱·稳定]** 仅说明"这是**可重定位 ELF**"（内核模块常用此形态，但不止内核模块）→ 需再命中 `.modinfo` / `__this_module` / `vermagic` 一类符号，才升到"Linux 可加载内核模块" |
+| ELF 可执行，`EI_OSABI` 非 0/3 | 按 §六 的 OSABI 表定系统 |
+| ELF，带 `.note.openbsd.ident` / `.note.netbsd.ident` / `.note.tag`(FreeBSD) | **[独有·稳定]** 对应 BSD → §3.1 |
+| PE32/PE32+，subsystem = EFI 相关 | UEFI 模块 → §3.6；否则 §3.1 Windows |
+| PE，`.sys` 扩展、导出 `DriverEntry`/`GsDriverEntry` | Windows 驱动模型 → §3.1 |
+| Mach-O（KEXT bundle / `.dext`） | macOS 家族 → §3.1 |
+| 无标准容器，含 `0x00ff7eeb` + `"imagefs"` | **[独有·稳定]** QNX IFS 镜像 → §3.2 |
+| 固件结构（FV → FFS → section） | UEFI/PI → §3.6 |
+| XML 配置 + 分区/major frame 词汇 | 分区 hypervisor 或分区 RTOS → §3.4/§3.5 |
+| C 源文件形式的配置（含 `struct config` 一类） | 静态分区 hypervisor → §3.5 |
+| ARXML | AUTOSAR → §3.8 |
+| 大量 EBCDIC 文本、记录式数据集 | 大型机 → §3.7 |
+| 单一镜像，内含初始化表段与成套 `uk_*` 符号 | Unikraft → §3.9 |
+| OCaml 源码 / Lwt 调用 | MirageOS → §3.9 |
+
+## 三、家族内指认
+
+### 3.1 UNIX / Windows 系内核与驱动
+
+| 系统 | 载体与结构 | 判据 |
+|---|---|---|
+| **Linux** | `.ko` = ET_REL；可能带签名尾、livepatch 节、BTF/split BTF | `.modinfo` / `__this_module` / `vermagic` **[独有·稳定]**；`module_init` **[独有·视构建]** |
+| **Android** | 同为 ELF 模块，受 KMI 约束 | ACK 分支串、KMI symbol list、protected symbol **[高·视构建]** |
+| **FreeBSD** | `.ko`（KLD，ELF）；**linker set 注册** | `set_sysinit_set` / `__start_set_*` **[独有·视构建]**（strip 后不可见） |
+| **NetBSD** | `.kmod` | `module_autoload` / `MODCTL_*` **[独有·视构建]** |
+| **OpenBSD** | 内核每次 boot 被**重新随机链接**（KARL） | 用户态 `.note.openbsd.ident` **[独有·稳定]**；link kit / rc 重链接脚本 **[高·视构建]** |
+| **illumos / Solaris** | `.so` 内核模块（DDI/DKI） | `_init`/`_fini`/`_info` + `modlinkage`/`modldrv`/`dev_ops`/`cb_ops` **[独有·稳定]**（必需导出）；`nulldev` 与 `nodev` 并存 **[独有·视构建]** |
+| **macOS** | KEXT（Mach-O，AuxKC 内）/ DEXT（用户态） | `IOKitPersonalities` **[高·视构建]**、`__TEXT_EXEC` 段 **[独有·稳定]**、`Info.plist` **[独有·稳定]**（就绪于 bundle） |
+| **Windows** | `.sys`（PE） | **先分驱动模型**：WDM（`DriverEntry` + `MajorFunction[]` **[独有·稳定]**）、KMDF（指向 `Wdf01000.sys` **[独有·视构建]**）、minifilter（`FltRegisterFilter` **[独有·视构建]**）、NDIS（`Miniport*`/`Ndis*` **[独有·视构建]**） |
+
+### 3.2 capability / 用户态驱动型内核
+
+| 系统 | 判据 | 结构线索 |
+|---|---|---|
+| **seL4** | `seL4_*` / `seL4_Call` **[独有·视构建]** | **capDL `.cdl`** 与 CAmkES ADL 价值高于符号表 |
+| **Fuchsia / Zircon** | `zx_*` / `fidl_*` **[独有·视构建]** | 组件清单、bind rules 字节码、driver host 划分 |
+| **Genode** | `session` / `ROM` / `IO_MEM` / `IO_PORT` / `IRQ` 服务名 **[高·视构建]** | init XML（`<route>` / `<start>`）**[独有·稳定]**（配置就在身边时） |
+| **HelenOS** | `driver_ops_t` / `devman_driver_register` / `ddf_fun_*` **[独有·视构建]** | fibril（用户态协作调度）**仅运行期** |
+| **Redox** | `:SCHEME_NAME` / SQE-CQE / `relibc` / `redox-rt` **[独有·视构建]** | initfs 与驱动目录 **[高·稳定]** |
+| **Haiku** | 模块名以 `driver_v1` / `device_v1` 结尾 **[独有·视构建]**（**符号被剥离后未必可见**） | device_node 树、KDL |
+| **MINIX 3** | 服务 label + endpoint、RS/SEF **[高·仅运行期]** | 用户态服务与 `REQ_*` 消息 |
+| **Plan 9 / 9front** | 9P 消息（`Tversion`/`Tattach`/`Twalk`）**[独有·仅运行期]** | `/srv`、fid、每进程命名空间 |
+| **HIC** | **自描述模块元数据**（UUID/版本/端点/资源/依赖/签名）**[独有·稳定]**；**入口页 IPC 形态** **[独有·仅运行期]** | 同特权级 + MMU 隔离；capability 记账有代际差异 |
+| **QNX Neutrino** | `procnto` / `"imagefs"` / IFS 魔数 `0x00ff7eeb` **[独有·稳定]** | `io-*` / `devb-*` / `devc-*` **[高·视构建]**；`devnp-*.so` **[独有·视构建]** |
+
+### 3.3 RTOS
+
+| 系统 | 判据 | 结构线索 |
+|---|---|---|
+| **FreeRTOS** | `"FreeRTOS"` 串、`pxCurrentTCB`、`pxReadyTasksLists` **[独有·视构建]** | `pcTaskName`、栈填充 `0xa5` **[高·视构建]** |
+| **ThreadX** | `tx_kernel_enter`、`_tx_thread_created_list` **[独有·视构建]** | **对象头魔数**（THRD `0x54485244`、QUEU、SEMA、MUTE、ATIM…）**[独有·稳定]** |
+| **ThreadX Modules** | `txm_*`、`_txm_module_kernel_call_dispatcher` **[独有·视构建]** | **module preamble 必在模块第一个地址** **[独有·稳定]** |
+| **RT-Thread** | `rt_thread_ready_priority_group`、`rt_thread_priority_table` **[独有·视构建]** | `rt_system_scheduler_start` |
+| **Zephyr** | `DEVICE_DT_DEFINE` / `SYS_INIT` **[独有·视构建]** | devicetree + Kconfig **[高·视构建]**；iterable section **[独有·视构建]**；map 里的 `__init_PRE_KERNEL*` 段 |
+| **NuttX** | `syscall.csv` / `drivers_early_initialize` **[独有·视构建]** | FLAT/PROTECTED/KERNEL 三种构建 **[高·仅运行期]**；upper/lower half **[独有·视构建]** |
+| **VxWorks** | `tIdle` / `tRootTask` **[独有·视构建]** | `WIND_TCB` / `td_*` **[独有·视构建]**；`.out`（DKM）/ `.vxe`（RTP）**[独有·稳定]**；VSB/VIP **[独有·稳定]** |
+| **RTEMS** | `CONFIGURE_INIT` / `Device_drivers` **[高·视构建]** | `confdefs.h` 构建期配置、`rtems_driver_address_table` **[独有·视构建]** |
+| **eCos** | `CYG_*`、`cyg_hal_invoke_constructors`、`hal_vsr_table`、`CYG_ISR_CALL_DSR` **[独有·视构建]** | CDL、`mlt_*.ldi`、RedBoot、虚拟向量表 **[独有·视构建]** |
+| **µC/OS（Micrium）** | `OSIntEnter` / `OSIntExit` / `OSSchedLock` **[独有·视构建]** | `OS_TCB`、`OS_TmrTask` |
+| **TI SYS/BIOS** | `ti.sysbios.knl.*`、`Swi_*` / `Hwi_*` / `Task_*` **[独有·视构建]** | Hwi > Swi > Task 分层 **仅运行期** |
+| **SAFERTOS** | `xMPUSetTaskRegions` 一类 **[高·视构建]**；与 FreeRTOS **同源但非同一份二进制** | ESM 的 ACP / OACP / 间接对象 ID **[独有·视构建]** |
+| **CMSIS-RTX5** | `osRtxError*` / `RTX_Config.h` / `OS_SAFETY_FEATURES` **[独有·视构建]** | `osThreadZone` / 安全等级 / 线程看门狗 **[独有·视构建]** |
+| **T-Kernel** | `tk_def_dev` / `tk_rea_dev` / `tk_wai_dev` **[独有·视构建]** | 三种执行上下文 **仅运行期** |
+| **TOPPERS** | `act_tsk` / `sta_cyc` **[高·视构建]** | **先判家族**（ASP3 / HRP3 / FMP3 / HRMP3）**[高·视构建]** |
+| **OSE / OSEck** | `hunt` / `attach` / `send` / `receive` / `SIGSELECT` **[独有·视构建]** | 信号队列附属于进程 **仅运行期** |
+| **Nucleus** | `NU_Create_*` / `NU_Allocate_Partition` **[独有·视构建]** | `NU_PARTITION_POOL`（**别与空间隔离域混**） |
+
+### 3.4 分区 / 安全 RTOS
+
+| 系统 | 判据 | 结构线索 |
+|---|---|---|
+| **INTEGRITY / INTEGRITY-178** | ARINC 653 APEX 服务名 **[高·视构建]** | 空间/时间/资源三域；静态启动表 **[独有·视构建]** |
+| **PikeOS** | **链接在固定地址的 APEX 服务表** **[独有·稳定]** | 三层：分区调度器 → system thread → guest 调度器 **仅运行期** |
+| **ARINC 653 / VxWorks 653** | `major frame` / `partition window` / `SET_PARTITION_MODE` **[独有·视构建]** | 分区模式、采样端口 vs 队列端口 **仅运行期** |
+| **Deos** | 三类调度模型并存（ARINC 653 + RMS + POSIX）**[独有·视构建]** | 跨核对齐时间窗 + 每核 scheduler、slack、SafeMC **[独有·视构建]** |
+
+### 3.5 Hypervisor
+
+**宿主侧厂商串**（CPUID 叶 0x40000000）：`KVMKVMKVM`、`Microsoft Hv`、`VMwareVMware`、`XenVMMXenVMM` —— **[独有·仅运行期]**。
+
+| 系统 | 判据 | 结构线索 |
+|---|---|---|
+| **Xen** | XenStore 路径、`backend-id`、`ring-ref`/`event-channel` 键 **[独有·仅运行期]**；`/dev/xen/evtchn` **[独有·稳定]** | grant table / shared ring / event channel；`shared_info` 位掩码 |
+| **Hyper-V / VMBus** | VMBus 总线、`netvsc` / `storvsc` **[独有·仅运行期]** | VSC/VSP、GPADL、SR-IOV 数据面切换 |
+| **ACRN** | `IVSHMEM_ENABLED` / `IVSHMEM_REGION` / `acrn-dm`；`dm:/` 与 `hv:/` 前缀 **[独有·视构建]** | Service VM / pre-launched / post-launched 三层 |
+| **Jailhouse** | `.cell` 配置 **[独有·稳定]**；控制台串 `Parking CPU n (Cell: ...)` **[独有·仅运行期]** | cell 描述符（内存区标志、PCI/IRQ 归属） |
+| **Bao** | C 源配置 `struct config` / `shmemlist` / `vmlist` / `shmem_id` **[独有·视构建]** | CPU/内存/中断独占；vCPU 与 pCPU 1:1 |
+| **XtratuM** | XM_CF XML（`<Partition>` / `<CyclicPlanTable>` / `<PortTable>`）**[独有·视构建]** | Plan 0 初始化 / Plan 1 维护；IPVI |
+| **QNX Hypervisor** | shmem **工厂页**字段（`name`/`size`/`shmem`/`vector`/`status`）**[独有·视构建]** | 三层地址；vdev |
+| **LynxSecure** | 判据薄：**内核里没有驱动与 I/O 栈**、无管理控制台入口 **[独有·仅运行期]** | 不可变 boot 分区；内核功能仅限三项职责 |
+| **Quest-V** | 判据薄：**每 sandbox 一个 monitor**、VM-exit 极少、无全局时钟 **[独有·仅运行期]** | monitor 只在引导/故障/影子页表/建通道时介入 |
+
+> **判据薄的两个系统**（LynxSecure / Quest-V）不以字符串定案——定案方式是**结构与行为**（见各自分支）。
+
+### 3.6 固件与引导
+
+| 系统 | 判据 | 结构线索 |
+|---|---|---|
+| **UEFI / PI** | PE32/PE32+ 且 subsystem 为 EFI 类；GUID 密集 **[独有·稳定]** | **FV → FFS file → section → PE32/TE**；HOB；`MODULE_TYPE`；PPI（PEI）vs Protocol（DXE）vs Runtime Services |
+
+### 3.7 主机 / 大型机
+
+| 系统 | 判据 | 结构线索 |
+|---|---|---|
+| **z/OS** | EBCDIC 文本 + 记录式数据集 + JCL **[高·稳定]** | load module / program object；TCB/SRB；AMODE/RMODE；XPLINK 与否 |
+| **IBM i** | `库/对象` 限定名、`*PGM` / `*SRVPGM` / `*MODULE` 对象类型 **[高·仅运行期]** | 单一存储层；MI/TIMI/SLIC 层次；activation group |
+| **OpenVMS** | **`ELFOSABI_OPENVMS` = 13** **[独有·稳定]**；DCL 命令文件 **[高·稳定]** | `.EXE` 镜像、`SYS$SHARE:`、逻辑名、AST / `$QIO`、RMS、描述符调用标准 |
+
+### 3.8 车载软件
+
+| 系统 | 判据 | 结构线索 |
+|---|---|---|
+| **AUTOSAR Classic** | ARXML + `Rte_*` 接口 **[独有·稳定]** | Runnable / RTEEvent / OS Task 映射；`E_OS_ACCESS`；BSW |
+| **AUTOSAR Adaptive** | 三类 Manifest（Execution / Service Instance / Machine）**[独有·稳定]** | `ara::com`、Function Group State / Machine State、`Checkpoint`（PHM）、UCM 与 Persistency |
+
+### 3.9 unikernel
+
+| 系统 | 判据 | 结构线索 |
+|---|---|---|
+| **Unikraft** | `uk_*` 符号 + `uk_syscall_e_*` / `uk_syscall_r_*` 成对出现 **[独有·视构建]** | 初始化表段（构造/早期/平台/库/rootfs/系统/晚期）；Kconfig |
+| **MirageOS** | OCaml 源码 + Lwt 调用 **[独有·稳定]** | 单一静态 ELF；设备接线来自构建期配置 |
+
+## 四、易混淆对
+
+| 容易混 | 分开的判据 |
+|---|---|
+| FreeRTOS / ThreadX / µC/OS / RT-Thread | 看对象头**魔数**（ThreadX 独有，且 strip 不掉）→ 再看唯一符号 |
+| Zephyr / NuttX | 都有 Kconfig 风格构建；**Zephyr 有 devicetree + iterable section**；**NuttX 有 `syscall.csv` + upper/lower half** |
+| VxWorks / QNX | `.out`/`.vxe` + `tIdle` vs **IFS 魔数 + `procnto` + `devnp-*.so`** |
+| FreeBSD / NetBSD / OpenBSD | **linker set `set_*`** vs **`.kmod` + autoload** vs **KARL 重链接 + `.note.openbsd.ident`** |
+| illumos / Linux | illumos 有 `_init`/`modlinkage`/`dev_ops`；**没有** `module_init`/`file_operations`；`nulldev` 与 `nodev` 是两个占位 |
+| seL4 / Fuchsia / Genode | `seL4_*` + capDL vs `zx_*` + bind rules vs `session` + init XML |
+| Jailhouse / Bao / XtratuM | `.cell` vs **C 源 `struct config`** vs **XM_CF XML** |
+| ACRN / Xen | ACRN 有 Service VM 三层与 `dm:/` `hv:/` 前缀；Xen 走 XenStore 路径 + grant/event |
+| QNX Neutrino / QNX Hypervisor | 前者是 resource manager 生态；后者有 `qvm` 配置与 shmem **工厂页** |
+| MINIX 3 / Plan 9 / Redox | RS + endpoint vs 9P + `/srv` vs scheme + SQE/CQE |
+| Haiku / BeOS | Haiku 模块名以 `driver_v1`/`device_v1` 结尾；**调试接口与文件系统 API 与 BeOS 不兼容** |
+| HIC / Fuchsia | HIC 有**自描述模块元数据**与**入口页 IPC 形态**；Fuchsia 有 driver host 与 bind rules |
+| z/OS / IBM i / OpenVMS | EBCDIC + 数据集 + JCL vs `库/对象` vs **`ELFOSABI=13`** + DCL |
+| INTEGRITY / PikeOS / Deos / ARINC 653 | 都讲分区；**PikeOS 的 APEX 服务表链接在固定地址**、**Deos 三类调度模型并存**可作区分 |
+| LynxSecure / Quest-V | 都"没有中央调度器"；前者是**不可变静态分区**，后者是**每 sandbox 一个 monitor** |
+
+## 五、负判据（看到 X 就不是 Y）
+
+| 看到 | 可以直接排除 |
+|---|---|
+| `set_sysinit_set` / `__start_set_*` | Linux（那是 FreeBSD 的 linker set） |
+| `_init` + `modlinkage` + `dev_ops` | Linux、FreeBSD（那是 illumos/Solaris 的 DDI/DKI 骨架） |
+| `0x00ff7eeb` + `"imagefs"` | 任何 Linux/BSD |
+| `procnto` / `devnp-*.so` | 任何非 QNX 系统 |
+| ARXML / `Rte_*` | 通用 RTOS 与桌面 OS |
+| 大规模 EBCDIC 记录 | 任何 Unix 系 |
+| `.cell` | Xen / ACRN / Bao / XtratuM |
+| `struct config` + `shmem_id` | 除 Bao 外的 hypervisor |
+| ThreadX 对象头魔数 | FreeRTOS / µC/OS / RT-Thread |
+| `ELFOSABI` = 9 / 2 / 12 / 13 | 分别是 FreeBSD / NetBSD / OpenBSD / OpenVMS，**不要按"BSD 都差不多"处理** |
+
+## 六、`EI_OSABI` 取值参照
+
+NONE=0、HPUX=1、**NETBSD=2**、LINUX=3、HURD=4、86OPEN=5、**SOLARIS=6**、AIX=7、IRIX=8、**FREEBSD=9**、TRU64=10、MODESTO=11、**OPENBSD=12**、**OPENVMS=13**、NSK=14、ARM=97、STANDALONE=255。
+
+- **note 段与 OSABI 是两套独立标识**：BSD 系的 note 更常见（见 §3.1），OpenVMS 走 OSABI=13
+- 注：2000 年曾有 FREEBSD=4 / NETBSD=5 / OPENBSD=6 的提案，**与现行值不同**——本表按现行值
+- OSABI 为 0（NONE）是常态，**不能反推"不是某个系统"**
+
+## 七、指认流程（一页版）
+
+```
+0. 证据归属：容器内有哪些对象？各自 scope 是什么？主体是哪一个？
+1. 载体与格式：PE / ELF(ET_REL?) / Mach-O / 无容器镜像 / 配置 / 转储 / 流量
+2. ELF：先读 EI_OSABI 与 note 段 → 常常一步定系统
+3. 无容器镜像：找魔数与签名串（IFS、固件卷、RTOS 特征串）
+4. 有配置：配置格式本身就是强判据（.cell / XM_CF / ARXML / manifests / Kconfig+devicetree）
+5. 符号与命名：逐行排除；命中易混对走 §四
+6. 仍不定：
+   ├─ 看"缺什么"：没有驱动与 I/O 栈？没有中央调度器？
+   └─ 看运行期可见面：系统信息接口、调试器命令、调试接口类型
+7. 定案后 → [[cross-system-models]] 查该系统的"正常异常"，再按 [[rerouting]] A 表进对应分支
+```
+
+## 八、使用注意
+
+- **先定 scope 再定系统**：跨 scope 的命中只记"存在性"，不作主体身份依据（§⓪）
+- **两维要分开看**：`独有·视构建` 的判据**看不见不等于不存在**——strip 过的产物上，缺判据不构成反证
+- **`弱` 级判据必须组合**：如 ET_REL 只能收到"可重定位 ELF"，不能直接定 Linux
+- **易混淆对的裁断优先于单条特征**：命中 §四 时按该行专项判据走
+- **判不出不要硬判**：家族定下、系统未定，也好过猜一个系统然后整条分析链跑偏；此时按家族级分支（如 [[re-rtos]] 主文档）先推进
+- 新增系统分支时，**同步往本表加一行**（判据须带两维标注与 scope 说明）
--- a/vendor-new/rev-skills/.claude/skills/re-analyze/references/triage.md
+++ b/vendor-new/rev-skills/.claude/skills/re-analyze/references/triage.md
@@ -0,0 +1,66 @@
+# 任务识别决策表
+
+入口根据「分析目标 + 输入文件」选择编排路径。目标命中多个大类时按依赖顺序串联。
+
+**前置：认目标属于哪个系统**（[[system-fingerprints]]）。目标不是常见形态（非 PE/ELF，或 ELF 但 OSABI/note 段指向非主流系统，或根本无容器）时，先走识别流程再查本表；**家族已定、系统未定**时按家族级分支推进，不要猜一个系统再按它编排。
+
+**路由按能力匹配**（能力层，见 [[capabilities]] 与 `capability-index.md`）：先由目标/输入特征确定「需要能力」，再查能力索引取提供该能力的技能——技能名只是索引结果，不按领域名硬编码。改技能的能力声明后索引会重生成，路由随之更新（`npm test` 校验路由与声明一致）。
+
+## 第 0 步：授权上下文（authorization_context）
+
+路由前先判定目标归属，存入会话变量 `RE_AUTH`（影响动态执行、补丁/绕过、密钥提取、脱壳产物扩散）：
+
+| 值 | 含义 |
+|---|---|
+| `owned` | 自有/自研软件 |
+| `ctf` | CTF/研究环境（题目/沙箱样本） |
+| `research` | 获得授权的测试与审计 |
+| `unknown` | 无法确认（默认向用户询问，用户不明确即保持 unknown） |
+
+**影响**：
+- 动态执行（运行样本/断点/内存读写）：`unknown` 与第三方商业软件 → 默认沙箱（[[re-sandbox]]），仅限授权内行为
+- 补丁/绕过流程（re-cracking 域：license/patching/keygen/drm）：仅 `owned`/`ctf`/`research` 可进入；`unknown` → 只做静态授权逻辑分析，先询问归属（与 [[re-cracking]] 授权边界一致）
+- 密钥提取/解密、脱壳产物扩散：同样受 `RE_AUTH` 约束
+
+## 目标 → 编排路径
+
+| 目标（用户描述） | 需要能力 | 编排路径（按顺序） |
+|---|---|---|
+| 判定恶意行为 / 会不会回连 | `malware-behavior`、`network-capture` | re-malware 网关 → re-sandbox → re-behavior → re-protocol（re-netcap / re-proto-rev / re-crypto-*）→ re-ioc |
+| 只有现象、没有样本（不落盘 / 内存驻留 / 寄生在别的进程） | `sample-acquisition`、`malware-behavior` | re-sample-acquire → re-triage → re-fileless / re-malware → re-ioc |
+| 勒索加密 / 文件被加密 / 勒索信 | `malware-behavior`、`crypto-identification`、`crypto-decryption` | re-malware → re-sandbox → re-ransomware → re-crypto-id / re-crypto-decrypt → re-ioc |
+| 无文件样本 / PowerShell 链 / 内存执行 | `malware-behavior`、`deobfuscation` | re-malware → re-fileless → re-script-deob → re-behavior → re-ioc |
+| 样本带壳 / 脱壳 | `unpack` | re-anti-analysis → re-packer-id → re-unpack-simple / re-unpack-advanced → 验证 |
+| 破解 / 授权绕过 / 注册码 | `license-analysis`、`binary-patching` | re-cracking →（若带壳）re-anti-analysis → re-license → re-patching / re-keygen |
+| 漏洞挖掘 / 崩溃分析 | `fuzzing`、`debugging` | re-vuln → re-fuzzing → re-crash-triage →（定位）re-binary-core |
+| 分析固件 / IoT 设备 | `firmware-extraction`、`emulation`、`hardware-interface` | re-firmware → re-fw-extract → re-fw-rootfs → re-fw-emulate →（UEFI/BIOS → re-uefi）→（RTOS → re-rtos）→（ARM → re-arm；MIPS → re-mips；RISC-V → re-riscv）→（TEE → re-tee）→（芯片/PCB → re-hw-chip）→（JTAG/UART → re-hardware-io）→（若见通信）re-protocol |
+| 分析网络流量 / 未知协议 | `network-capture`、`protocol-recovery`、`crypto-identification` | re-protocol → re-netcap → re-proto-rev → re-crypto-id / re-crypto-keys / re-crypto-decrypt |
+| 加密流量（TLS）分析 | `tls-analysis`、`crypto-identification` | re-protocol → re-tls → re-crypto-keys |
+| 射频 / 无线信号 | `rf-analysis`、`sdr-analysis`、`protocol-recovery` | re-protocol → re-sdr →（协议还原）re-proto-rev / re-iot-proto |
+| 移动 App 分析 | `dex-parser`、`jni-analysis`、`frida-instrumentation` | re-mobile → re-apk / re-ios → re-frida →（Flutter/RN → re-hybrid-app / re-flutter；鸿蒙 hap → re-harmonyos；脚本生成 → re-frida-script-author）→（含原生库 → re-android-native）→（加密体系审计 → re-android-crypto） |
+| iOS 越狱环境 / tweak 分析 | `jailbreak-analysis` | re-mobile → re-ios-jb →（动态插桩）re-frida |
+| 一般软件逆向 / 看逻辑 | `decompilation`、`elf-parser` | re-binary-core → re-triage → re-format-pe / re-format-elf / re-format-macho → re-ghidra / re-ida / re-radare2 → 按需动态 |
+| 架构相关目标（ARM/MIPS/RISC-V 裸机） | `arch-analysis` | re-binary-core → re-arm / re-mips / re-riscv →（若 RTOS）re-rtos |
+| 语言产物（Go/Rust/Swift/Zig/Nim/函数式） | `lang-runtime-analysis` | re-binary-core → re-go / re-rust / re-swift / re-zig / re-nim / re-fp-runtime |
+| 游戏逆向 / 主机与复古平台 | `game-analysis`、`console-analysis` | re-game（底座 re-binary-core）→（现代主机/复古平台 → re-console） |
+| shellcode / 位置无关载荷 | `shellcode-analysis`、`emulation` | re-binary-core → re-triage → re-shellcode → re-emulation |
+| eBPF / 内核跟踪程序 | `ebpf-analysis` | re-binary-core → re-ebpf →（内核侧）re-kernel |
+| hypervisor / 虚拟化目标 | `hypervisor-analysis` | re-binary-core → re-hypervisor →（内核底座）re-kernel |
+| 内核驱动 / rootkit | `kernel-analysis` | re-binary-core → re-kernel →（调试）re-windbg / re-gdb |
+| CTF 赛题 | `constraint-solving`、`symbolic-execution`、`exploit-development` | re-ctf → 题型识别 → re-angr / re-z3 / re-pwn / re-deobfuscate →（底座）re-binary-core |
+| .NET/Java/脚本样本 | `bytecode-parser`、`deobfuscation` | re-managed → re-dotnet / re-java / re-script-deob →（Java Card/SIM → re-javacard）→（恶意场景）re-malware |
+| Electron 桌面应用 | `electron-analysis` | re-managed → re-electron →（asar 内 JS 混淆）re-script-deob |
+| 智能合约 / EVM 字节码 | `blockchain-analysis` | re-managed → re-blockchain →（漏洞利用）re-vuln |
+| AI 模型 / 权重提取 / 模型水印 | `ai-model-analysis` | re-managed → **re-ai-triage 分流**：模型文件（.onnx/.pt/.safetensors 等）→ re-ai-model；仅 API（行为层）→ re-ai-attack；恶意行为（投毒/后门）→ re-malware |
+| macOS 原生应用 | `macho-parser` | re-binary-core → re-format-macho → re-macos |
+| 内存取证 / 威胁情报 | `memory-forensics`、`threat-intel` | re-forensics → re-mem-forensics → re-ti →（衔接）re-ioc |
+| 磁盘 / 镜像取证 | `disk-forensics` | re-forensics → re-disk-forensics →（时间线/情报）re-ti |
+| 移动设备取证 | `mobile-forensics` | re-forensics → re-mobile-forensics → re-ti |
+| 二进制变体 / 补丁对比 | `binary-diffing` | re-binary-core → re-variant |
+
+## 复合任务示例
+
+- "脱壳 → 静态 → 动态 → C2 协议 → 报告"：re-anti-analysis → re-binary-core → re-malware(re-sandbox) → re-protocol → re-ioc
+- ".NET 样本 → 恶意判定 → 内存取证"：re-managed(re-dotnet) →（恶意场景）re-malware → re-forensics(re-mem-forensics → re-ti) → re-ioc
+- "崩溃样本 → 漏洞根因"：re-vuln（re-fuzzing 复现 → re-crash-triage 定位）→（定位）re-binary-core
+- 每个环节完成后检查是否有新证据改变后续路径（如动态分析发现加壳 → 回退 re-anti-analysis）。中途再路由统一按 [[rerouting]] 双轨执行（证据触发 / 网关完成必查）。