Vision

The manual page for airportd, the daemon that runs Wi-Fi on every Mac, is 13 lines long and was last revised in 2006:

$ man airportd
airportd(8)              System Manager's Manual              airportd(8)

NAME
     airportd – airport daemon

SYNOPSIS
     airportd

DESCRIPTION
     airportd manages wireless interfaces.  airportd should not be invoked
     directly.

macOS 26.5                     7/5/2006                       macOS 26.5

The binary those 13 lines describe is a universal Mach-O carrying an arm64e and an x86_64 slice; the macOS 26.5 build of it is 3,220,640 bytes. Reading it — never running it — takes 10.4 seconds on an Apple Silicon laptop and returns, among other things, these:

$ openbinary airportd          # excerpts from one 24,848-line report

  Classes:            37
  Methods:            1593
  Frameworks:         37
  Private frameworks: 15
  XPC services:       14
  Telemetry strings:  118
  Function starts:    2793 (from LC_FUNCTION_STARTS)
  Imports:            811 (185 weak, 0 lazy)

── Capabilities (40 from entitlements, 33 from frameworks) ──

  [LOCATION]
    com.apple.wifi.bypass-location-services — Access WiFi-based location
        without user consent
  [KEYCHAIN]
    com.apple.keystore.sik.access — Access Secure Enclave sealed keys (SIK)
  [STORAGE]
    com.apple.private.security.nvram.wifi-psks — Read and write WiFi
        pre-shared keys in NVRAM

── Unmapped Entitlements (9 — not in knowledge base) ──

    com.apple.AppleNVMeEAN.allow
    com.apple.keystore.fdr-access
    com.apple.private.ZhuGeSupport.CopyValue
    com.apple.private.wifid.host.network
    com.apple.private.wifid.interface.management
    com.apple.private.wifivelocity
    com.apple.rootless.volume.iSCPreboot
    com.apple.security.iokit-user-client-class
    com.apple.security.temporary-exception.iokit-user-client-class

── Credentials (5 CWKeychain + 0 keychain sites) ──

  Wi-Fi PSK / EAP credentials: CWKeychainDeleteWiFiPassword,
  CWKeychainFindWiFiPassword, CWKeychainSetWiFiEAPIdentity,
  CWKeychainSetWiFiEAPUsernameAndPassword, CWKeychainSetWiFiPassword

── telemetry (118 entries) ──

  Destinations: {CoreAnalytics: 2, CoreWLAN-analytics: 14, Symptoms: 2,
                 WiFiAnalytics: 12, WirelessDiagnostics: 8,
                 wifianalyticsd: 2, other: 56}

  -[CWAnalyticsManager submitPowerState:]
  -[CWAnalyticsManager submitWiFiAnalyticsMessage:]
  -[dpsManager submitDpsSymptom:isCriticalApp:]_block_invoke

That is one slice, not the file. The architecture is auto-detected from the header and only the host slice — arm64e here — is analyzed, so the x86_64 slice contributes nothing to those counts.

None of the above is in the documentation. None of it is a vendor claim either, but the lines differ in how far they are facts:

What the daemon is reported to do

Seven behavior rules fire on airportd, all at informational severity, and each is a conjunction of an import and an entitlement rather than a traced dataflow:

So: a process on your machine can locate you without a consent prompt, holds your Wi-Fi passwords, has the entitlement to write them into NVRAM, sends strings to named analytics destinations — and voluntarily confines itself at startup. The output is an indicator set, not a verdict.

That is the situation for every binary on every machine. Processes nobody outside the vendor has read decide what touches your files, your network, your keychain, your camera. Parts are one command away — codesign -d --entitlements - prints all 49 entitlement keys, otool -L the 37 frameworks — but not the categorization, the descriptions, the cross-reference of entitlement against import, the XPC surface, the telemetry submitters or the call graph behind them. Reaching those meant manual disassembly: one binary, one specialist, days of work. So almost nothing gets looked at.

A compiled binary is not a sealed box. It is an unread document, and reading it can be automatic, fast, and open to anyone who can ask a question.

Reading without execution

Behavior is recovered from the bytes, and no instruction from the subject ever reaches the CPU: no sandbox, no VM, no instrumented run, and no network call anywhere in the analysis path. Where a value exists only at runtime — a string decrypted at startup, an API name resolved from a hash, a packed config — a bounded interpreter walks the lifted intermediate language instead of the processor (Emulator). The bounds are fixed per driver:

Exhausting a budget discards the run's result rather than truncating it: a partial decrypt is dropped, not surfaced.

Decoder coverage

Coverage is broad against enumerated specifications and thin against files that have actually shipped (Architectures):

Analysis cost and scale

Reading a binary costs seconds, so the unit of work stops being a binary and becomes a machine, a firmware image, a fleet — every file unpacked from a vendor image, every host in an organization, every version of the same product side by side. Not one analyst on one binary over days.

Measured on an idle Apple Silicon laptop; the figures move by more than half again under load.

The MCP tool surface

48 MCP tools sit over the corpus — corpus search, per-function decompilation, call-graph reachability that returns the witness path rather than a yes — so an agent can ask its own follow-up questions instead of receiving a report someone else scoped. It stops being a craft and becomes a query. Not all 48 are open doors:

Reachability answers carry their own limit. A reachable: false is trustworthy only when the search also reports complete: true — frontier fully resolved, not truncated, roots found. On an Objective-C or XPC daemon it usually is not, because objc_msgSend, dispatch_*, xpc_* and block edges cannot be followed: on airportd itself, a no is not an answer. The tool returns the unresolved call sites and the dispatch boundaries that caused it.

Source reconstruction

