Hochschule Wismar University of Applied Sciences Technology, Business and Design Fakultät für Ingenieurwissenschaften, Bereich EuI

Bachelor-Thesis

Vergleichende Analyse der Leistungsfähigkeit der Open-Source Software „The Sleuth Kit“ und deren Forks bei der physischen Auswertung der poolbasierten Dateisysteme APFS, ZFS, Btrfs und ReFS

Eingereicht am: 24. September 2020

von: Peter Titus

Betreuer: Prof. Dr. Antje Raab-Düsterhöft Zweitbetreuer: Dipl. Ing. Hans-Peter Merkel Aufgabenstellung

0.1 Aufgabenstellung

Vergleichende Analyse der Leistungsfähigkeit der Open-Source Software „The Sleuth Kit“ und deren Forks bei der physischen Auswertung der poolbasierten Dateisysteme APFS, ZFS, Btrfs und ReFS

Comparative Analysis of the Performance of Open-Source Software „The Sleuth Kit“ and Its Forks at Physical Evaluation of the Pool-based File Systems APFS, ZFS, Btrfs und ReFS

Ziel dieser Bachelor Thesis ist es, eine möglichst qualifizierte Aussage zum aktuellen Stand der Leistungsfähigkeit von Open Source Tools bei der Auswertung der benan- nten poolbasierten Dateisysteme zu erhalten um deren Einsatzmöglichkeiten in der Praxis genauer zu definieren.

Dazu soll, basierend auf rechtlichen Anforderungen und Anforderungen aus der forensischen Praxis, ein Katalog von aussagefähigen Tests erstellt werden. Diese sind dann sowohl auf die Auswertung klassischer Dateisysteme wie z.B. NTFS, als auch auf die Auswertung der poolbasierten Dateisysteme APFS, ZFS, Btrfs und ReFS anzuwenden. Dieser Prozess soll soweit als möglich automatisiert durchge- führt werden. Dazu sollen ausschließlich Open Soure Tools verwendet werden um eine maximale Transparenz der Vorgehensweise sicherzustellen.

Aus den Testergebnissen sollen sowohl die Aussagen zur aktuellen Leistungsfähigkeit, als auch offene Punkte zur Fehlerbehebung und relevante Themenfelder für zukün- ftige Entwicklungen abgeleitet werden.

2 0.2 Kurzreferat

Die Beweise in einem Strafverfahren müssen höchsten Ansprüchen genügen. Eine lückenlose Beweisbarkeit der erzielten Ergebnisse einer forensischen Untersuchung von Computersystemen kann mit proprietären „Closed Source“ Softwarelösungen jedoch prinzipbedingt nicht erreicht werden, da der Prozess der Auswertung selbst nicht anhand des Quellcodes nachvollzogen werden kann. Die Sammlung forensis- cher Tools „The Sleuth Kit“® bietet hier seit vielen Jahren eine Lösung im Bereich der Post-mortem Analyse von Dateisystemen. Sie ermöglicht eine solche Beweis- barkeit da der Quelltext frei verfügbar ist. Neben klassischen Dateisystemen wie z.B. NTFS haben neuartige Dateisysteme mittlerweile eine relevante Verbreitung erfahren[1]. Viele dieser Dateisysteme bieten Features die es erlauben, mehrere Par- titionen auf Dateisystemebene zu einem einzelnen Volume zusammenzufassen. Diese können verallgemeinernd als „poolbasierte“ Dateisysteme bezeichnet werden. „The Sleuth Kit“® wurde in verschiedenen Varianten weiterentwickelt, um auch derartige Dateisysteme analysieren zu können. Diese Arbeit soll konkrete Aussagen über die Leistungsfähigkeit dieser Software machen, welche es dem Praktiker in der IT Foren- sik ermöglichen, die Reife der Software für den praktischen Einsatz zu beurteilen.

0.3 Abstract

Evidence in criminal proceedings must meet the highest standard. Proprietary closed source software solutions cannot provide a complete chain of evidence for the results of forensic examinations on computer systems, since the process of the evaluation itself cannot be traced on the basis of the source code. The collection of forensic tools "The Sleuth Kit"® has been offering a solution in the field of post-mortem analysis of file systems for many years. It enables such provability as the source text is freely available. Besides traditional file systems like NTFS, new types of file systems have emerged and are widely used[1]. Many of these file systems offer features that allow multiple partitions to be combined into a single volume at the file system level. These can generally be referred to as pool based file systems. "The Sleuth Kit"® has been further developed in various versions in order to be able to analyze such file systems. This work should make concrete statements about the usability of this software, to enable the practitioner in IT forensics to assess the maturity of the software for practical use.

3 Inhaltsverzeichnis

Inhaltsverzeichnis

0.1 Aufgabenstellung...... 2 0.2 Kurzreferat...... 3 0.3 Abstract...... 3

1 Einleitung6 1.1 Anforderungen an Beweise im Strafverfahren...... 6 1.2 Dateisysteme...... 6 1.3 Auswertung von Dateisystemen...... 10 1.4 Das Prinzip „Ground Truth“...... 12 1.5 Auswertung poolbasierter Dateisysteme...... 13 1.6 Einführung zu den untersuchten Dateisystemen...... 15 1.6.1 Traditionelle Dateisysteme...... 15 1.6.2 Poolbasierte Dateisysteme...... 16

2 Anforderungen an die Ergebnisse der Auswertung von Dateisystemen 20 2.1 Rechtliche Anforderungen...... 20 2.2 Anforderungen aus der forensischen Praxis...... 21 2.2.1 Vollständigkeit...... 21 2.2.2 Nachvollziehbarkeit...... 21 2.2.3 Wiederholbarkeit...... 22 2.3 Abstraktion und Formalisierung...... 22

3 Entwicklung einer automatisierten Testumgebung 24 3.1 Vorüberlegungen...... 24 3.2 Konzeption...... 26 3.3 Verwendete Werkzeuge...... 27 3.4 Aufbau der Provisionierungsumgebung...... 28 3.5 Bereitstellung der Generatormaschinen...... 30 3.6 Bereitstellung der Analysemaschinen...... 31 3.7 Steuerung des Testablaufs...... 32 3.8 Generierung von Dateisystemobjekten...... 33 3.9 Forensische Analyse des erzeugten Datenträgers...... 37 3.10 Abgleich der Artefakte mit den erstellten Objekten...... 39

4 Durchführung der Tests und Bewertung der Ergebnisse 43 4.1 Fourth Extended File System (Ext4)...... 43 4.2 New Technology File System (NTFS)...... 45 4.3 Zettabyte File System (ZFS)...... 47 4.4 B-Tree File System (Btrfs)...... 49 4.5 Resilient File System (ReFS)...... 54

4 Inhaltsverzeichnis

4.6 Apple File System (APFS)...... 57

5 Fazit 62

Literaturverzeichnis 64

Abbildungsverzeichnis 69

Listings 71

Tabellenverzeichnis 72

Selbstständigkeitserklärung 73

5 Kapitel 1. Einleitung

1 Einleitung

1.1 Anforderungen an Beweise im Strafverfahren

Im deutschen Rechtssystem haben die Polizei und die Staatsanwaltschaft nach dem in § 161 StPO ausgeführten Legalitätsprinzip die Pflicht, selbständig Straftaten zu verfolgen und entsprechende Ermittlungen anzustellen. Bei hinreichendem Tatver- dacht erhebt die Staatsanwaltschaft Anklage vor dem zuständigen Gericht. Das Gericht entscheidet nach § 199 StPO, ob die vorgelegten Beweise ausreichend sind, um das sogenannte Haupt- oder auch Erkenntnisverfahren zu eröffnen.

Das Ziel ist dabei kein Geringeres, als die Wahrheit zu erkennen, um so objektiv wie möglich beurteilen zu können, ob ein Straftatbestand erfüllt wurde. Oft hängt sowohl das persönliche als auch das finanzielle Schicksal vieler Menschen am Aus- gang eines Strafverfahrens und der Korrektheit des gesprochenen Urteils. Die Justiz kann ihrer wichtigsten Aufgabe, der Wahrung des Rechtsfriedens durch die Wieder- herstellung des beeinträchtigen Rechts,[2, S. 3] nur dann gerecht werden, wenn sie die vorgelegten be- und entlastenden Beweise so objektiv als möglich betrachtet, da sie sich ansonsten dem Vorwurf der Parteilichkeit aussetzen würde.

Der Beweis an sich muss geeignet sein, einen beliebigen Betrachter zuverlässig und wiederholbar von dem zu beweisenden Sachverhalt zu überzeugen.[3, S. 56] Das Gericht hat seine Überzeugung aus lückenlos nachvollziehbaren Argumenten zu bilden,[3, S. 57]. Daraus ergibt sich die Forderung an die Strafverfolger, eine ebenso lückenlose Beweiskette aufzubauen welche an jeder Stelle der Überprüfung zugänglich ist.

1.2 Dateisysteme

Im Kontext von Computersystemen bieten Dateisysteme eine standardisierte Zu- griffsmöglichkeit auf Informationen in Form einer von einem zentralen Ordner oder Wurzelverzeichnis (root) ausgehenden baumartigen Struktur von Dateien und Ord- nern, wobei jeder Ordner weitere Unterordner und Dateien enthalten kann, Bild 1.1

6 Kapitel 1. Einleitung zeigt ein einfaches Beispiel. Die Ordner dienen dabei als strukturierende Elemente während die Dateien die eigentlichen Informationen enthalten.[4, S. 173]

Bild 1.1: Ordnungsschema eines Dateisystems

Der große Vorteil von Dateisystemen ist, dass diese Strukturen für Menschen einfach zu verstehen sind und Computer ebenfalls damit umgehen können. Dateisysteme wurden entwickelt, um die dauerhafte Speicherung von Informationen auf Daten- trägern wie Disketten oder Festplatten zu ermöglichen. Diese speichern Informatio- nen in serieller Form, also einer langen Folge von binären Werten (0 oder 1). In dieser Form sind die Informationen für Menschen jedoch sehr schwierig zu inter- pretieren, was in den 1960er Jahren die Entwicklung einer entsprechenden, für Men- schen einfach zu benutzenden Schnittstelle für die dauerhafte Speicherung größerer Datenmengen motivierte.[5]

Datenträger werden traditionell mit sogenannte Partitionen verwaltet die eine ein- deutige Zuordnung des verfügbaren Speichers gewährleisten. Klassische Dateisys- teme arbeiten innerhalb der Grenzen von Partitionen. Belegt ein Dateisystem den Inhalt einer Partition, spricht man auch von einem Volume. Abildung 1.2 zeigt dies am Beispiel einer Festplatte, die in mehrere Partitionen aufgeteilt ist, welche wiederum mit Dateisystemen formatiert sind. In Windows sind diese z.B. als Laufw- erksbuchstaben C:, D:, usw. verfügbar.

Praktisch jeder handelsübliche Computer, aber auch Smartphones und Internet of Things (IoT) Geräte nutzen Dateisysteme zur dauerhaften (persistenten) Spe- icherung von Informationen auf Datenträgern wie Festplatten oder Flash Speicher. Dabei werden sowohl das Betriebssystem des Computers selbst und alle Programme, als auch die zu verwaltenden Nutzdaten innerhalb von Dateisystemen abgelegt.

Dateisysteme sind dabei eng mit dem verwendeten Betriebssystem verknüpft. Das Betriebssystem wird beim Start des Computers vom Datenträger in den Arbeitsspe-

7 Kapitel 1. Einleitung

Bild 1.2: Unterteilung einer Festplatte in Partitionen und Volumes [4, S. 71] icher geladen. Das kann nur funktionieren wenn das Betriebssystem die Struktur der auf dem Datenträger abgelegten Informationen korrekt interpretiert. Da jedes Dateisystem seine eigenen Regeln für die Verwaltung der Daten enthält, kann ein Betriebssystem nur auf Daten zugreifen wenn es diese Regeln „kennt“, also über einen entsprechenden Treiber verfügt, der ihm diese Informationen verfügbar macht. Gängige Dateisysteme sind z.B. NTFS welches als standard Dateisystem für Com- puter mit Windows Betriebssystemen ausgeliefert wird, oder Third Extended File System (Ext3) bzw. Ext4 welche als Standard bei vielen Linux Distributionen ver- wendet werden.

Dateisysteme sind dabei jedoch nur eine von mehreren Abstraktionsebenen die zwis- chen dem Inhalt eines Datenträgers und einer als Beweis nutzbaren Information ste- hen. Nach Dewald und Freiling[6, S. 36] existieren folgende Abstraktionsschichten digitaler Spuren:

1. Die Magnetisierung eines Punktes auf einer Festplatte oder der Inhalt einer Speicherzelle als binärer Wert

2. Die Zusammenfassung der Bits zu Zeichen und der verwendete Zeichensatz

3. Das Dateisystem

4. Der Inhalt einer Datei

5. Die Interpretation des Dateiinhalts durch eine Anwendung, z.B. eine Textverarbeitung

Bei einer forensischen Untersuchung müssen diese Ebenen der Reihe nach durch- laufen werden um zu verwertbaren Ergebnissen zu gelangen. Die Analyse von Dateisys- temen ist somit ein Zwischenschritt bei der Suche nach Beweisen.

8 Kapitel 1. Einleitung

Die Einsatzmöglichkeiten von Dateisystemen sind nicht auf die Verwaltung von In- formationen auf Datenträgern beschränkt. So ermöglicht z.B. pcapFS[7] den Zugriff auf mitgeschnittene Netzwerkdaten in der Form eines Dateisystems. Dabei werden die unterschiedlichen Protokolle der Netzwerkpakete als Ordner dargestellt wie in Bild 1.3 dargestellt.

Bild 1.3: Netzwerkprotokolle als Ordnerstruktur[7]

