Skills-SI市场
skills-si.com
提交技能
/
界面已本地化；技能介绍与说明文档按所选语言由 AI 自动翻译，代码、命令、路径和专业术语保留原文，以原作者文档为准。
探索技能
效率与协作 · SKILL.md

re-fw-extract

re-fw-extract

【效率与协作】固件提取与解包：binwalk/unblob、magic 扫描、字节序。 触发词：固件、binwalk、解包固件、firmware、IoT、MCU、8051、AVR、PIC、MSP430、Intel HEX、.hex

独立 GitHub 快照 · 自动分类 · 以原作者文档为准

Ddslsdzc / rev-skillsApache-2.0

技能说明

GitHub

name: re-fw-extract description: > 固件提取与解包：binwalk/unblob、magic 扫描、字节序。 触发词：固件、binwalk、解包固件、firmware、IoT、MCU、8051、AVR、PIC、MSP430、Intel HEX、.hex capabilities: [firmware-extraction]

固件提取与解包

何时使用 / 何时不用

  • 用：拿到固件文件（.bin / .img / 升级包 / IoT 镜像）需要解开看内容
  • 用：需要判断固件打包方式、架构与字节序
  • 不用：已是文件系统镜像 / rootfs（直接走 [[re-fw-rootfs]]）
  • 不用：需要运行固件观察行为（走 [[re-fw-emulate]]）
  • 不用：需实物板子硬件提取（走 [[re-hardware-io]]）

工具准备

所有工具先验证再使用。解包与 magic 扫描是纯静态分析，可免沙箱（[[re-analyze/platform-tips]] 最高原则）；解出产物要运行时转 [[re-fw-emulate]]。

binwalk —— 自动解包主力

binwalk 有两条并存的产品线，装前先分辨：v3（Rust 重写）是 upstream 当前主线，v2（原 Python 实现）属 legacy，两者的参数集合与模块支持不同。

  • v3（当前主线）：按官方 README 的渠道安装——Docker 镜像 / cargo install binwalk / 源码构建。upstream 已不再把 pip 当作安装入口
  • v2（legacy）：PyPI 的 binwalk 包停在 2.1.0（2015-01），各发行版仓库包同属 2.x 线（Debian trixie 2.4.3、bookworm 2.3.4）
    • Linux: apt install binwalk（Debian/Ubuntu）/ dnf install binwalk / pacman -S binwalk
    • pip: pip install binwalk
    • macOS: brew install binwalk
    • Windows/WSL: Windows 本机无官方包，用 WSL 内 Linux 版
  • 验证: binwalk --version——使用前先确认 major。本技能的命令示例（-e / -M / -E）在 v2 与 v3 均保留；需要 v3 的其它参数时按实际版本查 binwalk --help

unblob —— 更准的自动解包（推荐主力）

  • 跨平台: pip install unblob（依赖较多，建议 venv: python3 -m venv venv && venv/bin/pip install unblob）
  • 各发行版基本无官方包，用 pip
  • 验证: unblob --version

dd —— 按偏移切分

  • Linux/macOS: coreutils 自带（macOS 自带 /usr/bin/dd）
  • Windows/WSL: WSL 内 Linux 版；Windows 本机用 Git Bash 自带 dd 或 WSL
  • 验证: dd --version

hexdump —— 十六进制查看与手工 magic 扫描

  • Linux: apt install bsdmainutils（Debian/Ubuntu）/ dnf install util-linux（Fedora/RHEL，含 hexdump）
  • macOS: 自带 /usr/bin/hexdump
  • Windows/WSL: WSL 内 Linux 版
  • 验证: hexdump -C /dev/null（无报错即可用；macOS 版无 --version）

sasquatch —— 老式/厂商魔改 squashfs 解包

  • Linux: 源码编译（git clone https://github.com/devttys0/sasquatch，需 apt install zlib1g-dev liblzma-dev build-essential 后 make）
  • macOS: 同上源码编译（需 Xcode Command Line Tools）
  • Windows/WSL: WSL 内编译
  • 验证: sasquatch -h 输出用法（编译产物在仓库子目录，需加入 PATH）

