IT-rikostutkinta · macOS

SQLite-, WAL- ja SHM-artefaktien manuaalinen tarkistaminen

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.

Pyydä sitoumukseton tarjous

Apple-tietokoneiden kohdalla tämä seikka on erityisen tärkeä, koska laitteisto- ja turvallisuusarkkitehtuuri ovat muuttuneet merkittävästi viime vuosina. Vanhempaa Intel-iMacia, Intel-Macia, jossa on T2-turvasiru, ja uusinta Apple Silicon -pohjaista Mac Studioa ei pidä käsitellä saman teknisen mallin mukaisesti. APFS, Secure Enclave, FileVault ja kunkin järjestelmän tila määräävät, mihin tietoihin pääsee käsiksi ja mikä varmuuskopiointimenetelmä aiheuttaa vähiten muutoksia.

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)

Miksi 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

Tyypillisiä käyttökohteita

•Oikeudelliset ja oikeuden ulkopuoliset asiantuntijalausunnot
•Todisteiden turvaaminen iMacista, Mac ministä, Mac Studiosta, MacBookista ja Mac Prosta
•Apple Silicon-, T2- ja vanhempien Intel-järjestelmien tutkimus
•Tapahtumien hallinta ja haittaohjelmien tutkimukset
•APFS-, käyttäjä-, sovellus- ja järjestelmätietojen analysointi
•Tiedosto-, käyttäjä- ja verkkoaktiviteettien rekonstruointi
•Automaattisten jäsennelytulosten tarkistaminen
•Poistettujen, historiallisten tai vain epäsuorasti näkyvien jälkien analysointi
•Asiakirjat tuomioistuimille, asianajajille, yrityksille ja viranomaisille

Miksi tämä tutkimusalue on rikosteknologisesti merkityksellinen?

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.

Rikostekninen arvo ei piile pelkästään löydetyn datan määrässä, vaan sen alkuperässä ja luotettavuudessa. Tiedostonimi, aikaleima tai tietokantamerkintä voi ilman asiayhteyttä olla harhaanjohtava. Siksi dokumentoimme, miten todiste on voinut syntyä, mitä vaihtoehtoisia selityksiä on olemassa ja mitkä muut jäljet tukevat löydöstä.

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

Erityisesti nykyaikaisissa Mac-tietokoneissa „perinteisen“ tietovälineanalyysin yritys voi epäonnistua teknisten rajoitusten vuoksi. Laitteistopohjainen salaus, Secure Enclave, FileVault ja APFS osoittavat selvästi, miksi asianmukainen varmuuskopiointi ennen varsinaista analyysia on niin tärkeää. Tässä vaiheessa tehtyjä virheitä ei aina voida korjata myöhemmin.

Usein kysyttyjä kysymyksiä