Um ihre Aufgabe erfüllen zu können, legen Dateisysteme zusätzlich zu den eigentlichen Dateiinhalten Verwaltungsinformationen auf den Datenträgern ab. In seinem Buch „File System Forensic Analysis“, teilt Brian Carrier die in Dateisystemen abgelegten Informationen in fünf Kategorien ein:[4, S. 175]

• Dateisystemdaten Sie enthalten dateisystemspezifische Informationen zum Layout wie z.B. die verwendete Blockgröße oder eine eindeutige Identifikationsnummer des Dateisys- tems. Damit der Inhalt des Dateisystems gelesen werden kann müssen diese korrekt interpretiert werden, um die Position der weiteren Daten auf dem Da- tenträger bestimmen zu können.

• Inhaltsdaten Die innerhalb der Dateien abgelegten Informationen z.B. der Inhalt eines Word-Dokuments. Diese Daten werden in einer Folge von Blöcken standar- disierter Größe abgelegt. Um den Inhalt der Datei lesen zu können, muss das Dateisystem die Adressen der zu dieser Datei gehörenden Böcke kennen.

• Metadaten Verwaltungsinformationen für Dateien. Enthält die Adressen der Blöcke, die Größe der Datei, Zugriffsberechtigungen und mehrere Zeitstempel z.B. wann zuletzt in die Datei geschrieben wurde.

9 Kapitel 1. Einleitung

• Dateinamen Zuordnung eines für Menschen verständlichen Dateinamens zu den entsprechen- den Metadaten. Diese werden in der beschriebenen hierarchischen Ordner- struktur abgebildet.

• Applikationsdaten Je nach Dateisystem existieren unterschiedlichen zusätzliche Funktionen wie z.B. Journaling um Datenverluste zu vermeiden, oder Quotas die den verwend- baren Speicherplatz pro Benutzer beschränken.

Zeitstempel fallen in die Kategorie der Metadaten und dokumentieren relevante Ereignisse aus dem Lebenszyklus einer Datei. Sie sind für den Forensiker von beson- derem Interesse, da sie z.B. dokumentieren wann eine Datei mit beweisrelevantem Inhalt auf dem Computer erstellt wurde. In der Kategorie der Metadaten werden durch die Dateisysteme meist die folgenden Zeitstempel gesetzt:

• modified – Der Zeitpunkt, zu dem der Dateiinhalt zuletzt verändert wurde.

• accessed – Der Zeitpunkt, zu dem der Dateiinhalt zuletzt gelesen wurde.

• changed – Der Zeitpunkt, zu dem der Metadaten Eintrag der Datei zuletzt verändert wurde.

• birth oder created – Zeitpunkt, zu dem die Datei im Dateisystem erzeugt wurde.

Dieser Satz an Zeitstempeln wird, entsprechende der jeweiligen Anfangsbuchstaben als „MACB Zeitstempel“ bezeichnet. Je nach Betriebs- und Dateisystem werden unterschiedliche Zeitstempel in unterschiedlichen Formaten gespeichert. Auch kann das Verhalten durch die Konfiguration des Systems verändert werden. In vielen Sys- temen wird z.B. der accessed Zeitstempel für Dateien nicht oder selten geschrieben, um die Performanz des Dateisystems zu erhöhen. Wie in Bild 1.4 ersichtlich, wird bei einer unveränderten Installation von Ubuntu Version 18.04 die Mount-Option relatime für die Systempartition gesetzt. Diese verhindert dass der accessed Zeit- stempel bei jedem Zugriff angepasst wird.

1.3 Auswertung von Dateisystemen

Da der Inhalt des Arbeitsspeichers eines Computers bereits wenige Sekunden nach dem Ausschalten des Geräts nicht mehr rekonstruierbar ist[8] liegt der Schwerpunkt

10 Kapitel 1. Einleitung

Bild 1.4: Inhalt der Datei /etc/fstab einer Ubuntu 18.04 Installation. der forensischen Analyse beschlagnahmter Computer in der Auswertung von Daten, die auf Datenspeichern in Dateisystemstrukturen persistent abgelegt sind. Da das Betriebssystem des Computers zum Analysezeitpunkt nicht aktiv ist, wird diese Vorgehensweise auch als Post-mortem oder Deadbox Analyse bezeichnet.[6, S. 57]

Die Auswertung erfolgt dabei nach einem Prozess, bei dem zunächst der Daten- träger selbst, dann die enthaltenen Volumes bzw. Partitionen, sowie das Dateisys- tem, und schlussendlich die Interpretation der Daten durch die jeweilige Applikation analysiert werden. Bild 1.8 zeigt diesen Prozess in der von Brian Carrier vorgestellten Form.

Bei der Analyse ist darauf zu achten, das die Daten nicht verfälscht werden. Daher ist es gute forensische Praxis, das zu untersuchende Gerät nur mittels eines soge- nannter „Write-Blockers“ mit dem Analysesystem zu verbinden. Dieser verhindert schreibenden Zugriff auf den Datenträger, lässt aber lesenden Zugriff zu.[4, S. 53-54] Nun wird ein Image, also eine vollständige Kopie des Datenträgers, in einem foren- sisch auswertbaren Format z.B. Expert Witness Format (EWF) angefertigt. Alle weiteren Untersuchungen werden auf der erstellten Imagedatei durchgeführt. Dieses Verfahren hat auch den Vorteil, dass die Ergebnisse der Untersuchung im Zweifelsfall anhand des Original-Datenträgers überprüft werden können.

Der intuitive Ansatz, das Dateisystem in einem passenden Betriebssystem zu öff- nen, (man spricht auch von „mounten“) und nach Dateien zu suchen, die eine entsprechende These stützen oder widerlegen, ist wegen der selektiven Anzeige der im Dateisystem enthaltenen Informationen durch das Betriebssystem nicht zielführend. So verhindern z.B. gesetzte Berechtigungen den Zugriff auf bestimmte Dateien. Stattdessen wird eine Methode benötigt, welche unabhängig vom Betriebssystem den möglichst vollständigen Zugriff auf die enthaltenen Informationen ermöglicht.

11 Kapitel 1. Einleitung

Bild 1.5: Standard Prozess der Datenträgeranalyse[4, S. 12]

Diese Methode wird als physische Datenträgeranalyse bezeichnet. Dies kann entwed- er extrem aufwändig „von Hand“ geschehen, indem der Inhalt ders Datenträgers byteweise analysiert wird, oder durch spezielle Software, die diesen Vorgang au- tomatisiert und damit beschleunigt, bzw. überhaupt erst praktisch durchführbar macht.

1.4 Das Prinzip „Ground Truth“

Es existieren verschiedene Softwareprodukte am Markt die eine physische Daten- trägeranalyse vornehmen können, z.B. OpenText™ EnCase™ oder Xways. Es han- delt sich dabei um kommerzielle Software, deren Quelltext (Source Code) nicht of- fengelegt ist. Da der Source Code eines ausführbaren Computerprogramms aus dem Programm selbst nicht wiederherstellbar ist, kann die Funktionsweise eines solchen Programms nicht, oder nur über sehr aufwändige Verfahren wie z.B. Reverse Engi- neering nachvollzogen werden.[9, S. 12]

Eine lückenlose Beweisbarkeit der erzielten Ergebnisse einer forensischen Unter- suchung von Datenträgern kann mit derartigen proprietären „Closed Source“ Soft- warelösungen prinzipbedingt nicht erreicht werden, da der Prozess der Auswertung

12 Kapitel 1. Einleitung selbst nicht anhand des Quelltextes nachvollzogen werden kann, und man stattdessen den Aussagen des Herstellers der Software zu diesem Prozess Glauben schenken muss. Es könnte daher in einem Gerichtsverfahren von der Verteidigung argumen- tiert werden, dass die Beweise aufgrund dieser fehlenden Nachvollziehbarkeit nicht stichhaltig seien. So sehen z.B. die Richtlinien des Federal Bureau of Investigation (FBI) zur Beschaffung von Software für die forensische Analyse digitaler Bildat- en eine Pflicht für den Hersteller zur Offenlegung des Quelltextes vor, um die Ar- beitsweise der Software nachvollziehen zu können.[10, S. 6-7]

Um diese Lücke zu schließen, werden Programme benötigt deren Quellcode offen- gelegt ist, und deren Funktionsweise dadurch im Detail nachvollzogen werden kann. Sie ermöglichen den Zugang zu „Ground Truth“ also den lückenlosen Nachweis, wie der Ermittler zu den vorgelegten Beweisen gelangt ist, in einer Form, die jederzeit durch Dritte nachvollzogen werden kann.[11, S. 7]

Die Sammlung forensischer Tools „The Sleuth Kit“® (TSK) ermöglicht eine solche Beweisbarkeit, da der Quelltext frei verfügbar ist. Sie wird verbreitet in Forschung und Lehre, aber teilweise auch in der forensischen Praxis verwendet.

1.5 Auswertung poolbasierter Dateisysteme

Aus der Entwicklung der Computertechnik ergeben sich neue Anforderungen an Dateisysteme. Die starre Zuordnung von einem Dateisystem zu einer Partition bzw. einem Volume hat sich dabei als hinderlich erwiesen, insbesondere da bereits der Ausfall einer Festplatte zum Totalverlust des Dateisystems führt. Das hat zur En- twicklung von Technologien zur Behebung dieses Problems wie z.B. Raidsystemen geführt. Diese bilden aus mehreren Festplatten ein virtuelles Volume, welches dem Computer präsentiert wird. Dabei werden die Daten zusammen mit zusätzlichen Wiederherstellungsinformationen über alle beteiligten Platten verteilt, so dass je nach Konfiguration eine oder mehrere Platten ausfallen können, ohne dass eine Be- triebsunterbrechung oder ein Datenverlust entsteht.[4, S. 147-170]

Die Entwickler neuerer Dateisysteme wie z.B. des ZFS oder Btrfs haben diese mit Funktionen ausgestattet, die es ermöglichen ein Dateisystem über mehrere Parti- tionen bzw. Datenträger zu verteilen oder mehrere Dateisysteme innerhalb eines Volumes zu verwalten. Damit soll die Komplexität bei der Bereitstellung von Spe- icherplatz reduziert und die Handhabung verbessert werden. Die Implementierungen

13 Kapitel 1. Einleitung unterscheiden sich wesentlich und auch die Bezeichnungen variieren. Dennoch kön- nen diese Dateisysteme vereinfacht unter dem Oberbegriff „poolbasierte Dateisys- teme“ zusammengefasst werden.[12, S. 76-78]

Die Bilder 1.6 und 1.7 verdeutlichen die zusätlichen Fähigkeiten poolbasierter Dateisys- teme.

Bild 1.6: Ein Dateisystem belegt mehrere Volumes

Bild 1.7: Mehrere Dateisysteme belegen ein Volume

Dies stellt eine zusätzliche Abstraktionsschicht dar, welche in dem vorgestellten Analyseprozess nicht enthalten ist. Daher muss auch die Software für die Analyse angepasst werden, um diese Dateisysteme auswerten zu können. Jan-Niclas Hilgert hat dafür in seiner Arbeit „Extending The Sleuth Kit and its underlying model for pooled storage“ den Begriff der Pool-Analyse in einem erweiterten Prozess eingeführt der in Bild 1.8 dargestellt ist.[12, S. 78]

14 Kapitel 1. Einleitung

Bild 1.8: Erweiterter Prozess der Analyse poolbasierter Dateisysteme[12, S. 77]

Auch TSK wurde mittlerweile in verschiedenen Varianten weiterentwickelt, um de- rartige Dateisysteme analysieren zu können. Die weit verbreiteten kommerziellen Softwareprodukte EnCase Forensic[13], FTK[14] und X-Ways Forensic[15] bieten aktuell keine Unterstützung für die Auswertung dieser Dateisysteme. Die Spezial- software MacQuisition® der Fa. Blackbag verfügt über die Fähigkeit APFS Dateisys- teme zu analysieren.[16]

1.6 Einführung zu den untersuchten Dateisystemen

1.6.1 Traditionelle Dateisysteme

Ext4 - Fourth Extended File System

In der Reihe der seit 1992 verfügbaren Ext Dateisystemreihe ist Ext4 die jüng- ste Weiterentwicklung aus dem Jahr 2008. Es basiert auf dem Unix File System (UFS). Es ist im Linux Kernel enthaltene quelloffene Software. Daher liegen Im- plementierungen für viele verschiedene Betriebssysteme vor. Zentrales Element ist der sogenannte Superblock. Die Metadaten werden in sogenannten Inodes gespe-

15 Kapitel 1. Einleitung ichert. Diese dienen als Verbindungsglied zwischen den Verzeichniseinträgen und den Blöcken, welche die Dateiinhalte speichern.

Die Analyse der verschiedenen Dateisysteme der Ext Reihe ist schon seit den ersten Versionen im Sleuthkit enthalten. Zur Analyse wurde das aktuelle Release Version 4.9.0 von TSK verwendet.

NTFS - New Technology File System

Hersteller ist die Fa. Microsoft. NTFS wurde 1993 vorgestellt und ist das Standard- dateisystem aller Windows Versionen seit Windows NT und Windows XP. Zentrale Struktur ist die MasterFileTable, welche in der Datei $MFT gespeichert wird. Sie enthält die wesentlichen Informationen über alle enthaltenen Dateien und Ordner - einschliesslich sich selbst - in jeweils 1 KiB großen Einträgen. Durch die Analyse der auf den Datenträgern vorgefundenen Strukturen wurden quelloffene Implemen- tierungen für andere Betriebssystem wie z.B. Linux entwickelt, welche viele der Funktionen von NTFS nachbilden.

Die Analyse von NTFS Dateisystemen ist schon seit den ersten Versionen in TSK enthalten. Deshalb wurde zur Analyse die aktuelle Release Version 4.9.0 verwen- det.

1.6.2 Poolbasierte Dateisysteme

ZFS - Zettabyte File System

