Practical IoT Hacking

Five authors, each writing the part they do professionally, which gives this book unusual range and an unusually even quality. It covers network assessment, protocol analysis, hardware interfaces, firmware, four radio technologies and the mobile applications that sit on top, and it is hands-on throughout - almost every chapter ends in an exercise against real hardware.

Three modules cite it, spread across network forensics, mobile and hardware, which is a fair description of how embedded challenges arrive: rarely as a single clean artefact, usually as a capture plus a dump plus an app.

Why it is on this shelf

Because hardware and firmware challenges reward knowing that a small number of standard interfaces exist. A four-pin header is almost certainly a serial console, a repeating two-wire pattern in a logic capture is almost certainly I2C, and a blob with a compressed filesystem forty kilobytes in is almost certainly a router image. None of that is deducible; it has to be learned once.

Chapter 5, Analyzing Network Protocols

How to approach a protocol nobody has written a dissector for, using their own worked example of building one. The method is the same one Attacking Network Protocols teaches - capture, identify the framing, isolate the fields that change - but here it is aimed at the small, custom, badly documented protocols embedded devices actually use.

The reason it earns a citation from the network forensics module is that CTF captures are usually exactly this: not HTTP, not DNS, but something homemade with a two-byte length and a command code. Getting from a capture to a field map is the challenge. Pcap triage is the first pass, the pcap packets view is where you read the bytes, and reversing a binary protocol is the method written out.

Chapter 7, UART, JTAG, and SWD Exploitation

The three ways into a board. UART is a serial console and it is astonishingly often left enabled, unauthenticated, printing a boot log and dropping to a shell. JTAG and SWD are debug interfaces, which means halting the processor, reading and writing memory, and dumping flash regardless of what the firmware wanted.

The chapter walks pin enumeration on an unlabelled board and then an attack on an STM32 microcontroller, defeating an authentication routine over UART and then over SWD. The transferable part for a competition is the reading: a UART capture is asynchronous, one wire per direction, and its baud rate is recoverable from the shortest pulse. That is a decoding problem you can do with the logic analyzer decoder and it is exactly what hardware and signal challenges covers.

Chapter 8, SPI and I2C

The two buses that connect a microcontroller to everything else on the board, and in particular to the flash chip where the firmware lives. SPI is four wires and fast, with a chip-select line saying who is being addressed. I2C is two wires and addressed in-band, with each transaction carrying a seven-bit device address.

Both are synchronous, which is why they are the friendliest thing you can be given in a signals challenge: a clock line tells you exactly when to sample the data line, so decoding is mechanical once you have identified which trace is which. The chapter's practical payoff is dumping an EEPROM over I2C and a flash chip over SPI, and the dump is where the firmware challenge starts.

Chapter 9, Firmware Hacking

Obtaining, extracting and analysing a firmware image, then backdooring it, then looking at how the update mechanism itself fails. The extraction half is what CTF firmware challenges consist of: an image is usually a header, a kernel and a compressed root filesystem concatenated, and the job is to find the boundaries and unpack the filesystem.

What to look for once unpacked is the part worth memorising: hardcoded credentials in a shadow file or a startup script, private keys in an etc directory, an unauthenticated CGI script, and the update verification that checks a checksum rather than a signature. The firmware unpacker does the extraction here and firmware and IoT challenges walks the analysis.

The update-process material has a general lesson that applies well beyond embedded work: a checksum proves the file arrived intact, and a signature proves who sent it. Confusing the two is how devices accept firmware from anybody, and it is the same confusion Designing Secure Software names between integrity and authenticity.

Chapter 14, Attacking Mobile Applications

Android and iOS together, framed as the companion application to a device rather than as an application in its own right. That framing is useful because companion apps are careless in specific ways: the endpoint the device uses is in the app, the pairing secret is in the app, and the protocol you could not read on the wire is implemented in the app in readable form.

It covers the platform security models, insecure data storage, and certificate pinning bypasses. For CTF work start with the APK and IPA analyzer and Android app teardown; this chapter is where to come back when the app is the only documentation of a protocol you need.

Where it stops

It assumes hardware. Large parts of the book cannot be followed without a logic analyser, a bus pirate, an SDR or the target devices themselves, and a competition gives you a capture file instead. Read those chapters for the concepts and expect to be several layers of abstraction above what they describe.

It is also broad rather than deep by design. The firmware chapter will get you into an image and will not teach you to reverse the binary you find - that is Practical Binary Analysis - and the radio chapters are introductions to four different fields.

What to take into a challenge

Ask what the device is talking to, and then go and read that side instead. Almost every embedded challenge has more than one artefact - a capture and an app, a dump and a protocol - and the answer is usually plainly visible in whichever one nobody bothered to obfuscate.