IT-Forensik · macOS

SQLite-, WAL- und SHM-Artefakte manuell validieren

Viele macOS-Anwendungen – Nachrichten, Safari, Fotos, Notizen – speichern ihre Daten in SQLite-Datenbanken. Neben der Hauptdatei existieren oft eine „-wal“- und eine „-shm“-Datei. Die WAL-Datei kann jüngere Änderungen und ältere Versionen von Datenbankseiten enthalten, die in der Hauptdatei noch nicht oder nicht mehr stehen.

Unverbindlich anfragen

Bei Apple-Computern ist dieser Punkt besonders wichtig, weil sich Hardware- und Sicherheitsarchitektur in den vergangenen Jahren erheblich verändert haben. Ein älterer Intel-iMac, ein Intel-Mac mit T2 Security Chip und ein aktueller Mac Studio mit Apple Silicon dürfen nicht nach demselben technischen Schema behandelt werden. APFS, Secure Enclave, FileVault und der jeweilige Systemzustand bestimmen, welche Daten zugänglich sind und welche Sicherungsmethode die geringsten Veränderungen verursacht.

Automatische Parser können WAL-Inhalte unterschiedlich behandeln. Deshalb werden relevante Datensätze bei Bedarf direkt gegen Datenbankseiten, Transaktionskontext und Begleitdateien geprüft.

Technischer Hintergrund

Im Write-Ahead-Logging werden Änderungen zunächst in die WAL geschrieben und später per Checkpoint in die Hauptdatei übernommen. Wer die Datenbank mit Standardwerkzeugen öffnet, kann einen Checkpoint auslösen und die WAL verändern. Unterschiedliche Parser behandeln WAL-Frames unterschiedlich; dadurch können Datensätze fehlen, doppelt erscheinen oder einem falschen Zeitpunkt zugeordnet werden.

Relevante Spuren und Datenquellen

  • Hauptdatenbank, -wal und -shm als Einheit gesichert
  • WAL-Frames mit Salt-Werten und Commit-Markierungen
  • Freelist-Seiten und nicht zugewiesener Bereich (gelöschte Datensätze)
  • Tabellenschema und Zeitstempelformate (z. B. Mac Absolute Time)

Warum LanCologne?

LanCologne untersucht Apple-Computer nicht nach einem pauschalen Standardschema, sondern anhand der konkreten Hardware- und Sicherheitsarchitektur. Unsere Mitarbeiter verfügen über jahrzehntelange Erfahrung in der Informationstechnologie und langjährige praktische Erfahrung in der IT-Forensik.

So gehen wir vor

  • Sicherung der Dateien als Gruppe, Auswertung nur an Kopien.
  • Parserergebnis mit Seiten- und Frame-Ebene abgleichen.
  • Dokumentation, aus welcher Quelle (Hauptdatei, WAL-Frame, freier Bereich) ein Datensatz stammt.

Grenzen

  • Nach erfolgtem Checkpoint und Überschreiben sind ältere Stände nicht mehr vorhanden.
  • Die Zuordnung eines WAL-Frames zu einem exakten Zeitpunkt ist nicht immer möglich.

Mögliche Ergebnisse

  • Validierte Datensätze mit Herkunftsangabe
  • Hinweise auf gelöschte oder geänderte Einträge

Typische Einsatzgebiete

•Gerichtliche und außergerichtliche Gutachten
•Beweissicherung von iMac, Mac mini, Mac Studio, MacBook und Mac Pro
•Untersuchung von Apple-Silicon-, T2- und älteren Intel-Systemen
•Incident Response und Malware-Untersuchungen
•Analyse von APFS-, Benutzer-, Anwendungs- und Systemartefakten
•Rekonstruktion von Datei-, Benutzer- und Netzwerkaktivitäten
•Gegenprüfung automatischer Parserergebnisse
•Auswertung gelöschter, historischer oder nur indirekt sichtbarer Spuren
•Dokumentation für Gerichte, Rechtsanwälte, Unternehmen und Behörden

Warum ist dieser Untersuchungsbereich forensisch relevant?

Viele macOS-Anwendungen speichern Informationen in SQLite. Eine belastbare Untersuchung berücksichtigt nicht nur die Hauptdatenbank, sondern je nach Zustand auch WAL- und SHM-Dateien und trennt aktive Datensätze von rekonstruierten Fragmenten.

Der forensische Wert liegt nicht allein in der Menge gefundener Daten, sondern in deren Herkunft und Belastbarkeit. Ein Dateiname, ein Zeitstempel oder ein Datenbankeintrag kann ohne Kontext missverständlich sein. Deshalb dokumentieren wir, wie ein Artefakt entstanden sein kann, welche Alternativerklärungen bestehen und welche weiteren Spuren den Befund stützen.