ZFS wurde ursprünglich von der Fa. Sun für das Betriebssystem Solaris entwick- elt. Es ist für große Datenmengen optimiert und verwendet intern 128 Bit Zeiger. Dadurch kann es theoretisch bis zu 2128 Byte große Dateisysteme verwalten, aktuelle Implementierungen nutzen jedoch nur 64 Bit Adressen. Es enthält viele Sicherheits- funktionen u.a.:

• Copy-On-Write um Kopiervorgänge auf Datenträgerebene zu reduzieren

• Atomare Transaktionen, durch die Schreibvorgänge entweder vollständig oder gar nicht ausgeführt werden

• interne Prüfsummen, um Fehler zu erkennen

• automatische Fehlerkorrektur

16 Kapitel 1. Einleitung

• 4 fach vorhandener Superblock

Es ermöglicht die Zusammenfassung mehrere Datenträger zu Pools unter der Ver- wendung verschiedener Raid-Level: disk, mirror, raidz[1-3] Als nutzbare Struk- turen lassen sich innerhalb dieser Pools beliebige „Dataset“-Strukturen kombinieren. ZFS stellt folgende Dataset-Strukturen zur Verfügung:

• Dateisysteme

• Kopien von Dateisystemen (Clones)

• Snapshots, also eingefrorene Zustände von Dateisystemen zu bestimmten Zeit- punkten.

• Block-Geräte, auf die das System beliebige Daten, auch andere Dateisysteme ablegen können.

Seit 2013 werden die Implementierungen für andere Betriebssysteme im Projekt OpenZFS gebündelt weiterentwickelt.[17] Dadurch existieren heute Implementierun- gen für z.B. Linux, macOS und Windows.

Die Analyse von ZFS wurde als Prototyp für poolbasierte Dateisysteme durch die Arbeit von Jan-Niclas Hilgert[12] in das Sleuthkit integriert. Diese Version ist als Fork fkie-cad/sleuthkit auf Github verfügbar.[18]

Btrfs – B-Tree File System

Eine erste Beta Version erschien 2007 für Linux. Btrfs wurde von vorneherein als Open Source Projekt unter der GNU Public License (GPL) mit Unterstützung mehrerer Firmen wie SUSE, Western Digital usw. entwickelt[19], wodurch es aus lizenzrechtlichen Gründen, im Gegensatz zu ZFS, in den Linux Kernel aufgenom- men werden konnte. Es ist deshalb für die allermeisten Linux Distributionen verfüg- bar und wird z.B. von SUSE Linux und Fedora als Standard Dateisystem verwen- det. Es benutzt schwerpunktmäßig sogenannte B-Bäume zur internen Verwaltung. Dabei handelt es sich um eine Datenstruktur, die sehr effizienten Zugriff auf beliebige Datenelemente ermöglicht. Die Konzeption ähnelt ZFS, mit den entsprechenden Fea- tures wie Copy-On-Write, Atomare Transaktionen, Snapshots, usw. Es ermöglicht ebenfalls die direkte Nutzung mehrerer Partitionen mit verschiedenen Raid-Leveln. Mehrere Dateisysteme können als sogenannte Subvolumes in einen Pool eingebunden werden. Der nutzbare Speicherplatz kann über Quotas flexibel gesteuert werden. Es existiert eine Implementierungen für Windows und ReactOS.

17 Kapitel 1. Einleitung

Die Analyse von Btrfs wurde durch die Arbeit von Jan-Nicklas Hilgert, Martin Lambertz und Shujian Yang in das Sleuthkit integriert[20] und ist ebenfalls im Fork fkie-cad/sleuthkit enthalten,[18] welcher für die Analyse von Btrfs verwendet wird.

ReFS – Resilient File Systemen

ReFS wurde 2012 von Microsoft für Windows Server 2012 und Windows 8 vorgestellt. Speziell für den Einsatz auf Dateiservern optimiert, kann es deutlich größere Daten- mengen verwalten als NTFS. Dabei wurde die Schnittstelle zum Betriebssystem von NTFS beibehalten, lediglich die Verwaltung der Daten auf den Speichersystemen wurde neu entwickelt. ReFS enthält umfassende Funktionen für einen sicheren und störungsfreien Betrieb wie Prüfsummen, interne Raid-Funktion, aktiver Fehlerbehe- bung und das selbständige Beseitigen defekter Daten. Eine Data-Tiering Funktion ermöglicht es Daten unterschiedlicher Verfügbarkeitsklassen in einem Dateisystem zu speichern. Treiber existieren aktuell nur für Microsoft Windows Server Betrieb- ssysteme. Ab „Windows 10 2017 Fall Creators Update“ wurden die Treiber vom Windows Client Betriebssystem entfernt.

Die Analyse von ReFS wurde durch die Arbeit von Paul Prade, Tobias Groß und An- dreas Dewald entwickelt[21] und ein entsprechender Fork von TSK veröffentlicht.[22].

APFS – Apple File System

APFS ist das aktuellste Dateisystem der Firma Apple und Nachfolger von Hier- archical File System (HFS+). Es ist verfügbar ab macOS Version 10.13 und iOS Version 10.3. Die volle Unterstützung aller Funktionen von macOS ist ab Version 10.15 (Catalina) gegeben. Es ist spzell für die Nutzung von Flash-Speichersystemen optimiert. APFS verwendet Copy-On-Write, Atomare Transaktionen, und interne Checksummen. Es bietet Snapshots, Clones, interne Komprimierung und Verschlüs- selung. Space Sharing erlaubt mehrere logische Laufwerke innerhalb eines Contain- ers. Ein Container kann sich aber nur über ein einzelnes Volume erstrecken. Es ex- istieren Implementierungen für Windows und Linux, die jedoch nur lesenden Zugriff ermöglichen.

Die Analyse von APFS wurde durch Joe T. Sylvie von der Fa. Blackbag zunächst in einem eigenen Fork blackbagtech/sleuthkit in das Sleuthkit integriert.[23] Seit

18 Kapitel 1. Einleitung dem Release 4.8.0 ist diese Technologie in der offiziellen TSK Version enthalten, so dass auch hier die TSK Version 4.9.0 für die Analyse verwendet wurde.

19 Kapitel 2. Anforderungen an die Ergebnisse der Auswertung von Dateisystemen

2 Anforderungen an die Ergebnisse der Auswertung von Dateisystemen

2.1 Rechtliche Anforderungen

In § 261 StPO ist der Grundsatz der freien Beweiswürdigung aufgestellt, nachdem das Gericht über das Ergebnis der Beweisaufnahme nach seiner freien, aus dem Inbegriff der Verhandlung geschöpften Überzeugung entscheidet. Es bestehen zwar weitgehende Regelungen darüber, welche Beweisen vor Gericht zulässig sind, ob ein Beweis aber als für das Urteil wesentlich erachtet wird liegt im Ermessen des Richters. Dabei muss das Gericht jedoch darauf achten dass seine Beweggründe für Dritte - z.B. für den Fall einer Revision - nachvollziehbar und in der Urteilsbegrün- dung aufgeführt sind. Ansonsten ist im Falle einer Revision Anlass für Widerruf des Urteils gegeben.

Die Ergebnisse der forensischen Auswertung von Datenträgern werden meist in Form eines Sachverständigengutachtens nach § 72 StPO als Beweis vorgelegt. In beson- deren Fällen muss der Forensiker auch direkt vor Gericht Fragen zu seinem Gutacht- en beantworten.

In den USA existiert mit den sogenannten „Daubert Standard“, benannt nach einem Prozess vor dem US Supreme Court[24], eine Liste von Kriterien, um zu prüfen, ob die in einem Sachverständigengutachten aufgestellen Behauptungen auf wissenschaftlichen Grundprinzipien beruhen. Brian Carrier entwickelt in seinem Ar- tikel „Open Source Digital Forensics Tools - The Legal Argument“ [10] die folgenden, aus dem Daubert Standard abgeleiteten Anforderungen für die Prozedur der foren- sischen Auswertung von Datenträgern:

• Testbarkeit: Gibt es Testmöglichkeiten und wurde die Prozedur getestet?

• Fehlerrate: Ist die Fehlerrate der Prozedur bekannt?

• Veröffentlichung: Wurde das Verfahren veröffentlicht und einer Peer Review unterzogen?

20 Kapitel 2. Anforderungen an die Ergebnisse der Auswertung von Dateisystemen

• Akzeptanz: Ist das Verfahren in der einschlägigen wissenschaftlichen Gemein- schaft allgemein anerkannt?

Dies entspricht auch den Kriterien die allgemein an wissenschaftliche Verfahren gestellt werden, die aussagekräftige Ergebnisse liefern sollen. Diese Kriterien können als Anhaltspunkt dafür dienen, welche Erwartungen an die Methoden einer foren- sischen Untersuchung gestellt werden, auch wenn die rechtlichen Anforderungen in Deutschland nicht definiert sind.

2.2 Anforderungen aus der forensischen Praxis

Um diese Anforderungen zu erfassen wurden mehrere praktisch arbeitende Foren- siker informell zu ihren Qualitätsanforderunge an die Ergebnisse einer forensischen Datenträgerunterschung befragt. Die folgenden Themenfelder wurden dabei erar- beitet:

2.2.1 Vollständigkeit

Dies ist eine grundlegende Anforderung an eine forensische Analyse. Kriminelle ver- suchen ihre Aktivitäten mit verschiedensten Methoden zu verschleiern, wie z.B. dem Ausnutzen von sogenanntem File-Slack, also dem ungenutzen Raum zwischen dem Dateiende und dem Ende des letzten Speicherblocks einer Datei. Zudem bietet unvollständige Analyse stets Raum für Gegenargumente, welche die vorgebrachten Thesen untergraben können. So könnte z.B. ein nicht ausgewerteter Teil der Fest- platte entlastendes Material enthalten haben.

2.2.2 Nachvollziehbarkeit

Die forensische Analyse muss auch für einen nicht mit der Materie vertrauten Laien verständlich dargestellt werden, so dass dieser die bei der Untersuchung vorgenomme- nen Schritte nachvollziehen kann. Weiter ist nicht nur das Ergebnis der Analyse son- dern auch die Vorgehensweise nachvollziehbar zu dokumentieren, um das Vertrauen des Gerichts in die vorgelegte Arbeit zu stärken.

21 Kapitel 2. Anforderungen an die Ergebnisse der Auswertung von Dateisystemen

2.2.3 Wiederholbarkeit

Wenn eine Überprüfung der Analyse oder weitergehende Untersuchungen angeord- net werden, muss nachweisbar sein, dass die Wiederholung der dargelegten Analy- seschritte jeweils exakt zum selben Ergebnis führt. Daher sind eine nachvollziehbare Dokumentation und Hashsummen wichtig. Mit Hashsummen von untersuchten Fest- platten und Dateien kann die Identität auch bei großen Datenmengen belegt wer- den.

2.3 Abstraktion und Formalisierung

Ziel der forensischen Untersuchung ist es ein möglichst genaues Bild der Handlungen zu erschaffen, welche zu dem Zustand des untersuchten Rechners geführt haben. Es kann z.B. versucht werden, den Empfang und das Lesen einer Email nachzuweisen indem die Email selbst in der Mailbox-Datei auf dem Rechner vorgefunden wird und das Read Flag für diese Mail gesetzt ist. Aus den Logdateien geht hervor, dass der persönliche Account des Verdächtigen zum entsprechenden Zeitpunkt an dem Computer angemeldet war.

Ein Analyseprogramm, das zum Erstellen einer derartigen Auswertung genutzt wer- den kann muss also in der Lage sein alle der im Standardmodell der Datenträgeranal- yse enthaltenen Schritte der Reihenfolge nach korrekt abzuarbeiten. Dazu gehört das Erkennen der Partition, ggf. des Pools, des Dateisystems und die Wiederherstellung aller im Dateisystem vorhandenen Dateien zusammen mit dem Verzeichnisspfad, dem Dateinamen, sowie aller Metadaten.

Die einzelnen Schritte der Analyse bauen also folgendermaßen aufeinander auf:

• Erkennung der Partitionsinformationen/Poolinformationen

– Typ der Partition

– Offset des ersten Blocks

– Blockgröße

• Erkennung von Dateisysteminformationen

– Typ des Dateisystems

– Benutzerdefinierter Name/Label

– ID des Dateisystems

22 Kapitel 2. Anforderungen an die Ergebnisse der Auswertung von Dateisystemen

– Auslesen von Dateiinformationen bzw. Metadaten für jede existierende Datei

∗ Dateiname

∗ Verzeichnisname/Ordnerpfad

∗ ID der Metadatenstruktur (Inode)

∗ Dateigröße

∗ MACB Zeitstempel

∗ Berechtigungen

∗ Wiederherstellen der Datei und Bildung des Hashwerts zur Identi- fizierung

Um nun die Leistungsfähigkeit eines Analyseprogramms zu messen, wird jeder einzelne Schritt dieser Kette mit den verschiedenen untersuchten Dateisystemen durchge- führt, und geprüft, ob der Vorgang erfolgreich war oder nicht. Daraus lässt sich eine Tabelle mit den Dateisystemen als Spalten und den Tests als Zeilen erstellen. Diese bietet eine übersichliche Darstellung für die Einschätzung der Leistungsfähigkeit des Analysewerkzeugs für das jeweilige Dateisystem. In den Zeilen kann für ein bestimmtes Objekt überprüft werden, ob das Analysewerkzeug im Bezug auf das jeweilige Dateisystem das Objekt wiederherstellen kann. Da die Tests vollautoma- tisch ablaufen, können die Tests beliebig oft wiederholt werden, und es kann eine Fehlerrate bestimmt werden.

23 Kapitel 3. Entwicklung einer automatisierten Testumgebung

3 Entwicklung einer automatisierten Testumgebung

3.1 Vorüberlegungen