操作步骤

按顺序执行，每步记下结果。

  1. 自动解包（unblob 优先，binwalk 兜底）：

    unblob firmware.bin                      # 更准，自动识别 50+ 容器格式并递归解包
# 或 binwalk：
binwalk firmware.bin                     # 先列出签名与偏移
binwalk -Me firmware.bin                 # -M 递归 -e 提取

    产物：firmware.bin/（unblob）或 _firmware.bin.extracted/（binwalk）目录。解出的文件系统转 [[re-fw-rootfs]]，ELF 转 [[re-binary-core]]。

  2. magic 手工扫描（自动解包不全时）：

    hexdump -C firmware.bin | head -40
# 或按 binwalk 报告的偏移核对：
dd if=firmware.bin bs=1 skip=<偏移> count=16 | hexdump -C

    常见魔数：JPEG FF D8 FF、gzip 1F 8B、squashfs hsqs、cramfs 45 3D CD 28（小端，大端反序）、U-Boot 27 05 19 56、jffs2 85 19、ELF 7F 45 4C 46。识别出一个就按该格式处理。

  3. 字节序判断：

    file firmware.bin                        # 输出含 LSB/MSB 提示
readelf -h <解出的ELF>                    # Machine 字段 + Data 字段（大小端）
strings firmware.bin | head               # 可读串确认字节序

    大端 ARM/MIPS 固件常见：大端时魔数与字符串按大端编码（如 hsqs 反序出现）；确认后整个流程按该字节序进行。

  4. 嵌套容器逐层解：

    • unblob / binwalk -Me 会自动递归，但嵌套（tar 里再 zip、自定义头包着 gzip）常中途断
    • 逐层手动：先解外层 → file 确认内层类型 → 用对应工具（tar/gzip 系统自带；squashfs 用 sasquatch；其他用 [[re-fw-rootfs]] 工具准备的 7z/unsquashfs）再解，直到出现文件系统或 ELF
    • 结束标记后的附加数据：图片（PNG IEND、JPEG FFD9）等格式的结束标记之后常附加容器/压缩流（解析器读到结束标记即停，附加数据对正常查看不可见）——file 会把整文件报成图片。定结束标记位置不能靠裸字节 first/last 搜索（IEND 字样可出现在 tEXt chunk 载荷内、FF D9 可出现在 JPEG 的 APP/COM 段内，首个/末个命中都可能是假标记）：PNG 从 8 字节签名起按 Length/Type/Data/CRC 遍历到结构合法且长度为 0 的 IEND，JPEG 从 SOI 起按 marker/segment 解析、SOS 后按 FF00 stuffing 与 RSTn 处理，取语法位置成立的 EOI；用解析出的真实结尾偏移去切附加数据（裸搜结果只作候选）
    • zip 缺签名也能修复：附加的 zip 可能缺本地文件头开头的 PK\x03\x04（4 字节被剥）——用字段自洽验证：补上签名后 version（常见 20/45）、mod date（年 1980+）、compressed/uncompressed size（与 EOCD/中央目录条目一致）全部合理，且 EOCD 在尾部完好 → 补 PK\x03\x04 前缀即完整可解（unzip 报 "missing 4 bytes" 或 zipfile OSError: Invalid argument 是典型征兆）
    • 套娃模式自动化：同一手法重复出现（如每层都是"图片+尾部 zip 含下一层"）时写循环自动剥——提取尾部 → 修复 → 解压 → 定位下一层 → 重复，直到无附加数据；中间产物每层命名保留（可回滚）

  5. 自动失败时手工切分（dd 按偏移）：

    binwalk firmware.bin                     # 找内嵌文件偏移
dd if=firmware.bin of=part1.bin bs=1 skip=<偏移1> count=<长度1>
dd if=firmware.bin of=part2.bin bs=1 skip=<偏移2>
file part*.bin                           # 每块验证

    厂商自定义头最常见：跳过头部 N 字节后才是标准格式（先 hexdump 目测头长度再切）。

