Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- tools:dateisystem:sleuthkit:disk_images_untersuchen_mit_tsk [2024/05/11 14:42] – angelegt gahsul
+++ tools:dateisystem:sleuthkit:disk_images_untersuchen_mit_tsk [2024/05/20 09:13] (aktuell) – Kleinere Korrekturen gahsul
@@ Zeile 1: / Zeile 1: @@
-<WRAP todo>
-Dies ist eine Übertragung aus dem [[https://www.suletuxe.de/forum/index.php?board=18;action=display;threadid=879|Suletuxe Forum Thread]] und benötigt, für das Wiki eine Überarbeitung. Stellen sind entsprechend markiert.
-</WRAP>
 ====== Disk Images untersuchen mit TSK ======
-<WRAP todo>
+In diesen Tutorial wird TSK und das EWF (Expert Witness Compression Format) für die Image Erstellung verwendet,
-  * Der Hinweis und Aufklärung zu Datenträger Verschlüsselung sollte eine eigne Wikiseite bekommen.
+da das [[ap>libewf]] Paket bei einem [[https://archlinux.org|Arch Linux]] als Abhängigkeit mit installiert wird.
-  * Fehlende Sprache. Fürs Wiki sollte der Text sachlich und ohne persönliche Rede verwendet werden.
+Als Alternative zu ''libewf'' sei [[aur>afflib]]<sup>**AUR**</sup> zubennen.
-</WRAP>
-===== Warum Datenträger Verschlüsselung wichtig ist =====
+Es werden Begriffe wie case (Fall), Evidence (Beweis) etc. fallen. Da diese Tools hauptsächlich in der Digital Forensik zum Einsatz kommen.
-Hallo Suletuxe,
+===== Vorbereitungen =====
-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.
+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.
-Um keine Grundsatzdiskussion zu starten, hier ein kurzes Beispiel, warum offline Verschlüsselung für seine eigenen Daten wichtig ist.
+<code bash>
+sudo blkdiscard -fz /dev/sdc
+</code>
-Beispiel:
+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]].
-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.
 <WRAP todo>
-  * Der Hinweis und Aufklärung zu Dateisysteme sollte eine eigne Wikiseite bekommen.
+Beispiel für das Anlegen einer Partitionstabelle und das Formatieren der Dateisysteme einfügen.
-  * Fehlende Sprache. Fürs Wiki sollte der Text sachlich und ohne persönliche Rede verwendet werden.
 </WRAP>
-===== Was ist ein Dateisystem? =====
-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.
+Nachdem das getan ist, erstellen wir auf beiden Dateisysteme diese Dateien mit folgedem Inhalt:
-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.
+<code bash>
+exFAT_filesystem ="/mnt/usb-stick_exfat"
+NTFS_filesystem ="/mnt/usb-stick_ntfs"
-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.
+sudo mkdir -p ${exFAT_filesystem} ${NTFS_filesystem}
+sudo mount /dev/sdc1 ${exFAT_filesystem}
+sudo mount /dev/sdc2 ${NTFS_filesystem}
-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.
+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
-<WRAP todo>
+echo "Ich bin ursprünglich gelöscht worden." >${NTFS_filesystem}/deleted_file.txt
-  * Fehlende Sprache. Fürs Wiki sollte der Text sachlich und ohne persönliche Rede verwendet werden.
-</WRAP>
-===== Daten Forensik mit dem sleuthkit =====
-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 [[https://github.com/libyal/libewf/|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.
-==== Vorbereitungen ====
-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:
-<code>
-file_on_an_exfat_volume.txt
-file_on_an_ntfs_volume.txt
-deleted_file.txt
 </code>
-mit folgendem Inhalt:
+Und löschen sofort wieder die Datei ''delted_file.txt'' vom USB-Stick, und unmounten alle Dateisysteme wieder.
-<code>
+<code bash>
-file_on_an_exfat_volume.txt:
+rm -i ${exFAT_filesystem}/file_on_an_exfat_volume.txt
+rm -i ${NTFS_filesystem}/file_on_an_ntfs_volume.txt
-Ich bin eine Datei auf einem extFAT Dateisystem
+sudo umount ${exFAT_filesystem} ${NTFS_filesystem}
-file_on_an_ntfs_volume.txt:
-Ich bin eine Datei auf einem NTFS Dateisystem
-deleted_file.txt:
-Ich bin ursprünglich gelöscht worden.
 </code>
-Wobei ich die Datei ''delted_file.txt'' danach sofort wieder gelöscht habe. Und den USB-Stick danach nicht weiter verwendet habe.
+===== Daten Sichern =====
-==== Daten Sichern ====
+<WRAP important>
+Das Erste, das man tun sollte, falls Daten von einem Datenträger versehentlich gelöscht wurden,
-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.
+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>
-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.
 <WRAP info>
-Es geht im folgenden Beispiel darum, Daten von einem intakten Datenträger zu sichern, der keine Hardware Fehlfunktion hat. Sollte die Hardware beschädigt sein, so müssen andere Tools wie dd_rescure herangezogen werden, um die Daten zu sichern.
+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.
-  * Fehlende Sprache. Fürs Wiki sollte der Text sachlich und ohne persönliche Rede verwendet werden.
 </WRAP>
-==== ewfacquire (Daten Sicherstellen) ====
+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:
-Um die Daten jetzt von meinem vorbereitenden USB-Stick sicherzustellen. Verwende ich das Tool ''ewfacqurie'' aus der [[https://github.com/libyal/libewf/|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:
+Wir legen für unseren Fall (**case**) ein neues Arbeitsverzeichnis an und wechsel in dieses:
-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:
 <code bash>
@@ Zeile 110: / Zeile 77: @@
 </code>
-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.
+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
-<code>
-~/tmp/case1
-❯ sudo ewfacquire -l image.log /dev/sdc
 ewfacquire 20140608
@@ Zeile 193: / Zeile 162: @@
 </code>
-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:
+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
-<code>
-~/tmp/case1
-❯ cat image.log
 MD5 hash calculated over data:      d6742b4b02073025bcdf0a6dceff4bb3
 </code>
-Es befinden sich derweil jetzt folgende Dateien in dem Arbeitsverzeichnis:
+im Arbeitsverzeichnis befinden sich zu disem Zeitpunkt nun folgende Dateien:
-<code>
+<code bash>
-~/tmp/case1
+ls -lh
-❯ ls -lh
 insgesamt 7,5M
 -rw-r--r-- 1 root      root        65    4. Mai 11:14 image.log
@@ Zeile 211: / Zeile 182: @@
 </code>
-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.
+<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 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.
+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>
+<code bash>
 sudo chown sebastian: usb_stick_image.E01
 chmod 400 usb_stick_image.E01
 </code>
-==== Daten Untersuchen/Analysieren ====
+===== Daten Untersuchen/Analysieren =====
+==== mmls (Image Struktur Analysieren) ====
 <WRAP todo>
   * mmls sollte eine eigene Wikiseite bekommen
-  * Fehlende Sprache
 </WRAP>
-=== mmls (Image Struktur Analysieren) ===
+Um die Innere Struktur des Images anzuzeigen, kann ''mmls'' verwendet werden:
-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:
-<code>
+<code bash>
-~/tmp/case1
+mmls usb_stick_image.E01
-❯ mmls -i list
-Supported image format types:
-   raw (Single or split raw file (dd))
-   ewf (Expert Witness Format (EnCase))
-</code>
-Wenden wir jetzt mmls auf unser Image an bekommen wir folgende Ausgabe:
-<code>
-~/tmp/case1
-❯ mmls usb_stick_image.E01
 GUID Partition Table (EFI)
 Offset Sector: 0
@@ Zeile 257: / Zeile 225: @@
 </code>
-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.
+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>
-Nicht Adressierte Berreiche auf einem Datenträger, muss nicht heisen das sich dort keine Daten mehr befinden, dieser Raum wurde nur zurzeit der Image Erstellung nicht Adressiert. Was nicht bedeutet das nicht früher mal dort Daten abgelegt wurden.
+**Auf nicht Adressierte Berreiche, können sich auch Daten befinden!**
+Dieser Raum wurde legetlich zurzeit der Image Erstellung nicht Adressiert.
 </WRAP>
-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.
+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.
-  * Fehlende Sprache
 </WRAP>
+Um in Erfahrung zu bringen welches Dateisystem sich an den [[wpde>Speicheradresse#Segmentierte_Adressen|offsets]] befindet,
+setzten wir das ''fsstat'' Tool folgendermassen ein:
-=== fsstat (Dateisystem Information anzeigen) ===
+<code bash [highlight_lines_extra="5,15,36,37,38"]>
+fsstat -o 2048 usb_stick_image.E01
-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:
-<code>
-~/tmp/case1
-❯ fsstat -o 2048 usb_stick_image.E01
 FILE SYSTEM INFORMATION
 --------------------------------------------
@@ Zeile 316: / Zeile 285: @@
 </code>
-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.
+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 mache ich jetzt noch mit der anderen Partition:
+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
-<code>
-~/tmp/case1
-❯ fsstat -o 1026048 usb_stick_image.E01
 FILE SYSTEM INFORMATION
 --------------------------------------------
@@ Zeile 365: / Zeile 335: @@
 </code>
-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
+Hier änliche Informationen spezifisch für das **NTFS Dateisystem**.
-Als nächstens wollen wir mal in eins der Dateisysteme hineinschauen und gucken was wir da so finden können.
+<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>
-  * fsstat sollte eine eigene Wikiseite bekommen.
+  * fls sollte eine eigene Wikiseite bekommen.
-  * Fehlende Sprache
 </WRAP>
-=== fls (Dateien und Verzeichnis von einem Dateisystem in einem Image auflisten) ==
+Um nun in das Dateisystem hineinzuschauen, verweden wir das Tool ''fls'':
-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.
+<code bash>
+fls -o 2048 usb_stick_image.E01
-<code>
-~/tmp/case1
-❯ fls -o 2048 usb_stick_image.E01
 r/r 2051:   FS_EXFAT (Volume Label Entry)
 r/r 2052:   $VOLUME_GUID
@@ Zeile 393: / Zeile 364: @@
 </code>
-Wir bekommen eine Ausgabe die in mehren Spalten unterteilt ist.
+Die Ausgabe ist in mehren Spalten unterteilt.
-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 [[https://wiki.sleuthkit.org/index.php?title=Fls#File_Type|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.
+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 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.
+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.**
-In der Letzten Spalte folgt dann noch der Dateiname bzw. Verzeichnisname.
+Es folgt die Spalte mit der [[wpde>Inode]] Nummer für die jweilige Datei.
-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 ;-)
+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
-<code>
-~/tmp/case1
-❯ fls -d -o 2048 usb_stick_image.E01
 r/r * 2063:   deleted_file.txt
 </code>
-Die ''-d'' Option hat die Ausgabe jetzt nur noch auf nicht mehr Referenzierte Dateien beschränkt.
+===== Daten Extrahieren =====
-Als nächstens geht es jetzt daran Daten aus unserem Image zu extrahieren.
+==== icat (Inhaltsausgabe anhand der Inode) ====
-=== Daten Extrahieren ===
 <WRAP todo>
   * icat sollte eine eigene Wikiseite bekommen.
-  * Fehlende Sprache
 </WRAP>
-== icat (Inhaltsausgabe anhand der Inode) ==
+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.
-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:
+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
-<code>
-~/tmp/case1
-❯ icat -o 2048 usb_stick_image.E01 2059
 Ich bin eine Datei auf einem extFAT Dateisystem
 </code>
-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.
+Um den Inhalt zu Extrahieren kann die Ausgabe einfach umgeleitet werden. Siehe dazu [[aw>Command-line_shell#Input_and_output]]
-<WARP important>
+<WRAP 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.
+**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>
-Für uns Otto Normalverbraucher ist es aber das was die meisten nur Wollen ;-)
+Um mehrere Dateien und Verzeichnisse zu Extraieren gibt es andere Möglichkeiten.
-</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.
+Dies funktioniert auch bei nicht mehr Referenzierten Dateien:
-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:
+<code bash>
+icat -o 2048 usb_stick_image.E01 2063
-<code>
-~/tmp/case1
-❯ icat -o 2048 usb_stick_image.E01 2063
 Ich bin ursprünglich gelöscht worden.
 </code>
-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 ;-)
+==== Dateisystem machen den Unterschied ====
-=== Dateisystem machen den Unterschied ===
+Beim examinieren von Daten, haben Dateisysteme gravierende Unterschiede.
+Manche sind mehr auf Sicherheit bedacht als andere.
-Es sei noch zu erwähnen das beim examinieren 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 den Unterscheid zu Demonstrieren hier die Fehlende Ausgabe des NTFS Dateisystems:
-Um jetzt noch kurz zu zeigen das sich Dateisystem unterschiedlich verhalten hier die Ausgabe unseres NTFS Dateisystems:
+<code bash>
+fls -o 1026048 usb_stick_image.E01
-<code>
-~/tmp/case1
-❯ fls -o 1026048 usb_stick_image.E01
 r/r 4-128-1:   $AttrDef
 r/r 8-128-2:   $BadClus
@@ Zeile 481: / Zeile 451: @@
 </code>
-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 ;-)
+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.
-um hier die nicht mehr Referenzierte Datei Ausfindig zu machen, müssen wir uns den Inhalt Verzeichnisse noch Anschauen:
+<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
-<code>
-~/tmp/case1
-❯ fls -r -o 1026048 usb_stick_image.E01
 r/r 4-128-1:   $AttrDef
 r/r 8-128-2:   $BadClus
@@ Zeile 527: / Zeile 496: @@
 </code>
-Wir sehen in dem TSK Virtual file **($OrphanFiles)** mehrer Verweisete Inodes. Dann wollen wir uns die erste doch mal anschauen:
+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
-<code>
-~/tmp/case1
-❯ icat -o 1026048 usb_stick_image.E01 27-128-2
 Ich bin ursprünglich gelöscht worden.
 </code>
-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.
+===== 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]]