In der Literatur, die sich mit der Leistungsfähigkeit von Analyseumgebungen beschäftigt,[10] werden meist Analysen gegen existierende Test-Images ausgeführt, die z.B. als Datei zum Download bereitgestellt werden.[25]. Dies ist auch sinnvoll, um Analysew- erkzeuge gegen bekannte Strukturen zu testen. Die Tests sind damit aber statisch. Sobald Updates oder neue Versionen für Teile der Analyseumgebung erscheinen, muss die Testumgebung manuell upgedatet und die Tests erneut durchgeführt wer- den. Für ein Update der Quell-Images ist man auf den Verantwortlichen für das jeweilige Image angewiesen. Paul Prade, Tobias Groß und Andreas Dewald dagegen verwenden zur Auswertung der Ergebnisse ihrer Erweiterung des TSK ein Script, welches dynamisch und zufallsbedingt Dateien innerhalb des Dateisystems erstellt, den Zustand dann mit im Betriebssystem enthaltenen Funktionen ausliest und an- schliessend eine forensische Analyse des Dateisystems durchführt.[21, S. 89-94] Dieses Prinzip bildet die Datenbestände, die bei forensischen Untersuchungen vorgefunden werden besser ab als statische Testimages. Daher wurde es auch für diese Arbeit übernommen.

Um den Aufwand für die Aktualisierung der Testumgebung zu minimieren, sollte sich diese beim ersten Aufruf selbständig aktualisieren, so dass sowohl auf der Seite der Gererierung, als auch bei der Analyse jeweils mit den neuesten Versionen gearbeitet wird. Ergeben sich relevante Updates kann die Umgebung einfach neu initialisiert werden, um die Änderungen einzupflegen.

Die folgenden Designentscheidungen wurden im Hinblick auf die jeweiligen An- forderungen getroffen:

Um die Forderung nach Vollständigkeit zu erfüllen:

• Es wird der gesamte Analyseprozess durchlaufen, von der Partition bis zum Dateiinhalt.

• Es werden sowohl existierende als auch gelöschte Dateien analysiert.

24 Kapitel 3. Entwicklung einer automatisierten Testumgebung

• Auf die Analyse von File Slack, alternativen Datenströmen und anderen vom jeweiligen Dateisystem abhängigen Funktionen wurde aus Zeitgründen verzichtet. Diese können bei Bedarf nachträglich implementiert werden.

Um die Forderung nach Nachvollziehbarkeit zu erfüllen:

• Die gesamte Testumgebung sollte einfach auf andere Computer portierbar sein.

• Das Setup muss nachvollziehbar sein und möglichst vollständig aus Scripten bestehen. Benötigte Betriebssystemimages sollten dynamisch aus offiziellen Quellen geladen werden, auch um den Umfang des Systems zu reduzieren.

• Die Systemvoraussetzungen müssen bekannt sein und der Aufbau der Umge- bung muss dokumentiert sein.

• Wenn möglich soll mit virtuellen Maschinen gearbeitet werden so dass die gesamte Umgebung innerhalb eines Rechners ablaufen kann.

• Das System, welches die beschriebenen Tests automatisiert durchführt sollte selbst soweit als möglich aus quelloffener Software bestehen

• Es sollte eine Skriptsprache verwendet werden, so dass keine Compilierung der Programme erforderlich ist

• Die Ergebnisse der Analyse sollten als Klartext in einem standardisierten Datenaustauschformat abgelegt werden. Es existiert zwar mit dem Body-File Format[26] bereits ein Austauschformat, welches die für die forensische Anal- yse relevanten Eigenschaften von Dateien abbildet. Allerdings ist darin keine Möglichkeit vorgesehen, Informationen für Partitionen und Dateisysteme, wie sie in den vorgelagerten Analyseschritten anfallen, abzulegen.

Um die Forderung nach Wiederholbarkeit zu erfüllen:

• Die Tests sollen vollständig automatisiert ablaufen.

Um die Vergleichbarkeit der Ergebnisse zu gewährleisten, sollte der Prozess der Analyse für jedes Dateisystem möglichst gleichartig aufgebaut sein und nur aufgrund von Unterschieden in den jeweiligen Datei- oder Betriebssystemen abweichen.

25 Kapitel 3. Entwicklung einer automatisierten Testumgebung

Bild 3.1: Struktur des Projektordners

3.2 Konzeption

Wie in Bild 3.1 dargestellt werden alle Elemente der Testumgebung strukturiert unterhalb eines Hauptverzeichnisses abgelegt:

Programmspezifische Inhalte liegen unter den entsprechend benannten Ordnern. Das install Verzeichniss enthält benötigte Installationspakete. Der data Ordner ist der zentrale Punkt, an dem Images und Analyseergebnisse abgelegt werden. Im Ordner tests befinden sich die Scripte, welche die automatisierten Testläufe durchführen.

Der Inhalt wird mittels git [27] gesichert und versioniert. Er kann auf Github unter ptitus/bt [28] heruntergeladen werden. Damit besteht eine Möglichkeit für Dritte, diese Tests selbständig nachzuvollziehen.

Der Ablauf des Vergleichsprozesses imitiert den tatsächlichen Ablauf einer foren- sischen Untersuchung. Zunächst werden auf einem Computer Dateiinhalte erzeugt. Diese werden später bei der Analyse wiederhergestellt und untersucht. Der konkrete Ablauf für ein bestimmtes Dateisystem – in diesem Fall NTFS - wird in Bild 3.2 skizziert.

Auf dem zentralen Host läuft die Virtualisierungsumgebung. Zudem steuert er den Ablauf und führt am Ende den Abgleich der Ergebnisse durch. Für die Analyse jedes Dateisystems wird eine passende Generatormaschine und eine entsprechende Analysemaschine benötigt.

Für die Generatormaschine wird das Betriebssystem verwendet, für welches das Dateisystem hauptsächlich entwickelt wird, um Fehlerquellen zu minimieren. Um einen sinnvollen Abgleich zu ermöglichen, erfolgt das Auslesen der Informationen mit Bordmitteln des Betriebssystems, nicht mit dem Analysewerkzeug.

26 Kapitel 3. Entwicklung einer automatisierten Testumgebung

Bild 3.2: Ablauf des Testprozesses

3.3 Verwendete Werkzeuge

Hardware und Betriebssystemumgebungen:

• Hostumgebung: Notebook mit einer Intel Core i7 10510U CPU, 16 GB RAM, einer 1 TB Samsung 970 EVO Plus NVMe HDD und TUXEDO OS 18.04 (Ubuntu basierend).

• Als Standard-Betriebssystem für die virtuellen Maschinen wurde Ubuntu 18.04 LTS gewählt, da dieses System bereits mehrere Jahre im produktiven Einsatz ist und entsprechend weniger unentdeckte Fehler zu erwarten sind.

• Die Windows Dateisysteme NTFS und ReFS wurden auf einem Windows Serv- er 2019 Core erzeugt.

• Für die Erzeugung des APFS Dateisystems wurde ein MAC mini, mit macOS 10.15 Catalina, verwendet

Tabelle 3.1 zeigt die verwendete Software

27 Kapitel 3. Entwicklung einer automatisierten Testumgebung

Tabelle 3.1: Übersicht über die verwendete Software Zweck Name Version Virtualisierungsumgebung VirtualBox [29] 6.0.16 Box-Generierung Packer [30] 1.5.4 Provisionierung: Vagrant [31] 2.2.7 Automatisierung Puppet Bolt [32] 2.14.0 Scripte Linux und MacOS Bourne again Shell (bash) Script [33] diverse Scripte Windows PowerShell (PoSh)[34] 5.1 Datenformat Java Script Object Notation (Json)[35]- Json Verarbeitung jq [36] 1.5.1 Test Framework shunit2 [37] 2.1.9 Versionsverwaltung git [27] 2.28.0

3.4 Aufbau der Provisionierungsumgebung

Eine manuelle Betriebssysteminstallation mehrerer Maschinen birgt stets die Möglichkeit, dass Fehler passieren, bzw. dass undokumentierte Abweichungen bei den erstellten Systemen entstehen. Um diesem Problem vorzubeugen, folgt der Aufbau der Tes- tumgebung dem Prinzip „Infrastructure as Code“[38, S. 55-56] und ermöglicht so eine schnelle, flexible und konsistente Bereitstellung der benötigten Betriebssyste- mumgebungen.

Die Bereitstellung erfolgt soweit als möglich mit Vagrant von der Fa. Hashicorp.[31] Vagrant generiert automatisch virtuelle Maschinen, die auf Konfigurationsdateien (Vagrantfiles) basieren.

Vagrant benötigt für die Erstellung virtueller Maschine eine sogenannt „Box“ al- so eine Basis-Betriebssystem Installation. Von dieser wird die eigentliche Virtuelle Maschine kopiert und nach den Vorgaben in der Vagrantfile angepassst.

Es existieren bereits viele fertige Vagrant-Boxen, die von einer Online-Plattform [39] heruntergeladen und direkt verwendet werden können. Allerdings würde bei der Nutzung dieser Boxen wieder ein Element der Unsicherheit entstehen, da der Prozess der Entstehung dieser Boxen nicht nachvollziehbar dokumentiert ist.

Deshalb wurden die genutzten Box-Dateien mit dem Tool Packer[30] generiert, so dass auch hier jeder Schritt aus der verwendeten Packer Konfigurationsdatei nachvol- lzogen werden kann.

Bild 3.3 zeigt die Verzeichnisstruktur der Packer Umgebung für die Generierung der Ubuntu Linux Box. In den entsprechenden Json Dateien werden sämtliche Parameter

28 Kapitel 3. Entwicklung einer automatisierten Testumgebung

Bild 3.3: Struktur der Packer Umgebung der Bereitstellung konfiguriert. Beim Start des Prozesses z.B. mit packer build ubuntu.json laufen die folgenden Schritte automatisch ab:

1. Herunterladen des original Betriebssystem-Images als Installationsquelle.

2. Erstellen und Starten einer virtuellen Maschine entsprechend der Konfigura- tionsdaten.

3. Installation des Betriebssystems.

4. Neustart und Laden des installierten Betriebssystems.

5. Ausführen von Scripten, welche die VirtualBox Erweiterung installiert um die Verwaltbarkeit in VirtualBox zu verbessern.

6. Anlegen des vagrant Benutzers.

7. Linux: Herunterladen eines provisorischen SSH Schlüssels für Vagrant, um die Steuerung und weitere Provisionierung durch Vagrant zu ermöglichen.

8. Windows: Freischalten des Zugangs per WinRM in der Firewall.

9. Herunterfahren des Betriebssystems.

10. Ablegen eines Abbilds der Maschine im Ordner box als Vorlage für Vagrant.

Aus diesen Box-Dateien werden durch Vagrant alle benötigten Maschinen dynamisch erzeugt. Vagrant sorgt dafür, dass die entsprechenden Maschinen in einem definierten Zustand bereitstehen. Dieser als Provisionierung bezeichnete Vorgang wird beim ersten Start der virtuellen Maschine mittels des Befehls vagrant up angestoßen. Dabei werden folgende Schritte ausgeführt:

1. Erzeugen einer virtuelle Maschine entsprechend der Konfiguration in der Vagrantfile.

29 Kapitel 3. Entwicklung einer automatisierten Testumgebung

Tabelle 3.2: Übersicht über die erstellten Generatormaschinen Dateisystem Betriebssystem Name Konfiguration Ext4, Ubuntu Linux 18.04 LTS generator_lnx Vollständig mittels ZFS, Vagrant kontrollierte Btrfs virtuelle Maschinen NTFS, Windows Server 2019 Core generator_win Vollständig mittels ReFS Vagrant kontrollierte virtuelle Maschinen APFS MacOS 10.15 Catalina generator_mac Physische Maschine, Benutzer mit root Rechten und SSH Zugriff konfiguriert

2. Start der virtuellen Maschine.

3. Verbindung zur Maschine über SSH oder WinRM aufbauen.

4. Einrichtung eines gemeinsamen Ordners, auf den sowohl von der Host-Maschine als auch von der virtuellen Maschine zugegriffen werden kann und der auf den zentralen Ordner data im Projektverzeichnis verweist.

5. Ausführen von spezifischen Skripten:

• Aktuelle Betriebssystem-Updates herunterladen und installieren.

• Anlegen eines Benutzers mit Root Rechten, um den Zugriff für die Scripte für die Testautomatisierung zu ermöglichen.

• Linux: Hinterlegen eines SSH Schlüssels, so dass der SSH Zugriff ohne Eingabe eines Passwords erfolgen kann.

• Installieren von Anwendungen, um die Maschinen auf ihren Einsatzzweck anpassen, z.B. eine bestimmte TSK Version.

3.5 Bereitstellung der Generatormaschinen

Tabelle 3.2 zeigt die erstellten Generatormaschinen

Die generator_lnx Maschine wird nach der Bereitstellung einer base Maschine und Konfiguration der Vagrantfile mittels des Befehls vagrant up generator_lnx initialisiert. Als zusätzliche Software wird für diese Maschine nur das Paket

30 Kapitel 3. Entwicklung einer automatisierten Testumgebung

Tabelle 3.3: Übersicht über die erstellten Analysemaschinen Dateisystem TSK Uniform Resource Locator (URL) Name Version Ext4, 4.9.0 https://github.com/sleuthkit/sleuthkit sleuthkit_49 NTFS, APFS ZFS, Btrfs 4.4.2 https://github.com/fkie-cad/sleuthkit sleuthkit_fkiecad ZFS, Btrfs 4.6.6 https://faui1- sleuthkit_faui gitlab.cs.fau.de/paul.prade/refs- sleuthkit-implementation zfsutil-linux für das ZFS Dateisystem benötigt. Ext4 und Btrfs werden bereits mit der Ubuntu Standard Installation unterstützt.

Die Box für die generator_win Maschine basiert auf den Scripten von Stefan Scherer [40]. NTFS und ReFS werden von Windows Server 2019 standardmäßig unterstützt, so dass keine zusätzliche Software installiert werden muss.

