Hallo Suletuxe,

Ich wollte für euch diesen Artikel schreiben, um aufzuklären, wie wichtig Verschlüsslung auch im privaten Umfeld sein kann. Auch gegen die allgemeine Meinung: „Man hat doch nichts zu verbergen!“ sollte jeder Mensch ein Anrecht auf Privatsphäre haben.

Um keine Grundsatzdiskussion zu starten, hier ein kurzes Beispiel, warum offline Verschlüsselung für seine eigenen Daten wichtig ist.

Beispiel:

Ihr habt wichtige Daten, die keiner Lesen soll (z.b. Login-Daten, Geschäftsdaten, etc.) auf ein externes Medium (z.b. einen USB-Stick) gespeichert ohne die Daten selbst oder das Medium selbst zu verschlüsseln. Jeder kann sich denken, was alles jetzt passieren kann, wenn dieser USB-Stick verloren oder gestohlen wird. Dasselbe gilt auch z.B. bei einem Verlust des Notebooks oder Smartphones.

Identitätsdiebstahl ist damit Tür und Tor geöffnet.

Deswegen heißt es lieber Vorsicht, als Nachsicht, indem man vorher eine Verschlüsselung einrichtet, bevor angefangen wird Daten auf dem Datenträger zu speichern.

Falls sich welche von euch jetzt Gedanken darüber machen, das dies beim versuch Daten wiederherzustellen eine Behinderung darstellt, ja das ist so, aber auch das ist kein Hexenwerk bei Datenwiederherstellung von verschlüsselten Datenträgern müssen im Vorfeld nur ein paar Schritte mehr getan werden, um erst die Verschlüsselung aufzuheben. Aber das sollte kein Grund sein, die Verschlüsselung komplett wegzulassen, das sollte nur als letzter Ausweg angesehen werden. Denn der beste Schutz gegen Datenverlust ist nicht der Versuch Daten wiederherzustellen, sondern Backups, Backups und noch mal Backups von seinen Daten. Hat man diese in der Hinterhand kann einem der Verlust von Daten wegen Defekt oder Versehen, ob verschlüsselt oder nicht so ziemlich egal sein.

Um das nachfolgende besser verstehen zu können, muss man wissen, was ein Dateisystem ist und wie dies funktionieren, nicht bis ins Detail, aber man sollte eine grobe Vorstellung haben.

Daten werden in einem Computer meistens in Form von Dateien auf einem Datenträger wie eine Festplatte abgespeichert. Aber was genau sind Daten und was ist eine Datei? Nun ja, Daten kann so ziemlich alles sein, Text, Ton, Bilder etc., das ist quasi der Inhalt einer Datei. Aber was ist die Datei denn jetzt eigentlich? Eine Datei ist quasi ein Container (In der Vorstellung: Ein Aufbewahrungsort für die Daten) dieser Container kann jetzt noch beschriftet werden (Das ist der Dateiname) und kann noch zig verschiedene Metadaten angehangen werden. Was sind denn jetzt schon wieder Metadaten? Metadaten sind zusätzliche Daten, die indirekt etwas mit dem eigentlichen Inhalt zutun haben und nur bei Bedarf gesichtet werden müssen. Im Falle unserer Datei, ist das z.b. der Dateiname, die Erstell-/Modifikation-/Änderungszeit.

Um die Verwaltung und Organisation auf einem Datenträger unserer Container (Dateien) wo diese genau gespeichert sind (weiter vorne, weiter hinten (bei HHDs) bzw. in Sektor 1 bzw. 379338 bei SSDs) darum kümmert sich nun ein sogenanntes Dateisystem. Ein Dateisystem kann man sich also quasi wie ein Inhaltsverzeichnis/Index vorstellen, indem sich unsere Dateien auf dem Datenträger befinden, mit ihren Metadaten und ihren Daten als Inhalt. Über die Jahrzehnte wurden für diesen Zweck zig verschiede Dateisysteme entwickelt. Jedes ist für einen anderen Einsatzzweck besser geeignet als das andere, darum soll es hierbei aber erst mal nicht gehen.

Jetzt, wo ihr eine grobe Ahnung habt was ein Dateisystem ist, so kann ich euch anhand eines Beispieles zeigen wie man Daten Forensik für einen Datenträger (hier im Beispiel ein USB-Stick) betreiben kann, um z.b. geglaubte gelöschte Dateien wiederherzustellen, von der man der Meinung war das, man diese gelöscht hat und deswegen es vielleicht auch nicht schlimm ist, wenn man den unverschlüsselten Datenträger verliert.

