re-firmware

Firmware / Embedded / Hardware Analysis

Complete Workflow

1. Initial survey: [[re-triage]] (capability:triage) —— file/hash/entropy to confirm firmware type, architecture, and endianness (if the [[re-analyze]] entry point was not used, do it first; read the RE_* session variable)
2. Extraction: [[re-fw-extract]] (capability:firmware-extraction) —— binwalk/unblob automatic unpacking, manual magic scanning, endianness determination
3. rootfs: [[re-fw-rootfs]] (capability:firmware-extraction) —— mount/unpack the filesystem, locate entry points via startup scripts, mine configurations/keys/hardcoded passwords
4. Emulation: [[re-fw-emulate]] (capability:emulation) —— when runtime is needed, prefer QEMU user-mode (lightest option, see [[re-analyze/platform-tips]]), full-system as needed
5. Hardware interfaces: [[re-hardware-io]] (capability:hardware-interface) —— when a physical board is needed (JTAG/UART/flash readout); if firmware files are available, do steps 2-4 first; hardware is the last resort
6. Communication: firmware communication, callbacks, custom protocols discovered during extraction/runtime → [[re-protocol]] (capability:network-capture、protocol-recovery、crypto-identification、crypto-decryption、key-extraction、tls-analysis；netcap / proto-rev / crypto-*）
7. Outputs: conclusions / report (according to RE_REPORT), hashes and evidence archived (see [[re-triage]] (capability:triage））

Archive the result of each step (evidence path + sha256, see [[re-triage]] (capability:triage)) for report citation; if malicious samples/backdoors are found, switch to [[re-malware]] (capability:malware-behavior、document-malware、evasion-analysis、key-extraction、threat-intel）。

When to Use Which Atomic Skill (Selection Tree)

• Have a firmware file (.bin / .img / update package) → [[re-fw-extract]] (capability:firmware-extraction) to unpack
• Already have a rootfs / unpacked artifacts → [[re-fw-rootfs]] (capability:firmware-extraction) to analyze the filesystem
• Need to run the firmware and observe behavior → [[re-fw-emulate]] (capability:emulation; confirm the architecture first, see [[re-triage]] (capability:triage））
• Have a physical board / need hardware extraction → [[re-hardware-io]] (capability:hardware-interface）
• Automotive ECU / CAN bus / OBD-UDS diagnostics → [[re-automotive]] (capability:automotive-analysis）
• See communication (firmware callbacks / custom protocols / encrypted communication) → [[re-protocol]] (capability:network-capture、protocol-recovery、crypto-identification、crypto-decryption、key-extraction、tls-analysis）
• Target is UEFI firmware (BIOS update package/DXE driver/bootkit) → [[re-uefi]] (capability:uefi-analysis; UEFITool parsing + OVMF emulation)

Cross-Domain Combinations

• Firmware communication protocols: [[re-firmware]] → [[re-protocol]] (netcap / proto-rev / crypto-* to identify and reconstruct firmware communication)
• Malicious samples/backdoors in firmware: [[re-firmware]] → [[re-malware]] (for sandbox behavior analysis see [[re-sandbox]])
• In-depth static analysis of ELF in firmware: → [[re-binary-core]] ([[re-format-elf]] / [[re-ghidra]])
• Emulation dynamic analysis defaults to sandbox + network isolation ([[re-analyze/platform-tips]] highest principle)
• This gateway is invoked by the "Analyze Firmware / IoT Devices" path in [[re-analyze]]'s triage.md (re-firmware → re-fw-extract → re-fw-rootfs → re-fw-emulate → re-protocol if communication is observed)

Common Pitfalls and Traps

• Got the firmware, skip preliminary analysis and go straight to binwalk → architecture/endianness unknown, the extracted program cannot be emulated — first do [[re-triage]] to confirm (big-endian ARM/MIPS is common)
• Give up when automatic unpacking fails → vendor-custom headers/encryption layers are the most common — switch to [[re-fw-extract]] manual magic scanning + dd splitting by offset
• Immediately demand a physical board → high cost, risk of damage — if you have a firmware file, first go extraction→rootfs→emulation; [[re-hardware-io]] is the last resort
• Run firmware without isolating the network → the firmware really calls back to the external network — sandbox by default + network isolation (the highest principle of [[re-analyze/platform-tips]]); for communication analysis switch to [[re-protocol]]
• Analyze rootfs without looking at startup scripts → facing dozens of binaries with no idea where to start — first go to [[re-fw-rootfs]] and read rcS / inittab / init.d to locate the program entry point
• Layer-by-layer verification of the boot chain (BootROM→FDL→SPL→U-Boot→system): Phenomenon — after patching out one layer of verification, flashing still fails, and later it is still stuck at another verification; Cause — in mobile SoCs (Unisoc/Spreadtrum, etc.) each layer of the flashing chain independently verifies signatures: BootROM→FDL1→FDL2→SPL Loader→U-Boot/LK→system, and SPL performs RSA-2048 verification on sml/trustos/uboot (DHTB+SIMGHDR format); on failure it enters an infinite loop; Countermeasure — trace layer by layer along the entire chain: ①Convert format features to constants: File header ASCII (such as DHTB) converted to an integer as 32-bit little-endian (1112819780), then in the decompilation of the previous layer search for that constant to locate the verification entry point; ② Failure trap = infinite loop (on verification failure branch to loop), patch the failure branch to NOP/adjust the branch so it continues; ③ Get the FDL2 load base address from the second FDL address on the spd_dump command line (use this as the load base address in IDA/Ghidra so xrefs line up correctly); ④ String search to find the entry point for "dispatching flashing logic by partition name"; ⑤ Hardware hardening solution (RP2350 as USB Host to automatically replay the handshake injection) is only for automation; the real key is reverse engineering and modifying the loading chain