Für die generator_mac Maschine wurde ein physischer Rechner benötigt, da Ver- suche, macOS 10.15 [41] als virtuelle Maschine bereitzustellen, fehlgeschlagen sind. Der Rechner wurde im Netzwerk mit einer festen Internet Protocol (IP) Adresse versehen Hier wurde auf eine Standard macOS Installation der administrative Be- nutzer user hinzugefügt, SSH in der Firewall freigeschaltet und ein entsprechendes Zertifikat vom Host auf den macOS Rechner übertragen, um eine automatisierte Anmeldung per Script zu ermöglichen. Als zusätzliche Software wurde mittels des Paketmanagers homebrew [42] das Paket jq[36] zum Parsen von Json[35] Dateien installiert.

3.6 Bereitstellung der Analysemaschinen

Tabelle 3.3 zeigt die erstellten Analysemaschinen

Auf den Analysemaschinen werden die für das Kompilieren des Sleuthkit erforder- lichen Pakete und Bibliotheken installiert. Zusätzlich wird das Paket xmount instal- liert, mit dem Dateisysteme aus Imagedateien gemountet werden können. Für die Installation von TSK wird dediziert das Git Repository der jeweiligen Version bzw. des jeweiligen Forks geklont, kompiliert und installiert. Das folgende Script zeigt dies beispielhaft für TSK 4.9.0.

31 Kapitel 3. Entwicklung einer automatisierten Testumgebung

1#!/usr/bin/env bash 2 apt install-qy automake libtool checkinstall libafflib-dev libewf-dev libvmdk-dev libvhdi-dev libsqlite3-dev postgresql-server-dev-10 default-jre default-jdk xmount 3 if![[-e/home/user/sleuthkit/.git]] 4 then git clone--depth=1 --branch release-4.9.0 https://github.com/ sleuthkit/sleuthkit.git/home/user/sleuthkit 5 fi 6 cd/home/user/sleuthkit 7 ./bootstrap 8 ./configure 9 make 10 checkinstall-y

Listing 3.1: sleuthkit-49.sh

3.7 Steuerung des Testablaufs

Zu jedem Dateisystem befinden sich im Ordner tests drei Scriptdateien, z.B. für Ext4:

• ext4_generate.sh Läuft auf der Generatormaschine. Erstellt ggf. die Partition und das Dateisys- tem und mountet diese. Es werden dann verschiedene Dateisystemobjekte generiert und deren Eigenschaften mit Bordmitteln ausgelesen. Die Ergebnisse der Analyse werden im data Ordner in der Datei ext4src.json abgelegt.

• ext4_analyze.sh Läuft auf der Analysemaschine. Sucht in der Imagedatei nach der entsprechen- den Partition und dem Dateisystem. Es werden dann sämtliche Dateisystemob- jekte gesucht, wiederhergestellt und ihre Eigenschaften im data Ordner in der Datei ext4tsk.json abgelegt.

• ext4_tests.sh Zentrale Steuerung und Auswertung. Die Generierung und Analyse erfolgt in der Funktion oneTimeSetup() Diese generiert den virtuellen Datenträger, startet die passende Generatormaschine und startet darauf das entsprechende

32 Kapitel 3. Entwicklung einer automatisierten Testumgebung

xxx_generate.sh Script. Anschließend wird sichergestellt, dass das Dateisys- tem geschlossen wird und die Imagedatei im data Ordner zur Analyse bere- itgestellt ist. Nun wird die Analysemaschine hochgefahren und dort das ent- sprechende xxx_analyze.sh Script gestartet. Weiter ist für jede zu testende Eigenschaft eine Testfunktion enthalten. Zur Durchführung der Tests wird im Anschluss das shunit2 Framework aufgerufen. Dieses validiert jede in dem Script enthaltene Funktion, die mit dem Schlüsselwort test beginnt, und pro- tokolliert Abweichungen.

3.8 Generierung von Dateisystemobjekten

Zunächst wird, falls für das Dateisystem erforderlich, eine Partition erstellt und es werden die für die Wiederherstellung relevanten Daten ermittelt.

In der Partition wird das entsprechende Dateisystem generiert. Dieses wird gemoun- tet, so dass schreibender Zugriff möglich ist. Es werden verschiedene Dateisystemob- jekte erstellt, um eine halbwegs realistische Bandbreite von Dateioperationen abzu- bilden. Der Umfang der Dateien ist allerdings deutlich kleiner als er auf einem realen Laufwerk zu erwarten wäre. Hier besteht ein Ansatz für eine Weiterentwicklung.

Diese Dateisystemobjekte wurden mit den jeweiligen Scripten erstellt:

• file.0 – Null Byte große Datei bash: touch file.0 PoSh: New-Item"file.0"-ItemType File

• file.binary – mit zufälligen Daten gefüllte Datei bash: cat file.binary PoSh: $data= New-Object byte[] 10kb (New-Object Random).NextBytes($data) [IO.File]::WriteAllBytes("file.binary", $data)

• file.txt – mit zufälligem Text gefüllte Datei bash: base64/dev/urandom| head-c 10000000 > file.txt PoSh:

33 Kapitel 3. Entwicklung einer automatisierten Testumgebung

$chars=[char[]] ([char]’0’..[char]’9’+[char]’A’..[char]’Z’+ [char]’a’..[char]’z’) $chars= $chars * 126 (1..(10kb/128)).foreach({-join(Get-Random $chars-Count 126)‘ | Add-Content"file.txt"})

• delfile.txt – entsprechend file.txt, wird nach Auslesen der Daten gelöscht bash: ... rm delfile.txt PoSh: ... Remove-Item"delfile.txt"-force

• subdir – Unterordner bash: mkdir subdir PoSh: New-Item"subdir"-ItemType Directory

• subdir/file2.txt – entsprechend file.txt, wird in Unterordner erstellt bash: base64/dev/urandom| head-c 10000000 > subdir/file.txt PoSh: $chars=[char[]] ([char]’0’..[char]’9’+[char]’A’..[char]’Z’+ [char]’a’..[char]’z’) $chars= $chars * 126 (1..(10kb/128)).foreach({-join(Get-Random $chars-Count 126)‘ | Add-Content"subdir/file.txt"})

Von jedem erstellten Objekt werden die folgenden Eigenschaften, mit je nach Be- triebssystem unterschiedlichen Befehlen ausgelesen:

• Dateiname/Pfad Linux: stat--format=%n macOS: basename Windows: Get-Item $myFile

• Inode Linux: stat--format=%i macOS: stat-f%i Windows: n.v.

34 Kapitel 3. Entwicklung einer automatisierten Testumgebung

• Typ – TSK gibt für normale Dateien ein r anstatt ein - aus, daher wird dieser Wert im Script entsprechend angepasst. Linux: stat--format=%A| cut-c1 macOS: ls-ld"$Path"| head-c1 Windows: (Get-Item $File).Mode.Substring(0,1)

• Berechtigungen/Mode Linux: stat--format=%A macOS: ls-l Windows: (Get-Item $File).Mode

• Modified Zeitstempel als Unixzeit[43] Linux: stat--format=%Y macOS: stat-st%s"$Path"| cut-d""-f 10 Windows: Get-Date((Get-Item $File).LastWriteTimeUtc)-uformat"%s"

• Accessed Zeitstempel als Unixzeit[43] Linux: stat--format=%X macOS: stat-st%s"$Path"| cut-d""-f9 Windows: Get-Date((Get-Item $File).LastAccessTimeUtc)-uformat"%s"

• Changed Zeitstempel als Unixzeit[43] Linux: stat--format=%Z macOS: stat-st%s"$Path"| cut-d""-f 11 Windows: 1 $fsutilResult= fsutil file layout"${myFile}" 2 $fchanged= $fsutilResult| select-string‘ 3 -pattern"Change Time\s+:\s+(.*)" | %{$_.matches.groups[1].Value} 4 $Y=("$fchanged").split("")[0].split("/")[2] 5 $M=("$fchanged").split("")[0].split("/")[0] 6 $D=("$fchanged").split("")[0].split("/")[1] 7 $hh=("$fchanged").split("")[1].split(":")[0] 8 $mm=("$fchanged").split("")[1].split(":")[1] 9 $ss=("$fchanged").split("")[1].split(":")[2] 10 [Math]::Floor([decimal](Get-Date-Year $Y-Month $M‘ 11 -Day $D-Hour $hh-Minute $mm-Second $ss-uformat"%s"))

Listing 3.2: changed-win

35 Kapitel 3. Entwicklung einer automatisierten Testumgebung

• Created Zeitstempel als Unixzeit[43] Linux: debugfs-R’stat<’"$inode"’>’"$fs" macOS: stat-st%s"$Path"| cut-d""-f 12 Windows: Get-Date((Get-Item $myFile).CreationTimeUtc)-uformat"%s"

• Dateigröße in Bytes Linux: stat--format=%s macOS: stat-f%z Windows: (Get-Item $File).Length

• Sha256 Hash des Dateiinhalts Linux: sha256sum macOS: shasum-a 256 Windows: Get-FileHash $myFile-Algorithm SHA256

Um die Vergleichbarkeit von Zeitstempeln zu gewährleisten werden diese immer im Unixzeit Format (Unix Epoch Time) abgespeichert und verglichen.[43]

Das Ergebnis wird in die entsprechende Json Datei geschrieben. Das Bild 3.4 zeigt die Anfangssequenz der für das Dateisystem APFS erstellten apfssrc.json Datei:

Bild 3.4: Ergebnis der APFS Generierung als Json Datei

36 Kapitel 3. Entwicklung einer automatisierten Testumgebung

3.9 Forensische Analyse des erzeugten Datenträgers

Auf der Analysemaschine werden, dem Prozess der forensischen Analyse folgend, verschiedene in TSK enthaltene Programme aufgerufen, um den Inhalt der im data Verzeichnis abgelegten Imagedateien zu analysieren.

Zunächst wird mit mmstat der Typ der Partition ermittelt und mit mmls nach der entsprechenden Partition gesucht. Es wird die Blockgröße und das Offset des ersten Blocks ermittelt, wie in Bild 3.5 dargestellt.

Bild 3.5: Auslesen von Partitionsinformationen mit mmls

Das ermittelte Offset wird genutzt, um mit fsstat die Eigenschaften des Dateisys- tems auszulesen: fsstat-o 2048 ext4.vmdk

Bild 3.6 zeigt das Ergebnis für ein Ext4 Dateisystem.

Mit dem Befehl fls kann nun die Liste der enthaltenen Dateien ausgegeben werden. Der Parameter -m gibt an, dass die Ausgabe im „Body file“ Format[26] erfolgen soll. Dieses Format ist für die automatische Weiterverarbeitung durch Scripte konzipiert. Pro Zeile werden die Eigenschaften einer Datei in durch | Zeichen getrennte Felder zurückgegeben. Die Felder enthalten folgende Werte: MD5|name|inode|mode_as_string|UID|GID|size|atime|mtime|ctime|crtime

Bild 3.7 zeigt die Ausgabe des Befehls fls -pro 2048 -m / ext4.vmdk.

Bild 3.7: Mit fls ausgelesene Dateiinformationen

37 Kapitel 3. Entwicklung einer automatisierten Testumgebung

Bild 3.6: Auslesen von Dateisysteminformationen mit fsstat

Mit der ermittelten Inode und dem Befehl icat wird der Inhalt der Dateien wieder- hergestellt, sowie mit sha256sum ein Sha256 Hashert des Dateiinhalts generiert, wie in den Bildern 3.8 und 3.9 dargestellt.

Bild 3.8: Wiederherstellung von Dateiinhalten mit icat

Bild 3.9: Generieren seines Sha256 Hashwertes

Die ermittelten Informationen werden ebenfalls im data Verzeichnis in einer [fs]tsk.json Datei abgelegt, welche dieselbe Struktur aufweist wie die von dem Generator-Skript erstellte Datei. Ein Beispiel zeigtBild 3.10.

38 Kapitel 3. Entwicklung einer automatisierten Testumgebung

Bild 3.10: Anfangssequenz einer apfstsk.json Datei

3.10 Abgleich der Artefakte mit den erstellten Objekten

Der tatsächliche Vergleich zwischen den Inhalten der beiden Json Dateien erfolgt durch das Test-Framework shunit2.[37] beim Dateisystem APFS sind das z.B. die apfssrc.json und apfstsk.json. Das Script dazu liegt im Ordner tests, für das Dateisystem APFS ist dies die Datei apfs_tests.sh.

Zum Abgleich werden mit dem Programm jq[36] die Inhalte der beiden Json Dateien geparst und einzeln verglichen. Zunächst wird aus dem Inhalt der Dateien ein Json Objekt im Arbeitsspeicher erzeugt, aus dem dann gezielt einzelne Werte abge- fragt werden können. Bild 3.11 zeigt den Vorgang am Beispiel der Eigenschaft .fs.type.

39 Kapitel 3. Entwicklung einer automatisierten Testumgebung

Bild 3.11: Auslesen der Eigenschaft type.fs aus einer Json Datei

Der Abgleich durch shunit2 erfolgt mittels sogenannter „Assertions“, deren Einhal- tung überprüft wird.

assertNotNull prüft, dass eine Variable nicht leer ist

assertEquals prüft, ob der Inhalt zweier Variablen identisch ist.

Dabei ist als Parameter die Meldung anzugeben, welche im Fehlerfall ausgegeben wird, sowie die zu prüfende(n) Variable(n). Tritt kein Fehler auf, wird lediglich die Anzahl der ausgeführten Testfunktionen als Rückmeldung ausgegeben. Bild 3.12 zeigt die Testfunktion für die Eigenschaft type.fs aus der apfs_tests.sh Datei.

Bild 3.12: Testfunktionfür die Eigenschaft fs.type

Zudem können mit dem Befehl startSkipping nachfolgende Tests ausgelassen wer- den, wenn diese ohnehin fehlschlagen würden. Wenn z.B. eine Datei nicht gefunden wird, macht es keinen Sinn mehr, weitere Tests zu den Eigenschaften dieser Datei durchzuführen. Bild 3.13 zeigt die Implementierung zur Auswertung einer 0 Byte großen Datei.

