Tracing what systems actually do

Operating systems are huge, and they change constantly. IPC interfaces, syscalls, state transitions that aren't written down anywhere. A lot of exploitable behavior lives in the gap between how a system is meant to work and what it actually does at runtime. That gap is what we look for, and we build tooling to check it version after version: what the system really does, not what the documentation claims.

We're a small lab, and we work on a short list of failure classes: IPC permission regressions, memory-management logic bugs, exploit primitives that hinge on system state. When we report one, it comes with enough evidence to show it's real and enough detail to fix it.

Our tooling: FARP and FALE

Automation doesn't find bugs by itself; it just lets one researcher cover far more ground. We run two in-house pipelines for that. FARP handles reconnaissance, working out what's there. FALE handles verification, confirming a finding actually fires.

Both are built for depth rather than coverage. They track changes in IPC surfaces and syscall behavior across macOS and iOS, which surfaces the kind of logic bugs that fuzzers and static analysis tend to walk straight past. Every finding ends up as a proof of concept that runs, so any fix we suggest is based on something we reproduced ourselves.

Research Signal // macOS

XPC services that don't agree with each other about permissions, and entitlement checks that quietly regressed from one release to the next.

OS Atlases: diffing the binaries

We keep machine-readable maps of the OS, called OS Atlases, built by diffing kernel binaries from one release to the next. They show exactly where something changed between two versions, and they give us a reference for what the system is supposed to be doing in the first place.

Owning our own stack

We keep outside dependencies to a minimum, on purpose. One stale third-party library is enough to undermine everything built on top of it. So our telemetry engines and hardened apps lean on as little external code as we can manage. Fewer parts we don't control means fewer ways in.

Why we do this

FARPSEC exists to find real problems, prove they're real, and help close them. We work with enterprise and government partners on infrastructure that has to hold up under pressure. We don't deal in vague risk scores. If we say something is broken, we can show it breaking.

Research comes first here, and the findings speak for themselves.