Kurz gesagt. Sichern Sie knowledgeC.db mit der zugehörigen -wal und den Biome-Ordner streams, legen Sie sie (oder eine ZIP) in KnowledgeC Parser ab, prüfen Sie den Tab Quellen, lesen Sie die Befunde, legen Sie einen Zeitraum fest und arbeiten Sie dann Sitzungen, Zeitleiste, Apps, Web und Biome ab. Exportieren Sie CSV, Timesketch-CSV oder JSON. Die Dekodierung läuft als WebAssembly in einem Web Worker in Ihrem Browser; die Dateien werden nie hochgeladen.

Dies ist das praktische Gegenstück zum Leitfaden zur forensischen Analyse von knowledgeC.db. Die Überlegungen hinter der Sitzungsanalyse finden Sie in Wer saß am Mac?. Die Beispiele nutzen das eingebaute Beispiel, das synthetisch und fiktiv ist: Es wurde für dieses Werkzeug erzeugt und stammt nicht aus einem echten Fall. Bezeichnungen in der Oberfläche können sich mit der Zeit leicht ändern; die Schritte bleiben dieselben.

Bevor Sie beginnen

Sie brauchen	Warum
`knowledgeC.db` + `-wal` (+ `-shm`), System und Benutzer	Jüngste Ereignisse stehen oft nur im WAL
Den Biome-Ordner `streams` mit intakter Struktur	Stream-Name, `local` / `remote` und `tombstone` ergeben sich aus dem Pfad
Den Pfadteil `Users/<name>/`	Das Werkzeug ordnet die Dateien diesem Konto zu
Einen aktuellen Desktop-Browser	Die Dekodierung läuft als WebAssembly in einem Web Worker

Schritt 1: Dateien sichern

Die Benutzerdatenbank (~/Library/Application Support/Knowledge/knowledgeC.db) und die Biome-Benutzer-Streams sind durch TCC geschützt: Der sammelnde Prozess braucht Festplattenvollzugriff. Die Systemdatenbank (/private/var/db/CoreDuet/Knowledge/knowledgeC.db) ist durch SIP eingeschränkt; ein Datenträgerabbild ist meist der sauberere Weg. Kopieren Sie die -wal- und -shm-Dateien mit jeder Datenbank und hashen Sie alles.

Befehle, Optionen für UAC und Velociraptor sowie deren Lücken behandeln knowledgeC.db und Biome: Speicherorte und Sicherung und die Sicherungsanleitung auf der Startseite.

Schritt 2: Dateien laden

Öffnen Sie die Startseite des Werkzeugs und legen Sie Folgendes ab:

einzelne Dateien (knowledgeC.db, knowledgeC.db-wal, SEGB-Dateien);
einen Ordner, zum Beispiel eine Kopie von Library;
eine ZIP einer Sicherung.

Um zuerst die Oberfläche kennenzulernen, klicken Sie auf Beispiel laden. Der Arbeitsbereich wechselt in den Vollbildmodus; mit Esc verlassen Sie ihn.

Das Beispiel ist ein fiktives MacBook, FIN-MBP-03, Benutzer dana.whitlock: eine System- und eine Benutzer-knowledgeC.db, jeweils mit -wal, und Biome-Dateien für App.InFocus (einschließlich einer älteren Tombstone-Datei und eines von einem iPhone synchronisierten Streams), App.WebUsage, Notification.Usage, Device.Metadata und App.MenuItem, sowohl in SEGB v1 als auch in v2.

Schritt 3: Den Tab Quellen prüfen

Bevor Sie irgendein Ereignis lesen, prüfen Sie, was dekodiert wurde:

Jede knowledgeC.db mit ihrer -wal verknüpft. Das Werkzeug liest die Datenbank so, wie SQLite sie nach Anwendung des WAL sehen würde, und vergleicht sie mit der Hauptdatei allein. Zeilen, die nur im WAL existieren, und Zeilen, die das WAL entfernt hat, werden markiert. Im Beispiel ist jede Systemzeile nach 10:00 UTC am 2026-09-14 nur im WAL vorhanden, und eine alte Zeile wird durch das WAL entfernt. Siehe Wiederherstellung aus dem knowledgeC-WAL.
Bereich: System- oder Benutzerdatenbank, abgeleitet aus dem Pfad.
Biome-Dateien: Stream-Name, SEGB-Version, local, remote/<device UUID> oder tombstone, Anzahl der Records je Status und CRC-Fehler.
Probleme: eine Datei, die mit Nullen beginnt (vermutlich im gesperrten Zustand kopiert), eine abgeschnittene SEGB-Datei oder eine SEGB-Datei, deren Stream-Name unbekannt ist, weil die Ordnerstruktur verloren ging. Die -shm-Datei wird aufgeführt, ist aber nicht nötig.

Schritt 4: Die Befunde lesen

