Skip to content

iot_firmware_real_world_case_studies.md

Latest commit

 

History

History
587 lines (425 loc) · 18.7 KB

iot_firmware_real_world_case_studies.md

File metadata and controls

587 lines (425 loc) · 18.7 KB
Raw

Real-World IoT Firmware Research Case Studies

Date: 2026-06-09

Purpose: show how real researchers and CTF authors approach firmware research goals: finding zero-days, reproducing one-days and n-days, discovering backdoors or implants, solving firmware challenges, and getting difficult firmware to emulate.

Use this with:

  • iot_firmware_elite_field_manual.md
  • iot_firmware_quickstart.md
  • emba_firmware_analysis_walkthrough.md
  • _personal/roadmaps/career_roi_comparison_2025.csv only as a career context file, not as technical methodology

This file is not a list of links to skim. Each case study is a pattern to copy:

goal -> initial clues -> sequence of moves -> proof standard -> what to practice

Compact Menu

How To Read These Writeups

Do not read a writeup like entertainment.

Read it like this:

1. Stop after the target/background section.
2. Predict the next move.
3. Read only until the next artifact appears.
4. Recreate that artifact locally if legal and practical.
5. Write a one-page "method card" from memory.
6. Compare your method card to the original.

For each writeup, extract:

Question Why it matters
What was the goal? 0-day, n-day reproduction, exploit chain, backdoor, emulation, CTF flag
What was the first useful artifact? firmware image, advisory, patch, binary, pcap, hardware dump
How did they find attack surface? routes, daemons, protocols, init scripts, strings, xrefs
How did they prove reachability? request, packet, service start, route map, emulation, hardware
How did they prove root cause? source line, decompiled function, debugger, crash, patch diff
What made it exploitable? command sink, memory primitive, auth bypass, root context, implant behavior
What was the blocker? NVRAM, hardware, missing libs, auth, encryption, patch gaps
What can I practice safely? extraction, route mapping, patch diff, emulation, report writing

Case Study Map

Goal Study What it teaches
Pwn2Own n-day/1-day reproduction TP-Link Archer A7/C7 writeups turn advisory/PoC clues into binary/protocol analysis and exploitability
Emulation against blockers Tenda AC15 EMUX NVRAM/hardware stubbing, rootfs bootstrapping, service rehosting
Backdoor discovery D-Link backdoor extracting firmware, reversing web server auth logic, recognizing hidden trust paths
Firmware malware/implant analysis Check Point Horse Shell malicious firmware comparison, implant capability analysis, router persistence
Incomplete patch/new vuln Forescout TP-Link rooting device, reviewing prior fixes, finding residual debug functionality
Physical + network chain Tenable Archer A7 USB symlink attack assumptions, symlink/path behavior, physical precondition honesty
Personal end-to-end firmware analysis D-Link DIR-820L binwalk/rootfs/web CGI/static-to-reproducer flow
CTF mechanics Grey Cat Firmware, PatriotCTF Banner extraction, filesystem search, odd acquisition sources such as PCAP

TP-Link Archer A7 / C7 Pwn2Own Cluster

Sources:

  • ZDI: Exploiting the TP-Link Archer A7 at Pwn2Own Tokyo
  • STAR Labs: Analysis and exploitation of a recent TP-Link Archer A7 vulnerability
  • Synacktiv: Pwn2Own Tokyo 2020: Defeating the TP-Link AC1750
  • Flashback Team: LAO BOMB - TP-LINK Archer C7/A7 LAN RCE
  • WithSecure Labs: TP-Link AC1750 Pwn2Own 2019 advisory

What They Were Trying To Achieve

Different researchers attacked related TP-Link router targets and daemons. The goal was not "scan firmware and hope." It was to identify a reachable LAN/router management service, reverse the protocol or request path, find a command injection or memory corruption primitive, and turn it into reliable code execution.

Research Sequence