MCU 镜像分析（8051 / AVR / PIC / MSP430）

何时进入本节

  • 前置：已走完步骤 1-5（自动解包、magic 扫描、字节序判断、嵌套解包、dd 切分），确认镜像里没有文件系统/ELF/可执行容器
  • 判断条件（满足即可进入本节）：
    • 无文件系统：binwalk/unblob 零命中或只有少量误报，无 squashfs/cramfs/jffs2 等魔数
    • 单镜像：体积小（几十 KB 量级）、无分区表、无 bootloader 引导头、无多段结构
    • MCU 特征：file 报 data/unknown；strings 无操作系统与库特征串（无 "libc"、无 RTOS 内核名）；镜像开头低地址处是短跳转/向量数据而非可读头
  • 例外分流：镜像中出现 RTOS 特征（调度器/任务创建字符串、TCB 形态）→ 定位复位向量与启动代码后转 [[re-rtos]]

镜像格式：Intel HEX 与二进制

  • Intel HEX（.hex）：ASCII 文本，逐行记录 :LLAAAATT<数据><校验和>——LL 数据长度、AAAA 段内地址、TT 记录类型（00 数据 / 01 结束 / 02·04 扩展地址 / 03·05 起始地址）、末字节校验和
    • 地址可分段不连续：多段记录之间留空，整文件按 bin 反汇编必然错位
    • 先转内存映像：按记录把数据落位到实际地址（02/04 扩展地址记录决定地址高 16 位），再按 flash 起始基址导入反汇编器
  • 二进制（.bin）：原始内存映像，无地址信息，导入时手动给基址
  • 程序内存布局（泛化，具体值因芯片而异）：
    • flash 起始：0x0000 或芯片映射基址（如 0x8000/0x10000 量级），以复位向量所在位置反推更可靠
    • 中断向量表：低地址固定区，复位向量位于表内固定偏移（见下节）

向量表定位

  • 复位向量 → 启动代码：从复位向量位置取入口地址，沿此反汇编即为启动序列（禁中断、初始化堆栈/时钟/外设、跳 main）
  • 复位向量位置各架构不同：8051 在 0x0000、AVR 在 0x0000、MSP430 在 0xFFFE（高地址端）、PIC 多为 0x0000（个别系列另有固定偏移）——按架构查位置，不猜
  • 跑 RTOS 的固件：复位向量 → 启动代码 → 内核初始化/任务创建 → 调度器启动，衔接 [[re-rtos]] 按任务表拆分

ISA 识别与反汇编

  • 识别要点（结合指令字宽、寻址特征、字节序判断）：
    • 8051：哈佛架构，程序/数据空间分离（MOVC 读程序区、MOVX 访问外部数据区）；SFR 特殊功能寄存器（0x80-0xFF 直接寻址）；0x20-0x2F 区可位寻址；累加器 A 与 DPTR 主导数据搬运
    • AVR：RISC，32 个通用寄存器（R0-R31）寄存器文件，指令大多单周期；哈佛架构
    • PIC：哈佛架构，寄存器分 bank、靠状态位切换（bank 切换）；指令字宽随系列不同（12/14/16 位），导入反汇编器时按对应宽度
    • MSP430：冯诺依曼（统一地址空间），16 位；中断向量表集中在高地址区（0xFFE0-0xFFFF）
    • 字节序：AVR/PIC/MSP430 为小端；8051 无原生端序指令、多字节数据惯例大端存放（Keil C51 默认大端），与其余三者相反——导入反汇编器时以实际数据确认（多字节常量、跳转目标地址的字节排列为判断依据）
  • 反汇编：选对应架构的处理器模块导入（Ghidra 含 8051/AVR/PIC/MSP430 处理器支持，[[re-ghidra]]；其他反汇编器同样有对应处理器，工具可替换，方法为核心）
  • 熔丝位/配置位（泛化概念）：烧录期配置项（各架构叫法不同：熔丝位/配置位/安全位），烧录时一次性写入，影响时钟源选择、看门狗、代码/读保护等。它不体现在镜像内容里，但决定芯片后续硬件行为——镜像读不到时要先怀疑它

