In 2001 I submitted a short paper to SANS on ICMP echo behaviour — the humble ping, the original "are you there?" of network diagnostics. I was interested less in what the echo said than in what it implied: that a machine could be known by its response, or by its silence, long before it said anything useful. The name of this blog is a nod to that paper. I am still, twenty-five years later, sending pings and reading responses.
The technique I want to describe here is methodologically the same thing, applied to source code rather than network packets. You send a query to a neighbouring system. You read what it says back. You go looking in Darwin to find whether the same thing is true there.
The lineage problem
macOS runs on Darwin, which is Apple's open-source Unix-like operating system. At Darwin's core is XNU — the kernel — which is itself a hybrid: a Mach microkernel, a BSD layer that shares substantial code ancestry with FreeBSD and OpenBSD, and an I/O Kit framework for drivers. Apple publishes XNU source on opensource.apple.com, which is genuinely useful.
What Apple does not publish is an annotated security changelog for the BSD layer. Apple Security Advisories document what was patched in a given release. They do not document which BSD-lineage functions were reviewed, which were inherited unchanged from a FreeBSD commit made in 2009, or which advisories from the OpenBSD security errata page were considered and found not to apply to Darwin.
That gap is where the technique lives.
The shared codebase, briefly
FreeBSD and OpenBSD both maintain public security advisory streams. FreeBSD's is at freebsd.org/security/advisories; OpenBSD's errata pages are at openbsd.org/errata.html, organised by release. Both go back to the mid-1990s. Both are indexed by CVE where one was assigned. Both describe the affected subsystem precisely.
Darwin's BSD layer draws most heavily from FreeBSD, with some code also sharing ancestry with OpenBSD. The proportion varies by subsystem — networking code, the VFS layer, process credential handling, and the audit subsystem all have identifiable shared lineage. The XNU source itself contains FreeBSD: attribution comments in many files, which is a reliable guide to where the cross-reference is likely to yield results.
The core claim: if a security-relevant bug was found and fixed in FreeBSD or OpenBSD in a subsystem whose code Darwin shares, there is a non-trivial probability that:
- the same bug exists or existed in Darwin;
- it was fixed independently in an Apple Security Advisory (in which case you have a cross-reference to cite);
- or it was not fixed, and the advisory is your starting point for investigation.
In either case, you have learned something. That is the point.
The technique in practice
The workflow has four steps. None of them require access to anything that is not publicly available.
Step 1 — Select a subsystem
Pick an area of Darwin where you already have some orientation. The BSD layer is large; the technique works best when you are not reading advisory descriptions entirely cold. Good starting subsystems include the VFS layer (bsd/vfs/ in XNU source), process credentials (bsd/kern/kern_proc.c, bsd/kern/uipc_syscalls.c), the socket layer, and the audit framework. All have clear FreeBSD ancestry and active advisory histories in the FreeBSD security archive.
Step 2 — Pull the FreeBSD advisories for that subsystem
FreeBSD advisories are available as plain text and are well-structured. Each names the affected component, the nature of the flaw, and the patch. A search across the archive for the subsystem name — vfs, kern, socket, credentials — gives you a list of candidate advisories.
Example: searching the FreeBSD advisory archive for kern_proc or setuid yields advisories going back to the late 1990s covering privilege handling in the process credential subsystem — precisely the area Darwin shares most directly.
Step 3 — Locate the equivalent code in XNU
Once you have a FreeBSD advisory describing a flaw in a named function, you locate the equivalent function in XNU source. This is usually straightforward for BSD-layer code. The function names are often identical; where they have diverged, the FreeBSD: attribution comment in the XNU file usually identifies the ancestral path.
$ grep -r "FreeBSD" xnu-*/bsd/kern/kern_proc.c | head -5
/* Copyright (c) 1995-1996 Gary Beihl. All rights reserved. */
/* Copyright (c) 1982, 1986, 1989, 1991 Regents of the University of California */
/* $FreeBSD: src/sys/kern/kern_proc.c,v 1.55 ... $ */Once you have the function, read it against the advisory's description. The question you are asking is: does the logic described in the advisory exist in this version of the function? Has the fix been applied (check Apple Security Advisories for the function name)? If not, is the Darwin code path reachable under the same conditions?
Step 4 — Document, do not assume
This is the step that turns a cross-reference exercise into research rather than speculation. Three outcomes are possible:
| Finding | What it means | Next step |
|---|---|---|
| Apple advisory references the CVE | Apple independently found or tracked it; fixed in a known release | Note the version delta; record as confirmed patched |
| Code diverged significantly before the BSD fix | Darwin may never have been vulnerable, or the fix is implicit | Document the divergence point; low priority |
| Code matches; no Apple advisory references the CVE | Candidate for investigation — not a confirmed vulnerability | Build a PoC; check current source; file only if reproducible |
The third outcome is the interesting one, and it requires the same rigour as any other finding: a working proof-of-concept, current source verification, and an explicit argument for why the condition is reachable and the impact is material. The cross-reference gives you a starting hypothesis, not a report.
Why this works for a solo researcher
Teams at well-funded security firms generate leads through continuous fuzzing campaigns, internal tooling, and the accumulated institutional knowledge of people who have been reading the same codebase for years. Solo researchers — doing this between a day job and a family, at 2am with a cup of tea going cold — do not have that pipeline.
What we do have is the same public record that every researcher has, and the time to read it carefully. The BSD advisory archive is, in effect, a curated list of the kinds of things that go wrong in exactly the code that Darwin inherits. It is a gift, if you know how to use it.
I have used this technique to identify several candidate areas worth looking at in XNU. Some yielded nothing interesting. A few became findings. The ratio matters less than the fact that the technique is systematic, reproducible, and produces a paper trail that makes the research defensible — which matters both for responsible disclosure and for your own sanity when you are three hours into a rabbit hole at midnight and need to remember why you started.
A note on scope: this technique applies to the BSD layer of XNU — the portion with documented FreeBSD/OpenBSD ancestry. It does not apply cleanly to the Mach layer, to Apple-original subsystems (TCC, notarisation, Gatekeeper, the Endpoint Security framework), or to the IOKit driver model, all of which have their own research approaches. Those are different posts.
Practicalities
A few things that make the technique more tractable:
- The FreeBSD advisory index is at
https://www.freebsd.org/security/advisories/and each advisory has a stable filename (FreeBSD-SA-YY:NN.component.asc). They are plain text, grep-able, and small. - The XNU source archive on
opensource.apple.comgives you every released version. Comparing a function across two XNU versions is a useful way to determine whether a change was made, even if it is not referenced in an advisory. - CVE records for the FreeBSD advisories give you the NVD descriptions, which sometimes include affected version ranges that clarify whether a Darwin version would have been contemporaneous with the flaw.
- The OpenBSD errata pages cover slightly different code in some areas (the networking stack, in particular) and are worth including in the survey even where FreeBSD is the primary reference.
I cover this technique in more detail — with worked examples and a structured template — in Chapter 8 of my forthcoming book on macOS security research methodology. The book is about the discipline of the work as much as the technical content; this post is a preview of one of its more practically useful sections.
The ICMP echo was designed to ask a simple question — "are you there?" — and receive a simple answer. What made it useful was not the answer itself, but what you could infer from the latency, the TTL, the pattern of response and silence. In 2001 I wrote about what a machine reveals when you ping it. In 2026 I am still reading responses, just from different sources.
The BSD advisory stream is a system that has been quietly answering questions about shared code for thirty years. It is worth asking it your questions before you assume silence means the problem does not exist.