Introducing MacCrab Rave: the macOS forensic app store

MacCrab has a plugin store.

It's called Rave, it lives at rave.maccrab.com, and it serves a signed catalogue of forensic plugins for MacCrab, the local-first Mac security tool I wrote about building in April. The first plugin is Mac Security Posture Pro, which gives you a graded hardening report and an evidence inventory of the machine in one run.

The name is inspired by Noisestorm - Crab Rave.

Where the idea came from

The inspiration isn't a security product. It's desktop apps like Bambu Studio, where the store lives inside the app: you browse, you click Install, and the thing just works, with no browser, no downloads folder, no dragging files about. I wanted installing a forensic collector to feel like that.

Other great security tools have similar third-party plugin capabilities, e.g. Burp. Rave is an attempt to have both: one-click installs in front, and a supply chain anyone can audit.

What plugins give MacCrab

Since April, MacCrab has grown a forensics side: collectors that snapshot parts of a Mac into structured evidence records for incident response. Plugins are how that side grows from here, and they change what MacCrab is in the process.

The first reason is speed. macOS artifacts move constantly: Biome has taken over much of what knowledgeC used to hold, the TCC schema shifts, new persistence locations appear with each release, and EDRs, MDMs and internal agents leave their own local state behind. A collector compiled into MacCrab ships when MacCrab ships. A plugin can ship the week the artifact changes.

The second is breadth. I'll never write every collector people need. Some will be EDR-specific, some MDM-specific, some for the odd internal agent an organisation deployed in 2019 and forgot about. The people who need those collectors are usually the people best placed to write them.

The third is flexibility. With collectors installable per case, MacCrab doubles as a forensic collector in its own right: put it on a machine, install the collectors the investigation needs, run them, and leave with structured evidence. The monitoring side doesn't have to be the point. The app becomes a platform you equip for the job in front of you.

And underneath all three, the trusted core stays small. Every collector compiled into the app is more code a user has to trust. Plugins let capability grow without the trusted core growing with it, but only if something carries the trust boundary properly. That something is Rave.

The first plugin: Mac Security Posture Pro

Run it and you get two views of the machine. The first is a graded hardening report: a practical read on the Mac's security posture. The second is an evidence inventory: one row per relevant local artifact, covering login items, extensions, persistence entries, configuration profiles, quarantine events, TCC grants and related security state. On my Mac, a normal run produced 409 evidence rows across seven content types.

The distinction matters. A grade is useful, but evidence is what makes the result explainable. If the plugin says something is risky, you can see the artifact behind the claim. If it finds persistence, you get the path. If it sees a TCC grant, you know which service, which client, and where the record came from.

This is a further iteration of the existing posture grading system available in the overview but with a forensic level of detail.

Why a plugin store needs a trust model

Forensic plugins are exactly the software you should be suspicious of installing. Their job is to read the parts of a Mac attackers care about most: persistence locations, privacy databases, login items, browser state, configuration, security controls. A malicious collector doesn't need to escalate anything; it's already pointed at the interesting places. And it runs in the worst possible context: mid-investigation, on a machine that may already be compromised, operated by the person with the most reason to trust their own tooling. Going after responder tooling isn't a hypothetical, it's an established pattern.

So "download this binary from a README and hope" was never going to be the distribution model. Signing keys live offline and never touch CI; releases are signed in a manual ceremony, which is slower than automation, and that's the point. Each catalogue file carries a detached Ed25519 signature you can check against a published public key with a few lines of Python. Each plugin version pins the digest of its artifact, manifest, signature and built bundle. Each publisher's key is pinned to their entry, so the same key has to sign every version. Revocation is signed. Plugins are declared read-only and network-denied, with output that is metadata only: verdicts, counts, paths and structured evidence, never file contents. Vetting checks the binary against those declarations, builds have to reproduce, and the catalogue records the results per version.

There's no account required, no server-side trust decision, no telemetry and no backend the app depends on. Static signed files, all the way down.

Building all of that for a catalogue this young might look like overkill. I think it's the only sensible time to build it. npm, PyPI, the browser extension stores and the editor marketplaces all had to bolt on signing, provenance, two-factor requirements and abuse response after their ecosystems were already worth attacking, and every one of those retrofits was slow and painful. Right now Rave's trust model is cheap to build, cheap to break and cheap to fix. That window doesn't last. The store is the delivery mechanism; the trust model is the product.

Built for disconnected places

A lot of forensic work happens where the internet isn't. The machine you're examining has been deliberately unplugged. The IR VLAN has no egress on purpose. The lab was air-gapped before you arrived. A plugin store that assumes a live connection to a vendor domain is useless in exactly the situations forensic tooling exists for.

