Awesome Embedded and IoT Security
A curated list of embedded and IoT security resources — roughly 100+ entries, CC0-1.0, 2.4k★ — maintained by fraunhofer-fkie‘s Cyber Analysis & Defense department. Its stated motivation is Mirai and the botnets after it: devices shipped without the security their exposure warrants.
Sections: software tools (analysis frameworks, extraction, support utilities), hardware tools (debug interfaces, wireless testing), 13 books spanning 2013–2020, 20+ research papers, case studies of real vulnerability analyses, free training including CTFs and workshops, blogs and YouTube channels, and conferences such as Hardwear.io. Commercial products are marked with a symbol. Named tools include FACT (Firmware Analysis and Comparison Tool), Ghidra, radare2, binwalk, and on the hardware side the Bus Pirate and the ChipWhisperer.
T2 — a curated list, but from a government-funded research institute rather than an individual, with an academic-papers section and a stated audience (beginners through experts). That is a visible editorial position, which is what separates it from the T3/T4 community catalogs elsewhere in the hub. The book range ending in 2020 is the clearest staleness signal on the page.
It answers the spoke’s open question
synthesis.md has been carrying “where does device security land?” with one book title’s worth of
evidence, borrowed from awesome-iot‘s reading list. This is the real source that question was waiting
for, and it settles the seam in a specific direction: the practice it catalogs is analysis of the
device, not defense of a fleet. Firmware extraction, binary reverse engineering, JTAG and UART probing,
side-channel work with a ChipWhisperer — these are done to a device to find out what it does and where
it breaks. The blue-team practice ../defensive-security-wiki owns (hardening to a benchmark, SOC triage,
coordinated disclosure) is a different activity that happens after someone has done this.
So the boundary the spoke wrote holds, and now has a case behind it: the device as an object of study stays here; the organizational practice of defending a fleet goes there. A FACT firmware analysis and a CIS benchmark are not two versions of one thing.
What the categories say about the field
The hardware section is the tell. A list of web-security resources needs no equipment. This one names debug interfaces and wireless testing gear, because on an embedded target the attack surface includes the pads on the board. open-hardware documents publishing a design so others can build it; the same physical accessibility is what makes a device analyzable by anyone holding it. The two are the same property viewed from opposite ends, and nothing in the spoke had connected them until now.
Case studies as a category, sitting beside the papers, is the second signal. It says the field’s knowledge lives in worked examples of specific devices rather than in general results — consistent with what embedded-systems says about constraint driving every decision, since a finding on one SoC often does not transfer to the next.
No section for the network tier. The list is organized around firmware and hardware; the protocol layer iot-protocols covers appears through tools, not as a topic. Whether that reflects the field or this institute’s specialization is not something one list can answer.
Related
fraunhofer-fkie · embedded-systems · microcontroller · awesome-iot · open-hardware · iot-protocols · rtos · synthesis