Automatische Parser können WAL-Inhalte unterschiedlich behandeln. Deshalb werden relevante Datensätze bei Bedarf direkt gegen Datenbankseiten, Transaktionskontext und Begleitdateien geprüft.

Gerade auf modernen Macs kann außerdem der Versuch einer „klassischen“ Datenträgeranalyse an technischen Grenzen scheitern. Hardwaregebundene Verschlüsselung, Secure Enclave, FileVault und APFS machen deutlich, warum eine fachgerechte Sicherung vor der eigentlichen Analyse so wichtig ist. Fehler in dieser Phase können später nicht immer rückgängig gemacht werden.

Häufige Fragen

Was ist bei „SQLite-, WAL- und SHM-Artefakte manuell validieren“ forensisch zu beachten?
Unsere Untersuchung beginnt nicht mit dem Start eines Analyseprogramms, sondern mit der Beweismittelaufnahme. Gerät, Modell, Serien- beziehungsweise Inventarbezug, Anschlusszustand, sichtbarer Systemzustand und vorhandene Peripherie werden dokumentiert. Danach wird entschieden, ob das System ausgeschaltet bleiben muss, ob eine Live-Erfassung sinnvoll ist oder ob ein Recovery-, Target-Disk- beziehungsweise Share-Disk-Verfahren fachlich vertretbar ist. Im nächsten Schritt wird die Sicherungsstrategie festgelegt. Dabei unterscheiden wir zwischen blockorientierter Abbildung, logischer Sicherung und gezielter Triage. Die Wahl hängt nicht von Bequemlichkeit ab, sondern von Hardwaregeneration, FileVault, APFS-Struktur, verfügbarem Entsperrzustand und der konkreten Beweisfrage. Wo technisch möglich, wird schreibgeschützt gearbeitet. Unvermeidbare Zustandsänderungen bei Live- oder Recovery-Maßnahmen werden ausdrücklich protokolliert. Die erzeugte Sicherung wird mit Hashwerten dokumentiert. Die eigentliche Analyse erfolgt nicht auf dem Original, sondern auf einer Arbeitskopie beziehungsweise einem verifizierten Beweisabbild. So können Parser, Suchläufe oder eigene Hilfsprogramme eingesetzt werden, ohne das Originalbeweismittel fortlaufend zu verändern. In komplexen Fällen arbeiten wir bewusst nicht mit einer einzigen Software. RECON LAB beziehungsweise RECON ITR, Belkasoft X und X-Ways liefern unterschiedliche Blickwinkel auf denselben Beweisbestand. Wenn ein relevantes Artefakt von Standardparsern nicht vollständig abgedeckt wird, ergänzen wir die Untersuchung durch eigens entwickelte Hilfsprogramme und Skripte. Entscheidend bleibt dabei stets die Rückbindung an die Rohdaten: Ein selbst entwickelter Parser ist nur dann forensisch sinnvoll, wenn sein Ergebnis reproduzierbar und technisch überprüfbar ist. Für einen fachfremden Leser ist dabei ein Punkt besonders wichtig: Ein Forensikprogramm „findet“ nicht automatisch die Wahrheit. Es liest Datenstrukturen und interpretiert sie nach bekannten Regeln. Ändert Apple mit einer neuen macOS-Version eine Datenbank oder ein Metadatenformat, kann ein Parser unvollständig oder falsch reagieren. Deshalb prüfen wir bei entscheidenden Befunden, aus welcher Datei, Datenbank oder Dateisystemstruktur das Ergebnis stammt und ob ein zweiter technischer Weg denselben Sachverhalt bestätigt. Das ist auch der Grund, warum wir mehrere Werkzeuge einsetzen. RECON LAB kann Apple-spezifische Strukturen nativ unter macOS auswerten; Belkasoft X bietet eine andere Artefakt- und Korrelationssicht; X-Ways ermöglicht sehr detaillierte Dateisystem- und Rohdatenprüfungen. Stimmen unabhängige Auswertungen überein, erhöht das die Belastbarkeit. Stimmen sie nicht überein, wird die Ursache untersucht und nicht einfach der bequemste Treffer ausgewählt.
Wie läuft eine solche forensische Untersuchung in der Praxis ab?
1 Beweismittelaufnahme und Zustandsdokumentation Das Apple-Gerät wird zunächst eindeutig identifiziert und fotografisch beziehungsweise schriftlich dokumentiert. Wir halten fest, ob es ein- oder ausgeschaltet, angemeldet, gesperrt oder mit externen Datenträgern verbunden ist. Diese Informationen können später entscheidend sein. 2 Technische Einordnung Chipgeneration, macOS-Version, APFS-Struktur, FileVault und relevante Sicherheitsmechanismen werden bestimmt. Erst daraus ergibt sich die geeignete Erfassungsmethode. 3 Beweissichere Sicherung Die Sicherung wird so gewählt, dass möglichst wenig auf dem Original verändert wird. RECON ITR kann je nach Fall für Imaging oder Triage moderner Macs eingesetzt werden. Andere Situationen erfordern Apple Recovery, Target Disk Mode bei Intel oder Share Disk bei Apple Silicon. Jeder Schritt wird protokolliert. 4 Integritätsprüfung Erzeugte Abbilder oder logische Sicherungen werden eindeutig benannt, mit Hashwerten versehen und verifiziert. Analyse und Suchläufe erfolgen anschließend auf Arbeitskopien. 5 Mehrstufige Auswertung RECON LAB, Belkasoft X und X-Ways werden je nach Fragestellung kombiniert. Ein wichtiges Ergebnis wird möglichst nicht nur aus einer einzigen Parseransicht übernommen. 6 Manuelle Validierung Wenn ein Artefakt besonders beweiserheblich, ungewöhnlich oder durch Standardsoftware nur teilweise unterstützt ist, prüfen wir Rohdaten, Datenbankstrukturen, Metadaten oder Dateisysteminformationen manuell. Bei Bedarf kommen eigene Werkzeuge zum Einsatz. 7 Bericht und Beweisbezug Am Ende wird nicht nur aufgelistet, was ein Tool angezeigt hat. Wir erklären, welche technische Quelle den Befund trägt, welche Schlussfolgerung zulässig ist und wo Grenzen bestehen.
Welche forensische Aussagekraft haben die Ergebnisse in diesem Bereich?
Viele macOS-Anwendungen speichern Informationen in SQLite. Eine belastbare Untersuchung berücksichtigt nicht nur die Hauptdatenbank, sondern je nach Zustand auch WAL- und SHM-Dateien und trennt aktive Datensätze von rekonstruierten Fragmenten. Der forensische Wert liegt nicht allein in der Menge gefundener Daten, sondern in deren Herkunft und Belastbarkeit. Ein Dateiname, ein Zeitstempel oder ein Datenbankeintrag kann ohne Kontext missverständlich sein. Deshalb dokumentieren wir, wie ein Artefakt entstanden sein kann, welche Alternativerklärungen bestehen und welche weiteren Spuren den Befund stützen. Automatische Parser können WAL-Inhalte unterschiedlich behandeln. Deshalb werden relevante Datensätze bei Bedarf direkt gegen Datenbankseiten, Transaktionskontext und Begleitdateien geprüft. Gerade auf modernen Macs kann außerdem der Versuch einer „klassischen“ Datenträgeranalyse an technischen Grenzen scheitern. Hardwaregebundene Verschlüsselung, Secure Enclave, FileVault und APFS machen deutlich, warum eine fachgerechte Sicherung vor der eigentlichen Analyse so wichtig ist. Fehler in dieser Phase können später nicht immer rückgängig gemacht werden.
Werden bei einer solchen Untersuchung Vermutungen als gesicherter Befund dargestellt?
Nein. Technische Untersuchungsergebnisse werden nur so weit dargestellt, wie sie durch den tatsächlich gesicherten Datenbestand belegt sind. Nicht belegbare Annahmen werden nicht als gesicherter Befund formuliert.
Warum darf man die Datenbank nicht einfach öffnen?
Weil das Öffnen einen Checkpoint auslösen und die WAL-Datei verändern kann.
Findet man in der WAL gelöschte Nachrichten?
Manchmal, wenn ältere Seitenversionen noch nicht überschrieben sind.
Gilt das nur für macOS?
Nein, auch iOS, Android und Windows-Anwendungen nutzen SQLite mit WAL.

Weiterführende Themen

LanCologne – macOS-Forensik in Köln

Sie benötigen eine professionelle Untersuchung zu „SQLite-, WAL- und SHM-Artefakte manuell validieren“? LanCologne unterstützt Sie bei der beweissicheren Sicherung, mehrstufigen Auswertung und nachvollziehbaren Dokumentation. Entscheidend ist dabei nicht, möglichst viele automatische Treffer zu erzeugen, sondern technisch belastbare und überprüfbare Beweise zu sichern.

Jetzt Kontakt aufnehmen