Attacking Network Protocols

Forshaw is a Project Zero researcher with an unusual specialism: he takes proprietary network protocols apart, and he has done it often enough to have a method rather than a set of anecdotes. This book is that method, laid out in the order you would actually use it - capture the traffic, identify the structures inside it, reverse the program that produces them, then attack the parser.

Four different modules cite it, from foundations through to reversing, which is unusual and is a fair reflection of what it is. It is not a networking book. It is a book about recognising structure in bytes, and that skill is the same whether the bytes came off a wire, out of a file or from a serial line.

Why it is on this shelf

Because the hardest moment in a network or reversing challenge is the first one, when you have a blob and no idea what any of it means, and this is the only book here that takes that moment seriously. Its answer is that protocols are built from a small vocabulary of structures, and once you can spot the vocabulary the blob stops being opaque.

Chapter 2, Capturing Application Traffic

Passive versus active capture, and why the distinction decides what you can learn. Passive capture is a tap: it costs the target nothing, it sees exactly what went past, and it is useless against anything encrypted. Active capture puts you in the middle, which means you can terminate TLS, but also that you have changed the thing you are measuring.

In a CTF the capture is usually handed to you, which makes this chapter feel skippable, and then it turns out to matter anyway: knowing whether a capture was taken at a tap or at a proxy tells you whether missing packets are lost or were never sent, and whether the client you are looking at is the real one. Start a capture challenge with pcap triage and the pcap overview.

Chapter 3, Network Protocol Structures

The chapter this whole book is worth buying for, and the one four of our modules point at. It is a catalogue of the parts protocols are made of, with the byte patterns each one produces.

• Numeric data - width, signedness, and the endianness that decides whether 0x0100 is 256 or 1.
• Booleans and bit flags, where one byte carries eight independent answers.
• Text, and the encoding question underneath it: ASCII, UTF-8, UTF-16, and length-prefixed versus terminated.
• Variable-length integers, where the high bit of each byte says whether another follows.
• Variable-length data, either terminated by a sentinel or preceded by its own length.
• The tag-length-value pattern, which is how a protocol stays extensible - and how a parser gets told to allocate four gigabytes.

Learn to recognise those six on sight and most unknown formats become tractable. A repeating three-part rhythm where the middle field predicts the distance to the next one is TLV, and everything after that is naming the tags. Bytes that look like ASCII with a length in front of them are a string table. This is exactly the reading reversing a binary protocol does, and the struct pack and unpack tool and the hex viewer are where to do it.

Chapter 5, Analysis from the Wire

Method applied: take a capture of a real chat application, and work out the protocol from nothing. He does it by diffing - send a known message, capture it, send a slightly different one, capture that, and see which bytes moved. It is the same technique that solves format challenges, and it is more reliable than staring at a hex dump because it changes one variable at a time.

The other lesson is about session state. A protocol's early packets usually establish something - a version, a session identifier, a key - that everything after it depends on, so a capture that starts mid-conversation may be unanalysable no matter how long you look. Check the start before you commit an hour. Following a TCP stream is the fastest way to see whether you have the handshake.

Chapter 6, Application Reverse Engineering

What to do when the traffic will not give up its secret: go to the program that generates it. He covers both managed code, where the disassembly is close to source, and native binaries, where it is not, and makes the case that this is usually faster than pure traffic analysis when custom encryption or obfuscation is involved.

The specific advice worth internalising is where to look. You are not reading the whole binary; you are looking for the call to send or the call to encrypt, and then reading backwards from it. That gets you to the serialiser, and the serialiser is the protocol specification. For managed targets reversing managed code applies directly, and for native ones reading a binary plus the ELF and PE analyzer.

Chapter 7, Network Protocol Security

The chapter three cryptography modules cite. It is a survey rather than a course: symmetric and asymmetric algorithms, modes of operation, signatures and key exchange, framed by what a protocol needs from each. That framing is what makes it useful next to a mathematics-free treatment like Designing Secure Software - Forshaw is concerned with the wire format, so he is explicit about where the IV goes, what the MAC covers, and what happens when a protocol authenticates the plaintext instead of the ciphertext.

For challenge work the payoff is in recognising a home-grown protocol's mistakes: an IV that is a counter starting at zero, a MAC over the message but not the header, a key derived from something the client also sends. AES and block cipher modes covers the mode failures, and decrypting a TLS capture handles the case where you were given the keys.

Where it stops

The book is built around Canape Core, the author's own .NET analysis library, and the practical exercises use it. That has not aged well and you should treat the code listings as pseudocode; the concepts underneath are unaffected. Its worked example is a custom chat program written for the book, which is clean but tidier than the protocols you will actually meet.

It is also pre-2017 on transport security, so the TLS material predates the current version and the modern encrypted-by-default internet. The structural chapters have not aged at all.

What to take into a challenge

Diff before you decode. Whenever you can make the target produce two outputs that differ in one known way, do that first: the bytes that change tell you where your field is, and the bytes that do not tell you what the framing is. It works on protocols, on file formats, on ciphertexts and on anything else where you have a generator and a mystery.