40 Kapitel 3. Entwicklung einer automatisierten Testumgebung

Bild 3.13: Auslassen weiterer Prüfungen mittels startSkipping

Als Ergebnis zeigt Shunit2 die durchgeführten Testfunktionen und ggf. die Mel- dungen zu fehlgeschlagenen Tests sowie die Anzahl der übersprungenen (=skipped) Tests an.

Bild 3.14 zeigt das Ergebnis einer Analyse der Auswertung eines Ext4 Dateisystems. Es wird deutlich, dass die beiden initialen Tests JQ, JSONOBJCOUNT sowie die Anal- yse der Partition PARTITION ohne Fehler abgeschlossen wurden. Bei der Analyse des Dateisystems wurde der Namen bzw. das Label des Dateisystems nicht kor- rekt wiederhergestellt, außerdem unterscheiden sich die IDs des Dateisystems. Bei den Dateien FILE-BINARY und FILE-SUBFILE wurden Abweichungen bei den Ac- cessed und Creation Zeitstempeln festgestellt. Da die gelöschte Datei nicht wieder- hergestellt werden konnte, wurden die weiteren 30 Tests für diese Datei übersprun- gen. Es wurden 10 Testfunktionen durchgeführt und insgesamt 8 Einzeltests sind fehlgeschlagen.

41 Kapitel 3. Entwicklung einer automatisierten Testumgebung

Bild 3.14: Ergebnis einer Prüfung mit dem shunit2 Framework

Da shunit2 Tests nur lokal abarbeitet und nicht in Funktionsaufrufen nachverfol- gt, müssen die Skripte für die Testdurchführung alle Tests direkt enthalten. Daher können wiederkehrende Aufgaben nicht in Funktionen ausgelagert werden sondern müssen vollständig im Scriptcode ausformuliert werden. Um die Menge an zu verwal- tendem Scriptcode zu reduzieren liegen die Tests für die Dateisystemobjekte in der Datei file_tests.txt und werden zur Laufzeit durch das Script testrunner.sh in das Testscript des jeweiligen Dateisystems eingebunden. Das zu testende Dateisys- tem wird dabei als Argument übergeben, wodurch die Datei dyn_tests.sh erstellt und ausgeführt wird.

Ein Mitschnitt eines vollständigen Analysevorgangs ist als Download verfügbar.[44]

42 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

4 Durchführung der Tests und Bewertung der Ergebnisse

4.1 Ext4

Da es sich um ein traditionelles Dateisystem handelt, benötigt Ext4 eine Partition in der es erstellt werden kann. Der Ablauf der Generierung ist dementsprechend:

1. Auf der Hostmaschine (Script ext4_tests.sh)

a) Erzeugen eines leeren virtuellen Datenträgers in VirtualBox. vboxmanage createmedium disk--filename ext4.vmdk--size 10000 --format VMDK

b) Einhängen des virtuellen Datenträgers in die Generatormaschine. vboxmanage storageattach generator-lnx--storagectl\ ’SATA Controller’--port 2 --type hdd--medium ext4.vmdk

c) Starten der Generatormaschine. vagrant up generator_lnx

2. Auf der Generatormaschine (Script ext4_generate.sh)

a) Initialisieren des Datenträgers. parted-s/dev/sdb mklabel gpt

b) Erstellen der Partition. parted-s-a optimal/dev/sdb mkpart primary ext4 0% 100%

c) Erstellen des Dateisystems, und Zuweisung des benutzerdefinierten La- bels ext4part. mkfs-t ext4-L"ext4part"/dev/sdb1

d) Mounten des Dateisystems nach /media/hdd. mount/dev/sdb1/media/hdd

Damit ist ein schreibender Zugriff auf das Dateisystem möglich und die Operationen zum Erstellen der Dateisystemobjekte können durchgeführt werden.

Die Analyse folgt dem standardmäßigen Vorgehen.

43 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Beobachtungen bei der Testdurchführung, Bild 4.1:

Bild 4.1: Ergebnis der Analyse von Ext4

• Unvollständige Wiederherstellung gelöschter Dateien Von einer gelöschten Datei können nur die Metadaten wiederhergestellt wer- den. Die Abweichung der Accessed Zeit rührt von dem auf das Auslesen des Zeitstempels folgenden Löschvorgang her.

• Abweichende Byte-Order der Dateisystem ID Dem Dateisystem wird bei seiner Erstellung eine automatisch generierte, ein- deutige ID, eine sogenannte Universally unique dentifier (UUID)[45] zugewiesen Diese auf der Generatormaschine mit dem Tool lsblk ausgelesen. Bild 4.2 zeigt das Ergebnis. Bei der Analyse mit dem Befehl fsstat wird diese als Volume

Bild 4.2: UUID des Dateisystems beim Auslesen mit lsblk

ID ausgelesen, Bild 4.3 zeigt das Ergebnis: Bei genauer Betrachtung fällt auf

Bild 4.3: UUID des Dateisystems beim Auslesen mit fsstat

dass es sich um dieselben IDs handelt. Die Ausgabe von lsblk enthält lediglich

44 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

zusätzliche Bindestriche und erfolgt in umgekehrter Byte-Order. Die Ausgabe von lsblk scheint dabei formal korrekt zu sein, da sie z.B. durch den Online- UUID Validator von freecodeformat.com [46] als gültige UUID in der Version 4 erkannt wird, während die Ausgabe von fsstat zurückgewiesen wird.

Diesem Umstand wurde bei der Generierung Rechnung getragen und die Byte- Order entsprechend der Ausgabe von fsstat angepasst: lsblk-f/dev/sdb1| grep’sdb1’| awk’{print $4}’| tr-d"-"\ | fold-w2| tac| paste-sd’\0’-

Bewertung: Die Auswertung von Ext4 Dateisystemen erscheint stabil und die Ergebnisse sind von hoher Qualität.

4.2 NTFS

Es ist ebenfalls auf das Vorhandensein einer Partition angewiesen. Deshalb entspricht der Prozess der Erzeugung des Dateisystems im wesentlichen dem Vorgehen bei Ext4.

Da als Betriebssystem auf der Generatormaschine Windows installiert ist lässt sich für die Generierung kein bash Script einsetzen. Als Alternative wurden PoSh Scripte verwendet.

Nach dem Bereitstellen des Datenträgers wird die Generatormaschine gebootet und das Script ntfs_generate.ps1 führt die folgenden Schritte durch:

1. Initialisieren des Datenträgers Initialize-Disk-Number1-PartitionStyle gpt

2. Erstellen der Partition New-Partition-Disknumber1-UseMaximumsize-AssignDriveLetter

3. Erstellen des Dateisystems, und Zuweisung des benutzerdefinierten Labels „ntfspart“. Dieser Befehl weist dem Dateisystem zugleich einen Laufwerks- buchstaben zu, so dass Schreiboperationen auf dem Dateisystem möglich sind. Format-Volume-DriveLetterE-Filesystem NTFS‘ -NewFileSystemLabel"ntfspart"

45 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Beobachtungen bei der Testdurchführung, Bild4.4:

Bild 4.4: Ergebnis derAnalyse von NTFS

• Abweichendes Schema für Inodes NTFS verwendet intern keine Inodes in der Form eines Integer-Wertes als Zeiger auf die Metadatenstruktur. TSK generiert zwar einen entsprechenden Zeiger in der Form 40-128-3 und gibt diesen als „Inode“ zurück. Da es sich dabei um eine TSK spezifische Datenstruktur handelt, gibt es unter Win- dows kein Tool, welches diese Datenstruktur erstellen kann. Für die praktis- che Auswertung von Dateisystemdaten ist dieser Umstand bedeutungslos, da die Wiederherstellung von Dateien mittels icat mit diesen „NTFS Inodes“ problemlos funktioniert.

• Abweichendes Schema für Berechtigungen Die internen Berechtigungsstrukturen entsprechen ebenfalls nicht den unter Linux verwendeten traditionellen Unix Dateiberechtigungen. Windows ver- wendet stattdessen Access Control Lists (ACLs). Da keine Möglichkeit besteht diese eindeutig zu übersetzen gibt es bei der Eigenschaft mode ebenfalls eine Abweichung. Dateisystemberechtigungen für NTFS können über eine Analyse der $Secure Systemdatei ermittelt werden.[4, S. 322]

46 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

• Wiederherstellung gelöschter Dateien nicht möglich Die Wiederherstellung einer gelöschten Datei konnte nicht erfolgreich imple- mentiert werden.

Bewertung: Die Auswertung von NTFS Dateisystemen erscheint stabil und die Ergebnisse sind von guter Qualität. Es existieren grundlegende Unterschiede im Datenmodell von Windows/NTFS und von unixoiden Betriebssystemen, für die TSK ursprünglich entwickelt wurde, die nur teilweise durch TSK abgefangen werden.

4.3 ZFS

Das Vorgehen bei der Analyse mit diesem Fork von TSK weicht vom bisher bekan- nten Vorgehen ab. Es wird vorausgesetzt, dass die zu analysierende(n) Imagedatei(en) in einem Ordner für sich abgelegt werden. Dann wird das neu hinzugekommene Pro- gramm pls mit dem Ordnerpfad als Parameter aufgerufen. Dieses gibt die zentralen Informationen zum Dateisystem und den beteiligten Volumes aus, wie in Bild 4.5 dargestellt.

Bild 4.5: Ausgabe der zentralen Informationen von ZFS durch pls

Beobachtungen bei der Testdurchführung, Bild 4.6:

• Auswertung von .vmdk Datenträgern schlägt fehl Die Analyse von auf virtuellen Datenträgern (.vmdk Dateien) erstellten ZFS Dateisystemen schlug fehl. Das Problem konnte bislang nicht behoben werden. Es wird die in Bild 4.7 dargestellte Fehlermeldung ausgegeben.

Um trotzdem eine Analyse des Dateisystems durchführen zu können wurde das Dateisystem auf über Loopdevices gemounteten Imagedateien eingerichtet. Dies entspricht nach eigener Aussage auch der Vorgehensweise des Autors bei der Entwicklung der Software.

47 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Bild 4.6: Ergebnis der Analyse von ZFS

Bild 4.7: Fehlermeldung bei der Analyse virtueller ZFS Datenträger mit pls

Um das Dateisystem zu erstellen, führt das Script zfs_generate.sh folgende Schritte auf der Generatormaschine durch:

1. Mittels dd zwei Dateien mit Nullen beschrieben dd if=/dev/zero of=zfs_file1.dd count=19531250 2> /dev/null dd if=/dev/zero of=zfs_file2.dd count=19531250 2> /dev/null

2. Die Dateien als Loopdevices mounten losetup/dev/loop1 zfs_file1.dd losetup/dev/loop2 zfs_file2.dd

3. Den ZFS Pool mit benutzerdefiniertem Label „zfs-2dev-mirror“ erstellen. Dieser wird dabei automatisch gemounted. zpool create zfs-2dev-mirror mirror/dev/loop1\ /dev/loop2-m/media/hdd

Vor dem Herunterfahren des Systems muss das Dateisystem noch mit zpool export [Label] ausgehängt werden. Ansonsten können die Imagedateien wed- er erneut eingehängt noch analysiert werden.

48 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Wurde diese Vorgehensweise beachtet, konnten die erzeugten Imagedateien mit pls analysiert werden, wie bereits in Bild 4.5 dargestellt.

• Keine Ausgabe des Dateisystemtyps In der Ausgabe wird der Typ des gefundenen Dateisystems nicht angezeigt. Da mit derselben Software auch Btrfs Dateisysteme analysiert werden können, kann dies zu Verwirrung führen.

• Auslesen von Dateisysteminformationen mit fsstat unvollständig Für die weiterführende Analyse werden die entsprechenden TSK Befehle jew- eils mit dem Parameter -P und dem Ordnerpfad der Imagedateien in der Form fsstat -P [Ordnername] aufgerufen. Wie Bild 4.8 zeigt, wird dabei zwar ein Poolname und die entsprechende Transaction Group Number (TXG) angezeigt, es fehlen aber weitere Angaben zum Dateisystem.

Bild 4.8: Fehler beim Auslesen von ZFS Informationen mit fsstat

• Auslesen von Dateiinformationen mit fls schlägt fehl Die weiterführende Auswertung der erstellten ZFS Dateisysteme schlug fehlt. Es ist nicht gelungen, z.B. mit fls Dateiobjekte aus den Imagedateien wieder- herzustellen, wie Bild 4.9 zeigt.

Bild 4.9: Fehler beim Auslesen von ZFS Dateisystemobjekten mit fls

Bewertung: Eine Auswertung von ZFS Dateisystemen in der forensischen Praxis scheint zum jetzigen Stand nicht möglich zu sein. Da die Algorithmen zur Auswertung von ZFS in dem offen verfügbaren Quellcode enthalten sind, können die vorhandenen Prob- leme vermutlich beseitigt werden. Die Integration des vorliegenden Codes in die Hauptversion von TSK wäre ebenfalls ein lohnenswertes Projekt.

4.4 Btrfs

Da die Auswertung von Btrfs ebenfalls mit der bereits bei ZFS beschriebenen TSK Version erfolgt, wird die Generierung der Imagedateien analog zu dem dort beschriebe- nen Ablauf durchgeführt. Der Befehl zum Erstellen des Dateisystems, welches 2

49 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Blockdevices zu einem Raid1 Verbund zusammenfasst und mit dem Label „btrfs- 2dev-raid1“ versieht, lautet: mkfs.btrfs-L’btrfs-2dev-raid1’/dev/loop1/dev/loop2

Das Dateisystem wird anschliessend mit dem folgenden Befehl gemountet: mount/media/hdd/dev/loop1 Hier muss lediglich eines der Loopdevices angegeben werden. Der Btrfs Treiber sorgt für die korrekte Einbindung aller beteilgten Geräte des Pools.