openbinary reconstruct turns airportd into a Rust project, because understanding is not the end state: 59 source files, 85,519 lines, all 1,593 recovered methods emitted, none stubbed, zero unrecovered IL operations.

Roughly 18% of the line count is generated scaffolding rather than recovered code. Here is one recovered method, the analytics submitter named in the telemetry list above, elisions marked:

// selector: -[CWAnalyticsManager submitPowerState:]
fn CWAnalyticsManager_submitPowerState(mut arg0: AnalyticsManager, mut arg1: bool) {
    let mut x0: u64 = 0;
    #[allow(non_upper_case_globals)] const sp: u64 = 0;
    let mut x0: u64 = (class!(WAMessage)) as u64;
    x0 = (func_0x1000e0c9c()) as u64;
    x0 = (func_0x1000e7900()) as u64;
    if x0 == 0 {
        let mut arg10_cstr = 0x1001390b8u64 /* "-[CWAnalyticsManager submitPowerState:]" */;
        unsafe { *((((((sp as u64).wrapping_add(16)) as u64).wrapping_add(8)) as usize) as *mut u64) = (&arg10_cstr as *const _ as usize) as u64; }
        let mut x0: u64 = (4) as u64;
        x0 = (func_0x1000dfdfc(x0, 0x100139078u64 /* "<%s[%d]> %s: %s: Failed to alloc WAMessage for ..." */)) as u64;
        return;
    } else {
        x0 = (class!(NSNumber)) as u64;
        x0 = (func_0x1000e99c0()) as u64;
        // ...
    }
}

The class is named, the selector is named, the branch structure is the original branch structure, and the log strings are resolved back to their literals.

Reconstruction limits

What is missing is everything above the machine level — and, on Mach-O, a third of the functions.

• Unnamed functions are dropped, not stubbed — 1,040 of the 2,793 functions in LC_FUNCTION_STARTS carry no symbol name, and the Mach-O scaffolder skips every one on the assumption that a nameless function is runtime or standard-library code. That is why src/functions/mod.rs is empty and a stripped Apple daemon reconstructs to Objective-C methods and nothing else. PE and ELF are not filtered.

• Callee names are known but not applied — 1,675 distinct call targets emit as func_0x…; for 97.7% the name was already recovered, and the text report names the callees of the method above. By the section each target address falls in:

  Callee section	Targets	Name already recovered as
  __objc_stubs	1,403 (83.8%)	the selector, printed by the same run as objc_msgSend$initWithMetricName:options:
  __auth_stubs	233 (13.9%)	an import resolved through the chained-fixups table
  __text	39 (2.3%)	nothing — genuinely unnamed

• Every callee is a no-op — all 1,675 are defined in types.rs as bodies returning zero, called from 16,075 sites in the class modules; the class! macro expands to 0u64 at a further 1,607 sites. Fixing the compile errors would still leave the project inert at every cross-function boundary.

• Types — values are still registers typed u64.

• Stack frames — there is no modelled frame behind the stack pointer, so sp is bound to the constant zero and the store above writes the format-string argument to address 24: syntactically Rust, semantically a null-page write.

Compilation status

openbinary verify runs cargo check over the generated project, and every coverage metric reads perfect while the project does not build. It reports class coverage 100%, method coverage 100%, lift ratio 100%, total unknowns 0 — and then:

Compiles:         NO
Errors (4658):
  error: `<<` is interpreted as a start of generic arguments for `u64`, not a shift
  error[E0425]: cannot find value `lr` in this scope
  error[E0061]: this function takes 6 arguments but 2 arguments were supplied

Total unknowns: 0 counts unrecovered IL operations only: the same run's project manifest records 74 unresolved class references against 1,607 resolved, and the emitted source carries 74 /* UNKNOWN classref */ sites.

Every one of the 37 class modules carries errors, concentrated in the XPC surface:

4,605 of the 4,658 attach to a source file, and the largest single class — 2,923 — is E0061, a callee stub declared with the arity of one call site and called with another. The no-op stubs are the compile failure, not a separate problem beside it.

The bet is that this distance closes — that a binary gets reconstructed into source you can read, diff, and rebuild, so a closed implementation stops being something you are required to trust. Today the output is a faithful skeleton whose joints all return zero.

Open binaries and hardware sovereignty

Every binary open: readable, searchable, auditable, comparable across every version, whoever shipped it.

And then the part that started it: sovereignty over hardware you already own. Take the best silicon made and refuse the software that shipped with it — Apple-silicon Macs on Linux, keeping the parts that are actually used, AirDrop and AirPlay and the AirPods and iPhone handoff, recovered from their binaries and reimplemented in the open. Porting to each new chipset becomes a pipeline step rather than a multi-year effort. None of that exists yet; it is the reason the reconstruction target is Rust — the same language a reimplementation would be written in, so analysis and replacement are one pipeline run to different depths.

Preconditions

Three conditions had to hold at once: a fast self-contained stack, a never-execute discipline, and consumers that read structured facts.

• A fast, self-contained stack — a decoder and lifter fast enough that reading a binary costs seconds rather than days, with no network dependency anywhere in the analysis path. It ships as three binaries: an operator CLI that needs no server; a coordinator that serves the API and MCP and owns the corpus, accounts and job stores but spawns zero compute of its own; and a worker that runs the engine pool and takes every analysis, reconstruction and unpack job. A coordinator with no worker analyzes nothing.
• A never-execute discipline — the subject is never run, so the same pipeline is safe to point at malware and at a vendor's signed system daemon.
• Consumers that read structured facts — language models and the agents built on them, which is what makes a 24,848-line report on one Wi-Fi daemon usable by someone who has never read disassembly.

Product → · Roadmap → · Architectures →