本节常见坑与陷阱

  • Intel HEX 多段当 bin 直接反汇编：现象——反汇编错位，地址与代码对不上，全是无效指令；原因——HEX 分段记录地址不连续，且忽略 02/04 扩展地址记录会把高地址段数据落到低地址；对策——先按记录类型把数据落到实际地址（扩展地址记录参与地址合成），生成连续内存视图，再按 flash 基址导入
  • 向量表偏移猜错：现象——从文件头直接反汇编得到一堆数据/无效指令，找不到入口；原因——各架构复位向量位置不同（8051/AVR 在 0x0000、MSP430 在 0xFFFE、PIC 多为 0x0000 或系列固定偏移），猜错就从数据开始反汇编；对策——先确认架构，再按该架构复位向量固定位置取入口，从复位向量跟启动代码
  • 熔丝位锁定读保护，镜像不可得：现象——芯片读保护开启，读取操作返回全 F/拒绝响应，拿不到完整镜像；原因——烧录期配置位开启了读保护（代码保护），正常读取接口被锁；对策——走替代路径：芯片自带 UART bootloader 交互（若未禁用）、逻辑分析仪采集固件升级/烧录流量（[[re-hardware-io]]）按协议还原；镜像不可读时不强求，改从行为侧分析（串口输出/协议交互）
  • 数据 EEPROM 与程序 flash 混淆：现象——反汇编出大量无效指令，或分析半天发现是数据；原因——镜像含数据 EEPROM/校准表/配置表映像（非易失数据区，独立于程序区），被当成代码；对策——用复位向量/向量表定位程序区起点，程序区之外的高熵/全 F/重复模式段先排除为数据区，再反汇编

跨域联合

  • [[re-firmware]]：工作流第 2 步固定调用本技能
  • 解出的文件系统 → [[re-fw-rootfs]]；解出的可运行程序 → [[re-fw-emulate]]
  • 解出的 ELF → [[re-binary-core]]（[[re-format-elf]] / [[re-ghidra]]）；发现恶意样本 → [[re-malware]]
  • 本技能被 [[re-analyze]] 的 triage「分析固件 / IoT 设备」路径调用（re-firmware → re-fw-extract）