Für das Auslesen des Created Zeitstempels der erzeugten Dateien in einem Btrfs Dateisystem konnte keine funktionierende Methode gefunden werden. Daher ist dieses Feld in der btrfssrc.json nicht gefüllt, wie in Bild 4.10 dargestellt.

Bild 4.10: Fehlender Created Zeitstempel bei Btrfs Generierung

Die Analyse folgt dem von ZFS bekannten Schema.

Beobachtungen bei der Testdurchführung, Bild 4.11:

50 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Bild 4.11: Testergebnis der Analyse von Btrfs

• Auswertung von .vmdk Datenträgern schlägt fehl Dies entspricht dem Verhalten bei ZFS. Entsprechend werden auch für die Analyse von Btrfs Loopdevices genutzt.

Bei der Analyse stellt der pls Befehl den Inhalt des Pools korrekt dar, wie Bild 4.12 zeigt.

Auch die weitere Analyse mit fsstat, fls und istat, sowie die Wiederher- stellung der Dateien mit icat funktionieren, Bild 4.13 zeigt exemplarisch die

51 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Bild 4.12: Analyse zentraler Informationen von Btrfs mit pls

Ausgabe von fsstat

Bild 4.13: Analyse von Btrfs mit fsstat

• Ausgabe im Body-File Format wird nicht unterstützt

52 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Beim Auslesen der Dateiinformationen mit fls fällt auf, dass hier die Option -m zur Ausgabe der Informationen im Body-File Format nicht funktioniert. Es wird lediglich die in Bild 4.14 gezeigte Ausgabe zurückgegeben. Damit kann der Pfad innerhalb des Dateisystems nicht ohne weiteres automatisch ermittelt werden. Für die Analyse der Metadaten wurde deshalb auf das Tool istat aus dem TSK zurückgegriffen.

Bild 4.14: Analyse von Btrfs Dateisystemobjekten mit fls

• Keine Ausgabe des Changed Zeitstempels und mode istat gibt in dieser Version nur die Created, Accessed und Modified Zeit- stempel zurück. Wie in Bild 4.15 ersichtlich fehlt die Ausgabe des Changed Zeitstempel, der eine Änderung der Inode protokolliert. Der mode, also die Informationen zu den Berechtigungen innerhalb des Dateisystems, fehlt eben- falls.

Bild 4.15: Analyse von Metadaten in Btrfs mit istat

Bild 4.16 zeigt die entsprechende Ausgabe des istat Befehls aus dem TSK 4.9.0 bei der Analyse eines Ext4 Dateisystems:

53 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Bild 4.16: Analyse von Metadaten in Ext4 mit istat

• Die Wiederherstellung von Dateiinhalten mittels icat erfolgt korrekt und ohne Auffälligkeiten.

• Wiederherstellung gelöschter Dateien nicht möglich Die Wiederherstellung einer gelöschten Datei konnte nicht erfolgreich imple- mentiert werden.

Bewertung: Das Testergebnis für die Analyse von Btrfs weist wie in Bild 4.11 dargestellt durch die beschriebenen Probleme einige fehlgeschlagenen Assertions auf. Gleichwohl funk- tioniert der Analyseprozess insgesamt, so dass eine forensische Auswertung prinzip- iell möglich ist. Das größte Problem dürfte die Unsicherheit sein, ob sich das Image grundsätzlich mit pls öffnen lässt oder die beobachtete Fehlermeldung auftritt, da in diesem Fall keine Analyse möglich ist.

4.5 ReFS

Die Analyse von ReFS folgt weitestgehend dem Vorgehen bei der Analyse von NTFS. Es wird lediglich bei der Erstellung des Dateisystems der Typ ReFS angegeben

Dazu enthält das Script refs_generate.ps1, welches auf der virtuellen Maschine generator-win ausgeführt wird, die Zeile:

54 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Format-Volume-DriveLetter $driveLetter-Filesystem ReFS‘ -NewFileSystemLabel $fsLabel> Out-Null

Für die erstellten Dateien kann auf der Generatormaschine kein Changed Zeitstem- pel ermittelt werden, da das dafür benötigte Tool fsutil keine ReFS Dateisysteme auslesen kann, wie Bild 4.17 zeigt.

Bild 4.17: Ausgabe von fsutil auf ReFS Dateisystem

Die Analyse folgt dem gängigen Schema. Es sind für diesen Fork des TSK keine abweichenden Befehlsoptionen dokumentiert.

Beobachtungen bei der Testdurchführung, Bild 4.18:

Bild 4.18: Testergebnis der Analyse von ReFS

55 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

• Keine Ausgabe der UUID des Dateisystems Das Programm fsstat gibt, wie in Bild 4.19 dargestellt keine UUID des Dateisystems aus. Es wird lediglich eine Volume Serial Number und eine Volume Signature ausgegeben. Es konnte keine Technik ermittelt werden, diese auf der Generatormaschine auszulesen.

Bild 4.19: Ausgabe von fsstat bei der Analyse von ReFS

• Unvollständige Ausgabe der Inode im Body-File Format Bei der Ausgabe von fls im Body-File Format fällt auf, dass nicht die voll- ständige Inode angegeben wird, so dass diese wie in Bild 4.20 dargestellt vor der Wiederherstellung des Dateiinhalts manuell mit einem fls Befehl ohne die Option -m ermittelt werden muss.

56 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Bild 4.20: Ausgabe von fls mit und ohne -m bei der Analyse von ReFS

Dies wird mit den folgenden Befehlen umgesetzt: inode=$(fls-p-r-o"$firstUnit""$imageFile"| grep $name |\ cut-d""-f2| grep-oP’.*(?=:)’) icat-o"$firstUnit""$imageFile""$inode">\ "restoredir${filePath}"

• Wiederherstellung gelöschter Dateien nicht möglich Die Wiederherstellung einer gelöschten Datei konnte nicht erfolgreich imple- mentiert werden.

Bewertung: Aufgrund des beschriebenen Verhaltens sind auch im Testergebnis von ReFS einige fehlgeschlagenen Assertions enthalten, wie in Bild 4.18 zu sehen. Diese sollten je- doch in der Praxis keine schwerwiegenden Auswirkungen haben, so dass sich ReFS Dateisysteme mit dieser Variante des Sleuthkit gut auswerten lassen.

4.6 APFS

Da die Auswertung von APFS auf einer physischen Maschine erfolgt, besteht keine Möglichkeit eine .vmdk Datei als virtuelle Festplatte einzubinden. Für macOS ex- istiert jedoch mit dem Apple Disk Image Format ein eigenständiges Dateiformat für Speicherabbilder, die von TSK in der Version 4.9.0 direkt analysiert werden können. Die Dateien haben die Endung .dmg.

57 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Dementsprechend wird mit dem Apple Dienstprogramm hdiutil zunächst auf der Generatormaschine eine .dmg Datei erstellt, diese mit dem APFS Dateisystem for- matiert und gemountet. Nachdem die Dateisystemobjekte generiert und ausgewertet sind wird das Dateisystem ausgehängt und die Datei per scp Befehl in den data Ordner auf dem Host kopiert, auf den die Analysemaschine zugreifen kann.

Dies wird wie folgt umgesetzt:

1. Erstellen der .dmg Datei mit dem Label apfsimg und Formatierung mit dem APFS Dateisystem hdiutil create-megabytes 1000 -layout GPTSPUD-fs apfs\ -volname"apfsimg" apfs.dmg

2. Mounten des Dateisystems hdiutil attach apfs.dmg Dabei werden mehrere virtuelle Gerätedateien angelegt und das Dateisystem in den Pfad /Volumes/[Dateisystem-Label] gemountet. Bild 4.21 zeigt die Ausgabe des Befehls.

Bild 4.21: Mounten des APFS Dateisystems mit hdiutil

3. Erstellen und Auswerten der Dateisystemobjekte.

4. Unmounten des Dateisystems. Hier muss die Gerätedatei angegeben werden auf die der Mountpfad zeigt. umount/dev/disk3s1

5. Transfer der .dmg Datei, dieser Befehl wird auf dem Host ausgeführt. scp"user@${genMachineIP}:/Users/user/apfsimg/apfs.dmg"\ "${baseDir}/data"

Die Analyse des Dateisystems erfolgt mit TSK in der Version 4.9.0.

Bild 4.22 zeigt, dass mmls die Partiton als disk image erkennt.

Um das APFS Dateisystem analysieren zu können, muss zunächst die Blocknum- mer des Superblocks, die APSB Block Number ermittelt werden. Dazu wird das zu

58 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Bild 4.22: Analyse eines APFS Images mit mmls diesem Zweck neu entwickelte Programm pstat mit dem Offset der entsprechenden Partition aufgerufen, wie in Bild 4.23 dargestellt.

59 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Bild 4.23: Ermitteln der APSB Block Nummer mittels pstat

Diese Nummer muss bei allen weiterführenden Befehlen mit der Option -B [Nr] übergeben werden, damit TSK den Inhalt des Dateisystems korrekt auswerten kann. Bild 4.24 zeigt als Beispiel das Auslesen von Dateisystemobjekten mit fls.

60 Kapitel 4. Durchführung der Tests und Bewertung der Ergebnisse

Bild 4.24: Auslesen von APFS Dateisystemobjekten mit fls

Die weitere Vorgehensweise bei der Analyse erfolgt nach Standard.

Beobachtungen bei der Testdurchführung, Bild 4.25:

Bild 4.25: Testergebnis der Analyse von APFS

• Wiederherstellung gelöschter Dateien nicht möglich Die Wiederherstellung einer gelöschten Datei konnte nicht erfolgreich imple- mentiert werden.

Bewertung: Die Auswertung von APFS Dateisystemen erfolgt weitgehend vollständig und ohne Fehler. Damit sollten sich APFS Dateisystem in der Praxis gut auswerten lassen.

61 Kapitel 5. Fazit

5 Fazit

Die erstellte Testumgebung ermöglicht es, die Analysen in einer vergleichbaren Umge- bung auszuführen, und kann als Basis für weitere Tests dienen. Die automatische Ausführung einer Vielzahl von Analysen bietet eine Möglichkeit die geforderten Fehlerraten zu ermitteln.

Im Nachhinein betrachtet ist die Struktur noch nicht optimal, um z.B. verschiedene Hardwarekonfigurationen desselben Dateisystems zu testen, z.B. Btrfs auf einer einzelnen Platte, als Raid1 und als Raid5 Verbund.

Die neuartigen Dateisysteme bieten noch viele Features, wie z.B. Snapshots oder Verschlüsselung, die in dieser Arbeit noch nicht betrachtet wurden. Hier bestehen noch vielfältige Entwicklungsmöglichkeiten.

Die Erweiterung von TSK um ein weiteres Dateisystem ist eine anspruchsvolle Aufgabe. Da es sich um Open Source Software handelt findet die Entwicklung entsprechend des "Basar"Modells [47] unkoordiniert bzw. selbstorganisiert statt. Da- her ergeben sich viele verschiedene Versionen, mit unterschiedlichen Reifegraden und Bedienkonzepten. Diese Komplexität erscheint als ein Hinderniss für den foren- sischen Praktiker, der für seine Arbeit auf die Unterstützung durch entsprechend einfach zu bedienende und zuverlässige Werkzeuge angewiesen ist.

Eine Zusammenfassung der Ergebnisse zeigt Bild 5.1

62 Kapitel 5. Fazit

Tests Ext4 NTFS ZFS Btrfs ReFS APFS Partition OK OK n.v. n.v. OK OK Dateisystem OK OK type type id OK Dateien: Länge 0 OK inode not found filepath inode OK mode mode mode change time change time creation time Binärdaten OK inode not found filepath inode OK mode mode mode change time change time creation time Text OK inode not found filepath inode OK mode mode mode change time change time creation time Unterordner OK inode not found filepath inode OK mode mode mode change time change time creation time Datei in OK inode not found filepath inode OK Unterordner mode mode mode change time change time creation time gelöscht filepath not found not found not found not found not found size sha256 Bemerkungen Referenz 1 Referenz 1 lediglich Auswertung von Auswertung nur auf per Abweichendes Inode kein poolbasiertes Da- kein poolbasiertes Da- per Loopdevice gemoun- Loopdevice gemounte- Konstrukt, daher keine teisystem. teisystem. teten RAW Images mög- ten RAW Images mög- Beeinträchtigung. lich, andere Datenträger lich, andere Datenträger Abweichendes Inode schlagen fehl schlagen fehl Konstrukt, daher keine Change Time im Datei- Beeinträchtigung. system nicht implemen- tiert

Bild 5.1: Tabelle der Auswertungsergebnisse

Die Implementierungen für APFS und ReFS zeigen hierbei gute Ergebnisse, während Btrfs und insbesondere ZFS noch nicht die nötige Reife für den Einsatz in der Praxis haben. Dies resultiert insbesondere aus den Schwierigkeit beim Öffnen von Imagefiles die nicht unter Laborbedingungen entstanden sind.

63 Literaturverzeichnis

Literaturverzeichnis

[1] Tenzer, F.: Marktanteile der führenden Betriebssysteme weltweit von Januar 2009 bis Januar 2020. https:// de.statista.com/statistik/daten/studie/157902/umfrage/ marktanteil-der-genutzten-betriebssysteme-weltweit-seit-2009/. Version: 2019, Abruf: 13. April 2020

[2] Rostalski, Georg Freund, F.: Strafrecht Allgemeiner Teil. Springer-Verlag, 2019. – ISBN 978–3–662–59030–0

[3] Roll, Rolf Ackermann, Horst Clages, H.: Handbuch der Kriminalistik. Richard Boorberg Verlag, 2019. – ISBN 978–3–415–06025–8

[4] Carrier, Brian: File System Forensic Analysis. Pearson Education, Inc., 2005. – ISBN 978–0–32–126817–2

