How do I install the Reverse Eng Firmware skill?

Run npx skillmds@latest add noorqureshi/reverse-eng-firmware in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Reverse Eng Firmware safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Reverse Eng Firmware?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Reverse Eng Firmware free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Reverse Eng Firmware?

NoorQureshi (@noorqureshi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Reverse Eng Firmware by noorqureshi

Name: Reverse Eng Firmware
Author: NoorQureshi

Reverse Eng Firmware

Extract and analyze device firmware to find hardcoded secrets, backdoors, vulnerable services, and the real version behind an appliance. Load when you have a firmware image or can pull one. Signals: a .bin/.img firmware download, a router/IoT/appliance in scope, an OTA update file, a flash dump, "analyze this firmware", SquashFS/JFFS2/CramFS, U-Boot headers, hunting the code behind a CVE on FortiGate/Ivanti/etc.

NoorQureshi Updated Sep 17, 2026

File contents

Firmware analysis

When it applies

You have a firmware image — a vendor download, an OTA update, or a flash dump — for a router, IoT device, or network appliance in scope. Offline firmware analysis is the static counterpart to network-appliance-attacks: it explains why a device is vulnerable and often yields the exact version, hardcoded creds, or patched-function diff behind an edge CVE.

Why it works

Firmware ships the whole system: a packed filesystem, config, keys, and binaries. Vendors routinely leave hardcoded credentials, private keys, debug/backdoor accounts, and old vulnerable services in the image — all readable offline, with no traffic to the live device, once you carve the filesystem out of the container.

Method

Recognize and carve. binwalk <image> to identify the container and offsets (U-Boot header, compression, one or more filesystems). Extract with binwalk -e (or unsquashfs / firmware-mod-kit for SquashFS/JFFS2/CramFS). Encrypted images → find the bootloader/update routine that decrypts (often in a prior version's cleartext image).
Inventory the filesystem. Identify the OS/libc, the init scripts, the web root, and the service binaries. emba automates a first-pass audit if you want breadth fast.
Hunt secrets & accounts. /etc/passwd+/etc/shadow (crack weak hashes offline), hardcoded API keys/private keys/certs, backdoor accounts, and secrets in config and startup scripts (CWE-798, CWE-912).
Pin the version and diff. Read the real build/version from the filesystem (not a spoofable banner) to drive CVE applicability. Diff the pre/post-patch image of a known CVE to locate the vulnerable function, then analyze it with reverse-eng-binary-triage.
Find the reachable attack surface. Network-listening binaries (the web UI CGI, telnet/SSH, custom daemons) are the ones that matter live — triage those for injection/overflow and map them back to a remote path on the running device.

Gotchas

binwalk -e can fail silently on nested/obscure formats — check offsets manually and try unsquashfs/sasquatch for non-standard SquashFS; a partial carve looks like "nothing there".
Vendor keys are shared across a product line — a key in one image often unlocks the whole fleet; that's the finding, but handle it responsibly per RoE.
Version from the filesystem, not the banner — appliances backport patches and keep old strings; the image is ground truth.
Only analyze firmware you're authorized to — redistribution of vendor firmware may itself be restricted; keep it in the git-ignored engagements/ tree.

Verify success

A concrete offline finding: a hardcoded credential/key, a backdoor account, the pinned build version, or a vulnerable network-facing binary and its remote entry point — each traceable to a file in the extracted image.

References

binwalk & firmware-mod-kit docs; emba firmware analyzer; OWASP IoT / firmware testing guidance; CWE-798/912.

---name: reverse-eng-firmwaredescription: Extract and analyze device firmware to find hardcoded secrets, backdoors, vulnerable services, and the real version behind an appliance. Load when you have a firmware image or can pull one. Signals: a .bin/.img firmware download, a router/IoT/appliance in scope, an OTA update file, a flash dump, "analyze this firmware", SquashFS/JFFS2/CramFS, U-Boot headers, hunting the code behind a CVE on FortiGate/Ivanti/etc.---# Firmware analysis## When it appliesYou have a firmware image — a vendor download, an OTA update, or a flash dump — for a router, IoTdevice, or network appliance in scope. Offline firmware analysis is the static counterpart to`network-appliance-attacks`: it explains *why* a device is vulnerable and often yields the exactversion, hardcoded creds, or patched-function diff behind an edge CVE.## Why it worksFirmware ships the whole system: a packed filesystem, config, keys, and binaries. Vendors routinelyleave hardcoded credentials, private keys, debug/backdoor accounts, and old vulnerable services inthe image — all readable offline, with no traffic to the live device, once you carve the filesystemout of the container.## Method1. **Recognize and carve.** `binwalk <image>` to identify the container and offsets (U-Boot header, compression, one or more filesystems). Extract with `binwalk -e` (or `unsquashfs` / firmware-mod-kit for SquashFS/JFFS2/CramFS). Encrypted images → find the bootloader/update routine that decrypts (often in a prior version's cleartext image).2. **Inventory the filesystem.** Identify the OS/libc, the init scripts, the web root, and the service binaries. `emba` automates a first-pass audit if you want breadth fast.3. **Hunt secrets & accounts.** `/etc/passwd`+`/etc/shadow` (crack weak hashes offline), hardcoded API keys/private keys/certs, backdoor accounts, and secrets in config and startup scripts (`CWE-798`, `CWE-912`).4. **Pin the version and diff.** Read the real build/version from the filesystem (not a spoofable banner) to drive CVE applicability. Diff the pre/post-patch image of a known CVE to locate the vulnerable function, then analyze it with `reverse-eng-binary-triage`.5. **Find the reachable attack surface.** Network-listening binaries (the web UI CGI, telnet/SSH, custom daemons) are the ones that matter live — triage those for injection/overflow and map them back to a remote path on the running device.## Gotchas- **`binwalk -e` can fail silently on nested/obscure formats** — check offsets manually and try `unsquashfs`/`sasquatch` for non-standard SquashFS; a partial carve looks like "nothing there".- **Vendor keys are shared across a product line** — a key in one image often unlocks the whole fleet; that's the finding, but handle it responsibly per RoE.- **Version from the filesystem, not the banner** — appliances backport patches and keep old strings; the image is ground truth.- **Only analyze firmware you're authorized to** — redistribution of vendor firmware may itself be restricted; keep it in the git-ignored `engagements/` tree.## Verify successA concrete offline finding: a hardcoded credential/key, a backdoor account, the pinned buildversion, or a vulnerable network-facing binary and its remote entry point — each traceable to afile in the extracted image.## References`binwalk` & firmware-mod-kit docs; `emba` firmware analyzer; OWASP IoT / firmware testing guidance;CWE-798/912.

Frequently asked questions