Informatica forense · macOS

Convalidare manualmente gli artefatti SQLite, WAL e SHM

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.

Richiesta non vincolante

Nel caso dei computer Apple, questo aspetto è particolarmente importante, poiché l’hardware e l’architettura di sicurezza hanno subito notevoli cambiamenti negli ultimi anni. Un vecchio iMac con processore Intel, un Mac con processore Intel dotato di chip di sicurezza T2 e un Mac Studio di ultima generazione con Apple Silicon non possono essere trattati secondo lo stesso schema tecnico. APFS, Secure Enclave, FileVault e lo stato del sistema determinano quali dati sono accessibili e quale metodo di backup comporta il minor numero di modifiche.

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)

Perché 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

Campi di applicazione tipici

•Perizie giudiziarie ed extragiudiziarie
•Acquisizione delle prove da iMac, Mac mini, Mac Studio, MacBook e Mac Pro
•Analisi dei sistemi Apple Silicon, T2 e dei sistemi Intel di vecchia generazione
•Risposta agli incidenti e analisi del malware
•Analisi degli artefatti APFS, degli utenti, delle applicazioni e del sistema
•Ricostruzione delle attività relative a file, utenti e rete
•Verifica incrociata dei risultati dei parser automatici
•Analisi di tracce cancellate, storiche o visibili solo indirettamente
•Documentazione per tribunali, avvocati, aziende e autorità pubbliche

Perché questo ambito di indagine è rilevante dal punto di vista forense?

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.

Il valore forense non risiede solo nella quantità di dati rinvenuti, ma anche nella loro provenienza e attendibilità. Il nome di un file, un timestamp o una voce di database possono essere fraintesi se privi di contesto. Per questo motivo documentiamo come un reperto possa essere stato generato, quali spiegazioni alternative esistano e quali ulteriori indizi confermino il risultato dell’analisi.

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

Soprattutto sui Mac moderni, inoltre, il tentativo di effettuare un’analisi „classica“ del supporto dati può fallire a causa di limiti tecnici. La crittografia integrata nell’hardware, Secure Enclave, FileVault e APFS chiariscono perché sia così importante eseguire un backup a regola d’arte prima dell’analisi vera e propria. Gli errori commessi in questa fase non possono sempre essere corretti in un secondo momento.

Domande frequenti

Was ist bei „SQLite-, WAL- und SHM-Artefakte manuell validieren“ forensisch zu beachten?
La nostra indagine non inizia con l'avvio di un programma di analisi, bensì con la raccolta delle prove. Vengono documentati il dispositivo, il modello, il numero di serie o di inventario, lo stato delle connessioni, lo stato visibile del sistema e le periferiche presenti. Successivamente si decide se il sistema debba rimanere spento, se sia opportuno procedere a un'acquisizione „live“ o se sia tecnicamente giustificabile ricorrere a una procedura di recovery, target disk o share disk. Nella fase successiva viene definita la strategia di backup. A tal fine distinguiamo tra imaging a blocchi, backup logico e triage mirato. La scelta non dipende dalla comodità, ma dalla generazione dell’hardware, da FileVault, dalla struttura APFS, dallo stato di sblocco disponibile e dalla specifica questione probatoria. Laddove tecnicamente possibile, si opera in modalità di sola lettura. Eventuali modifiche inevitabili dello stato durante le operazioni live o di ripristino vengono espressamente registrate. Il backup generato viene documentato con valori hash. L’analisi vera e propria non viene effettuata sull’originale, ma su una copia di lavoro o su un’immagine probatoria verificata. In questo modo è possibile utilizzare parser, operazioni di ricerca o programmi di supporto propri senza modificare continuamente la prova originale. Nei casi complessi, scegliamo consapevolmente di non lavorare con un unico software. RECON LAB o RECON ITR, Belkasoft X e X-Ways offrono diverse prospettive sullo stesso corpus probatorio. Se un artefatto rilevante non viene completamente analizzato dai parser standard, integriamo l’indagine con programmi ausiliari e script sviluppati internamente. In questo contesto, il collegamento ai dati grezzi rimane sempre fondamentale: un parser sviluppato internamente ha senso dal punto di vista forense solo se il suo risultato è riproducibile e tecnicamente verificabile. Per un lettore non esperto del settore, un aspetto è particolarmente importante: un programma forense non «trova» automaticamente la verità. Esso legge le strutture dei dati e le interpreta secondo regole note. Se Apple modifica un database o un formato di metadati con una nuova versione di macOS, un parser potrebbe reagire in modo incompleto o errato. Per questo motivo, in caso di risultati determinanti, verifichiamo da quale file, database o struttura del file system provenga il risultato e se un secondo approccio tecnico confermi la stessa situazione. Questo è anche il motivo per cui utilizziamo diversi strumenti. RECON LAB è in grado di analizzare in modo nativo su macOS le strutture specifiche di Apple; Belkasoft X offre una prospettiva diversa sugli artefatti e sulle correlazioni; X-Ways consente analisi molto dettagliate del file system e dei dati grezzi. Se le analisi indipendenti concordano, l’affidabilità dei risultati aumenta. Se non concordano, si indaga sulla causa e non ci si limita a selezionare semplicemente il risultato più conveniente.
Come si svolge nella pratica un’indagine forense di questo tipo?
1 Raccolta delle prove e documentazione dello stato Il dispositivo Apple viene innanzitutto identificato in modo univoco e documentato tramite fotografie o per iscritto. Si rileva se è acceso o spento, se è connesso all’account utente, se è bloccato o se è collegato a supporti di dati esterni. Queste informazioni possono rivelarsi decisive in seguito. 2 Analisi tecnica Vengono determinate la generazione del chip, la versione di macOS, la struttura APFS, FileVault e i meccanismi di sicurezza rilevanti. Solo sulla base di questi dati si individua il metodo di acquisizione più adeguato. 3 Backup a prova di prova Il metodo di backup viene scelto in modo da modificare il meno possibile l’originale. A seconda del caso, RECON ITR può essere utilizzato per l’imaging o il triage dei Mac di ultima generazione. Altre situazioni richiedono Apple Recovery, la modalità Target Disk su Intel o Share Disk su Apple Silicon. Ogni fase viene registrata. 4 Verifica dell’integrità Le immagini o i backup logici generati vengono denominati in modo univoco, contrassegnati con valori hash e verificati. L’analisi e le operazioni di ricerca vengono quindi eseguite su copie di lavoro. 5 Valutazione multistadio RECON LAB, Belkasoft X e X-Ways vengono combinati a seconda della problematica. Un risultato importante non viene, per quanto possibile, ricavato da una singola visualizzazione del parser. 6 Convalida manuale Se un artefatto è particolarmente rilevante ai fini probatori, insolito o supportato solo parzialmente dal software standard, verifichiamo manualmente i dati grezzi, le strutture dei database, i metadati o le informazioni del file system. Se necessario, vengono utilizzati strumenti sviluppati internamente. 7 Relazione e riferimento probatorio Alla fine non ci limitiamo a elencare ciò che uno strumento ha visualizzato. Spieghiamo quale fonte tecnica sta alla base del risultato, quale conclusione è ammissibile e dove si trovano i limiti.
Qual è il valore probatorio forense dei risultati ottenuti in questo ambito?
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.
In un esame di questo tipo, le ipotesi vengono presentate come risultati certi?
No. I risultati delle analisi tecniche vengono presentati solo nella misura in cui sono comprovati dai dati effettivamente disponibili. Le ipotesi non comprovabili non vengono formulate come risultati accertati.
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 – Analisi forense di macOS a Colonia

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.

Contattaci subito