常见坑与陷阱

  • 自动解包失败 ≠ 没东西：现象——binwalk 输出空白或解出 0 字节文件；原因——厂商自定义头/加密层使魔数不匹配，签名库漏判；对策——hexdump 手工扫自定义头（步骤 2），跳过头部偏移再用 dd 切分（步骤 5）
  • 字节序错 → 全错：现象——解出的文件/ELF/字符串全乱；原因——大端 ARM/MIPS 固件被当小端处理；对策——先 file + readelf -h 确认字节序（步骤 3），后续解包/分析全程保持一致
  • 大端 MIPS 头被 binwalk 漏：现象——binwalk 识别不出已知文件系统（如 squashfs）；原因——签名按小端特征匹配，大端魔数反序；对策——hexdump 手工找反序魔数，按偏移 dd，用 sasquatch 解
  • 解包产物混入垃圾：现象——解出的"文件"是随机数据，file 报 data；原因——签名误报或切分偏移错位；对策——每个产物 file + 看头 16 字节验证 magic，无效即重试偏移
  • 扩展名与内容不符（伪装扩展名）：现象——.jpg 报 PNG、.so 报 tar、.c 报 XZ；原因——作者故意用无关扩展名（隐写/套娃/免检场景常见）；对策——永远以 file/魔数为准，扩展名只当线索；file 输出带 "with extra data prepended" 等提示时直接照做
  • zip 报错但能列出文件：现象——unzip 报 "missing 4 bytes"/"invalid zip with overlapped components"（zip bomb 误报）或 Python zipfile OSError: [Errno 22] Invalid argument；原因——本地文件头缺 PK\x03\x04 签名，或数据前有前缀垃圾；对策——先 unzip -l 看能否列出（能列出说明 EOCD/中央目录完好），补签名（步骤 4）或用 UNZIP_DISABLE_ZIPBOMB_DETECTION=TRUE 强制
  • ME 固件（Intel ME / CSME）从启动链入手：现象——解出 ME 固件分区（FTPR/RBE/BUP）后不知从何下手，代码里一串 ROM_SVC_* 调用看不懂；原因——ME 是独立处理器固件，启动链与普通固件不同：ROM（PCH 内固化，不可提取）验签 FTPR → 解压 RBE（初始化 PCH/SPI、UTOK 校验、boot_cfg）→ kernel（ThreadX RTOS）→ BUP（硬件 bringup，读 boot_cfg 决定开不开 DCI）→ pm/vfs/heci/crypto 等 38 个 user processes；对策——先解 FPT（Flash Partition Table：ME 区域固定偏移处的分区路由表，记录各分区位置/大小/类型——ROM/RBE 无文件系统全靠查它定位分区，UEFIExtract 源码有解析参考），再按 RBE→kernel→BUP 顺序跟进；调试接口/硬件初始化逻辑在 BUP
  • UTOK 是 ME 调试解锁的 OEM 后门：现象——想开 ME 调试接口（DCI/DFX）找不到开关；原因——Intel 为 OEM 留的解锁机制：SPI Flash 的 FPT 分区表中独立 UTOK 分区，写入数据即可解锁 DFX 调试接口（无需硬件熔丝）；对策——逆向 RBE 的 rbe_utok_check 定位校验逻辑：标志位 UTOK[0x298]==1 才启动调试能力（厂家默认 FF 不启动），且 DCI 开放受多层校验链控制（boot_mode==2、boot_cfg 解析、CT handler 门控、FPF Debug Auth 等），单改标志位不够；定位技巧：ME 运行 base 是 0x4000，字符串偏移按此换算
  • ME 固件漏洞利用受 ROM cookie 限制：现象——ME 固件里找到缓冲区溢出（如 Intel-SA-00086：CT 文件 num_records（偏移 +0x06 的 uint16）无校验，record 数超 100 覆写栈 cookie/返回地址），ROP 却打不通；原因——ME 的 cookie 由 ROM（mask ROM 不可提取）在 SRAM 预填充进程上下文表生成，无法像 TXE 平台那样用 TLS 绕过；对策——先确认目标平台 cookie 来源（ROM 生成则溢出利用受限），完整逆向认证链路（UTOK→boot_cfg→CT handler 多层校验）后找非溢出路径
  • 分块周期变换：现象——单一全文件 XOR/旋转只在开头有效；原因——变换按块大小（常见 256/512/1024/2048/4096）重置；对策——先按常见 Flash/传输块大小检查变换是否按块重置周期，显式分块解码
  • 块首自带掩码混淆：现象——高熵固件被当强加密；原因——分块自带掩码混淆（如 mask = block[0]、plain[i] = ROR8(packed[i], n) XOR mask（mask 字节自身不参与变换，i 从 1 起））；对策——先用强 crib（向量表 SRAM 栈指针/Thumb Reset Vector）约束恢复首块，再验证模型
  • 众数 crib 不可靠：现象——文本密集块用众数字节做掩码仍乱码；原因——最常见明文字节不一定是零；对策——改用块首字节模型，验证标准：乱码消失 + 第二份同系列固件复现 + round-trip 逐字节一致
  • CRC 字符串 ≠ CRC 字段：现象——看到 CRC 名字符串就假设末尾是标准 CRC；原因——字符串只是元数据键；对策——系统排除常见 CRC/硬件 CRC/Adler/累加族后保留为未知字段，不强行命名 （来源：reverse-skill field-journal，MIT）

发现更多相关技能

查看全部技能
我的收藏