Um euch zu demonstrieren, wie Daten untersucht und auch wiederhergestellt werden können, werde ich die Tools aus dem The Sleuth Kit und das Expert Witness Compression Format (EWF) für die Imagedatei aus dem Projekt libewf verwenden.

Beide Projekte sind für Menschen, die Digital Forensik als Berufsfeld haben, entwickelt worden und verwenden deswegen bei Verwendung der Tools immer wieder mal Begriffe wie case (Fall), Evidence (Beweis) etc. fallen. Da diese Tools hauptsächlich dort in Einsatz kommen.

Zur Demonstrationszwecke habe ich einen kleinen USB-Stick (ca. 4 GiB) vorbereitet. Ich habe diesen im Vorfeld mit blkdiscard -fz mit nullen beschrieben, um optimale Bedingungen für den Wiederherstellungsversuch und dem Komprimierungsalgorithmus zu schaffen.

Dann habe ich eine neue Guided Partition Tabelle (GPT) angelegt, mit zwei unterschiedlich großen Partitionen. Die ich wiederum einmal mit dem exFat und dem NTFS Dateisystem formatiert habe. (Formatieren beschreibt den Vorgang, wenn ein neues Dateisystem auf einem Volumen angelegt wird.)

Auf diesem Dateisystem habe ich dann im jeweiligen Root Verzeichnis die entsprechenden Dateien neu angelegt:

file_on_an_exfat_volume.txt
file_on_an_ntfs_volume.txt
deleted_file.txt

mit folgendem Inhalt:

file_on_an_exfat_volume.txt:

Ich bin eine Datei auf einem extFAT Dateisystem

file_on_an_ntfs_volume.txt:

Ich bin eine Datei auf einem NTFS Dateisystem

deleted_file.txt:
Ich bin ursprünglich gelöscht worden.

Wobei ich die Datei delted_file.txt danach sofort wieder gelöscht habe. Und den USB-Stick danach nicht weiter verwendet habe.

Das Erste, das man tun sollte, falls man festgestellt hat, dass man Daten von seinem Datenträger versehentlich gelöscht hat. Ist die Daten auf dem Datenträger zu sichern und nicht mehr weiterzuverwenden, um die Wahrscheinlichkeit zu verringern, dass Daten auf dem Datenträger überschrieben werden. Denn das einfache Löschen einer Datei ist nichts anderes als dem Dateisystem zu sagen: „Die Datei brauche ich nicht mehr, die kannst du aus dem Index streichen“. Mit anderen Worten, es wurde nur der Eintrag im Index gelöscht, aber die Daten liegen immer noch in Rohform auf dem Datenträger vor, bis diese durch Zufall (wegen Platzmangel, Controller Aufräumarbeiten etc.) tatsächlich gelöscht werden.

Experten schließen solch einen Datenträger, um sicherzugehen, an einen sogenannten Write Blocker (Schreibblocker) an, um Schreibvorgänge gänzlich zu verhindern (damit eine Fehlkonfiguration seiner Forenisc Station nichts weiter kaputt machen könnte) für den Heimgebrauch geht das natürlich auch ohne.

Um die Daten jetzt von meinem vorbereitenden USB-Stick sicherzustellen. Verwende ich das Tool ewfacqurie aus der libewf Bibliothek. Das als Abhängigkeit bei einem Arch System bei der Installation von sleuthkit mit installiert wird. Dabei verwende ich das Expert Witness Compression Format (EWF), das noch einige Metadaten rund um das zu sichernde Medium und der Forensik Station (in unseren Fall unser PC) sichert. Welche zusätzlichen Daten das sind, könnt ihr weiter unten im Shell Output nachlesen:

Zuerst lege ich ein neues Verzeichnis für unseren Fall (case) an, wie gesagt, die Terminologie der Tools sind Berufsbezogen. Und wechsel in das Verzeichnis:

mkdir -p ~/tmp/case1
cd ~/tmp/case1

Als Nächstes starte ich das Programm mit Root Rechten, um Zugriff auf den USB-Stick zu bekommen. Die einzige Option, die ich verwende, ist die -l Option um eine Logdatei für Fehler und der MD5 Prüfsummen Ausgabe anzugeben. Alle weiteren Optionen lasse ich weg und lasse mich stattdessen von dem Programm abfragen, was noch fehlt.

~/tmp/case1
❯ 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 habe ich etwas gekürzt. Man sieht hier das das Sicherstellen der Daten von dem Datenträger 3 Min Gedauert hat, und die MD5 Prüfsumme über die Daten hinweg d6742b4b02073025bcdf0a6dceff4bb3 ist. Diese bfindet sich nun auch noch mal in der Datei:

~/tmp/case1
❯ cat image.log
MD5 hash calculated over data:      d6742b4b02073025bcdf0a6dceff4bb3

