Inhaltsverzeichnis
Disk Images untersuchen mit TSK
In diesen Tutorial wird TSK und das EWF (Expert Witness Compression Format) für die Image Erstellung verwendet,
da das libewf Paket bei einem Arch Linux als Abhängigkeit mit installiert wird.
Als Alternative zu libewf sei afflibAUR zubennen.
Es werden Begriffe wie case (Fall), Evidence (Beweis) etc. fallen. Da diese Tools hauptsächlich in der Digital Forensik zum Einsatz kommen.
Vorbereitungen
Dafür werden wir einen kleinen USB-Stick (ca. 4 GiB) vorbereiten. Dieser wird in diesem Toturial unter /dev/sdc angesprochen.
Mithilfe von blkdiscard werden wir diesen mit nullen beschreiben,
um optimale Bedingungen für den Wiederherstellungsversuch und dem Komprimierungsalgorithmus zu schaffen.
sudo blkdiscard -fz /dev/sdc
Als nächtes legen wir auf dem USB-Stick eine neue GPT mit zwei unterschiedlich großen Partitionen an. Die wir mit dem exFat und dem NTFS Dateisystem formatieren.
Beispiel für das Anlegen einer Partitionstabelle und das Formatieren der Dateisysteme einfügen.
Nachdem das getan ist, erstellen wir auf beiden Dateisysteme diese Dateien mit folgedem Inhalt:
exFAT_filesystem ="/mnt/usb-stick_exfat" NTFS_filesystem ="/mnt/usb-stick_ntfs" sudo mkdir -p ${exFAT_filesystem} ${NTFS_filesystem} sudo mount /dev/sdc1 ${exFAT_filesystem} sudo mount /dev/sdc2 ${NTFS_filesystem} echo "Ich bin eine Datei auf einem extFAT Dateisystem" >${exFAT_filesystem}/file_on_an_exfat_volume.txt echo "Ich bin eine Datei auf einem NTFS Dateisystem" >${NTFS_filesystem}/file_on_an_ntfs_volume.txt echo "Ich bin ursprünglich gelöscht worden." >${exFAT_filesystem}/deleted_file.txt echo "Ich bin ursprünglich gelöscht worden." >${NTFS_filesystem}/deleted_file.txt
Und löschen sofort wieder die Datei delted_file.txt vom USB-Stick, und unmounten alle Dateisysteme wieder.
rm -i ${exFAT_filesystem}/file_on_an_exfat_volume.txt rm -i ${NTFS_filesystem}/file_on_an_ntfs_volume.txt sudo umount ${exFAT_filesystem} ${NTFS_filesystem}
Daten Sichern
Das Erste, das man tun sollte, falls Daten von einem Datenträger versehentlich gelöscht wurden, sind die Daten auf dem Datenträger zu sichern und den Datenträger nicht mehr weiterzuverwenden, um zu verhindern dass Daten auf dem Datenträger überschrieben werden.
Im folgenden Beispiel handelt es sich um einem intakten Datenträger.
Sollen Daten von beschädigten Datenträgern gesichert werden, so müssen andere Tools wie dd_rescure herangezogen werden.
ewfacquire (Daten Sicherstellen)
- Es sollte für ewfacquire eine eigene Wikiseite verwendet werden.
Um Daten vom USB-Stick sicherzustellen. Verwende wir das Tool ewfacqurie aus der libewf Bibliothek.
Das EWF speichert noch einige Metadaten rund um das zu sichernde Medium und der Forensik Station (in unseren Fall unser PC).
Welche zusätzlichen Metadaten das sind, können wir weiter unten im Shell Output nachlesen:
Wir legen für unseren Fall (case) ein neues Arbeitsverzeichnis an und wechsel in dieses:
mkdir -p ~/tmp/case1 cd ~/tmp/case1
Als Nächstes starten wir das Programm mit Root Rechten, um Zugriff auf den USB-Stick zu bekommen.
Die einzige Option, die wir angeben, ist die -l Option um eine Logdatei für Fehler und der MD5 Prüfsummen Ausgabe anzugeben.
für den rest lassen wir uns von ewfacquire abfragen.
sudo ewfacquire -l image.log /dev/sdc ewfacquire 20140608 Device information: Bus type: USB Vendor: Generic Model: Flash Disk Serial: Storage media information: Type: Device Media type: Removable Media size: 4.2 GB (4208984064 bytes) Bytes per sector: 512 Acquiry parameters required, please provide the necessary input Image path and filename without extension: usb_stick_image Case number: 001 Description: Test USB Stick Evidence number: 001 Examiner name: Sebastian Notes: Ein einfacher Test USB Stick Media type (fixed, removable, optical, memory) [removable]: Media characteristics (logical, physical) [logical]: Use EWF file format (ewf, smart, ftk, encase1, encase2, encase3, encase4, encase5, encase6, linen5, linen6, ewfx) [encase6]: Compression method (deflate) [deflate]: Compression level (none, empty-block, fast, best) [none]: best Start to acquire at offset (0 <= value <= 4208984064) [0]: The number of bytes to acquire (0 <= value <= 4208984064) [4208984064]: Evidence segment file size in bytes (1.0 MiB <= value <= 7.9 EiB) [1.4 GiB]: 5G The number of bytes per sector (1 <= value <= 4294967295) [512]: The number of sectors to read at once (16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768) [64]: The number of sectors to be used as error granularity (1 <= value <= 64) [64]: The number of retries when a read error occurs (0 <= value <= 255) [2]: Wipe sectors on read error (mimic EnCase like behavior) (yes, no) [no]: The following acquiry parameters were provided: Image path and filename: usb_stick_image.E01 Case number: 001 Description: Test USB Stick Evidence number: 001 Examiner name: Sebastian Notes: Ein einfacher Test USB Stick Media type: removable disk Is physical: yes EWF file format: EnCase 6 (.E01) Compression method: deflate Compression level: best Acquiry start offset: 0 Number of bytes to acquire: 3.9 GiB (4208984064 bytes) Evidence segment file size: 5.0 GiB (5368709120 bytes) Bytes per sector: 512 Block size: 64 sectors Error granularity: 64 sectors Retries on read error: 2 Zero sectors on read error: no Continue acquiry with these values (yes, no) [yes]: Acquiry started at: May 04, 2024 11:11:23 This could take a while. Status: at 1%. acquired 78 MiB (82804736 bytes) of total 3.9 GiB (4208984064 bytes). completion in 6 minute(s) and 36 second(s) with 10 MiB/s (10522460 bytes/second). ... Status: at 99%. acquired 3.9 GiB (4200300544 bytes) of total 3.9 GiB (4208984064 bytes). completion in 1 second(s) with 22 MiB/s (23254055 bytes/second). Acquiry completed at: May 04, 2024 11:14:23 Written: 3.9 GiB (4208985380 bytes) in 3 minute(s) and 0 second(s) with 22 MiB/s (23383252 bytes/second). MD5 hash calculated over data: d6742b4b02073025bcdf0a6dceff4bb3 ewfacquire: SUCCESS
Die Ausgabe ist auf das wesentliche gekürzt worden.
Das Sicherstellen der Daten hat 3 Min Gedauert und die MD5 Prüfsumme über die Daten ist d6742b4b02073025bcdf0a6dceff4bb3.
Diese wurde in die Datei image.log geschrieben:
cat image.log MD5 hash calculated over data: d6742b4b02073025bcdf0a6dceff4bb3
im Arbeitsverzeichnis befinden sich zu disem Zeitpunkt nun folgende Dateien:
ls -lh insgesamt 7,5M -rw-r--r-- 1 root root 65 4. Mai 11:14 image.log -r-------- 1 root root 7,5M 4. Mai 11:14 usb_stick_image.E01
Das Image, des 4 GiB großen USB-Sticks, ist auf 7,5 MiB Komprimiert worden. Das ist der vorarbeitung des Datenträgers geschuldet. Die Sektoren die mit nullen beschrieben wurden können sehr gut Komprimiert werden. Dies ist ein sehr unrealistisches Scenario.
Damit wir ohne Root Rechte am Image weiterarbeiten können, änderen wir den den Besitzer des Images auf unseren Benutzer. Sicherheitshalber geben wir der Datei auch nur Leserechte, da wir von dieser Datei nur lesen möchten.
sudo chown sebastian: usb_stick_image.E01 chmod 400 usb_stick_image.E01
Daten Untersuchen/Analysieren
mmls (Image Struktur Analysieren)
- mmls sollte eine eigene Wikiseite bekommen
Um die Innere Struktur des Images anzuzeigen, kann mmls verwendet werden:
mmls usb_stick_image.E01 GUID Partition Table (EFI) Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 000: Meta 0000000000 0000000000 0000000001 Safety Table 001: ------- 0000000000 0000002047 0000002048 Unallocated 002: Meta 0000000001 0000000001 0000000001 GPT Header 003: Meta 0000000002 0000000033 0000000032 Partition Table 004: 000 0000002048 0001026047 0001024000 Microsoft basic data 005: 001 0001026048 0003123199 0002097152 Microsoft basic data 006: ------- 0003123200 0008220671 0005097472 Unallocated
Man erkennt, eine GPT mit 2 Partitionen und noch nicht zugewiesener Raum zwischen der Safety Table und dem GPT Header bzw. noch einmal ganz am ende des Datenträgers.
Auf nicht Adressierte Berreiche, können sich auch Daten befinden! Dieser Raum wurde legetlich zurzeit der Image Erstellung nicht Adressiert.
Wir haben jetzt also eine Ahnung wo sich Daten befinden können. Einmal am offset 2048, und einmal am offset 1026048.
fsstat (Dateisystem Information anzeigen)
- fsstat sollte eine eigene Wikiseite bekommen.
Um in Erfahrung zu bringen welches Dateisystem sich an den offsets befindet,
setzten wir das fsstat Tool folgendermassen ein:
fsstat -o 2048 usb_stick_image.E01 FILE SYSTEM INFORMATION -------------------------------------------- File System Type: exFAT Volume Serial Number: 6eff-feb2 Volume Label (from root directory): FS_EXFAT File System Name (from MBR): EXFAT File System Revision: 1.0 Partition Offset: 2048 Number of FATs: 1 File System Layout (in sectors): Range: 0 - 1023999 * Reserved: 0 - 2047 ** Volume Boot Record (VBR): 0 - 11 *** Boot Sector (MBR): 0 ** Backup Volume Boot Record (VBR): 12 - 23 *** Backup Boot Sector (MBR): 12 ** FAT alignment space: 24 - 2047 * FAT 1: 2048 - 2175 * Data Area alignment space: 2176 - 4095 * Data Area: 4096 - 1023999 ** Cluster Heap: 4096 - 1023999 *** Root Directory: 4224 - 4287 METADATA INFORMATION -------------------------------------------- Metadata Layout (in virtual inodes): Range: 2 - 16318469 * Root Directory: 2 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 32768 Cluster Range: 2 - 15937
Es werden wichtige Informationen über das vorhandene Dateisystem angezeigt. Unteranderem das es sich um ein exFAT Dateisystem handelt und wie groß es ist.
Das gleiche wiederholen wir mit der anderen Partition:
fsstat -o 1026048 usb_stick_image.E01 FILE SYSTEM INFORMATION -------------------------------------------- File System Type: NTFS Volume Serial Number: 09908AA36C27F66F OEM Name: NTFS Volume Name: FS_NTFS Version: Windows XP METADATA INFORMATION -------------------------------------------- First Cluster of MFT: 4 First Cluster of MFT Mirror: 131071 Size of MFT Entries: 1024 bytes Size of Index Records: 4096 bytes Range: 0 - 1152 Root Directory: 5 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 4096 Total Cluster Range: 0 - 262142 Total Sector Range: 0 - 2097150 $AttrDef Attribute Values: $STANDARD_INFORMATION (16) Size: 48-72 Flags: Resident $ATTRIBUTE_LIST (32) Size: No Limit Flags: Non-resident $FILE_NAME (48) Size: 68-578 Flags: Resident,Index $OBJECT_ID (64) Size: 0-256 Flags: Resident $SECURITY_DESCRIPTOR (80) Size: No Limit Flags: Non-resident $VOLUME_NAME (96) Size: 2-256 Flags: Resident $VOLUME_INFORMATION (112) Size: 12-12 Flags: Resident $DATA (128) Size: No Limit Flags: $INDEX_ROOT (144) Size: No Limit Flags: Resident $INDEX_ALLOCATION (160) Size: No Limit Flags: Non-resident $BITMAP (176) Size: No Limit Flags: Non-resident $REPARSE_POINT (192) Size: 0-16384 Flags: Non-resident $EA_INFORMATION (208) Size: 8-8 Flags: Resident $EA (224) Size: 0-65536 Flags: $LOGGED_UTILITY_STREAM (256) Size: 0-65536 Flags: Non-resident
Hier änliche Informationen spezifisch für das NTFS Dateisystem.
Um die Ausgaben verstehen zu können, sollte man sich der Dokumentation des jeweiligen Dateisystems widmen.
fls (Dateien und Verzeichnis von einem Dateisystem in einem Image auflisten)
- fls sollte eine eigene Wikiseite bekommen.
Um nun in das Dateisystem hineinzuschauen, verweden wir das Tool fls:
fls -o 2048 usb_stick_image.E01 r/r 2051: FS_EXFAT (Volume Label Entry) r/r 2052: $VOLUME_GUID r/r 2053: $ALLOC_BITMAP r/r 2054: $UPCASE_TABLE d/d 2055: .Trash-1000 r/r 2059: file_on_an_exfat_volume.txt r/r * 2063: deleted_file.txt v/v 16318467: $MBR v/v 16318468: $FAT1 V/V 16318469: $OrphanFiles
Die Ausgabe ist in mehren Spalten unterteilt.
Die erste Spalte zeigt, um was es sich handelt eine Datei (r, Regular file), ein Verzeichnis (d, Directory) eine Virtuelle TSK Datei (v, TSK Virtual file) etc. Mehr Information dazu gibt siehe TSK Wiki
Es folgt eine Spalte indem eventuell ein * zu sehen ist. Dieses * bedeutet das diese Datei gelöscht, bzw. nicht mehr über den Index des Dateisystems referenziert wird. Und damit irgendwann überschrieben werden würde.
Es folgt die Spalte mit der Inode Nummer für die jweilige Datei.
In der Letzten Spalte ist noch der Dateiname bzw. Verzeichnisname angegeben.
Zum Filtern von nicht mehr Referenzierten Dateien kann man auch den -d Schalter verwenden:
fls -d -o 2048 usb_stick_image.E01 r/r * 2063: deleted_file.txt
Daten Extrahieren
icat (Inhaltsausgabe anhand der Inode)
- icat sollte eine eigene Wikiseite bekommen.
wie das normale cat, gibt icat Eingabe Daten an die Standardausgabe weiter.
Der unterschied ist das icat für das Arbeiten mit Image Dateien entworfen wurde und als Referenz (bzw. Zeiger) Inode Nr. entgegennimmt.
Um den Inhalt von file_on_an_exfat_volume.txt auszugeben verwenden wir dessen Inode Nr 2059:
icat -o 2048 usb_stick_image.E01 2059 Ich bin eine Datei auf einem extFAT Dateisystem
Um den Inhalt zu Extrahieren kann die Ausgabe einfach umgeleitet werden. Siehe dazu Command-line_shell#Input_and_output
Dies ist keine vollständigen Extraktion! Es wird dabei nur der Dateiinhalt extrahiert nicht aber die Metadaten. Dies spielt bei der Beweis Führung eine wichtige Rolle!
Um mehrere Dateien und Verzeichnisse zu Extraieren gibt es andere Möglichkeiten.
Dies funktioniert auch bei nicht mehr Referenzierten Dateien:
icat -o 2048 usb_stick_image.E01 2063 Ich bin ursprünglich gelöscht worden.
Dateisystem machen den Unterschied
Beim examinieren von Daten, haben Dateisysteme gravierende Unterschiede. Manche sind mehr auf Sicherheit bedacht als andere.
Um den Unterscheid zu Demonstrieren hier die Fehlende Ausgabe des NTFS Dateisystems:
fls -o 1026048 usb_stick_image.E01 r/r 4-128-1: $AttrDef r/r 8-128-2: $BadClus r/r 8-128-1: $BadClus:$Bad r/r 6-128-1: $Bitmap r/r 7-128-1: $Boot d/d 11-144-2: $Extend r/r 2-128-1: $LogFile r/r 0-128-1: $MFT r/r 1-128-1: $MFTMirr r/r 9-128-2: $Secure:$SDS r/r 9-144-3: $Secure:$SDH r/r 9-144-4: $Secure:$SII r/r 10-128-1: $UpCase r/r 10-128-2: $UpCase:$Info r/r 3-128-3: $Volume d/d 30-144-2: .Trash-1000 r/r 29-128-2: file_on_an_ntfs_volume.txt V/V 1152: $OrphanFiles
Beim NTFS Dateisystem landen nicht mehr Referenzierte Dateien im TSK Virtual file ($OrphanFiles).
Um diese sehen zu können muss die Option -r mit angegeben werden. Zudem verwendet NTFS eine anderes System für die Inode Nr. bezeichnung.
fls -r -o 1026048 usb_stick_image.E01 r/r 4-128-1: $AttrDef r/r 8-128-2: $BadClus r/r 8-128-1: $BadClus:$Bad r/r 6-128-1: $Bitmap r/r 7-128-1: $Boot d/d 11-144-2: $Extend + r/r 25-144-2: $ObjId:$O + r/r 24-144-3: $Quota:$O + r/r 24-144-2: $Quota:$Q + r/r 26-144-2: $Reparse:$R r/r 2-128-1: $LogFile r/r 0-128-1: $MFT r/r 1-128-1: $MFTMirr r/r 9-128-2: $Secure:$SDS r/r 9-144-3: $Secure:$SDH r/r 9-144-4: $Secure:$SII r/r 10-128-1: $UpCase r/r 10-128-2: $UpCase:$Info r/r 3-128-3: $Volume d/d 30-144-2: .Trash-1000 + d/d 35-144-2: expunged + d/d 32-144-2: files + d/d 31-144-2: info r/r 29-128-2: file_on_an_ntfs_volume.txt V/V 1152: $OrphanFiles + -/r * 16: OrphanFile-16 + -/r * 17: OrphanFile-17 + -/r * 18: OrphanFile-18 + -/r * 19: OrphanFile-19 + -/r * 20: OrphanFile-20 + -/r * 21: OrphanFile-21 + -/r * 22: OrphanFile-22 + -/r * 23: OrphanFile-23 + -/r * 27-128-2: OrphanFile-27 + -/r * 28-128-2: OrphanFile-28 + -/r * 33-128-2: OrphanFile-33 + -/r * 34-128-2: OrphanFile-34
Beispiel Ausgabe der nicht mehr Referenzierten Datei mit der Inode Nr. 27-128-2
icat -o 1026048 usb_stick_image.E01 27-128-2 Ich bin ursprünglich gelöscht worden.