firmware/advisory/target device
  -> identify model, firmware version, architecture
  -> extract rootfs
  -> find startup scripts and listening daemons
  -> locate target daemon such as tdpServer or sync-server
  -> reverse protocol/message parser
  -> trace attacker-controlled fields
  -> find sink or memory corruption
  -> build LAN-side request/packet
  -> demonstrate root-level impact

What To Learn

The repeated pattern is:

daemon + protocol + reachable LAN surface + root context = high-value firmware target

For n-day reproduction, start from public advisories and ask:

  • Which binary contains the vulnerable service?
  • Which init script starts it?
  • Which port/protocol reaches it?
  • Which parser handles the attacker field?
  • What changed in the patched firmware?

Practice Exercise

Use an old router firmware image:

binwalk -Me firmware.bin
find squashfs-root -type f -perm /111 -exec file {} \; | tee executables.txt
rg -n "tdp|sync|httpd|uhttpd|upnp|soap|cgi|lan|udp|tcp" squashfs-root
strings -a squashfs-root/usr/bin/* 2>/dev/null | rg "GET|POST|http|tdp|sync|system|popen|strcpy|sprintf"

Then write:

Which daemon would I reverse first, and why?
What input reaches it?
What would prove exploitability?

Tenda AC15 Emulation Against The Odds

Sources:

  • EMUX: Extracting the Tenda AC15 firmware
  • EMUX: Emulating Tenda AC15
  • CVE-2020-10987 replication writeups around Tenda AC15 command injection

What They Were Trying To Achieve

The goal was not just "extract files." It was to get the Tenda AC15 firmware far enough into a rehosted/emulated state that the web interface and vulnerable handlers could be exercised.

Research Sequence

obtain/dump firmware
  -> carve flash/rootfs
  -> identify architecture and kernel/rootfs assumptions
  -> start firmware under QEMU/EMUX
  -> observe crashes/reboots
  -> identify missing hardware/NVRAM behavior
  -> stub/map vendor NVRAM functions
  -> start web service
  -> exercise vulnerable route

What To Learn

Emulation failure is usually specific:

missing NVRAM
missing device node
missing config partition
wrong kernel/machine model
service expecting board-specific behavior

The elite move is to identify the exact missing assumption, not to keep rerunning the same emulator command.

Practice Exercise

When an emulated service exits:

QEMU_STRACE=1 qemu-arm-static -L rootfs rootfs/bin/target args 2>&1 | tee qemu_strace.txt
rg -n "open|ENOENT|ioctl|nvram|mtd|proc|sys|config|not found" qemu_strace.txt
rg -n "nvram|getenv|mib|get_config|uci" rootfs 2>/dev/null

Write:

What exactly is missing?
Can I stub it?
Is static proof enough if stubbing is too expensive?

D-Link Backdoor In Firmware Web Server

Sources:

  • Hackaday summary of reverse engineering a D-Link backdoor
  • Original public work by Craig Heffner / devttys0-style firmware analysis

What They Were Trying To Achieve

This is a classic example of discovering a hidden trust path/backdoor in firmware by extracting the filesystem and reversing the web server authentication logic.

Research Sequence

download firmware
  -> binwalk extraction
  -> locate SquashFS/rootfs
  -> identify web server binary
  -> reverse authentication/HTTP handling paths
  -> find special-case bypass condition
  -> prove request behavior

What To Learn

Backdoors often do not look like "backdoor" strings. They look like:

  • special user-agent handling
  • magic token comparisons
  • debug endpoints
  • hidden accounts
  • compile-time/vendor support paths
  • conditions reachable only with a strange header or file

Practice Exercise

On any firmware web server binary:

strings -a httpd | rg -i "user-agent|authorization|cookie|admin|debug|backdoor|xml|soap|login|password"

In Ghidra/IDA:

Find HTTP header parsing.
Find auth decision branch.
Find string comparisons.
Ask: is there any alternate path to "authenticated"?

TP-Link Horse Shell Malicious Firmware Implant

Source:

  • Check Point Research: malicious firmware implant for TP-Link routers linked to Camaro Dragon / Mustang Panda overlap

What They Were Trying To Achieve

This is not a normal vulnerability-hunting writeup. It is firmware implant/malware analysis: understand what was modified, what capabilities the implant had, how it persisted, and what threat activity it supported.

Research Sequence

obtain suspicious router firmware/image
  -> identify modified components
  -> reverse implant binaries/scripts
  -> map command-and-control behavior
  -> identify persistence and network exposure
  -> compare with known router implants
  -> produce detection/defensive guidance

What To Learn

Firmware malware/backdoor analysis asks a different question:

What changed, what persists, what communicates, and what control does the operator get?

Useful local workflow:

find rootfs -type f -perm /111 -exec file {} \; | tee executables.txt
rg -n "http|https|socket|connect|listen|shell|cmd|token|key|cron|init.d|rcS" rootfs 2>/dev/null
find rootfs/etc/init.d rootfs/etc/rc.d rootfs/etc/cron* -type f 2>/dev/null

Practice Exercise

Take two firmware versions from the same vendor:

diff -ruN old_rootfs new_rootfs > rootfs.diff
rg -n "init|cron|rcS|http|connect|shell|authorized_keys|dropbear|iptables" rootfs.diff

Write:

Which changes are expected vendor updates?
Which changes create persistence or remote control?

Forescout TP-Link Rooting Routers Research

Source:

  • Forescout Vedere Labs: New TP-Link Router Vulnerabilities: A Primer on Rooting Routers

What They Were Trying To Achieve

Forescout used rooting and prior vulnerability context to inspect TP-Link Omada/Festa router internals, then found new issues including command injection and residual debug functionality after an earlier fix.

Research Sequence

start from prior flaw / patch context
  -> gain/root lab device under controlled conditions
  -> inspect internals and debug behavior
  -> analyze web/VPN/config handling
  -> identify incomplete remediation or residual code
  -> generalize to related device families
  -> coordinate disclosure

What To Learn

The high-value move is:

patches are research maps

After a vendor patches one flaw, ask:

  • Did they remove the root cause or only block one path?
  • Is debug code still present?
  • Is the same pattern copied into other models?
  • Did the patch create a new reachable condition?
  • Are private keys, credentials, or debug toggles reused?

Practice Exercise

Given old and patched firmware:

diff -ruN old_rootfs new_rootfs > patch.diff
rg -n "debug|root|shell|admin|vpn|wireguard|uci|system\\(|popen|exec|private key|authorized" patch.diff

Then build a table:

changed file -> security-relevant branch -> old behavior -> new behavior -> bypass hypothesis

Tenable TP-Link USB Symlink Vulnerabilities

Source:

  • Tenable Research Advisory TRA-2020-60: TP-Link Archer Routers USB Symlink Following Vulnerabilities

What They Were Trying To Achieve

This case is useful because the exploitability assumptions are not purely remote. It involved physical/network positioning and symlink/path behavior around USB storage exposure.

Research Sequence

identify feature boundary
  -> USB storage / file sharing behavior
  -> symlink/path handling
  -> privilege and filesystem assumptions
  -> demonstrate arbitrary code execution under defined preconditions

What To Learn

Not every strong firmware vulnerability is unauthenticated internet RCE. Real reports must state attacker position:

  • remote WAN
  • LAN
  • authenticated admin
  • physical + LAN
  • local shell
  • supply-chain/update path

Practice Exercise

When you find a file/path issue, score preconditions:

Can attacker place a file?
Can attacker choose a path?
Can attacker trigger the consumer service?
What privilege does the consumer run as?
What crosses from data into code?

Personal D-Link DIR-820L Firmware Analysis

Source:

  • Nam's Journal: IoT Security Analysis: D-Link DIR-820L Router

What They Were Trying To Achieve

This is a useful personal-blog example because it follows a very teachable end-to-end path: binwalk extraction, filesystem inspection, credentials, startup analysis, CGI/service analysis, command injection proof.

Research Sequence

download firmware
  -> binwalk finds SquashFS
  -> extract rootfs
  -> inspect shadow/config files
  -> inspect startup scripts
  -> identify service handling CGI requests
  -> test command injection through web route

What To Learn

This is closest to your 48-hour assignment flow:

extract -> map startup/web -> grep sinks -> pick one route -> reproduce safely

Practice Exercise

After extraction:

rg -n "cgi|ncc|httpd|lighttpd|boa|uhttpd|REQUEST_METHOD|QUERY_STRING" rootfs 2>/dev/null
rg -n "ping|traceroute|nslookup|system\\(|popen|exec|wget|curl" rootfs 2>/dev/null

Then produce a one-page mini-report using templates/iot_firmware_case_template.md.

CTF Firmware Extraction Examples

Sources:

  • CTFtime: Grey Cat The Flag 2022 Firmware
  • CTFtime: PatriotCTF Banner

What They Were Trying To Achieve

These are not full vulnerability-research case studies. They are small extraction/triage drills.

Patterns

Grey Cat Firmware:

firmware blob -> binwalk -> SquashFS extraction -> grep/search -> flag

PatriotCTF Banner:

pcap/TCP data -> recover binary stream -> binwalk -> SquashFS -> router banner file -> flag

What To Learn

CTFs teach fast mechanics:

  • recognize embedded filesystems
  • recover firmware from unusual containers
  • use binwalk/unblob/strings quickly
  • search rootfs effectively
  • avoid overthinking when the answer is an artifact

They do not usually teach exploitability or responsible disclosure. Pair them with real writeups.

General Research Blogs To Read Regularly

Seed list from the user-provided nday_blogs_scored.md:

Source Best use
Google Project Zero root-cause analysis discipline, patch diffing, exploit context
Source Incite full exploit chains and n-day reproduction style
STAR Labs practical exploitation writeups, Pwn2Own-style chains
Synacktiv deep RE/exploitation writeups
Quarkslab low-level RE, firmware, hypervisor, crypto/security engineering
Trail of Bits methodology, fuzzing, code review, harnesses
NCC Group Research applied product/security research
Claroty Team82 OT/IoT vulnerability research
Forescout Vedere Labs embedded/OT/IoT device research and fleet-level implications
Check Point Research malware, implants, IoT/router threat research
Tenable Research advisories with clear preconditions and impact
PortSwigger Research web logic, HTTP parser, and request-smuggling thinking
GitHub Security Lab source-to-root-cause vulnerability research
CTFtime writeups fast mechanics and puzzle-style practice

How to consume:

1. One writeup per week.
2. Write a method card.
3. Reproduce only legal/safe parts.
4. Add one pattern to your local playbook.
5. Add one false-positive lesson.

Exercises

Exercise 1: Method Card

Pick one case above and write:

Target:
Goal:
First artifact:
Attack surface:
Critical observation:
Verification method:
Exploitability argument:
What I can reuse:
What I cannot legally reproduce:

Exercise 2: N-Day Reproduction Plan

Pick a public CVE/advisory.

Do not run public exploit code first.

Instead:

1. Identify affected firmware.
2. Identify patched firmware.
3. Extract both.
4. Diff changed files.
5. Locate changed route/binary/function.
6. Explain root cause in your own words.
7. Build a safe verification request or test case.

Exercise 3: Emulation Blocker Journal

For any firmware that fails under QEMU/EMBA:

Command:
Observed failure:
Missing file/device/config:
Evidence:
Stub attempted:
Result:
Decision: continue emulation / static proof / hardware required

Exercise 4: Backdoor Hunt

On a firmware rootfs:

rg -n "debug|backdoor|support|telnet|dropbear|authorized_keys|root:|admin|magic|user-agent|shell|cmd" rootfs 2>/dev/null
strings -a rootfs/** 2>/dev/null | rg -i "debug|support|user-agent|authorization|telnet|shell|cmd"

Then manually verify whether any hit is reachable and meaningful.

Sources