Der Tab Befunde fasst zusammen, was auffällt. Behandeln Sie jeden Punkt als Spur: Öffnen Sie ihn, prüfen Sie die zugrunde liegenden Records und entscheiden Sie, ob er in den Bericht gehört. Das Beispiel ist so aufgebaut, dass sich folgende Spuren lohnen: eine entsperrte Sitzung während der Mittagspause, ein erstes Auftauchen von Terminal, gelöschte Biome-Web-Records und eine kurze Entsperrung mitten in der Nacht.

Schritt 5: Den Zeitraum festlegen

Ein eigener Zeitraum hält alle Tabs auf dasselbe Zeitfenster fokussiert:

Bedienelement	Verwendung
Von / Bis	Sekundengenau setzen, zum Beispiel 2026-09-14 10:00:00 bis 10:55:00 UTC
Voreinstellungen	Schnell wählbare Zeiträume
Um dieses Ereignis	Zentriert den Zeitraum auf ein ausgewähltes Ereignis
Dichteleiste	Zeigt, wo sich Ereignisse häufen, um Spitzen und Lücken zu erkennen

Der Zeitraum wird im URL-Hash gespeichert, sodass eine Kollegin oder ein Kollege, der denselben Link mit denselben Dateien öffnet, dasselbe Zeitfenster sieht, und er wird in die Dateinamen der Exporte geschrieben.

Schritt 6: Sitzungen und Zeitleiste prüfen

Der Tab Sitzungen beantwortet die Frage „Wer saß an der Tastatur?“, soweit die Daten es zulassen: entsperrte Intervalle, gebildet aus /device/isLocked, die gegen Display, Stromversorgung und App-Fokus zu lesen sind. Im Beispiel fällt die Sitzung von 10:04:31 bis 10:49:38 UTC (12:04 bis 12:49 Uhr Ortszeit) in Danas Mittagspause. Die Sitzung zeigt Aktivität unter ihrem Konto, nicht, wer getippt hat; der Methodenartikel erläutert die Grenzen.

Der Tab Zeitleiste führt knowledgeC- und Biome-Ereignisse zusammen. Zeiten werden in UTC gespeichert; für knowledgeC-Zeilen liefert ZSECONDSFROMGMT den lokalen Offset (+02:00 im Beispiel). Die Biome-Records „im Fokus“ und „nicht im Fokus“ aus App.InFocus werden je App zu Intervallen zusammengefasst.

Schritt 7: Apps, Web und Biome-Details prüfen

Apps: Fokus und Nutzung je Bundle-ID. Im Beispiel erscheint com.apple.Terminal nur innerhalb der Vorfallssitzung.
Web: URLs und Domains aus /app/webUsage, /safari/history und App.WebUsage, darunter files.example und transfer.example.
Biome: eine Zeile pro Stream, Speicher und Herkunft (local, remote mit der Geräte-UUID, tombstone) mit SEGB-Version, Anzahl der Records, gelöschten Records und CRC-Fehlern. Ein Klick auf einen Stream listet seine Records; die Details jedes Records zeigen Status, CRC-Ergebnis und die dekodierten Protobuf-Felder. Streams ohne öffentliche Feldzuordnung, etwa App.MenuItem, werden ohne Schema dekodiert und behalten die rohen Feldnummern (SEGB-Format).

Vom iPhone synchronisierte Records (remote/<UUID> in Biome, eine andere ZDEVICEID in knowledgeC) sind als solche gekennzeichnet. Halten Sie sie aus der Aktivität des Mac heraus.

Schritt 8: Die Ergebnisse exportieren

Export	Inhalt
CSV: Zeitleiste	Ereignisse im aktuellen Zeitraum
CSV: Apps	Summen je App
CSV: Sitzungen	Entsperrte Sitzungen
Timesketch-CSV	Ereignisse in einem Format, das Timesketch importieren kann
JSON	Die dekodierten Ereignisse, für Skripte und andere Werkzeuge

Bewahren Sie die Exporte zusammen mit den Hashes der Quelldateien auf. Der Zeitraum im Dateinamen hält fest, welches Zeitfenster ein Export abdeckt.

Grenzen, die Sie beachten sollten

Die Bedeutung der Felder in Biome-Payloads stammt aus mac_apt und iLEAPP, nicht von Apple. Nicht dekodierte Felder bleiben roh.
Records zeigen Aktivität unter einem Konto auf einem Gerät, nicht Identität.
Die Aufbewahrung ist begrenzt (etwa vier Wochen in knowledgeC, rund 28 Tage für die meisten Biome-Streams laut iOS-Forschung); messen Sie sie je Stream.
Gleichen Sie wichtige Records mit APOLLO, mac_apt oder ccl-segb ab.

KnowledgeC Parser ist ein unabhängiges Projekt, weder mit Apple verbunden noch von Apple unterstützt.

knowledgeC.db und Biome im Browser analysieren