Es befinden sich derweil jetzt folgende Dateien in dem Arbeitsverzeichnis:

~/tmp/case1
❯ 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

Wie man gut erkennen kann, ist das Image, meines 4 GiB großen USB-Sticks. Auf grade mal 7,5 MiB Komprimiert worden. Das ist der guten vorarbeit dem Beschreiben mit nullen des Datenträgers geschuldet. Hier konnte der größte Teil des Datenträgers die Sektoren mit dem nullen sehr gut Komprimiert werden. Dies ist in der Wirklichkeit natürlich ein sehr unrealistisches Scenario.

Damit ich jetzt ohne Root Rechte weiterarbeiten kann, ändere ich noch den Besitzer der des Images auf meinen Benutzer. Und sicherheitshalber gebe ich der Datei nur Leserechte, da ich von dieser Datei nur lesen möchte.

sudo chown sebastian: usb_stick_image.E01
chmod 400 usb_stick_image.E01

Jetzt wo wir eine Datensicherung in Form eines Images haben, können wir uns mit mmls die Innere Struktur dieses Images anzeigen lassen. Dabei unterstützt mmls folgende Formate:

~/tmp/case1
❯ mmls -i list
Supported image format types:
   raw (Single or split raw file (dd))
   ewf (Expert Witness Format (EnCase))

Wenden wir jetzt mmls auf unser Image an bekommen wir folgende Ausgabe:

~/tmp/case1
❯ 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

Wir können hier sehr schön sehen, das sich in diesem Image eine GUID Partition Table (GPT) mit der Position (offset) seiner eigenen Metadaten + 2 Partitionen und noch nicht zugewiesener Raum sich zwischen der Safety Table und dem GPT Header bzw. noch einmal ganz am ende des Datenträgers befindet.

Wir haben also zumindest jetzt eine Ahnung wo sich interessante Daten befinden können. Einmal an Position (offset) 2048, und einmal an Position 1026048 die Partitionen die Beide als Beschreibung Microsoft basic data in der Partitionstabelle eingetragen habe. Wir wissen bis jetzt nur noch nicht was wir da genau vorfinden können. Das untersuchen wir jetzt mit einem weiteren Tool aus der sleuthkit Sammlung.

Mithilfe des offsets, also der Position im Image sich das Vermutete Dateisystem aufhält, können wir uns mit fsstat uns nun weitere Informationen darüber ausgeben lassen. Dabei schaue ich mir als erstes das Dateisystem das ich unter dem offset 2048 befindet einmal genauer an:

~/tmp/case1
❯ 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

Hier bekommen wir jetzt einige wichtige Informationen über das Dateisystem. Zum einem das es sich um ein exFAT Dateisystem handelt, wie groß es ist, bzw. wie weit es sich von Sektor zu Sektor ersteckt und viele weitere Informationen die den Kontext zu meinen Beitrag jetzt sprengen würden. Wir halten hier für uns nur fest wir haben hier ein exFAT Dateisystem.

Das gleiche mache ich jetzt noch mit der anderen Partition:

~/tmp/case1
❯ 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 das selbe Spiel, nur noch mit noch mehr Informationen spezifisch für das NTFS Dateisystem. Um die ganze Ausgabe davon wie auch die vorherige verstehen zu können. Sollte man sich speziell der Dokumentation des jeweiligen Dateisystems widmen. Wir halten hier nur fest wir haben ein hier ein NTFS Dateisystem

Als nächstens wollen wir mal in eins der Dateisysteme hineinschauen und gucken was wir da so finden können.

Jetzt kommen wir zum spanenden Teil, welche Dateien befinden sich den nun in unserem Dateisystem das sich in unsrem Image befindet. Wir können mit einem weiteren Tool aus unsere Toolbox das den Namen fls trägt dort mal ins Dateisystem reinspiken.

~/tmp/case1
❯ 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

Wir bekommen eine Ausgabe die in mehren Spalten unterteilt ist. Die erste Spalte, zeigt an um was es sich handelt eine Datei (r, Regular file), ein Verzeichnis (d, Directory) eine Virtuelle TSK Datei (v, TSK Virtual file) etc. Dabei gibt es noch mehre Typen diese Typen entnimmt bitte aus dem TSK Wiki

Es folgt eine Spalte wo 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, Das ist Qusi Die Index Nr. von unsrem Dateisystem worüber die Daten Referenziert werden. Bitte macht euch anderweitig schlau was eine Inode ist das würde hier den Rahmen sprengen. Jedenfalls können wir mithilfe dieser Nr. an unsere Verloren Daten kommen.

