5.3 KiB
5.3 KiB
name, type, description, capabilities
| name | type | description | capabilities | |||||
|---|---|---|---|---|---|---|---|---|
| re-firmware | gateway | 固件/嵌入式/硬件分析网关。编排：提取 → rootfs → 仿真 → 硬件接口。 子技能：re-fw-extract re-fw-rootfs re-fw-emulate re-hardware-io re-automotive re-uefi re-rtos re-tee。 触发词：固件分析、固件、IoT、解包固件、rootfs、仿真固件、firmware analysis。 |
|
固件 / 嵌入式 / 硬件分析
完整工作流
- 初勘：re-triage（能力：
triage） —— file/哈希/熵确认固件类型、架构与字节序（未走 re-analyze 入口则先补做，读取RE_*会话变量） - 提取：re-fw-extract（能力：
firmware-extraction） —— binwalk/unblob 自动解包，magic 手工扫描，字节序判断 - rootfs：re-fw-rootfs（能力：
firmware-extraction） —— 挂载/解包文件系统，启动脚本定位入口，配置/密钥/硬编码口令挖掘 - 仿真：re-fw-emulate（能力：
emulation） —— 需要运行时用 QEMU 用户态优先（最轻方案，见 re-analyze/platform-tips），全系统按需 - 硬件接口：re-hardware-io（能力：
hardware-interface） —— 需实物板子时（JTAG/UART/flash 读取）；有固件文件先走 2-4，硬件是最后手段 - 通信：提取/运行中发现固件通信、回连、自定义协议 → re-protocol（能力：
network-capture、protocol-recovery、crypto-identification、crypto-decryption、key-extraction、tls-analysis；netcap / proto-rev / crypto-*） - 产出：结论 / 报告（按
RE_REPORT），哈希与证据存档（见 re-triage（能力：triage））
每步结果存档（证据路径 + sha256，见 re-triage（能力：triage）），供报告引用；发现恶意样本/后门随时转 re-malware（能力：malware-behavior、document-malware、evasion-analysis、key-extraction、threat-intel）。
何时用哪个原子技能（选择树）
- 有固件文件（.bin / .img / 升级包）→ re-fw-extract（能力：
firmware-extraction） 解包 - 已有 rootfs / 解包产物 → re-fw-rootfs（能力：
firmware-extraction） 分析文件系统 - 需要运行固件观察行为 → re-fw-emulate（能力：
emulation；先确认架构，见 re-triage（能力：triage）） - 有实物板子 / 需要硬件提取 → re-hardware-io（能力：
hardware-interface） - 汽车 ECU / CAN 总线 / OBD-UDS 诊断 → re-automotive（能力：
automotive-analysis） - 见通信（固件回连 / 自定义协议 / 加密通信）→ re-protocol（能力：
network-capture、protocol-recovery、crypto-identification、crypto-decryption、key-extraction、tls-analysis） - 目标是 UEFI 固件（BIOS 更新包/DXE 驱动/bootkit）→ re-uefi（能力：
uefi-analysis；UEFITool 解析 + OVMF 仿真）
跨域联合
- 固件通信协议：re-firmware → re-protocol（netcap / proto-rev / crypto-* 识别与重建固件通信）
- 固件内恶意样本/后门：re-firmware → re-malware（沙箱行为分析见 re-sandbox）
- 固件内 ELF 深度静态分析：→ re-binary-core（re-format-elf / re-ghidra）
- 仿真动态分析默认沙箱 + 网络隔离（re-analyze/platform-tips 最高原则）
- 本网关被 re-analyze 的 triage.md「分析固件 / IoT 设备」路径调用（re-firmware → re-fw-extract → re-fw-rootfs → re-fw-emulate → 若见通信 re-protocol）
常见坑与陷阱
- 拿到固件跳过初勘直接 binwalk → 架构/字节序未知，解出的程序无法仿真 —— 先 re-triage 确认（大端 ARM/MIPS 常见）
- 自动解包失败就放弃 → 厂商自定义头/加密层最常见 —— 转 re-fw-extract 手工 magic 扫描 + dd 按偏移切分
- 一上来就要实物板子 → 成本高、有损坏风险 —— 有固件文件先走 提取→rootfs→仿真，re-hardware-io 是最后手段
- 仿真不隔离网络就跑固件 → 固件真实回连外网 —— 默认沙箱 + 网络隔离（re-analyze/platform-tips 最高原则），通信分析转 re-protocol
- rootfs 分析不看启动脚本 → 面对几十个二进制无从下手 —— 先 re-fw-rootfs 读 rcS / inittab / init.d 定位程序入口
- 启动链逐层校验（BootROM→FDL→SPL→U-Boot→system）：现象——patch 掉一层校验刷机仍失败，后面还卡在别的验证；原因——移动 SoC（Unisoc/展锐等）刷机链每层独立验签：BootROM→FDL1→FDL2→SPL Loader→U-Boot/LK→system，SPL 对 sml/trustos/uboot 做 RSA-2048 校验（DHTB+SIMGHDR 格式），失败进死循环；对策——沿整条链逐层追：①格式特征转常量：文件头 ASCII（如
DHTB）按 32 位小端转整数（1112819780），在上一层反编译中搜该常量定位校验入口；②失败陷阱=死循环（校验失败 branch 到 loop），patch 失败分支改 NOP/调整分支让它继续走；③FDL2 加载基址从 spd_dump 命令行第二个 FDL 地址拿（IDA/Ghidra 加载基址用这个，xref 才对得上）；④字符串搜索找"按分区名分发刷写逻辑"的入口；⑤硬件固化方案（RP2350 作 USB Host 自动重放握手注入）只做自动化，真正关键在逆向与魔改加载链