Rave assumes nothing of the sort. Because the catalogue and its artifacts are static signed files, you can mirror the whole tree onto a host inside your boundary, or onto localhost, and point MacCrab at it: the catalogue source in the app's settings is a plain URL field. Verification is identical either way, because the app checks the signatures and the pinned digests, not the domain they came from. rave.maccrab.com is the default, not a dependency.

What you can verify today

An invitation to verify should say what verification currently covers. Today, anyone can check the live catalogue signatures against the published public key, check the digests against the live artifact, and run the verification recipe end to end against the live plugin. That recipe passes, and I check it as part of release.

The gap: Posture Pro itself isn't currently rebuildable from public source. Its source-commit fields are zeroed in the catalogue on purpose, and the docs say so. That will be rectified in future releases. The exemption is for the first-party plugin only; community plugins will require public source, and the reference plugin below shows the expected shape. I'd rather list that gap myself than have someone find it.

In the app

MacCrab v1.21.3 or newer is the right baseline. The catalogue nominally reaches back to v1.19.0, but the install-and-run path landed across later releases, so older versions are archaeology.

This is where the Bambu Studio part pays off. The Forensics catalogue tab shows the feed as signed and verified, checks revocation freshness, shows the publisher key as pinned, knows installed from update-available, and runs the plugin from a button. Installing takes one click, or a terminal command if you prefer:

The storefront behind it is deliberately plain. The first version had search, filters and an "N of N shown" counter, the usual marketplace furniture, and a review pass by a small fleet of Claude agents called it absurd, which it was. Each plugin page now leads with the questions I'd ask before installing forensic code: what it reads, how it runs, who signed it, which key is pinned, and how to verify the artifact yourself. The store's one law came out of the same cleanup: nothing appears in the catalogue unless it can be installed, verified and run.

Submissions are open

Community plugins are the eventual point of Rave, and the submission path is open now. Your source stays in your own public repo; submitting opens an owner-reviewed vetting pull request; your plugin is rebuilt in a network-denied sandbox and must match your published artifact; the manifest must match what the binary actually does; and nothing goes live until the catalogue is re-signed. The submission form asks for nine fields rather than the fifteen it started with, because most of the deleted ones asked authors to hand-type facts the vetting pipeline derives from the code anyway, and every hand-typed security claim is a chance to be wrong or to lie.

To make sure the path works from the outside, I built a community plugin the way an outsider would have to: login-items-lite, a small Swift collector that lists launchd daemons and agents, the classic login items, with a code-signing verdict on each. It's read-only, network-denied, reproducibly built, signed with its own author key, and it lives in com.example.* because com.maccrab.* is reserved. It's public on GitHub as the reference for what a good submission looks like, and I hope someone forks it into something better than mine. Before opening submissions I walked a real one end to end, through the same gates a stranger's code will face. That walk found bugs; more on those below.

The half of the door that stays shut, for now, is execution: MacCrab doesn't yet run community plugins. That lane arrives in a later release, once the containment that confines a community plugin to what its manifest declared has been tested properly by people who aren't me. That's a trust decision, not a missing feature.

The first week, briefly

Launch week found real bugs, including in the install path and the public verification recipe. One of them is worth touching on, as I'd deem it a successful failure.

For most of its short life, Posture Pro produced nothing inside the app. Not an error: nothing. I rewrote the plugin twice chasing it, once to add the evidence inventory, once to move collection in-process, and the row count stayed at zero. The actual cause was on the other side of the trust boundary. The app grants the first-party execution lane by checking the publisher key against a pinned fingerprint, and that pin was still an unset placeholder from when the gate first shipped. The gate failed closed, exactly as designed, and quietly refused every plugin, including one signed with my own key. Setting the pin in v1.21.2 took the same scan from zero rows to the 409 in the screenshot above. The second fix mattered as much as the first: the gate now says why it refused.

That's the lesson I'd pull out of the whole week. Every trust boundary needs two behaviours: it needs to fail closed, and it needs to say why. A gate that fails closed and silent doesn't look like security. It looks like your code doesn't work.

Where things stand

Rave is live at rave.maccrab.com. Posture Pro is installable today: the catalogue verifies, the publisher key is pinned, revocation is checked, and the plugin produces structured evidence in the app.

The boring facts, because every launch thread asks within the hour: MacCrab is Apache 2.0 and needs macOS 13 Ventura or newer; Rave is free; Posture Pro is free as well, first-party, with source not yet public; the reference plugin lives at github.com/peterhanily/maccrab-plugin-reference and the verification docs are at rave.maccrab.com/docs/verification/. As always, Claude and Codex were the tools used most throughout the build.

If you run MacCrab, install Posture Pro and run the verification recipe against the live artifact. It passes now, and I check. If any step fails, don't install it; tell me instead.

I'll be launching more plugins soon so watch this space.