Was ist bei „SQLite-, WAL- und SHM-Artefakte manuell validieren“ forensisch zu beachten?
Tutkimuksemme ei ala analysointiohjelman käynnistämisestä, vaan todistusaineiston keräämisestä. Laitteen malli, sarjanumero tai inventaariotunnus, liitäntöjen kunto, näkyvä järjestelmän tila ja olemassa olevat oheislaitteet dokumentoidaan. Sen jälkeen päätetään, onko järjestelmän oltava sammutettuna, onko reaaliaikainen tiedonkeruu järkevää vai onko palautus-, kohdelevy- tai jaetun levyn menettely teknisesti perusteltu. Seuraavassa vaiheessa määritetään varmuuskopiointistrategia. Tässä yhteydessä erotamme toisistaan lohkokohtaisen kopioinnin, loogisen varmuuskopioinnin ja kohdennetun triagetoimenpiteen. Valinta ei riipu mukavuudesta, vaan laitteistosukupolvesta, FileVaultista, APFS-rakenteesta, käytettävissä olevasta lukituksen avaustilasta ja konkreettisesta todistekysymyksestä. Mikäli se on teknisesti mahdollista, työskennellään kirjoitussuojatussa tilassa. Live- tai palautustoimenpiteiden yhteydessä väistämättömät tilamuutokset kirjataan nimenomaisesti lokiin. Luotu varmuuskopio dokumentoidaan hajautusarvoilla. Varsinainen analyysi ei tapahdu alkuperäiskappaleella, vaan työkopiolla tai todennetulla todistuskuvalla. Näin voidaan käyttää jäsennimiä, hakutoimintoja tai omia apuohjelmia muuttamatta jatkuvasti alkuperäistä todistusaineistoa. Monimutkaisissa tapauksissa emme tarkoituksella käytä vain yhtä ohjelmistoa. RECON LAB tai RECON ITR, Belkasoft X ja X-Ways tarjoavat erilaisia näkökulmia samaan todistusaineistoon. Jos standardiparserit eivät kata merkittävää artefaktia kokonaan, täydennämme tutkimusta itse kehitetyillä apuohjelmilla ja skripteillä. Ratkaisevaa on aina yhteys raakadataan: itse kehitetty jäsennin on rikosteknologisesti järkevä vain, jos sen tulos on toistettavissa ja teknisesti todennettavissa. Alaa tuntemattomalle lukijalle yksi seikka on tässä erityisen tärkeä: rikostekninen ohjelma ei „löydä“ totuutta automaattisesti. Se lukee tietorakenteita ja tulkitsee niitä tunnettujen sääntöjen mukaisesti. Jos Apple muuttaa tietokantaa tai metatietomuotoa uudessa macOS-versiossa, jäsennin voi reagoida epätäydellisesti tai virheellisesti. Siksi tarkistamme ratkaisevien havaintojen kohdalla, mistä tiedostosta, tietokannasta tai tiedostojärjestelmärakenteesta tulos on peräisin ja vahvistaako toinen tekninen menetelmä saman tosiseikan. Tämä on myös syy siihen, miksi käytämme useita työkaluja. RECON LAB pystyy analysoimaan Apple-spesifisiä rakenteita natiivisti macOS-ympäristössä; Belkasoft X tarjoaa erilaisen näkymän artefakteihin ja korrelaatioihin; X-Ways mahdollistaa erittäin yksityiskohtaiset tiedostojärjestelmä- ja raakadatatarkastukset. Jos riippumattomat analyysit ovat yhdenmukaisia, se lisää tulosten luotettavuutta. Jos ne eivät ole yhdenmukaisia, syy tutkitaan eikä valita yksinkertaisesti kätevintä tulosta.
Miten tällainen rikostekninen tutkimus sujuu käytännössä?
1 Todistusaineiston kerääminen ja tilan dokumentointi Apple-laite tunnistetaan ensin yksiselitteisesti ja siitä laaditaan valokuvallinen tai kirjallinen dokumentaatio. Kirjaamme ylös, onko laite päällä vai pois päältä, kirjautuneena sisään, lukittuna vai liitettynä ulkoisiin tallennusvälineisiin. Nämä tiedot voivat olla ratkaisevia myöhemmin. 2 Tekninen luokittelu Määritetään sirusukupolvi, macOS-versio, APFS-rakenne, FileVault ja merkitykselliset suojausmekanismit. Vasta tämän perusteella voidaan määrittää sopiva tallennusmenetelmä. 3 Todistusaineiston turvaava varmuuskopiointi Varmuuskopiointi valitaan siten, että alkuperäiseen laitteeseen tehdään mahdollisimman vähän muutoksia. RECON ITR:ää voidaan käyttää tapauksesta riippuen nykyaikaisten Mac-tietokoneiden kuvantamiseen tai triageen. Muissa tilanteissa tarvitaan Apple Recovery -toimintoa, Target Disk Mode -tilaa Intel-pohjaisissa laitteissa tai Share Disk -tilaa Apple Silicon -laitteissa. Jokainen vaihe kirjataan lokiin. 4 Eheyden tarkistus Luodut kuvat tai loogiset varmuuskopiot nimetään yksiselitteisesti, niille annetaan hajautusarvot ja ne tarkistetaan. Analysointi ja hakutoiminnot suoritetaan tämän jälkeen työkopioilla. 5 Monivaiheinen arviointi RECON LAB, Belkasoft X ja X-Ways yhdistetään kysymyksen luonteen mukaan. Tärkeää tulosta ei mahdollisuuksien mukaan oteta huomioon vain yhden jäsenninäkymän perusteella. 6 Manuaalinen validointi Jos jokin artefakti on erityisen todistusvoimainen, epätavallinen tai sitä tuetaan vakio-ohjelmistoilla vain osittain, tarkastamme raakadataa, tietokantarakenteita, metatietoja tai tiedostojärjestelmätietoja manuaalisesti. Tarvittaessa käytämme omia työkalujamme. 7 Raportti ja todistusaineisto Lopuksi emme pelkästään luettele sitä, mitä työkalu on näyttänyt. Selitämme, mikä tekninen lähde tukee havaintoa, mikä johtopäätös on perusteltu ja missä rajoitukset ovat.
Minkälaista rikosteknistä merkitystä tuloksilla on tällä alalla?
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.
Esitetäänkö tällaisessa tutkimuksessa oletuksia varmoina tuloksina?
Ei. Teknisten tutkimusten tulokset esitetään vain siltä osin kuin ne perustuvat tosiasiallisesti vahvistettuun aineistoon. Oletuksia, joita ei voida todentaa, ei esitetä vahvistettuina havaintoina.
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-rikostutkinta Kölnissä

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.

Ota yhteyttä nyt