Suletuxe Linux Wiki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== 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 [[ap>libewf]] Paket bei einem [[https://archlinux.org|Arch Linux]] als Abhängigkeit mit installiert wird.
Als Alternative zu ''libewf'' sei [[aur>afflib]]<sup>**AUR**</sup> 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.

<code bash>
sudo blkdiscard -fz /dev/sdc
</code>

Als nächtes legen wir auf dem USB-Stick eine neue [[wpde>GUID_Partition_Table|GPT]] mit zwei unterschiedlich großen [[wpde>Partition_(Datenträger)|Partitionen]] an.
Die wir mit dem [[wpde>File_Allocation_Table#exFAT|exFat]] und dem [[wpde>NTFS]] [[wpde>Dateisystem]] [[wpde>Formatierung#High-Level-Formatierung|formatieren]].

<WRAP todo>
Beispiel für das Anlegen einer Partitionstabelle und das Formatieren der Dateisysteme einfügen.
</WRAP>

Nachdem das getan ist, erstellen wir auf beiden Dateisysteme diese Dateien mit folgedem Inhalt:

<code bash>
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
</code>

Und löschen sofort wieder die Datei ''delted_file.txt'' vom USB-Stick, und unmounten alle Dateisysteme wieder.

<code bash>
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}
</code>

===== Daten Sichern =====

<WRAP important>
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.
</WRAP>

<WRAP info>
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.
</WRAP>

==== ewfacquire (Daten Sicherstellen) ====

<WRAP todo>
  * Es sollte für ewfacquire eine eigene Wikiseite verwendet werden.
</WRAP>

Um Daten vom USB-Stick sicherzustellen. Verwende wir das Tool ''ewfacqurie'' aus der [[https://github.com/libyal/libewf/|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:

<code bash>
mkdir -p ~/tmp/case1
cd ~/tmp/case1
</code>

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.

<code bash>
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
</code>

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:

<code bash>
cat image.log

MD5 hash calculated over data:      d6742b4b02073025bcdf0a6dceff4bb3
</code>

im Arbeitsverzeichnis befinden sich zu disem Zeitpunkt nun folgende Dateien:

<code bash>
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
</code>

<WRAP info>
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.**
</WRAP>

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.

<code bash>
sudo chown sebastian: usb_stick_image.E01
chmod 400 usb_stick_image.E01
</code>

===== Daten Untersuchen/Analysieren =====

==== mmls (Image Struktur Analysieren) ====

<WRAP todo>
  * mmls sollte eine eigene Wikiseite bekommen
</WRAP>

Um die Innere Struktur des Images anzuzeigen, kann ''mmls'' verwendet werden:

<code bash>
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
</code>

Man erkennt, eine GPT mit 2 Partitionen und noch nicht zugewiesener Raum zwischen der Safety Table und dem [[wpde>GUID_Partition_Table#Header_der_GUID-Partitionstabelle|GPT Header]] bzw. noch einmal ganz am ende des Datenträgers.

<WRAP important>
**Auf nicht Adressierte Berreiche, können sich auch Daten befinden!**
Dieser Raum wurde legetlich zurzeit der Image Erstellung nicht Adressiert.
</WRAP>

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) ====

<WRAP todo>
  * fsstat sollte eine eigene Wikiseite bekommen.
</WRAP>

Um in Erfahrung zu bringen welches Dateisystem sich an den [[wpde>Speicheradresse#Segmentierte_Adressen|offsets]] befindet,
setzten wir das ''fsstat'' Tool folgendermassen ein:

<code bash [highlight_lines_extra="5,15,36,37,38"]>
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
</code>

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:

<code bash [highlight_lines_extra="5,22,23,24,25"]>
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
</code>

Hier änliche Informationen spezifisch für das **NTFS Dateisystem**.

<WRAP help>
Um die Ausgaben verstehen zu können, sollte man sich der Dokumentation des jeweiligen Dateisystems widmen.
</WRAP>

==== fls (Dateien und Verzeichnis von einem Dateisystem in einem Image auflisten) ====

<WRAP todo>
  * fls sollte eine eigene Wikiseite bekommen.
</WRAP>

Um nun in das Dateisystem hineinzuschauen, verweden wir das Tool ''fls'':

<code bash>
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
</code>

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 [[https://wiki.sleuthkit.org/index.php?title=Fls#File_Type|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 [[wpde>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:

<code bash>
fls -d -o 2048 usb_stick_image.E01

r/r * 2063:   deleted_file.txt
</code>

===== Daten Extrahieren =====

==== icat (Inhaltsausgabe anhand der Inode) ====

<WRAP todo>
  * icat sollte eine eigene Wikiseite bekommen.
</WRAP>

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**:

<code bash>
icat -o 2048 usb_stick_image.E01 2059

Ich bin eine Datei auf einem extFAT Dateisystem
</code>

Um den Inhalt zu Extrahieren kann die Ausgabe einfach umgeleitet werden. Siehe dazu [[aw>Command-line_shell#Input_and_output]]

<WRAP important>
**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!
</WRAP>

Um mehrere Dateien und Verzeichnisse zu Extraieren gibt es andere Möglichkeiten.

Dies funktioniert auch bei nicht mehr Referenzierten Dateien:

<code bash>
icat -o 2048 usb_stick_image.E01 2063

Ich bin ursprünglich gelöscht worden.
</code>

==== 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:

<code bash>
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
</code>

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.

<code bash [highlight_lines_extra="27,28,29,30,31,32,33,34,35,36,37,38,39"]>
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
</code>

Beispiel Ausgabe der nicht mehr Referenzierten Datei mit der Inode Nr. ''27-128-2''

<code bash>
icat -o 1026048 usb_stick_image.E01 27-128-2

Ich bin ursprünglich gelöscht worden.
</code>

===== Siehe auch =====

  * [[sleuthkit]]
  * [[https://www.sleuthkit.org/|Projekt Homepage]]
  * [[https://wiki.sleuthkit.org/|TSK Wiki]]
  * [[https://github.com/libyal/libewf|libewf auf Github]]
  * [[https://github.com/sshock/AFFLIBv3|afflib auf Github]]
  * [[https://www.suletuxe.de/forum/index.php?board=18;action=display;threadid=879|Suletuxe Forum Diskussionsthread]]