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 ex­a­mi­nie­ren 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.

Siehe auch