[5] Neumann, R.C. Daley, P.: A General-Purpose File System For Secondary Storage. https://www.multicians.org/fjcc4.html. Version: 1965, Abruf: 16. August 2020

[6] Freiling, Andreas Dewald, Felix C.: Forensische Informatik. Felix C. Freiling, 2015. – ISBN 978–3–842–126817–2

[7] Lampertz, Jan-Niclas Hilgert, M.: pcapFS – Mounting Network Data. https://github.com/fkie-cad/pcapFS#pcapfs--mounting-network-data. Version: 2018, Abruf: 16. August 2020

[8] Yoongu, Jamie Liu , Ben Jaiyen, Kim: An Experimental Study of Da- ta Retention Behavior in Modern DRAM Devices: Implications for Reten- tion Time Profiling Mechanisms. In: SIGARCH Comput. Archit. News 41 (2013), Nr. 3, 60–71. http://dx.doi.org/10.1145/2508148.2485928. – DOI 10.1145/2508148.2485928. – ISSN 0163–5964

[9] Eilam, Eldad: Reversing: Secrets of Reverse Engineering. Wiley Publishin Inc., 2005. – ISBN 978–0–7645–7481–8

64 Literaturverzeichnis

[10] Carrier, Brian: Open Source Digital Forensics Tools The Legal Argument 1. (2009), 04

[11] Carvey, Cory Altheide, H.: Digital Forensics with Open Source Tools. Syn- gress, 2011. – ISBN 978–1–59749–586–8

[12] Jan-Nicklas Hilgert, Lambertz, Martin: Extending The Sleuth Kit and its underlying model for pooled storage. In: [54], S. 76 – 85. – Supplement

[13] Open Text Corporation (Hrsg.): EnCase® Forensic USER GUIDE Version 8.07. Waterloo, Ontario, Canada: Open Text Corporation, 2018

[14] Bone, Brendan: What File Systems Do AccessData Products Sup- port? https://support.accessdata.com/hc/en-us/articles/ 206381588-What-file-systems-do-AccessData-products-support-. Version: 2018, Abruf: 13. April 2020

[15] Forensics, X-Ways: Integrierte Software für Computerforensik. X-Ways Soft- ware Technology AG, Version 19.9. http://www.x-ways.net/forensics/ index-d.html. Version: 2020, Abruf: 13. April 2020

[16] Blackbagtech: MacQuisition Compatibility and Require- ments. https://www.blackbagtech.com/products/macquisition/ macquisition-compatibility-requirements/. Version: 2020, Abruf: 16. August 2020

[17] Project, OpenZFS: Welcome to OpenZFS. https://openzfs.org/wiki/ Main_Page. Version: 2020, Abruf: 16. August 2020

[18] Hilgert, Jan-Nicklas: fkie-cad/sleuthkit : forked from sleuthkit/sleuthkit. https://github.com/fkie-cad/sleuthkit. Version: 2018, Abruf: 13. April 2020

[19] Project, Btrfs: Btrfs Wiki Main Page. https://btrfs.wiki.kernel.org/ index.php/Main_Page. Version: 2020, Abruf: 16. August 2020

[20] Yang, Jan-Nicklas Hilgert, Martin Lambertz, S.: Forensic analysis of multiple device BTRFS configurations using The Sleuth Kit. In: [55], S. 21 – 29. – Supplement

[21] Dewald, Paul Prade,Tobias Groß, A.: Forensic Analysis of the Resilient File System (ReFS) Version 3.4. Erlangen-Nurnberg: Friedrich-Alexander- Universitat, Dept. of Computer Science, Technical Reports, 2019

65 Literaturverzeichnis

[22] Prade, Paul: ReFS sleuthkit implementation. https://faui1-gitlab. cs.fau.de/paul.prade/refs-sleuthkit-implementation. Version: 2019, Abruf: 16. August 2020

[23] Roberts, Joe Sylve, Scott J.: sleuthkit-APFS : forked from sleuthkit/sleuthkit. https://github.com/blackbagtech/sleuthkit-APFS. Version: 2019, Abruf: 13. April 2020

[24] STATES, SUPREME COURT OF THE U.: Daubert v. Merrell Dow Phar- maceuticals (92-102), 509 U.S. 579 (1993). https://www.law.cornell.edu/ supct/html/92-102.ZO.html. Version: 1993, Abruf: 16. August 2020

[25] Images, Digital Forensics Tool T.: Digital Forensics Tool Testing Images. http://dftt.sourceforge.net/. Version: 2010, Abruf: 19. August 2020

[26] Carrier, Brian: Body file. http://wiki.sleuthkit.org/index.php?title= Body_file. Version: 2009, Abruf: 19. August 2020

[27] Long, Scott Chacon., J.: git–distributed-even-if-your-workspace-isnt. https: //git-scm.com/. Version: 2020, Abruf: 19. August 2020

[28] Titus, Peter: ptitus/bt. https://github.com/ptitus/bt.git. Version: 2020, Abruf: 19. August 2020

[29] Corporation, Oracle: VirtualBox. https://www.virtualbox.org. Version: 2020, Abruf: 20. August 2020

[30] HashiCorp: HashiCorp Packer. https://www.packer.io. Version: 2020, Abruf: 20. August 2020

[31] HashiCorp: HashiCorp Vagrant. https://www.vagrantup.com. Version: 2020, Abruf: 20. August 2020

[32] Puppet: Welcome to Bolt. https://puppet.com/docs/bolt/latest/bolt. html. Version: 2020, Abruf: 20. August 2020

[33] Ramey, Chet: The GNU Bourne-Again SHell. https://tiswww.case.edu/ php/chet/bash/bashtop.html. Version: 2020, Abruf: 20. August 2020

[34] Corporation, Microsoft: Powershell Dokumentation. https://docs. microsoft.com/de-de/powershell. Version: 2020, Abruf: 20. August 2020

[35] json.org: Einführung in JSON. https://www.json.org/json-de.html. Version: 2020, Abruf: 20. August 2020

66 Literaturverzeichnis

[36] Langford, William: jq is a lightweight and flexible command-line JSON pro- cessor. https://stedolan.github.io/jq. Version: 2020, Abruf: 20. August 2020

[37] Ward, Kate: kward/shunit2. https://github.com/kward/shunit2. Version: 2020, Abruf: 20. Augustl 2020

[38] Hogan, Thomas A. Limoncelli, Christina J.: The Practice of System and Network Administration, DevOps and Other Best Practices for Enterprise IT. Bd. 1. 3. Addison-Wesley, 2017. – ISBN 978–0–321–91916–8

[39] HashiCorp: HashiCorp Vagrant Cloud. https://app.vagrantup.com/boxes. Version: 2020, Abruf: 20. August 2020

[40] Scherer, Stefan: StefanScherer/packer-windows. https://github.com/ StefanScherer/packer-windows. Version: 2020, Abruf: 20. August 2020

[41] Inc., Apple: macOS Catalina. https://www.apple.com/de/macos/ catalina/. Version: 2020, Abruf: 21. August 2020

[42] Howell, Max: Homebrew - Der fehlende Paketmanager für macOS. https: //brew.sh/index_de. Version: 2020, Abruf: 21. August 2020

[43] IEEE ; Group, The O.: A.4.16 Seconds Since the Epoch. https: //pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04. html#tag_21_04_16. Version: 2018, Abruf: 22. August 2020

[44] Titus, Peter: Testdurchführung Ext4 Dateisystem. https://nextcloud03. webo.hosting/s/5gpgd4m9GtDtGBi. Version: 2020, Abruf: 22. August 2020

[45] (ITU), International Telecommunication U.: Universally Unique Identifiers (UUIDs). https://www.itu.int/en/ITU-T/asn1/Pages/UUID/uuids.aspx. Version: 2020, Abruf: 22. August 2020

[46] Frecodefromat.com: UUID / GUID Validator. https://www. freecodeformat.com/validate-uuid-guid.php. Version: 2020, Abruf: 22. August 2020

[47] Raymond, Eric S.: The Cathedral and the Bazaar. 3. O’Reilly, 2001. – ISBN 978–0–596–00108–8

[48] BSI - Bundesamt für Sicherheit in der Informationstechnik (Hrsg.): Leitfaden „IT-Forensik“. Bonn: BSI - Bundesamt für Sicherheit in der Infor- mationstechnik, 2011

67 Literaturverzeichnis

[49] Microsoft: NTFS Technical Reference. https://docs.microsoft. com/en-us/previous-versions/windows/it-pro/windows-server-2003/ cc758691(v=ws.10). Version: 2009, Abruf: 16. August 2020

[50] Ray, Kenneth: SANS Forensics Whitepapers: Putting it all together through Automation. https://digital-forensics.sans.org/community/papers/ gcfe/putting-automation_4438. Version: 2019, Abruf: 13. April 2020

[51] Carrier, Brian: The Sleuth Kit ® (TSK). https://github.com/sleuthkit/ sleuthkit. Version: 2020, Abruf: 13. April 2020

[52] Venema, Dan Farmer, W.: The Coroner’s Toolkit (TCT) ). http://www. porcupine.org/forensics/tct.html. Version: 2009, Abruf: 22. August 2020

[53] Inc., Wikimedia F.: NTFS. https://de.wikipedia.org/wiki/NTFS. Version: 2020, Abruf: 22. August 2020

[54] Casey, Eoghan (Hrsg.): Digital Investigation. Bd. 22. Elsevier Ltd., 2017 . – Supplement

[55] Casey, Eoghan (Hrsg.): Digital Investigation. Bd. 26. Elsevier Ltd., 2018 . – Supplement

68 Abbildungsverzeichnis

Abbildungsverzeichnis

1.1 Ordnungsschema eines Dateisystems...... 7 1.2 Unterteilung einer Festplatte in Partitionen und Volumes [4, S. 71]..8 1.3 Netzwerkprotokolle als Ordnerstruktur[7]...... 9 1.4 Inhalt der Datei /etc/fstab einer Ubuntu 18.04 Installation..... 11 1.5 Standard Prozess der Datenträgeranalyse[4, S. 12]...... 12 1.6 Ein Dateisystem belegt mehrere Volumes...... 14 1.7 Mehrere Dateisysteme belegen ein Volume...... 14 1.8 Erweiterter Prozess der Analyse poolbasierter Dateisysteme[12, S. 77] 15

3.1 Struktur des Projektordners...... 26 3.2 Ablauf des Testprozesses...... 27 3.3 Struktur der Packer Umgebung...... 29 3.4 Ergebnis der APFS Generierung als Json Datei...... 36 3.5 Auslesen von Partitionsinformationen mit mmls ...... 37 3.7 Mit fls ausgelesene Dateiinformationen...... 37 3.6 Auslesen von Dateisysteminformationen mit fsstat ...... 38 3.8 Wiederherstellung von Dateiinhalten mit icat ...... 38 3.9 Generieren seines Sha256 Hashwertes...... 38 3.10 Anfangssequenz einer apfstsk.json Datei...... 39 3.11 Auslesen der Eigenschaft type.fs aus einer Json Datei...... 40 3.12 Testfunktionfür die Eigenschaft fs.type ...... 40 3.13 Auslassen weiterer Prüfungen mittels startSkipping ...... 41 3.14 Ergebnis einer Prüfung mit dem shunit2 Framework...... 42

4.1 Ergebnis der Analyse von Ext4...... 44 4.2 UUID des Dateisystems beim Auslesen mit lsblk ...... 44 4.3 UUID des Dateisystems beim Auslesen mit fsstat ...... 44 4.4 Ergebnis derAnalyse von NTFS...... 46 4.5 Ausgabe der zentralen Informationen von ZFS durch pls ...... 47 4.6 Ergebnis der Analyse von ZFS...... 48 4.7 Fehlermeldung bei der Analyse virtueller ZFS Datenträger mit pls . 48 4.8 Fehler beim Auslesen von ZFS Informationen mit fsstat ...... 49 4.9 Fehler beim Auslesen von ZFS Dateisystemobjekten mit fls ..... 49 4.10 Fehlender Created Zeitstempel bei Btrfs Generierung...... 50 4.11 Testergebnis der Analyse von Btrfs...... 51 4.12 Analyse zentraler Informationen von Btrfs mit pls ...... 52 4.13 Analyse von Btrfs mit fsstat ...... 52 4.14 Analyse von Btrfs Dateisystemobjekten mit fls ...... 53 4.15 Analyse von Metadaten in Btrfs mit istat ...... 53

69 Abbildungsverzeichnis

4.16 Analyse von Metadaten in Ext4 mit istat ...... 54 4.17 Ausgabe von fsutil auf ReFS Dateisystem...... 55 4.18 Testergebnis der Analyse von ReFS...... 55 4.19 Ausgabe von fsstat bei der Analyse von ReFS...... 56 4.20 Ausgabe von fls mit und ohne -m bei der Analyse von ReFS..... 57 4.21 Mounten des APFS Dateisystems mit hdiutil ...... 58 4.22 Analyse eines APFS Images mit mmls ...... 59 4.23 Ermitteln der APSB Block Nummer mittels pstat ...... 60 4.24 Auslesen von APFS Dateisystemobjekten mit fls ...... 61 4.25 Testergebnis der Analyse von APFS...... 61

5.1 Tabelle der Auswertungsergebnisse...... 63

70 Listings

Listings

3.1 sleuthkit-49.sh...... 32 3.2 changed-win...... 35

71 Tabellenverzeichnis

Tabellenverzeichnis

3.1 Übersicht über die verwendete Software...... 28 3.2 Übersicht über die erstellten Generatormaschinen...... 30 3.3 Übersicht über die erstellten Analysemaschinen...... 31

72 Selbstständigkeitserklärung

Selbstständigkeitserklärung

Hiermit erkläre ich, dass ich die hier vorliegende Arbeit selbstständig, ohne uner- laubte fremde Hilfe und nur unter Verwendung der aufgeführten Hilfsmittel ange- fertigt habe.

Ort, Datum Unterschrift

73