The shape of an answer
In 2001 I wrote a short paper for SANS on ICMP crafting. I thought I was writing about a protocol. I was actually working out how to ask a question carefully — and how much a careful answer reveals.
The name of this blog is a PING reference. Not a subtle one — it is right there in the title. But the reason it is a PING reference is worth explaining, because it is not just nostalgia for a protocol.
In 2001 I was interested in what ICMP echo responses could tell you beyond the obvious. The obvious thing an echo reply tells you is that the host is up. What I was interested in was everything else: the TTL on the return packet, the response latency under crafted payloads, the way different implementations handled fields they were not supposed to care about. ICMP was, in theory, a simple ping-pong. In practice, every implementation made small choices that were not in the RFC, and those choices were legible if you asked the right questions.
The paper I wrote for SANS that year was a practical survey of that territory. I will not pretend it was a landmark contribution — ICMP fingerprinting was not a new idea in 2001, and smarter people than me had been poking at it for years. What writing it gave me was something more durable than the findings themselves: a way of thinking about the relationship between a question and an answer.
The protocol as a lens
Here is the thing about PING that I keep coming back to. Mike Muuss designed it as a diagnostic tool — a way to verify that a network path existed and that a host was reachable. The question it asks is binary: are you there? The answer it expects is equally binary: yes, here is your packet back.
But the answer is never just binary. Every reply carries a timestamp, a TTL, a payload echo. The implementation decides how to handle the edge cases: what to do with an oversized payload, how to respond to a crafted identifier, whether to preserve the data field exactly as received. None of those decisions are security decisions, in the sense that nobody sat down and wrote a threat model for the ICMP echo handler. They are just implementation decisions, made by someone who was solving a different problem entirely.
And yet those decisions are readable. A system tells you something about how it was built every time it answers a question it was not designed to think carefully about. That is the insight I keep finding useful, long after the specific ICMP findings have aged past relevance.
How it became a method
I came to security research sideways, the way most people of my generation did. In 1994 I started my first proper job — University College Scarborough, running systems that were emphatically not designed with security in mind, because nobody's were. I learned to read behaviour before I had a vocabulary for it. You watched what a system did when you pushed it slightly past its intended use. You noticed the things that did not match the documentation. You wrote them down.
The ICMP paper was the first time I tried to formalise that habit. Take a protocol. Understand what it was designed to do. Craft inputs that are technically valid but live at the edges of the specification. Read the responses carefully. The vulnerabilities, if there are any, tend to live in the gap between what the specification says and what the implementation assumed.
That is still, in 2026, the method I use. The protocols and systems have changed completely. The habit of mind has not. I am still sending pings and reading the shape of what comes back.
Why the blog is named after a diagnostic packet
When I started this blog I wanted a name that captured something true about how security research actually works, as opposed to how it is sometimes portrayed. It is not primarily about exploits, or about finding spectacular things. It is mostly about asking careful questions and paying attention to the answers you were not necessarily expecting.
A PING is the most unassuming possible question. It does not try to authenticate, or negotiate, or prove anything. It just says: are you there? And then it listens.
Every piece of research I have done that was worth anything started from something like that posture. Not: I know what I am looking for. But: I am going to ask this carefully and see what comes back. The 2001 ICMP paper was where I first wrote that down as a method rather than just doing it by instinct.
That paper is Chapter 2 of my forthcoming book on macOS security research methodology, alongside the six-phase framework it eventually grew into. But the ICMP work is where the framework started, and the blog name is its acknowledgement.
What still holds
The specific techniques in the 2001 paper are history. Modern network stacks are hardened, and ICMP fingerprinting as a meaningful attack surface has long since been addressed. I am not writing this to revive it.
What holds is the underlying observation: that implementation decisions made by people solving one problem become legible to people asking a slightly different one. This is true of ICMP. It is true of the kernel interfaces I spend my time on now. It is true of every protocol, API, and trust boundary in any system complex enough to be interesting.
The gap between specification and implementation is where security lives. You find it by asking carefully. You read it in the shape of the answer. That has not changed in twenty-five years, and I doubt it will change in the next twenty-five.
Mike Muuss named PING after the sound a sonar pulse makes when it finds something in the dark. The sonar operator is not listening for the ping itself — that is just the question going out. They are listening for the echo, and reading everything they can from its shape and timing and what it is not quite saying.
Twenty-five years on, I am still the sonar operator. The water has changed. The pulse works the same way.