Wintersemester 2009/2010 Kapitel 3: Dateisystemanalyse
Inhalt Allgemeines zu Dateisystemen Linux-Dateisysteme am Beispiel von ext2/ext3 Microsoft-Dateisysteme FAT NTFS 2
Inhalt Allgemeines zu Dateisystemen Linux-Dateisysteme am Beispiel von ext2/ext3 Microsoft-Dateisysteme FAT NTFS 3
Grundlagen von Dateisystemen (1/2) Organisation der Daten in Hierarchie aus Verzeichnissen und Dateien Unterteilung der Daten in Benutzerdaten (Payload) Strukturdaten (Verwaltung der Benutzerdaten) Dateisysteme sind of unabhängig von Hardware oder Betriebssystem Windows auf FAT oder NTFS Linux auf FAT, ext2/ext3/ext4, ReiserFS 4
Grundlagen von Dateisystemen (2/2) Kenntnisse über Dateisysteme ermöglichen Zugriff auf Daten (Struktur- und Nutzerdaten) Rekonstruktion von Vorgängen auf dem Dateisystem Ohne Hilfe des eigentlichen Betriebssystems Interpretation der Inhalte von Nutzerdaten liegt Abstraktionsstufe höher Muss mit speziellen Anwendungstools untersucht werden Nicht Gegenstand der Dateisystemanalyse 5
Zur Mehrdeutigkeit des Begriffs 'Block' Datenträgerblock: Kleinste adressierbare Einheit auf Datenträger Angelegt bei Low-Level-Formatierung Typische Größe: 512 Byte Viele Autoren / Programme sprechen von Sektor Dateisystemblock: Kleinste adressierbare Einheit über das Dateisystem Angelegt bei Datenträger-Formatierung Typische Größen: 1024 Byte, 2048 Byte, 4096 Byte In dieser Vorlesung: FS-Block 6
Mehrdeutigkeit des Begriffs 'Adresse' Logische Partitionsadresse / Laufwerksadresse: Adresse (LBA) des Datenträgerblocks relativ zum Anfang der Partition Einheit: Datenträgerblock Logische Dateisystemadresse: Adresse des FS-Blocks relativ zum Anfang des Dateisystems Einheit: FS-Block Logische Dateiadresse: Adresse des Datenblocks relativ zum Anfang der Datei Einheit: FS-Block 7
Abstraktes Referenzsystem für Dateisysteme Fünf Kategorien von Daten: Dateisystemdaten Inhaltsdaten Metadaten Dateiname Anwendungsdaten des Dateisystems Vorteil: Vereinfacht Vergleich von Dateisystemen Ermöglicht abstrakte Vorgehensbeschreibung für Analyse Nachteil: Referenzmodell passt nicht immer 8
Dateisystem- und Inhaltsdaten Dateisystemdaten liefern allgemeine Informationen über die Organisation der Daten auf dem Datenträger: Wie groß ist ein Dateisystemblock für Inhaltsdaten? Nicht zu verwechseln mit einem Festplattenblock aus LowLevel-Formatierung In Windows oft auch Cluster genannt Brian Carrier: Data Unit Wie groß ist das Dateisystem? Welche Datenblöcke sind belegt? Inhaltsdaten speichern Inhalte der Dateien Typischerweise größter Anteil der Daten 9
Metadaten Metadaten = Daten über Daten Meta = Über, hinter, neben Typische Informationen: Speicherort der Datei (Unterschiedliche Strategien) Größe der Datei Zeitstempel Erstellung Letzter lesender Zugriff Letzte Änderung Löschung Beispiele: Inodes in UNIX, FAT-Verzeichniseinträge 10
Dateiname und Anwendungsdaten Dateiname: Stellt typischerweise Verbindung zwischen externem Namen (für den Anwender) und internem Namen (z.b. Inode) her Meist in Verzeichnisdatei gespeichert Analogie: URL <--> IP-Adresse Anwendungsdaten des Dateisystems: Nicht benötigt für Kern-Funktionalität des Dateisystems Stellt typischerweise nützliche Features bereit: Dateisystem-Journal Quota-Statistiken 11
Essentielle vs. nicht-essentielle Daten Begriffsunterscheidung durch Brian Carrier: Essential file system data are those that are needed to save and retrieve files. Non-essential file system data are there for convenience and not needed for the basic functionality. Beispiele: Essentiell:? Nicht-essentiell:? Vertrauenswürdigkeit essentieller / nicht-essentieller Daten? 12
Analyse von Dateisystemdaten Wichtige Dateisystemdaten sind typischerweise in ersten Datenträgerblöcken der Partition untergebracht Liefern Informationen über: Art des Dateisystems Speicherort weiterer Informationen über das Dateisystem Vertrauenswürdige (weil essentielle) Daten: Ansicht mit Hexeditor (z.b. xxd) oder Tool aus TSK (fsstat) Volume Slack nicht vergessen: Unbenutzte Datenträgerblöcke hinter Dateisystem Potentieller Speicherort für versteckte Dateien 13
Analyse von Inhaltsdaten: Allozierte Blöcke Anlegen einer Datei: Datenblöcke werden alloziert Zugehörige Datenblöcke werden im Dateisystem als belegt markiert Allokationsalgorithmus abhängig vom Dateisystem u. OS Löschen einer Datei: Oft werden nur die Verweise Dateiname --> Metadaten gelöscht Datenblöcke werden als unbenutzt markiert Folge: Daten liegen unverändert auf Datenträger 14
Analyse von Inhaltsdaten (1/2) Suche mit Hilfe der Metadaten: Sind Metadaten noch verfügbar (insbesondere die Verweise auf Datenblöcke), ist Analyse relativ einfach Datenblöcke auslesen --> Zu neuer Datei 'zusammenbauen' Anschließend auf Dateiebene analysieren Andernfalls Stringsuche, Puzzletechnik,... Stringsuche nach Schlüsselwörtern ASCII-String (z.b. E-Mail-Adresse, Telefonnummer) Dateiverwaltungs-String ('Signaturen' z.b. in pdf-, Bild-, OfficeDateien) Prinzipielles Problem: Fragmentierung der Daten 15
Analyse von Inhaltsdaten (2/2) Prinzipielles Problem: Fragmentierung der Daten Daten werden i.d.r. in mehreren FS-Blöcke gespeichert Geht gesuchter String über Blockgrenzen, ist Auffinden ggfls. schwierig Referenztest aus Computer Forensic Tool Testing (CFTT) verwenden: www.cftt.nist.gov Suche auf unbelegten Datenblöcken Ansicht von Datenblöcken mit Tools aus TSK: xxd: Hexeditor (vgl. Praktikum) dcat: Ansicht von Datenblöcken als Hexdump, ASCII, HTML 16
Inhaltsdaten: File Slack (1/2) File Slack: Speicherbereich von EOF bis Ende des FS-Blocks Hintergrund: Tatsächliche Dateigröße und allozierter Speicherbereich auf Festplatte stimmen in der Regel nicht überein Besteht aus RAM Slack und Drive Slack RAM Slack: Speicherbereich von EOF bis Ende des aktuellen Datenträgerblocks Wurde von DOS und älteren Windows-Varianten mit Inhalten aus Memory Buffer (= RAM-Daten) beschrieben 17
Inhaltsdaten: File Slack (2/2) Drive Slack: 'Hintere' vollständig unbelegte Datenträgerblöcke In diesen bleibt oft das bisherige Bitmuster unverändert Beispiel: Datenträgerblockgröße: 512 Byte FS-Blockgröße: 4096 Byte Textdatei von 2000 Byte wird gespeichert File Slack: Byte bis Byte RAM Slack: Byte - Byte Drive Slack: Byte - Byte 18
Inhaltsdaten: Sicheres Löschen von Dateien Je nach Betriebssystem gibt es viele Tools: PGP für Windows shred für Linux: Überschreibt alle Datenblöcke vollständig und mehrfach mit verschiedenen Bytemustern 19
Inhaltsanalyse: Problem verschlüsselte Dateien (1/2) Verschlüsselung auf verschiedenen Stufen: Dateiverschlüsselung auf Anwendungsebene Verschlüsselung auf Dateisystemebene An der Hardware-Schnittstelle Dateiverschlüsselung auf Anwendungsebene: Beispiel: PGP, GnuPG Oft leitet sich Entschlüsselungsschlüssel aus Passwort ab In der Regel Brute-Force-Angriff auf Passwort: Schwaches Passwort --> Daten rekonstruierbar Typischerweise liegen Metadaten im Klartext vor 20
Inhaltsanalyse: Problem verschlüsselte Dateien (2/2) Verschlüsselung auf Dateisystemebene: Beispiele: TrueCrypt, EFS/BitLocker (Windows), DM-Crypt (Linux) Manchmal liegen Dateisystemdaten im Klartext vor Entschlüsselung wie bei Dateiverschlüsselung Erfolgversprechenderer Ansatz als Brute-Force: Live-Analyse des RAM Suche nach Entschlüsselungsschlüssel im Hauptspeicher Techniken: Dump des RAM, Cold Boot 21
Analyse des Dateinamens Dateilöschungsstrategien: Dateisystem setzt Eintrag im Verzeichnis auf unbenutzt: Dateisystem erhält Name der Datei, setzt aber zusätzlich den Verweis auf Metadateneintrag auf '0' Name der Datei und Verweis auf Metadaten bleibt erhalten Sehr einfache Rekonstruktion Bei chronologischer Vergabe der Metadateneinträge oft zu erraten, welche Metadaten zur gelöschten Datei gehören Achtung: Freigegebene Datenblöcke können wieder beschrieben sein Suche nach Schlüsselwörtern in Dateinamen 22
Analyse der Metadaten (1/2) Metadaten können benutzt oder unbenutzt sein Bei Löschen einer Datei werden Metadaten oft freigegeben Tool ils (TSK) zeigt alle benutzten sowie wieder freigegebenen Metadateneinträge eines Verzeichnisses an Typischer Aufruf: ils -a image Danach Zugriff auf die Metadaten selbst: Tool istat (TSK) zeigt Inhalt der Metadaten an Typischer Aufruf: istat image inode Dann sind Zeitstempel der Datei sowie Adressen der Datenblöcke bekannt 23
Analyse der Metadaten (2/2) Auswertung der Zeitstempel: Timelining Chronologische Auswertung von Zugriffs-/Änderungszeiten Ergibt wichtige Anhaltspunkte für Vorgehen des Angreifers Vorsicht: Zeitstempel sind keine essentiellen Daten Auswertung der Datenblöcke: Direktes Ansehen oder Herausschreiben Analyse auf Anwendungsebene File Slack nicht vergessen!!! 24
Analyse der Anwendungsdaten (1/2) Typischerweise nur Journal-Analyse Journal hält zuletzt durchgeführte Änderungen am Dateisystem vor: Effizientere Wiederherstellung bei Absturz Beim Booten wird Journal gegen Dateisystem getestet Ggfls. werden Änderungen eingespielt Journal-Analyse steckt noch in den Kinderschuhen Tools aus TSK jls: Anwendbar für FAT, NTFS, ext2/ext3, ISO9660 jcat: Zeigt Blöcke im Journal an 25
Analyse der Anwendungsdaten (2/2) jls [-f fstype] image 26
Inhalt Allgemeines zu Dateisystemen Linux-Dateisysteme am Beispiel von ext2/ext3 Microsoft-Dateisysteme FAT NTFS 27
ext2 / ext3 ( / ext4) Verbreitete Dateisysteme unter Linux Seit ext3 mit Journal Maximale Dateisystemgröße wächst: ext2: 16 TByte ( = 16 240 Byte ) ext3: 32 TByte ( = 32 240 Byte ) ext4: 1 EByte ( =1024 PByte = 1 260 Byte ) T = Tera = 240 P = Peta = 250 E = Exa = 260 Aber auch andere Dateisysteme bekannt: ReiserFS, XFS Vorsicht: Nicht alle sind mit Forensik-Tools untersuchbar (z.b. kennt TSK nicht ReiserFS) 28
Strukturierung einer Partition (= Laufwerk) 1 bis n Blockgruppen: Jeweils gleiche Größe (bis auf letzte Gruppe) Aufbau einer Blockgruppe: Superblock: Grundlegende Information über Dateisystem Gruppenbezeichnungstabelle (Group Descriptor Table): Verwaltung der Blockgruppen im Dateisystem Data Bitmap: Belegtstatus der FS-Blöcke der Blockgruppe Inode Bitmap: Belegtstatus der Inodes der Blockgruppe Inode-Tabelle: Enthält die Inodes (Metadaten) Datenblöcke (größter Anteil) 29
Dateisystemdaten: Superblock Belegt Bytes 1024 bis 2047 (beginnend bei 0) der Partition Seit Revision 1 von ext2 nur in Blockgruppen 0,1,3,5,7,... Enthält folgende Informationen: Größe eines Dateisystemblocks: FS-Block (z.b. 4096 Byte) Anzahl der FS-Blöcke pro Blockgruppe Anzahl der Inodes und FS-Blöcke im Dateisystem Anzahl freier FS-Blöcke und freier Inodes Reservierter Bereich für privilegierten Nutzer (=root) Ohne gültigen Superblock kann Partition nicht eingebunden werden (Backups auf Platte notwendig!) 30
Aufbau des Superblocks als Übersicht... Byte-Nr. (dez.) Beschreibung ( Boot Loader, ggfls. Partitionstabelle) 0 1023 1024 1027 Anzahl an Inodes 1028 1031 Dateisystemgröße in FS-Blöcken 1032 1035 Anzahl reservierter Blöcke für root 1036 1039 Zähler für freie Blöcke 1040 1043 Zähler für freie Inodes 1044 1047 Blocknummer des Superblocks (Typ. 0 oder 1) 1048 1051 Größe eines FS-Blocks... Weitere Informationen über Dateisystem 31
... oder etwas Informatik-näher struct ext2_super_block { u32 s_inodes_count; /* Inodes count */ u32 s_blocks_count; /* Blocks count */ u32 s_r_blocks_count; /* Reserved blocks count */ u32 s_free_blocks_count; /* Free blocks count */ u32 s_free_inodes_count; /* Free inodes count */ u32 s_first_data_block; /* First Data Block */ u32 s_log_block_size; /* Block size */ s32 s_log_frag_size; /* Fragment size */ u32 s_blocks_per_group; /* # Blocks per group */ u32 s_frags_per_group; /* # Fragments per group... }; 32
Beispiel eines Superblocks Aufruf: xxd device less 33
Interpretation von Bytemustern im Superblock (1/2) Anzahl der Inodes (s_inodes_count): Bytemuster: 00f8 0100 Entspricht folgender Hex-Zahl: Entspricht folgender Dezimalzahl: Anzahl der Blöcke (s_blocks_count): Bytemuster: 80ef 0300 Entspricht folgender Hex-Zahl: Entspricht folgender Dezimalzahl: 34
Interpretation von Bytemustern im Superblock (2/2) Anzahl der reservierten Blöcke (s_r_blocks_count): Bytemuster: 6032 0000 Entspricht folgender Hex-Zahl: Entspricht folgender Dezimalzahl: Für root sind * 4096 = Byte reserviert Blockgröße: block size = 1024 << s_log_block_size; Bytemuster: 0200 0000 Entspricht folgender Hex-Zahl: Entspricht folgender Dezimalzahl: Also beträgt die Blockgröße (= 1024 << ) 35
Dateisystemdaten: Gruppendeskriptortabelle Steht immer im auf den Superblock folgenden FS-Block: Also nur dann, falls Superblock in Blockgruppe steht FS-Block = 1 KByte ==> Steht im FS-Block 2 FS-Block >= 2 KByte ==> Steht im FS-Block 1 Inhalt: Gruppendeskriptoren (jeweils 32 Byte lang) Bei n Blockgruppen stehen n Gruppendeskriptoren in Tabelle Ziel eines Gruppendeskriptors: Verwaltung der zugehörigen Blockgruppe: Lage der Data Bitmap, Inode-Bitmap, Inode-Tabelle... 36
Aufbau eines Gruppendeskriptors Byte-Nr. (dez.) Beschreibung 0 3 FS-Block-Nummer des Data Bitmap 4 7 FS-Block-Nummer des Inode Bitmap 8 11 Erster FS-Block der Inode-Tabelle 12 13 Anzahl freier Blöcke 14 15 Anzahl freier Inodes 16 17 Anzahl an Inodes für Verzeichnisse 18 19 Padding 20 31 Reserviert 37
Data Bitmap Oft auch Block Bitmap Belegt genau einen FS-Block Jedes Bit gibt an, ob der zugehörige Datenblock belegt ist: Bit = 0: Block unbelegt Bit =1: Block belegt Zuordnung Bit im Data Bitmap <--> FS-Block: Beispiel: 0100 0011 Byte 0: Belegtstatus der Datenblöcke 0-7 Byte 1: Belegtstatus der Datenblöcke 8-15 In jedem Byte ausgehend vom least significant bit 0100 0001 Belegt sind die Datenblöcke Die übrigen Datenblöcke sind unbelegt 38
Inode Bitmap und Inode-Tabelle Inode Bitmap: Belegt genau einen FS-Block Oft wird aber nur Hälfte der Bits benötigt Jedes Bit gibt an, ob der zugehörige Inode verwendet wird Verwaltung wie bei Data Bitmap Inode-Tabelle: Enthält Inodes Inodes = Metadaten in ext2/ext3 Enthält keine Dateinamen 39
Erster Analyseansatz Aus Superblock und Gruppendeskriptortabelle ergibt sich Layout der gesamten Partition: Superblock definiert FS-Blockgröße Gruppendeskriptortabelle... Superblock defekt: Suche nach Backup... definiert Layout dieser Blockgruppe.... verweist auf die übrigen Blockgruppen. Z.B. über Magic Signature (z.zt. 0x53ef in Bytes 56-57) Versteckte Daten außerhalb 'regulärer' Dateien: Boot-Bereich, Superblock (inkl. Backups), reservierte Blöcke File Slack 40
Größe und Anzahl der Blockgruppen: Beispiel Randbedingungen: Dateisystem belegt 990 MByte 1 MByte = 1024 KByte = 210 KByte = 220 Byte Jeder FS-Block hat Größe 4096 Byte Fragen: Wie viele FS-Blöcke enthält eine Blockgruppe? Wie groß (in Bytes) ist eine Blockgruppe? Wie viele Blockgruppen legt ext2/ext3 an? 41
Details zum Dateisystem mit fsstat Linux-Tool (TSK): fsstat <device> Ausgabe diverser Informationen über Dateisystem 42
Metadaten In Linux: Metadaten = Inodes Jede Datei ist über ihren Inode eindeutig adressierbar: Wiederholung: In Linux werden auch Verzeichnisse und Geräte als Datei abstrahiert Im Dateisystem beginnt Inode-Nummerierung bei 1 Reservierte Inodes: Beschädigte Blöcke: Wurzelverzeichnis / : Journal (nur in ext3): Verzeichnis lost+found: Inode 1 Inode 2 Inode 8 Inode 11 Erste frei verwendbare Inode-Nummer ist 12 43
Zugriffsrechte unter UNIX / Linux 3 Rechte: Lesen / Schreiben / Ausführen 3 Rechterollen: Besitzer / Gruppe / Welt Beispiel: $ ls -l vorlesung.pdf -rw-r--r-- 1 baier users 654321 2009-10-12 20:39 vorlesung.pdf Zuordnung der uid zu Name über /etc/passwd Zuordnung der gid zu Gruppe über /etc/group 44
Zeiten und Zeitstempel unter UNIX / Linux Zeitangaben in Sekunden seit EPOCH: EPOCH = 01. Januar 1970, 00:00 Uhr, UTC 32 Bit = 232 Sekunden (ungefähr 4 Milliarden Sekunden) Dargestellt als signed integer: Zeitspanne vor EPOCH und danach 3 Zeitstempel: MAC mtime (modification time): Letzter schreibender Zugriff atime (access time): Letzter lesender Zugriff ctime (change time): Letzte Änderung der Metadaten Beispiel: Ungefähres Datum von 1257406553? 45
Aufbau eines Inodes als Übersicht (1/2)... Adresse (dez.) Beschreibung 0 1 Dateityp und Zugriffsrechte (file mode) 2 3 Eigentümer der Datei: User ID (uid) 4 7 Dateigröße in Bytes 8 11 Zeit: Letzter lesender Zugriff auf die Datei (atime) 12 15 Zeit: Letzte Änderung des Inodes (ctime) 16 19 Zeit: Letzter schreibender Zugriff auf Datei (mtime) 20 23 Zeit: Dateilöschung (dtime) 24 25 Gruppe der Datei: Group ID (gid) 26 27 Verweiszähler (Hard links counter) 46
Aufbau eines Inodes als Übersicht (2/2)... Adresse (dez.) Beschreibung 40 43 Zeiger auf den ersten Datenblock 44 47 Zeiger auf den zweiten Datenblock 48 51 Zeiger auf den dritten Datenblock... 84 87 Zeiger auf den zwölften Datenblock 88 91 Zeiger auf den einfachen Indirektionsblock 92 95 Zeiger auf den Zweifach-Indirektionsblock 96 99 Zeiger auf den Dreifach-Indirektionsblock... Zusätzliche Attribute (zum Beispiel Access Control Lists, OS-abhängig) 47
... oder etwas Informatik-näher struct ext2_inode { u16 i_mode; /* File mode */ u16 i_uid; /* Owner Uid */ u32 i_size; /* Size in bytes */ u32 i_atime; /* Access time */ u32 i_ctime; /* Change time */ u32 i_mtime; /* Modification time */ u32 i_dtime; /* Deletion Time */ u16 i_gid; /* Group Id */ u16 i_links_count; /* Links count */ u32 i_blocks; /* Blocks count */... }; 48
Adressierung der Datenblöcke Quelle: http://en.wikipedia.org/wiki/ext2 49
Zeitstempel sind nicht essentielle Daten (1/2) Einfache Änderung mit Standardprogramm touch Ändern der mtime: Syntax: Beispiel: touch -t [YY]MMDDhhmm -m <datei> $ ls -l vorlesung.pdf -rw-r--r-- 1 baier users 654321 2009-10-12 20:39 vorlesung.pdf $ touch -t 0801011234 -m vorlesung.pdf $ ls -l vorlesung.pdf -rw-r--r-- 1 baier users 654321 2008-01-01 12:34 vorlesung.pdf 50
Zeitstempel sind nicht essentielle Daten (2/2) Ändern der atime: Syntax: Beispiel: touch -t [YY]MMDDhhmm -a <datei> $ ls -lu vorlesung.pdf -rw-r--r-- 1 baier users 654321 2009-10-12 20:39 vorlesung.pdf $ touch -t 0902031234 -m vorlesung.pdf $ ls -lu vorlesung.pdf -rw-r--r-- 1 baier users 654321 2009-02-03 12:34 vorlesung.pdf 51
Dateinamen und Verzeichnisse Verzeichnis: Verlinkte Listen von Verzeichniseinträgen Jeder Verzeichniseintrag (=record) enthält: Dateinamen Inode der Datei Zeiger auf den nächsten Verzeichniseintrag Hinweise: Verzeichnis = bestimmter Dateityp unter Linux Jedes Verzeichnis besitzt selber einen Inode Ausgangspunkt für Dateizugriff: Root-Verzeichnis mit Inode 2 Von dort 'Durchhangeln' zu gewünschter Datei 52
Verzeichnis-Struktur Adresse (dez.) Beschreibung 0 3 Inode der Datei Inode = 0: Verzeichniseintrag nicht genutzt (Inode-Nummerierung startet bei 1!) 4 5 Zeiger auf den nächsten Verzeichniseintrag Angabe als Länge des aktuellen Records, gezählt vom Beginn des aktuellen Eintrags --> Länge mindestens so lang wie aktuell benötigt 6 6 Anzahl der Zeichen im Dateinamen (maximal 255 Zeichen) 7 7 Dateityp (1 = regulär, 2 = directory,...) 8 eor Dateiname zzgl. optional 'Record-Slack' (eor = end of record) 53
Beispiel für Verzeichniseintrag Aufrufmöglichkeiten: icat device inode-number xxd less dcat device fs-block-number xxd less 54
Erster Record Offset Bytemuster Wert Bedeutung 0-3 0200 0000 2 Root-Verzeichnis 4-5 0c00 12 Nächster Record ab 12 6-6 01 1 Ein Zeichen im Namen 7-7 02 2 Verzeichnis 8-8 2e 46 ASCII-Zeichen '.' 9-11 000000 - ungenutzt 55
Zweiter Record Offset Bytemuster Wert Bedeutung 12-15 0200 0000 2 Root-Verzeichnis 16-17 0c00 12 Nächster Record ab 24 18-18 02 2 Zwei Zeichen im Namen 19-19 02 2 Verzeichnis 20-21 2e2e 46 46 ASCII-Darstellung von.. 22-23 0000 - ungenutzt 56
Dritter Record Offset Bytemuster Wert Bedeutung 24-27 0b00 0000 11 Verzeichnis lost+found 28-29 1400 20 Nächster Record ab 44 30-30 0a 2 Zehn Zeichen im Namen 31-31 02 2 Verzeichnis 32-41 6c6f...6e64 - lost+found 42-43 0000 - ungenutzt 57
Vierter Record Offset Bytemuster Wert Bedeutung 44-47 0c00 0000 12 Inode Nr. 12 48-49 3000 48 Nächster Record ab 92 50-50 19 25 25 Zeichen im Namen 51-51 01 1 Reguläre Datei 52-76 7465...6363 - test-modularfunctions.cc 77-91 726163...2d70 - String aus altem Eintrag: ractical2.tex-p 58
Untersuchung einer Partition mit TSK Zugriff auf Daten auf verschiedenen Abstraktionsstufen: Datenträgerebene Dateisystemebene Dateinamenebene Metadatenebene Dateiebene / Anwendungsebene Verschiedene Tools zum Auswerten von Daten auf unterschiedlichen Ebenen 59
Untersuchung einer Partition mit TSK: Grundlegendes mmls device (Multimedia listing): Grundlegende Informationen über den Datenträger Partitionen, nicht-allozierte Bereiche Vergleiche Datenträgeranalyse fsstat device (File system status): Grundlegende Informationen über das Dateisystem Auswertung des Superblocks und der Gruppendeskriptortabelle unter ext2 Lage der Blockgruppen und Inhaltsdaten bekannt 60
Untersuchung einer Partition mit TSK: Dateinamen ffind device inode (File name finding): Gibt Name der 'Datei' zu dem Inode aus ffind -d: Anwendung nur auf gelöschte Dateien ffind -a: Gibt die Namen aller Links des Inodes aus Beispiel: ffind -a device 2 / /. /.. fls device [inode] /lost+found/.. (File listing): Informationen über Dateien im Verzeichnis mit Inode inode Defaultwert für inode: 2 (d.h. Wurzel-Verzeichnis) fls -r: Rekursive Suche in nicht-gelöschten Verzeichnisse 61
Untersuchung einer Partition mit TSK: Metadaten ils device (Inode listing): Informationen über Inodes ils -a: Aktuell verwendete oder freigegebene Inodes ils -e: Alle Inodes (e = every) Aus chronologischer Vergabe oft Hinweise auf gelöschte Dateien oder Zugehörigkeit zu Blockgruppe istat device inode (Inode status): Informationen über Inhalt des Inodes Auch die Information, wann eine Datei gelöscht wurde Link auf Inhaltsdaten über Direct Blocks, einfachen Indirektionsblock,... 62
Untersuchung einer Partition mit TSK: Daten icat device inode: Ausgabe des Inhalts einer Datei mittels ihres Inodes Ausgabe auf die Standardausgabe dcat device unit_address [num]: Ausgabe des Inhalts einer Datei mittels ihrer FS-BlockAdresse num: Anzahl der auszugebenden Blöcke (Default = 1) dcat -h: Ausgabe als Hexdump 63
Timelining Rekonstruktion von Vorgängen auf dem Dateisystem Schritt1: Auslesen von Inode-Informationen mittels ils ils -m: Ausgabeformat, das mactime interpretieren kann Ausgabe in eine Datei Kommando: ils -am device > output1.ils Schritt 2: Auswerten der Daten mittels mactime mactime -b body DATE_RANGE body ist Datei, DATE_RANGE ist Zeitraum (MM/DD/YYYY) Kommando: mactime -b output1.ils 11/24/2009 64
Inhalt Allgemeines zu Dateisystemen Linux-Dateisysteme am Beispiel von ext2/ext3 Microsoft-Dateisysteme FAT NTFS 65
Grundlegendes zu FAT (1/2) Einfaches Dateisystem: Meist für DOS oder ältere Windows-Varianten Aber auch für UNIX u. Linux Verwendung z.b. für Flash-Speicher in Digitalkameras Wird daher auch in naher Zukunft von Bedeutung sein FAT = File Allocation Table Tabelle fester Größe, die Pointer auf FS-Blöcke enthält FS-Blöcke heißen in Microsoft-Terminologie Cluster Aus FAT-Pointern ist auch Belegtstatus der Cluster erkennbar 66
Grundlegendes zu FAT (2/2) Drei unterschiedliche Grundvarianten: FATx mit x = 12, 16, 32 x ist die Länge eines FAT-Pointers in Bit Länge eines FAT-Eintrags bestimmt max. Cluster-Anzahl: Beispiel FAT16: Es gibt höchstens 216 = 65536 Cluster Aus Clustergröße folgt max. Größe des Dateisystems FAT folgt nicht dem abstrakten Dateisystemschema: Dateiname und Metadaten stehen gemeinsam in Verzeichniseinträgen Keine FS-Anwendungsdaten (insbesondere kein Journal) 67
Datenverwaltung unter FAT Verzeichniseintrag enthält unter Anderem: Dateiname Adresse des ersten Clusters des Dateiinhalts: n1 Dateigröße Zeitstempel (MAC-Informationen) Weitere Datencluster ergeben sich aus FAT: Cluster Chain Eintrag n1 in FAT: Verweis auf Clusteradresse n2 des zweiten Datenclusters oder EOF Und so weiter bis EOF Anzahl der Cluster ergibt sich aus Datei- und Clustergröße 68
Aufteilungskonzept des Laufwerks unter FAT Drei Bereiche (von 'vorne' nach 'hinten' auf Laufwerk): Reserved area (Reservierter Bereich) FAT area (FAT-Bereich) Data area (Datenbereich) Wichtig: Nur im Datenbereich werden Cluster zur Adressierung verwendet Kleinste Cluster-Adresse ist 2!!! Lage von Cluster 2 im Datenbereich ist für FAT12/16 und FAT32 verschieden (siehe gleich) 69
Reserved area = Reservierter Bereich Beginnt immer bei HDD-Block 0 des Laufwerks Dort steht Großteil der Dateisystemdaten Enthält Bootsektor sowie ggfls. weitere HDD-Blöcke: FAT12/16: Reserved area besteht typ. aus einem HDD-Block FAT32: Reserved area besteht aus mehreren HDD-Blöcken FSINFO in Block 1: Hinweise über freie Cluster Backup des Bootsektors (Default ist Block 6) Größe der reserved area steht im Bootsektor Vorsicht: Reserved area wird nicht über Cluster adressiert 70
FAT area = FAT-Bereich Beginnt im HDD-Block direkt hinter reserved area Enthält eine oder mehrere FATs Typischerweise 2 FATs: Primary FAT (FAT0) Backup von FAT0 (FAT1): FAT0 und FAT1 inhaltsgleich Größe des FAT-Bereichs steht im Bootsektor: Anzahl der FATs Größe einer FAT Vorsicht: FAT area wird nicht über Cluster adressiert 71
Data area = Datenbereich Beginnt im HDD-Block direkt hinter FAT area Enthält Verzeichnisse und Inhaltsdaten Wurzelverzeichnis: Bei FAT12/16 steht dieses direkt hinter FAT-Bereich Bei FAT32 kann es irgendwo im Datenbereich liegen (Cluster-Nummer steht im Bootsektor) Lage von Cluster 2: FAT12/16: Direkt hinter Wurzelverzeichnis FAT32: Direkt am Anfang des Datenbereichs 72
Essentielle Daten des Bootsektors Byte-Nr. (dez.) Beschreibung 11 12 Größe eines HDD-Blocks in Bytes 13 13 Größe eines Clusters in HDD-Blöcken Erlaubt: 2n, jedoch maximal 32 KByte 14 15 Größe der reserved area in HDD-Blöcken 16 16 Anzahl an FATs (typischerweise 2) 17 18 Maximale Einträge im Wurzelverzeichnis Für FAT32 = 0 (da in separater Datenstruktur) 19 20 Größe des Dateisystems in HDD-Blöcken Falls größer, benutze Bytes 32-35 22 23 Anzahl der HDD-Blöcke pro FATx (nur x=12,16) 73
Nicht-Essentielle Daten des Bootsektors Byte-Nr. (dez.) Beschreibung 00 02 Jump-Anweisung zu Boot-Code Essentiell, falls bootfähig 03 10 OEM-Name oder Leerzeichen Gibt evtl. Hinweise auf verwendetes OS 21 21 Medientyp: Wechselmedium oder nicht 510 511 'Signatur': Hexdump 55aa (=0xaa55) 74
Fallbeispiel: Analyse des Bootsektors Hexdump einer Flash-Speicherkarte aus Digitalkamera Ziel: Laufwerksaufteilung bestimmen 75
Interpretation von Bytemustern im Bootsektor (1/4) OEM-Name (03-10, nicht-essentiell): Hexdump: Entspricht String: Größe eines HDD-Blocks in Bytes (11-12, essentiell): Hexdump: Entspricht folgender Hex-Zahl: Entspricht folgender Dezimalzahl: 76
Interpretation von Bytemustern im Bootsektor (2/4) Größe eines Clusters in HDD-Blöcken (13, essentiell): Hexdump: Entspricht folgender Hex-Zahl: Entspricht folgender Dezimalzahl: Größe reserved area in HDD-Blöcken (14-15, essentiell): Hexdump: Entspricht folgender Hex-Zahl: Entspricht folgender Dezimalzahl: Dort beginnt die FAT 77
Interpretation von Bytemustern im Bootsektor (3/4) Anzahl der FATs (16, essentiell): Hexdump: Entspricht folgender Hex-Zahl: Entspricht folgender Dezimalzahl: Größe einer FAT in HDD-Blöcken (22-23, essentiell): Hexdump: Entspricht folgender Hex-Zahl: Entspricht folgender Dezimalzahl: 78
Interpretation von Bytemustern im Bootsektor (4/4) Max. Dateianzahl im Wurzelverzeichnis (17-18, essentiell): Hexdump: Entspricht folgender Hex-Zahl: Entspricht folgender Dezimalzahl: Größe des Wurzelverzeichnisses: Jeder Dateieintrag im Wurzelverzeichnis besteht aus 32 Byte Größe in Bytes: Größe in HDD-Blöcken: 79
Layout des FAT-Systems der Digitalkamera Bereich HDD-Blöcke Reserved Area FAT area FAT0 FAT1 Wurzelverzeichnis Cluster 2 Cluster 3 80
Umrechnung Laufwerkadresse Clusteradresse Bekannt: Logische Laufwerkadresse von Cluster 2: AL(Cluster2) Anzahl der HDD-Blöcke pro Cluster: N Clusteradresse des betrachteten Clustern : n Gesucht: Logische Laufwerkadresse von Cluster n AL(Clustern) = (n - 2) N + AL(Cluster2) Auflösen nach n ergibt umgekehrte Berechnung: n = ( AL (Clustern) - AL (Cluster2) ) / N + 2 81
Metadaten: FAT-Einträge Zwei Ziele des FAT-Eintrags n: Gibt Belegtstatus des zugehörigen Clusters n an Falls Cluster n alloziert, gibt es folgende Alternativen: Weist auf den auf Cluster n folgenden Cluster Zeigt an, dass Cluster n der letzte Cluster der Cluster Chain ist Gibt an, dass Cluster n beschädigt ist (heute eigentlich überflüssig) FAT-Einträge starten direkt hinter reserviertem Bereich Nummerierung startet bei n = 0: Die ersten beiden FATEinträge werden für Datencluster nicht benötigt FAT-Eintrag 0: Media Type des Laufwerks FAT-Eintrag 1: Dirty status (z.b. gesetzt bei Systemabsturz) 82
FAT12/16 FAT12: Jeder FAT-Eintrag hat Bitlänge 12 Cluster unbelegt: FAT-Eintrag ist 0x000 Cluster beschädigt: FAT-Eintrag ist 0xff7 EOF-Markierung: FAT-Eintrag ist 0xff8-0xfff Andernfalls Adresse des folgenden Clusters in Cluster Chain FAT16: Jeder FAT-Eintrag hat Bitlänge 16 Cluster unbelegt: FAT-Eintrag ist 0x0000 Cluster beschädigt: FAT-Eintrag ist 0xfff7 EOF-Markierung: FAT-Eintrag ist 0xfff8-0xffff Andernfalls Adresse des folgenden Clusters in Cluster Chain 83
FAT32 und Dateilöschung Jeder FAT-Eintrag hat Bitlänge 32 Davon werden aber nur 28 Bit benutzt: Cluster unbelegt: FAT-Eintrag ist 0x00000000 Cluster beschädigt: FAT-Eintrag ist 0x0ffffff7 EOF-Markierung: Andernfalls Adresse des folgenden Clusters in Cluster Chain FAT-Eintrag ist 0x0fffffff8-0x0fffffff Dateilöschung: FAT-Einträge der Cluster werden auf 0 gesetzt Inhalte der Datencluster bleiben typischerweise erhalten 84
Beispiel: FAT0 der Digitalkamera in HDD-Block 1 baier@watson $ dcat /dev/sdb1 1 xxd less 0000000: f8ff ffff ffff ffff ffff 0600 0700 0800... 0000010: 0900 0a00 0b00 0c00 0d00 0e00 0f00 1000... 0000020: 1100 1200 1300 1400 1500 1600 1700 1800... 0000030: 1900 1a00 1b00 1c00 1d00 1e00 1f00 2000.... 0000040: 2100 2200 2300 2400 2500 2600 2700 2800!.".#.$.%.&.'.(. 0000050: 2900 2a00 2b00 2c00 2d00 2e00 2f00 3000 ).*.+.,.-.../.0. 0000060: 3100 3200 3300 3400 3500 3600 3700 3800 1.2.3.4.5.6.7.8. 0000070: 3900 3a00 3b00 3c00 3d00 3e00 3f00 4000 9.:.;.<.=.>.?.@. 0000080: 4100 4200 4300 4400 4500 4600 4700 4800 A.B.C.D.E.F.G.H. [REMOVED] 00001b0: d900 da00 db00 dc00 dd00 de00 df00 e000... 00001c0: e100 e200 ffff e400 e500 e600 e700 e800... 85
Analyse der nicht-allozierten Inhaltsdaten Gehe FAT durch: Suche alle FAT-Einträge mit Wert 0 Suche alle FAT-Einträge zu beschädigten Clustern Wird heute typischerweise von Festplatten direkt gemanagt Manche Tools lassen diese Cluster aus Lese alle zugehörigen Datencluster aus File System Slack und FAT-Slack nicht vergessen: Oft bleiben am 'Ende' des Laufwerks HDD-Blöcke übrig Vorsicht: Größe des Dateisystems in Bootsektor kann einfach mit Hex-Editor manipuliert werden FAT-Slack: Bereich zwischen letztem FAT-Eintrag und nächstem Bereich (nächster FAT oder Datenbereich) 86
Verzeichnisse: Grundlagen (1/3) Verzeichniseinträge enthalten Dateinamen und Metadaten Jeder Verzeichniseintrag hat die Länge 32 Byte Inhalt eines Verzeichniseintrags: Dateiname Clusteradresse des ersten Datenclusters MAC-Zeitstempel: Unterschiedliche Genauigkeit Dateigröße Attribute: In 4 Byte kodiert entspricht max. Dateigröße 4 GByte Essentiell: Verzeichnis (Ja/Nein), Langer Dateiname (J/N) Nicht-essentiell: Zugriffsrechte, Systemdatei, Archiv (für Backup) 87
Verzeichnisse: Grundlagen (2/3) Beim Anlegen eines neuen Verzeichnisses wird ein Cluster alloziert und zunächst mit Nullbytes überschrieben Dateigröße des neuen Verzeichnis im Elternverzeichnis = 0 Also kann Größe eines Verzeichnisses nur durch Abschreiten der Cluster Chain bestimmt werden Ausnahme: Rootverzeichnis, dessen Größe im Bootsektor steht Erste beiden Verzeichniseinträge sind. und.. Ausnahme: Rootverzeichnis Zeitstempel für. und.. werden nie verändert Inkonsistenz mit Zeitstempeln im Elternverzeichnis 88
Verzeichnisse: Grundlagen (3/3) Löschen einer Datei: Erstes Zeichen des Dateinamens im Verzeichniseintrag wird auf den Wert 0xe5 gesetzt Der Rest des Verzeichniseintrags bleibt erhalten Insbesondere also der Verweis auf den ersten Datencluster Aber: In FAT werden alle Datencluster auf unbelegt gesetzt Cluster Chain geht dadurch bis auf ersten Cluster verloren Namenskonflikt: vase.jpg und nase.jpg nach Löschung Namenskonflikt Jeweils _ase.jpg 89
Verzeichnisstruktur Byte-Nr. (dez.) Beschreibung 00 00 Erstes ASCII-Zeichen des Dateinamens oder 0x00 für nicht-alloziert oder 0xe5 für gelöscht 01 10 Restliche Zeichen des Dateinamens (8+3) 11 11 Attribute (Zugriffsrechte, Langer Name, Dir, ) 12 12 Reserviert 13 19 Zeitstempel für created und accessed 20 21 Nur FAT32: Höherwertige Bytes 1. Clusteradresse 22 25 Zeitstempel für last written 26 27 Niederwertige Bytes 1. Clusteradresse 28 31 Dateigröße in Bytes (= 0 für Verzeichnisse) 90
Suche nach gelöschten Verzeichnissen Annahme: Daten-Cluster wurde seit Löschung nicht wieder alloziert Suchen nach bestimmter Signatur: Bytes 0-10 stehen für '.' 2e20 2020 2020 2020 2020 20 Bytes 32-42 stehen für '..' 2e2e 2020 2020 2020 2020 20 Kann mit Tool sigfind aus TSK durchgeführt werden Angabe von Maximal 4 Suchbytes sigfind 2e20202e image sucht nach Signatur 2E202020 Slack Space nicht vergessen! 91
Adressierung von Metadaten im TSK Anlehnung an UNIX-Konvention für Inodes: Metadaten stehen in Verzeichnissen Wurzelverzeichnis hat 'Inode' 2 Unterteilung des Datenbereichs in 32-Byte-Segmente: Erste 32 Byte in Datenbereich haben Inode '3' Zweite 32 Byte in Datenbereich haben Inode '4' Ein bisschen Umrechnung ist nötig Nur sinnvolle Metadaten, falls in Cluster ein Verzeichnis steht Beispiel für Root-Verzeichnis: istat device 2 92
Beispiel: Wurzelverzeichnis / der Digitalkamera baier@watson $ dcat /dev/sdb1 xxd less 0000000: 4443 494d 2020 2020 2020 2010 0000 4869 DCIM 0000010: 3d3a 4a3a 0000 dd8a 4a3a 0200 0000 0000 =:J:...J:... 0000020: 0000 0000 0000 0000 0000 0000 0000 0000... 0000030: 0000 0000 0000 0000 0000 0000 0000 0000......Hi Erster Verzeichniseintrag: Dateiname: Adresse des ersten Datenclusters: Weitere Datencluster: Dateigröße: Zugriff auf Metadaten mit TSK: 93
Beispiel: Verzeichnis /DCIM der Digitalkamera (1/2) baier@watson $ dcat /dev/sdb1 xxd less 0000000: 2e20 2020 2020 2020 2020 2010 0000 4969. 0000010: 3d3a 3d3a 0000 4969 3d3a 0200 0000 0000 =:=:..Ii=:... 0000020: 2e2e 2020 2020 2020 2020 2010 0000 4969.. 0000030: 3d3a 3d3a 0000 4969 3d3a 0000 0000 0000 =:=:..Ii=:... 0000040: 3130 3044 5343 494d 2020 2010 0000 4969 100DSCIM 0000050: 3d3a 4a3a 0000 e68a 4a3a 0300 0000 0000 =:J:...J:... 0000060: 3130 3144 5343 494d 2020 2010 0064 5c51 101DSCIM 0000070: 413b 7d3b 0000 a699 7d3b 0400 0000 0000 A;};...};... 0000080: 0000 0000 0000 0000 0000 0000 0000 0000... 0000090: 0000 0000 0000 0000 0000 0000 0000 0000... 00000a0: 0000 0000 0000 0000 0000 0000 0000 0000... 00000b0: 0000 0000 0000 0000 0000 0000 0000 0000......Ii...Ii...Ii..d\Q 94
Beispiel: Verzeichnis /DCIM der Digitalkamera (2/2) 0000060: 3130 3144 5343 494d 2020 2010 0064 5c51 101DSCIM 0000070: 413b 7d3b 0000 a699 7d3b 0400 0000 0000 A;};...};.....d\Q Vierter Verzeichniseintrag: Dateiname: Adresse des ersten Datenclusters: Weitere Datencluster: Dateigröße: Zugriff auf Metadaten mit TSK: 95
Beispiel: Verzeichnis /DCIM/101DSCIM (1/2) baier@watson $ dcat /dev/sdb1 32 xxd less [REMOVED Entries for. and..] 0000040: 4249 4c44 3039 3433 4a50 4700 0000 f55e BILD0943JPG...^ 0000050: 853b 893b 0000 f65e 853b 0500 a545 3700.;.;...^.;...E7. 0000060: 4249 4c44 3039 3434 4a50 4700 0000 065f BILD0944JPG..._ 0000070: 853b 893b 0000 065f 853b e300 8f5b 2600.;.;..._.;...[&. 0000080: 4249 4c44 3039 3435 4a50 4700 0000 115f BILD0945JPG..._ 0000090: 853b 893b 0000 115f 853b 7d01 c483 3500.;.;..._.;}...5. 00000a0: 4249 4c44 3039 3436 4a50 4700 0000 1c5f BILD0946JPG..._ 00000b0: 853b 893b 0000 1c5f 853b 5402 7d92 3100.;.;..._.;T.}.1. 00000c0: 4249 4c44 3039 3437 4a50 4700 0000 6e78 BILD0947JPG...nx 00000d0: 853b 893b 0000 6e78 853b 1b03 2cad 3900.;.;..nx.;..,.9. 00000e0: 4249 4c44 3039 3438 4a50 4700 0000 7d78 BILD0948JPG...}x 00000f0: 853b 893b 0000 7d78 853b 0204 27b5 3500.;.;..}x.;..'.5. 0000100: e549 4c44 3039 3339 4a50 4700 0000 e08b.ild0939jpg... 0000110: 7d3b 7d3b 0000 e08b 7d3b ce04 b676 3100 };};...};...v1. 96
Beispiel: Verzeichnis /DCIM/101DSCIM (2/2) baier@watson $ dcat /dev/sdb1 32 xxd less [REMOVED] 0001340: e549 4c44 3037 3539 4a50 4700 0000 448f.ILD0759JPG...D. 0001350: 343b 373b 0000 448f 343b efdd 1778 2900 4;7;..D.4;...x). 0001360: e549 4c44 3037 3630 4a50 4700 0000 478f.ILD0760JPG...G. 0001370: 343b 373b 0000 478f 343b 95de 7e44 3d00 4;7;..G.4;..~D=. 0001380: e549 4c44 3037 3631 4a50 4700 0000 4f8f.ILD0761JPG...O. 0001390: 343b 373b 0000 4f8f 343b 8bdf 082b 3500 4;7;..O.4;...+5. 00013a0: e549 4c44 3037 3632 4a50 4700 0000 2e7b.ILD0762JPG...{ 00013b0: 363b 373b 0000 2e7b 363b 60e0 c919 3700 6;7;...{6;`...7. 00013c0: e549 4c44 3037 3633 4a50 4700 0000 457b.ILD0763JPG...E{ 00013d0: 363b 373b 0000 457b 363b 3de1 853a 4300 6;7;..E{6;=..:C. 00013e0: 0000 0000 0000 0000 0000 0000 0000 0000... 00013f0: 0000 0000 0000 0000 0000 0000 0000 0000... 0001400: 0000 0000 0000 0000 0000 0000 0000 0000... 0001410: 0000 0000 0000 0000 0000 0000 0000 0000... 97
Versuch einer Dateirekonstruktion 00013c0: e549 4c44 3037 3633 4a50 4700 0000 457b.ILD0763JPG...E{ 00013d0: 363b 373b 0000 457b 363b 3de1 853a 4300 6;7;..E{6;=..:C. Warum ist eine erfolgreiche Wiederherstellung wahrscheinlich? Vorgehen zur Rekonstruktion von BILD0763.JPG: Erster Datencluster: HDD-Block des ersten Datenclusters: Dateigröße: Anzahl HDD-Blöcke der Datei: Befehl zum Auslesen: 98
Defragmentierung vs. Dateiwiederherstellung Annahme: Defragmentierung nicht lange her Hohe Wahrscheinlichkeit für Dateiwiederherstellung Dateien, die nach Defragmentierung gelöscht wurden Denn diese liegen typischerweise nicht fragmentiert vor Geringe Wahrscheinlichkeit für Dateiwiederherstellung: Dateien, die vor Defragmentierung gelöscht wurden Deren Speicherbereich wird typischerweise überschrieben Oder man findet nur ersten Datencluster 99