Three months in
Thirty-five posts. Stuart didn't plan that — he planned one. What the discipline of writing up research regularly has done to the research itself. What it left open. The blog is still a PING into the dark.
How attackers see your network, Part 2: what the logs say
The inside view from the logs. What the honeynet record actually showed about attacker behaviour — the patterns, the scanning, the things that came back. The gap between what was intended to be visible and what was.
How attackers see your network, Part 1: the outside view
An attacker does not see your network the way you drew it on the whiteboard. They see what answers. Reconnaissance, banner-grabbing, and the gap between your network diagram and what is actually exposed.
The insurance company's pf estate
Somewhere, in a repository that no longer exists, is a CVS history of every firewall rule change made at an unnamed insurance company for about four years. What managing pf rulesets as code, at scale, taught about configuration discipline.
Binary analysis without symbols
Without symbols, a binary is not mute. It is speaking a different language — but you already know most of the words. What strings, import tables, function prologues, and structure reveal before you disassemble a single instruction.
The NFC handshake, Part 2: what the proof actually proves
The CMAC is correct. The key never leaves the chip. The counter increments. What the design actually guarantees — and its honest limits. What cloning means and doesn't mean for NTAG 424 DNA. Educational, from first principles.
The NFC handshake, Part 1: what happens in the air
Every contactless tap involves two simultaneous things: a transaction, and a proof. The proof is the interesting part. What happens in the RF field — the challenge, the response, the CMAC — and why the key-never-leaves design is the right choice.
Reading vendor advisories
A security advisory tells you what was fixed. It does not always tell you what was broken. Reading between those two things — cross-referencing commits, version ranges, CVE entries — is a research method in its own right.
Fuzzing: a week of noise
Fuzzing is not intelligence. It is patience with better tooling. What a week of fuzzing actually looks like — reading the output, the noise-to-signal ratio, what it finds that manual review misses, and vice versa.
How I set up a research box
The right research environment is one you trust completely — not because nothing can go wrong, but because you know exactly what going wrong looks like. Isolation, snapshots, tooling, and the discipline of keeping research separate from production.
The specification is a promise, Part 2: what happens when they break
The gap between a specification and its implementation is not always a bug. Sometimes it is. The skill is in telling the difference — when a security boundary has been crossed versus a benign divergence. BSD examples, from the source.
The specification is a promise, Part 1: what contracts look like
Every protocol begins as a document. The document is a set of promises. RFCs, man pages, vendor docs — how to read them as contracts, what MUST and SHOULD actually mean, and where security researchers should pay closest attention.
Reading a packet capture
A packet capture is a conversation, written down. The interesting questions are: who is talking, and what are they not saying? Wireshark and tcpdump as research tools — the gap between specification and what actually goes across the wire.
What the logs said
The Oracle honeynet generated more data in a week than could be read in a month. The discipline was not collection — it was interpretation. What the logs actually showed, and how to separate observation from conclusion.
The minimal reproducer
The bug is not the ten thousand lines that led to it. The bug is the twelve lines that prove it. The art of reduction — what the discipline of minimising a reproducer teaches you about the defect itself, and why it matters for the engineer who receives it.
Static analysis for the impatient
You do not have to run the code to know something is wrong. Sometimes the wrongness is right there in the text. Grep-driven research, pattern recognition in source, and what you can find without executing a single instruction.
Before the report, Part 2: writing it so someone can act on it
A report that cannot be acted on is a complaint. Three things: reproduction steps, impact statement, fix hint. Writing for the engineer who has to understand and fix it, not for the audience. Economy of language as a form of respect.
Before the report, Part 1: verifying what you actually found
The most dangerous moment in security research is when you think you've found something. The discipline of asking "am I actually sure?" — distinguishing real vulnerabilities from defence-in-depth, and why the minimal PoC is a verification tool first.
The 2am habit
There is a specific quality of attention that arrives around 2am. The distractions are asleep. The problem is not. What late-night independent research produces — and why working without external reason generates different thinking than daytime professional work.
Reading a kernel, Part 2: where the interesting bits live
Once you know where the rooms are, the question becomes: which doors are left ajar? Privilege transitions, input parsing, interface boundaries — the places in a kernel where trust changes hands, and where a careful reader pays closest attention.
Reading a kernel, Part 1: getting your bearings
Kernel source is not a book you read front to back. It is a building you learn to navigate. How to orient yourself in a production kernel for the first time — directory structure, subsystem mapping, finding the entry points.
The internet hotel
The data centre in Budapest had guards with AK-47s. Stuart knows this because he walked past them carrying patch cables. CityReach, the dot-com era, Europe by train with an Ericsson handset and early GPRS on Cellnet — managing a network estate from a moving carriage.
The first job
University College Scarborough, 1994. The first proper job. What computing looked like before the web swallowed everything — and what that environment taught about networks that still holds thirty years later.
Why I still read the man pages
A man page is a promise. The interesting question, for a security researcher, is whether the code keeps it. The gap between documentation and implementation is where the unveil(2) bug lived for eight years. On reading technical documentation as a research technique.
Ninety days
The 90-day standard is a number that has a human being inside it. What coordinated disclosure actually feels like from the researcher’s side: the acknowledgements, the silences, the two-word replies, the patches, the closures without comment. Warm and honest throughout.
The stone that knows itself
Genuine Whitby Jet has been imitated since the Victorian era. For 150 years, provenance was a matter of expertise and trust. NTAG 424 DNA NFC chips implement AES-128 CMAC authentication in hardware. The stone no longer just claims to be genuine — it can demonstrate it.
What a CVE doesn’t say
A CVE entry is a summary of a summary. The interesting material — the affected function, the commit that fixed it, the real-world trigger — lives in the references, not the description. How to follow a CVE back to the room where the secrets are kept.
Writing for the person who has to fix it
A vulnerability report is not written for the researcher. It is written for the engineer who has to understand it, reproduce it, fix it, and ship the fix. Three paragraphs, a minimal reproducer, the impact. Everything else is noise. On the craft of the good report.
Touch and go
Every time you tap your card on a London Underground barrier, something genuinely interesting happens in about 300 milliseconds. Stuart worked on TfL contactless payment architecture. This is what it looks like from the inside — and why the key that never leaves is the design choice that makes it all work.
The honeynet and the long wait
Setting a trap is the easy part. Stuart ran an Oracle honeynet long enough to develop a specific discipline: separating observation from interpretation, resisting the urge to intervene, and trusting the log as truth. The habits it built have lasted twenty years.
The open source that made this possible
Apple publishes XNU — the kernel at the heart of every Mac — as open source. They are not obliged to. They have been doing it for over twenty years. Every piece of macOS research on this blog depends on that decision. A warm acknowledgement of something that deserves one.
The unreasonable joy of it
Nobody asked me to do this. I read kernel source in the evenings, in Whitby, for fun. The bug had been in a #if 0 block for eight years. The reply from OpenBSD was two words. It was the best two words I'd read all week. On why independent security research is genuinely, ridiculously good fun — and why you might like it too.
Running tight
Twenty-five years of OpenBSD: from Snort on firewall hosts at CityReach to a large insurer running CVS-managed pf rulesets across a global estate, to reading the kernel source on a Mac Mini and finding two bugs now fixed and credited. On the OS that treats correctness as a discipline, not a feature.
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. This is where the blog gets its name.
The neighbours always answer
FreeBSD and OpenBSD publish a security advisory record going back decades. Darwin shares a great deal of code with both. A practical technique for using that public record as an annotated security changelog for XNU — one of the most underused starting points in solo macOS research.