In der Letzten Spalte folgt dann noch der Dateiname bzw. Verzeichnisname.

Zum Auffinden von nicht mehr Referenzierten Dateien können wir es uns auch noch ein wenig einfacher machen. Denn man arbeit ja schliss lich nicht immer mit so einem leeren Datenträger

~/tmp/case1
❯ fls -d -o 2048 usb_stick_image.E01
r/r * 2063:   deleted_file.txt

Die -d Option hat die Ausgabe jetzt nur noch auf nicht mehr Referenzierte Dateien beschränkt.

Als nächstens geht es jetzt daran Daten aus unserem Image zu extrahieren.

wie das normale cat, gibt icat Eingabe Daten an die Standardausgabe weiter. Nur mit dem unterschied das icat für das Arbeiten mit Image Dateien entworfen wurde und als Referenz (bzw. Zeiger) Inode Nr. entgegennimmt. Wir lassen uns also jetzt als erstes mal den Inhalt der Datei file_on_an_exfat_volume.txt mit der Inode Nr. 2059 Ausgeben:

~/tmp/case1
❯ icat -o 2048 usb_stick_image.E01 2059
Ich bin eine Datei auf einem extFAT Dateisystem

Wie wir sehen hat das schon mal geklappt. Hätten wir die Ausgabe jetzt in eine Datei umgeleitet so hätten wir den Inhalt aus der Datei im Image erfolgreich Extrahiert.

<WARP important> Dies ist nicht zu verwechseln mit einer vollständigen Extraktion. Hier haben wir nur den Dateiinhalt extrahiert nicht aber die Metadaten. Dies spielt bei der Beweis Führung eine wichtige Rolle.

Für uns Otto Normalverbraucher ist es aber das was die meisten nur Wollen </WARP>

Der weilen gibt es auch noch andere Möglichkeiten und Tools um gleich viele Dateien und Verzeichnisse auf einen Schlag zu extraieren. Ich wollte hier nur Grundsätzlich einmal aufzeigen das wenn keine Verschlüsselung eingesetzt wird, wie einfach es an selbst geglaubte gelöschte Daten wieder ran zukommen. Jeder sollte für sich also das Risiko von Datenmissbrauch selbst Abwegen.

Das ganze zum Schluss jetzt noch mal für die vermeintliche gelöschte Datei:

~/tmp/case1
❯ icat -o 2048 usb_stick_image.E01 2063
Ich bin ursprünglich gelöscht worden.

Auch das hat geklappt. Tja hoffentlich hat noch niemand einfach so mal Datenträger auf einer Verkaufsplattform verkauft. Und gemeint ein Leeren des Papierkorbs bzw. schnell formatieren des Datenträgers würde reichen

Es sei noch zu erwähnen das beim ex­a­mi­nie­ren von Daten gravierende Unterschiede bei den Dateisystemen gibt. Diese verwaltet die Daten ganz anders als andere und manche sind auch mehr auf Sicherheit bedacht als wiederum andere

Um jetzt noch kurz zu zeigen das sich Dateisystem unterschiedlich verhalten hier die Ausgabe unseres NTFS Dateisystems:

~/tmp/case1
❯ 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

Nanu? Wo ist dann hier unsere gelöschte Datei hin? Wir sehen hier gar kein * und auch die iNode Nr. sehen anders aus. Das ist eine eigenart des Dateisystem NTFS Dies verwendet ein anderes System bei den Inodes. Wenn ihr mehr wissen wollt dann ist die Suchmaschine eueres Vertrauens jetzt euer bester Freund

um hier die nicht mehr Referenzierte Datei Ausfindig zu machen, müssen wir uns den Inhalt Verzeichnisse noch Anschauen:

~/tmp/case1
❯ 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

Wir sehen in dem TSK Virtual file ($OrphanFiles) mehrer Verweisete Inodes. Dann wollen wir uns die erste doch mal anschauen:

~/tmp/case1
❯ icat -o 1026048 usb_stick_image.E01 27-128-2
Ich bin ursprünglich gelöscht worden.

Oh das war dann woll auf anhieb ein Glückstreffer. Es gibt natürlich noch andere wege das Dateisystem nach Daten zu durchsuchen als dies Händisch zu machen. Wofür haben wir ja schließlich unsere Computer. Mir ging ursprünglich nur aufzuzeigen wie mehr oder weniger einfach es ist unverschlüsselte Daten zu extraieren und das man mit den eigenarten der unterschiedlichen Dateisysteme sich vertraut machen sollte. Um so mehr Erfahrung dazu kommt desdo schneller und feiner findet man sich auch in bei großen Datenmengen zurecht. Besonders wenn wir das nicht mehr Händisch sondern Automatisiert machen.