Aufbereitung Besonderer Speicherkonfigurationen Als Analysefähiges Material (RAID, LVM, WSS, Verschlüsselung)

Hochschule Wismar
University of Applied Sciences

Technology, Business and Design
Fakultät für Ingenieurwissenschaften, Bereich EuI
Projektarbeit
Aufbereitung besonderer Speicherkonfigurationen als analysefähiges

Material (RAID, LVM, WSS, Verschlüsselung)
Eingereicht am: 6. Juli 2019
von: Melanie Wetzig

Sven Lötgering
Tom Gertenbach
Stefan Depping
Inhaltsverzeichnis
Inhaltsverzeichnis
1 Vorüberlegungen 4
1.1 Motivation und Zielstellung . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Anforderung an den Ermittlungsprozess . . . . . . . . . . . . . . . . . 4
1.3 Einordnung in Ermittlungsprozess . . . . . . . . . . . . . . . . . . . . 6
1.4 Write-Blocker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1 Rohdatenformat (RAW) . . . . . . . . . . . . . . . . . . . . . 7
1.5.2 Expert Witness Format (EWF) . . . . . . . . . . . . . . . . . 8
1.5.3 Advanced Forensic Format (AFF) . . . . . . . . . . . . . . . . 8
1.5.4 Xmount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Rechtliche Betrachtung 9
2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Private Ermittlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Behördliche Ermittlungen . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Speichermedien 13
3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Magnetspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Speicherung auf einer HDD . . . . . . . . . . . . . . . . . . . 14
3.2.2 Löschen von Daten auf einer HDD . . . . . . . . . . . . . . . 15
3.2.3 Forensische Relevanz . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Flash-Speicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1 Speicherung auf einer Solid-State-Drive (SSD) . . . . . . . . . 16
3.3.2 Löschen von Daten auf einer SSD . . . . . . . . . . . . . . . . 16
3.3.3 Forensische Relevanz . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Analyse eines Datenträgerverbundes 19

4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Hardware-RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 Schritt 1: Einbinden der Abbilder . . . . . . . . . . . . . . . . 23
4.2.2 Schritt 2: Öffnen der Abbilder in R-Studio . . . . . . . . . . . 23
4.2.3 Schritt 3: Modellierung des RAID-Layouts . . . . . . . . . . . 24
4.3 Software Lösungen unter Linux . . . . . . . . . . . . . . . . . . . . . 31
4.3.1 Software-RAID . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.2 Logical Volume Manager (LVM) . . . . . . . . . . . . . . . . . 36
2
Inhaltsverzeichnis
4.4 Software Lösungen unter Windows . . . . . . . . . . . . . . . . . . . 40

4.4.1 Logical Disk Manager (LDM) . . . . . . . . . . . . . . . . . . 40
4.4.2 Windows Storage Spaces (WSS) . . . . . . . . . . . . . . . . . 40
5 Verschlüsselte Datenträger 46
5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Festplattenverschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Verschlüsselungstools . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.1 Microsoft BitLocker . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.2 FileVault 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3.3 Linux Unified Key Setup (LUKS)/ dm-crypt . . . . . . . . . . 54
5.3.4 VeraCrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6 Fazit 63
Literaturverzeichnis 65
Abbildungsverzeichnis 69
Abkürzungsverzeichnis 71
Selbstständigkeitserklärung 73
3
Kapitel 1. Vorüberlegungen
1 Vorüberlegungen
1.1 Motivation und Zielstellung
Der Ingenieursstudiengang IT-Forensik legt in seiner technischen Ausrichtung

besonderen Wert auf das Erlangen qualitativ hochwertiger Fähigkeiten zur Analyse
digitaler Spuren. Wie diese Spuren aus kriminaltaktischer Sicht zu bewerten sind,
ist ebenfalls Teil des Lehrplans. Nun soll diese Projektarbeit die Brücke von der
Erhebung analoger Spuren, zur Erhebung und Sicherung digitaler Spuren bilden.
Hierbei wird einleitend die Einordnung im Ermittlungsprozess beschrieben, anschlie-
ßend werden die rechtlichen sowie organisatorischen Grundlagen kurz erläutert. Im
technischen Schwerpunkt der Projektarbeit steht die Datenerhebung von Massen-
datenspeichern. Besonderes Augenmerk wird auf physikalische Speichermethoden,
Speicherverbund verteilter Datenträger und Kryptographie gelegt. Die Themen
werden unter dem Gesichtspunkt der Post-Mortem-Analyse durchgeführt, sodass
eine Betrachtung von aktiven Systemen nicht Gegenstand dieser Arbeit ist. Auf die
Datenerhebung via Netzwerk wird ebenfalls nicht eingegangen.
1.2 Anforderung an den Ermittlungsprozess
Nach Geschonneck, Computer Forensik [1, S. 66–67] gibt es sechs Grundsätze, die bei
einer Datenerhebung und Auswertung permanent berücksichtigt werden sollten
Akzeptanz
Damit die Skepsis gegenüber der gewonnenen Erkenntnisse minimiert wird, soll-
ten Methoden, Dateiformate und Softwarelösungen verwendet werden, die in der
Fachwelt als sicheres forensisches Verfahren anerkannt sind. Erkenntnisse die mit
Hilfe neuer unkonventioneller Hilfsmittel erlangt wurden, können einfacher in Fra-
ge gestellt werden, als Welche die durch anerkannten Methoden herausgearbeitet
wurden.
4
Glaubwürdigkeit
Die angewendeten Methoden müssen für Dritte nachvollziehbar sein. Der Ermittler
sollte, die Verarbeitungsschritte von Beginn bis zum Abschluss verstehen und erör-
tern können. Je komplexer die Werkzeuge werden, desto wichtiger ist das Verständnis
der Funktionalität.
Wiederholbarkeit
Jedes Ergebnis und Zwischenergebnis muss, bei gleicher Herangehensweisen und

denselben Bedingungen, reproduzierbar sein.
Integrität
Es ist sicherzustellen, dass die gesammelten Spuren unverändert sind und bleiben.
Ist eine Veränderung einer Arbeitskopie notwendig, muss dies begründet und doku-
mentiert werden. Das Original darf nicht verändert werden. Dies ist im gesamten
Ermittlungsprozess zu gewährleisten.
Kausalität
Die Beweisspuren müssen entsprechend nachvollziehbar aufgearbeitet werden, dass

Ursache und Auswirkung direkt voneinander abhängig sind. Indizien müssen als
solche angegeben werden. Vermutungen dürfen nicht als Teil einer Beweiskette fun-
gieren.
Dokumentation
Jeder Schritt im Ablauf der Beweissichtung, Beweiserhebung und der Beweisbewer-

tung muss exakt dokumentiert werden.
5
1.3 Einordnung in Ermittlungsprozess
Eine Ermittlung im Zusammenhang mit Computerkriminalität kann mit Hilfe des

Secure-Analyse-Present-Modell abgebildet werden. Nach diesem Modell beinhaltet
die Secure-Phase die Sicherung der vorhandenen Spuren. Die Analyse-Phase
beschäftigt sich mit der Auswertung der gesammelten Spuren. Abschließend werden
in der Present-Phase die gewonnenen Erkenntnisse in Form von Beweisen und
Kausalitätszusammenhängen in einem Gutachten festgehalten.
Die Ausprägung und Form der einzelnen Phasen ist je nach individuellem Fall un-
terschiedlich. Ist eine Live-Analyse vorgesehen verschwimmen die Grenzen zwischen
Secure- und Analyse-Phase. Hier werden Spuren gesichert, die sogleich ausgewer-
tet und interpretiert werden, da sie entweder selbst flüchtig sind oder auf weitere
flüchtige Daten verweisen. Sollte eine Straftat nach § 303a Strafgesetzbuch (StGB)
- Datenveränderung oder § 303b StGB - Computersabotage gerade geschehen oder
ist sie vor kurzer Zeit geschehen, ist die Sicherung von flüchtigen Daten ein funda-
mentaler Ermittlungsschritt.
Auf die Life-Analyse soll hier nicht weiter eingegangen werden. Diese Arbeit kon-
zentriert sich auf die Datenerhebung der Secure-Phase für eine Offline-Analyse.
1.4 Write-Blocker
Für eine forensische Datenduplizierung ist es wichtig sicherzustellen, dass weder

Personen noch Anwendungen die Originaldateien verändern. Um eine solche Ver-
änderung zu verhindern, müssen alle schreibenden Zugriffe unterbunden werden.
Dieses erfolgt durch sogenannte Write-Blocker. Es gibt zwei Varianten von Write-
Blockern. Hardware-Writeblocker, welche sicher und kostenintensiver sind sowie
Software-Writeblocker, welche Schreibbefehle des Treibers abfangen.
Bei einem Hardware-Writeblocker handelt es sich, wie der Name bereits vermu-
ten lässt, um ein Gerät, welches die Kommunikation zwischen dem Computer und
dem zu untersuchendem Medium kontrolliert und überwacht. Alle Zugriffe, egal ob
Lese- oder Schreibzugriffe, werden durch den Hardware-Writeblocker überprüft und
abgefangen. Handelt es sich um einen Schreibzugriff, so wird dieser blockiert und
somit nicht an das Speichermedium weitergegeben. Handelt es sich um einen lesen-
den Zugriff, so wird dieser an das Speichermedium weitergegeben. Dadurch wird ein
Schreiben auf dem Speichermedium verhindert und die Daten sind somit weiterhin
6
im Originalzustand vorhanden. Hardware-Writeblocker werden von vielen handels-

üblichen Schnittstellen (z. B. SATA, USB) unterstützt.
Bei einem Software-Writeblocker muss eine Anpassung des für die Analyse genutz-
ten Computers erfolgen. Dieses kann durch unterschiedliche Wege erfolgen. Zum
einen gibt es Programme (z. B. USB Write Blocker for ALL Windows, für Win-
dows Betriebssysteme), welche bestimmte Einträge in der Windows-Registry ver-
ändern und hierdurch einen Schreibschutz hervorrufen. Diese Anpassung kann man
auch entsprechend manuell durchführen, solche Programme vereinfachen diese An-
passung jedoch. Zum Zweiten gibt es auch die Möglichkeit, bestimmte Treiber des
Systems durch spezielle angepasste Treiber zu ersetzen. Hierdurch wird nicht nur
ein Schreibschutz gesetzt, sondern aktiv in die Kommunikation zwischen Computer
und Speichermedium eingegriffen (z. B. das Tool EnCase, welches diese Möglichkeit
unterstützt). Eine dritte Methode ist die Manipulation des BIOS. Im BIOS wird der
Interrupt-Befehl INT13h verändert, welcher unter anderem für die Steuerung der
Schreibzugriffe auf die Festplatte zuständig ist.
1.5 Software
Neben den verbreiteten großen Softwarelösungen zur Imageerstellung, gibt es eine

Vielzahl kleiner Open Source Programmen. Beispielsweise das in Linux integrierte
dd oder weitere Programme wie dcfldd, dc3dd und ewfacquire. Die meisten Pro-
gramme zur Erstellung eines Datenträgerimages erfüllen ihre Aufgabe. Eine dieser
wichtigen Aufgaben ist es nicht lesbare Sektoren mit einer „0“ zu speichern und zu
dokumentieren. Differenzierter ist die Wahl des entsprechenden Dateiformats. Als
geeigneter Standard für forensische Duplikate haben sich Rohdatenformat (RAW)
Expert Witness Format (EWF) und Advanced Forensic Format (AFF) behauptet.
1.5.1 Rohdatenformat (RAW)
RAW ist das älteste forensische Dateiformat um gesamte Datenträger in ihrer ganz-
heit zu speichern. Es unterstützt keine Komprimierung. Zur Auswertung muss es
immer entpackt sein. Metadaten zugehörig zum Datenträger wie zum Beispiel Has-
hwerte müssen in einer weiteren Datei gespeichert werden. Großer Vorteil dieses
Dateiformats ist, dass es von nahezu jedem forensischen System verarbeitet werden
kann. Die gängigen Dateiendungen sind unter anderem *.raw, *.dd, *.img.
7
1.5.2 Expert Witness Format (EWF)
EWF ist ein proporitäres Dateiformat von der Firma EnCase. Es besitzt effektive
Komprimierungsalgorithmen beim erstellten der Abbilder und beinhaltet, neben den
eigentlichen Daten, viele Metainformationen über den Sicherungsprozess. EWF ist
offengelegt, sodass Drittanbieter es nutzen können. Aktuell ist die Dateiformatver-
sion EnCase6.
1.5.3 Advanced Forensic Format (AFF)
AFF ist ein Open Source Standart, welcher die gleichen Funktionen wie EFW bie-
tet. Die mitgelieferten Bibliotheken von AFF besitzen die Funktion, das Duplikat
zur laufzeit als RAW-Abbild einzubinden, dadurch wird die kompatibilität erhöht.
Darüber hinaus hat es eine bessere Komprimierung [2].
1.5.4 Xmount
Xmount ist ein Programm für Linux, dass es dem Anwender ermöglicht, die oben ge-
nannten Dateiformate in weitere Dateien zu mounten. So kann ein EWF-Abbild als
Rohdatenformat bereitgestellt werden, wodurch sich die Kompatibilität erhöht. Es
ermöglicht das Erstellen eines Schreibcaches, sodass mit der Kopie gearbeitet werden
kann ohne das Original zu verändern. Beispielsweise wird ein EWF-Bootimage als
vmdk-Datei mit Chache bereitgestellt und im Anschluss mit VMWare genutzt.
8
Kapitel 2. Rechtliche Betrachtung
2 Rechtliche Betrachtung
2.1 Einleitung
Dieses Kapitel soll einen kleinen Überblick über die rechtlichen Normen in Bezug
auf Analyse von forensisch erhobenen Daten bzw. der Grundlage für die Erhebung
der Daten überhaupt und deren Verwendung bieten.
Es gibt grundlegende rechtliche Rahmenbedingungen die für eine forensische Ana-
lyse oder allgemein die Erhebung von Daten getroffen und durchgesetzt werden
müssen [3]:
• die Erhebung
• die Speicherung
• die Verarbeitung und Nutzung
• die Übermittlung
• die Berichtigung, Löschung und Sperrung
• Benachrichtigungs- und Auskunftspflichten
• die Kontrolle
• sowie Haftungs- und Strafvorschriften
Diese grundlegenden rechtlichen Rahmenbedingungen sind in diversen Gesetzen,

Verordungen, Richtlinien und Verfahrensvorschriften geregelt. Hierzu zählen Ge-
setze und Verordnungen wie Grundgesetz (GG)1 , StGB2 , Datenschutzgrundverord-
nung (DSGVO)3 und Bundesdatenschutzgesetz (BDSG)4 , um nur einige zu nennen.
1
Es regelt die freiheitlich demokratische Grundordnung.
2
Es regelt in Deutschland das materielle Strafrecht. Unter anderem sind hier die Voraussetzungen
und Rechtsfolgen strafbaren Handelns bestimmt.
3
Es regelt die Verarbeitung personenbezogener Daten durch die meisten Datenverarbeiter (private
und öffentliche), vereinheitlicht EU-weit
4
Es regelt zusammen mit den Landesdatenschutzgesetzen und anderen bereichsspezifischen Re-
gelungen den Umgang mit personenbezogenen Daten, welche verarbeitet werden. Die Verarbei-
tung kann manuell oder durch Informations- und Kommunikationssysteme erfolgen.
9
Für den Bereich der forensischen Analyse gibt es hauptsächlich zwei Gruppen, welche
Ermittlungen durchführen. Das sind zum einen IT-Forensiker, welche im privaten
Sektor Ermittlungen, als Dienstleistung, durchführen und die staatliche Behörden,
welche Ermittlungen aufgrund von Ermittlungsverfahren durchführen. Bei den Er-
mittlungen ist die staatliche Behörde an Verfahrensvorschriften, wie die Strafpro-
zessordnung (StPO), gebunden. Diese gelten so nicht für die privaten Ermittlungen,
dennoch sind ihre Ermittlungshandlungen geregelt. Die Rechtmäßigkeit der Ermitt-
lungen ergibt sich aus den allgemeinen Gesetzen [4].
2.2 Private Ermittlungen
Im Zuge von privaten Ermittlungen, aus welchen sich später auch staatliche Ermitt-
lung (z. B. nach einer Anzeige) ergeben können, müssen die entsprechenden Beweise
ebenfalls beweissicher erhoben werden.
Nach § 202a Abs. 1 StGB ist das Ausspähen von Daten strafbar. Hiernach darf der
IT-Forensiker ohne Erlaubnis des Verfügungsbefugten5 der Daten, diese nicht be-
gutachten.
Anhand der beauftragten forensischen Analyse durch einen Arbeitgeber, als Beispiel,
kann man sehr gut den schmalen Grad von erlaubten und unerlaubten Analysen
durch einen IT-Forensiker kenntlich machen.
Bei dienstlichen Daten erfolgt die Erstellung und Speicherung von Daten im Rah-
men des Dienstverhältnisses auf Weisung und Veranlassung des Arbeitgebers. Daher
ist hier auch der Arbeitgeber über die Daten verfügungsbefugt. Somit ist es mög-
lich, einen privaten IT-Forensiker mit der Analyse zu beauftragen, ohne dass dieser
sich nach § 202a Abs. 1 StGB strafbar macht. Es verhält sich etwas anders, wenn
private Daten von der Analyse betroffen sind. Private Daten sind Daten, welche
gegen Zugriff Unbefugter besonders gesichert sind. Der Verfügungsberechtigte, in
diesem Fall der Mitarbeiter, drückt mit diesen Schutzmaßnahmen aus, den Zugang
zu den Daten zu verhindern oder zu erschweren. Zu diesen Schutzmaßnahmen zählt
nicht das Kennwort zum Entsperren des Systems (z. B. Windows-Anmeldung). Die-
se User-Kennung dient der datenschutzrechtlichen Zugangskontrolle, im Rahmen
von Eingabekontrollen, der Zuordnung bestimmter Vorgänge zu einem Nutzer und
nicht zur Sicherung von Daten gegen den Zugriff des Arbeitgebers. Eine Analyse der
privater Daten darf nur mit Erlaubnis des Verfügungsberechtigten erfolgen [4].
5
Verfügungsberechtigt = Inhaber der Eigentumsrechte/Verfügungsrechte
10
2.3 Behördliche Ermittlungen
Bei behördlichen Ermittlungen gibt es sehr viele spezifische Gesetze, Verordnungen

und Richtlinien, welche berücksichtigt werden müssen.
Hierzu zählen zusätzlich zu den allgemeinen Gesetzen auch weitere wie StPO, Lan-
despolizeigesetze6 , Polizeigesetz (PolG) und Bundeskriminalamtsgesetze (BKAG).
Die Erhebung der Daten, also z. B. die Herausgabe des Datenträgers oder die Erstel-
lung einer Kopie des Datenträgers, ist grundsätzlich nur mit richterlicher Verfügung
oder nach gesetzlichen Richtlinien zur Gefahrenabwehr zulässig.
Werden Daten unrechtmäßig erhoben, können diese nicht als Beweismittel herange-
zogen werden.
Bei einer forensischen Analyse handelt es sich grundsätzlich um eine Durchsuchung
eines Datenträgers, um Beweise zu finden oder Sachverhalte zu analysieren und ge-
gebenenfalls dadurch auf neue Beweise zu stoßen.
Nach § 110 StPO ist eine Durchsuchung von elektronischen Speichermedien ge-
rechtfertigt. Die „Sicherung“ der Daten erfolgt im Regelfall durch die freiwillige
Herausgabe des Datenträgers oder durch die Beschlagnahme des Datenträgers gem.
§ 98 StPO.
Danach kann eine Durchsuchung, nach richterlicher bzw. staatsanwaltschaftlicher
Anordnung, erfolgen.
Ein weiteres Ermittlungsinstrument ist die Online-Durchsuchung. Hierbei handelt
es sich um eine verdeckte Durchsuchung, diese wird ohne Wissen des Betroffenen
durchgeführt. Online-Durchsuchungen sind nach § 100b StPO möglich. Allerdings
werden an ihre Anordnung besonders hohe Maßstäbe gesetzt, da hier ein Eingriff in
die Grund- und Persönlichkeitsrechte stattfinden [5].
2.4 Zusammenfassung
Es müssen auch bei der forensischen Analyse von Daten die Grundrechte gewahrt
werden. Dieses wird durch vielerlei Gesetze und Verordnungen garantiert. Dadurch
ist es dem IT-Forensiker nur innerhalb bestimmter Rahmenbedingungen möglich
Analysen vorzunehmen. Grundsätzlich bedarf es der Zustimmung des Verfügungs-
berechtigten oder entsprechende richterliche oder staatsanwaltliche Anordnungen,
um eine Analyse von Datenträgern durchzuführen.
6
Landespolizeigesetze z. B. PolG NW, SOG M-V
11
Daten müssen so sicher gespeichert werden, dass unbefugter Zugriff, aber auch ver-
sehentlicher Verlust nicht möglich ist - dies gilt auch bei der Übertragung, z. B. von
einer Behörde zur Nächsten.
Daten, die für den ursprünglichen Zweck der Speicherung nicht mehr benötigt wer-
den, müssen gelöscht werden.
12
Kapitel 3. Speichermedien
3 Speichermedien
3.1 Einleitung
Warum ist es interessant sich verschiedene Speichermedien/Speichertypen anzu-

schauen? Festplatten sind Speichermedien, welche forensisch analysiert werden kön-
nen.
Sie können wertvolle Informationen liefern, weil ein Löschen von Daten durch den
Anwender nicht zwangsläufig ein permanentes und unwiderrufliches Löschen der
Daten von der Festplatte zur Folge hat. Daraus ergeben sich aus forensischer Sicht
einige Möglichkeiten der Analyse von Datenträgern. Bei einer forensischen Analyse
muss man aber ebenfalls auf die Integrität der Daten achten, sodass diese Daten
bei der Image-Erstellung oder einer Datensicherung im Originalzustand bleiben und
keine Veränderung erfahren.
Da es sich bei einem RAID-System um einen Festplattenverbund (ein oder mehrere
Datenplatten) handelt, welche auf verschiedene Weisen zusammenarbeiten, um un-
ter anderem eine erhöhte Zugriffsgeschwindigkeit oder eine bessere Verlustsicherheit
der Daten zu erreichen wird im Folgenden auf die aktuell wichtigsten Speicherty-
pen magnetische Speicher und Flash-Speicher eingegangen, welche hauptsächlich für
Festplattenverbunde verwendet werden. Es sollen in diesem Kapitel die Grundzüge
und Besonderheiten der oben genannten Speichertypen kurz herausgearbeitet wer-
den.
3.2 Magnetspeicher
Zum einen gibt es Magnetspeicher, wozu auch die Hard Drive Disk (HDD), Dis-
ketten oder Magnetbänder gehören. Bei magnetischen Speichern werden Bits durch
magnetische Bereiche mit gegensätzlicher Polarität dargestellt. Sie bestehen aus be-
weglichen Teilen, weshalb sie grundsätzlich stoßanfällig sind, was sie für den Einsatz
in stationärer Hardware (z. B. RAID-System) prädestiniert. Da Disketten im Laufe
der Zeit von anderen Speichermedien, wie CDs oder DVDs und USB-Sticks verdrängt
wurden wird in dieser Arbeit nicht weiter auf diese eingegangen. Magnetbänder sind
13
weniger als Festplatte im herkömmlichen Sinne (Nutzung im Computer als Speicher

zum Arbeiten) geeignet, werden aber grundsätzlich als Backup-Medium verwendet,
da bei Magnetbändern ein Zugriff auf die Daten nur sequenziell möglich ist.
Häufiger im Einsatz befindlich sind HDDs. Hierbei handelt es sich um Festplat-
ten, welche in einem vakuumverschweißten Gehäuse mit zumeist zwei übereinander
rotierenden Magnetplatten auf einer gemeinsamen, drehbaren Achse untergebracht
sind. Zum Datenzugriff sind zwei übereinander angeordnete Lese- und Schreibköpfe
zwischen den Platten untergebracht. Anders als bei Magnetbändern ist ein direkter
Zugriff (nicht sequenziell) auf die Daten möglich, da die einzelnen Festplatten in
Spuren und Sektoren unterteilt sind.
3.2.1 Speicherung auf einer HDD
Das Speichern der Daten auf der Festplatte erfolgt durch die Magnetisierung kleins-
ter Eisenpartikel. Diese Eisenpartikel sind auf der Oberfläche der Magnetplatten
aufgetragen. Eine Festplatte muss, damit die Daten wiedergefunden werden kön-
nen, eingeteilt werden. So wird eine Unterteilung von außen nach innen in Spuren
vorgenommen, welche man sich als konzentrische Kreise vorstellen kann. Die Spuren-
dichte, der Abstand der Spuren, bestimmt die Speichermenge. Zwei untereinander
liegende Spuren heißen Zylinder und besitzen eine Zylinderadresse. Die Spuren wer-
den dann wiederum in noch kleinere Abschnitte unterteilt, welche sich Sektoren oder
Block nennen. Sie entsprechen einem Kreisausschnitt. Diese Blöcke sind die kleinste
Einheit einer Festplatte, welche verwendet werden können. Blöcke mit einer Größe
von 64 KByte sind keine Seltenheit. Mehrere Blöcke können zu einem Cluster zu-
sammengefasst werden (beinhaltet zwischen einem und 128 Sektoren), welches die
Speicherverwaltung großer Datenmengen erleichtert. Es ist nur möglich, dass Clus-
ter von dem Betriebssystem angesprochen werden, nicht jedoch einzelne Sektoren.
Wenn man eine Datei speichert, entspricht die Größe dieser Datei aber nicht zwangs-
läufig der Größe eines oder mehrerer Cluster. Wenn wir uns vorstellen, dass wir einen
Cluster aus acht Sektoren haben und die Datei 6,5 Sektoren beschreibt, so bezeich-
net man die unbeschriebenen 1,5 Sektoren als File-Slack. Diese File-Slacks spielen
für die forensische Analyse eine wichtige Rolle. Der File-Slack kann Informationen
über gelöschte Dateien, genutze Programme usw. enthalten.
14
3.2.2 Löschen von Daten auf einer HDD
Hauptsächlich gibt es zwei Möglichkeiten wie Daten „gelöscht“ werden. Es ist mög-
lich, dass der Index-Eintrag einer Datei gelöscht wird - hier kann man sich ein In-
haltsverzeichnis in einem Buch vorstellen welches herausgerissen wird, was zur Folge
hat, dass die Daten selbst weiterhin, allerdings unreferenziert, auf der Festplatte zu
finden sind (unallocated area; nicht allokierter Bereich). Sie werden dem Anwen-
der nicht mehr im Datei-Explorer angezeigt, weshalb dieser von einer „Löschung“
ausgeht. Hier wird vom System ein Flag gesetzt, welches die Datei nur als gelöscht
kennzeichnet. Andererseits wird eine wirkliche Löschung der Daten nur durch das
Überschreiben der Datei ermöglicht, je häufiger dieses Überschreiben stattfindet je
sicherer ist die vollständige Löschung der Dateien.
3.2.3 Forensische Relevanz
Sofern die Sektoren nicht überschrieben wurden, besteht die Möglichkeit die Da-
ten, auch wenn diese nicht mehr referenziert sind, wiederherzustellen. Erst mit dem
Überschreiben der Sektoren, mit neuen Daten, gehen die Daten in diesen Sektoren
verloren.
3.3 Flash-Speicher
Ein weiteres Speichermedium ist der Flash-Speicher. Ein Flash-Speicher ist auf der
Basis der Electrically Earsable Programmable Read-Only Memory (EEPROM)-
Technologie entwickelt. Es handelt sich hierbei um eine elektrische Speichermethode,
welche nichtflüchtig ist, weshalb die Daten auch bei stromlosen Zustand weiter
bestehen bleiben. Das Speichern auf diese Weise hat einen schnellen Lese- und
Schreibzugriff zur Folge, weshalb ein Flash-Speicher schneller als ein magnetischer
Speicher ist, da hier keine zusätzlichen mechanischen Teile zum Lesen oder
Schreiben der Daten verwendet werden muss. Ein Nachteil der Flash-Speicher ist
hingegen die begrenzte Lebensdauer. Diese begrenzte Lebensdauer wird durch die
vorhandene Oxidationsschicht verursacht, welche zum dauerhaften Speichern der
Daten benötigt wird. Bei schreibendem Zugriff gelangen Elektroden durch diese
Oxidationsschicht, wobei diese jedes Mal etwas mehr beschädigt wird.
15
3.3.1 Speicherung auf einer SSD
Flash-Speicher ist blockweise organisiert. Typischerweise hat ein Speicherblock 128

bis 512 kByte. Die Blöcke sind üblicherweise zwischen 128 kByte und 512 kByte
groß. Selbst wenn es nur um ein paar Bit geht, welche gespeichert werden müs-
sen, so muss der ganze Block neu geschrieben werden. Der Controller ist für die
Steuerung der Speicher- und Lesezugriffe zuständig. Er kontrolliert, welche Blö-
cke bzw. dessen Speicherzellen angesprochen werden. Hier versucht der Controller
entsprechend ein Balancing (Wear-Leveling) zwischen häufiger und weniger häufig
genutzen Speicherzellen zu bewahren, sodass weniger häufig genutzte Speicherzellen
vorrangig angesprochen werden. Das erhält die Lebensdauer, da bei jedem Schreib-
zugriff die Sperrschicht und damit die Lebensdauer der Speicherzellen immer weiter
verringert wird. Aus diesem Grund versucht das Wear-Leveling mithilfe von ver-
schiedenen Verfahren und Methoden die Lebensdauer der Speicherzellen zu verlän-
gern, indem der Controller die Schreibzugriffe auf die verschiedenen Speicherblöcke
gleichmäßig verteilt. Es gibt ein Problem, welches beim statischen Wear-Leveling
auftritt und die Zusammenarbeit mit dem Mechanismus des Betriebssystem betrifft.
Wenn Dateien gelöscht (z. B. eine Datei wird im Datei-Explorer gelöscht) werden,
bekommt der Flash-Controller, dieses erstmal nicht mit. Die Dateien werden erst
vorerst nicht von dem Controller, auf der Festplatte selbst, gelöscht. Das Betriebs-
system hat jedoch für sich die Kennzeichnung (Flag), dass der Platz anderweitig
genutzt werden kann. Jetzt kann es beim statischen Wear-Leveling passieren, dass
der Controller, mit viel Aufwand, anfängt die Dateien zu verschieben (aufgrund des
Speicherzellen-Managements). Das würde hier aber keinen Sinn ergeben, da die Da-
teien vom Anwender nicht mehr benötigt werden und grundsätzlich als gelöscht zu
werten wären.
3.3.2 Löschen von Daten auf einer SSD
Hierbei hilft der TRIM-Befehl, mit welchem das Betriebssystem dem Flash-
Controller mitteilt, welche Speicherbereiche nicht mehr gebraucht werden. Da Daten
grundsätzlich nicht endgültig gelöscht, sondern zum Löschen markiert werden, wird
eine zusätzliche Garbage-Collection benötigt. Der TRIM-Befehl ruft die Garbage-
Collection auf und entfernt die als gelöscht markierten Daten auch physikalisch.
Physikalisch heißt, die Zellen werden entladen und die Informationen endgültig ent-
fernt. Der TRIM-Befehl ist nicht Bestandteil des Betriebssystems.
16
3.3.3 Forensische Relevanz
Bei einer SSD ist, sofern der TRIM-Befehl und die Garbage-Collection aktiviert
sind, eine Herstellung bzw. Auslesen von gelöschten Daten sehr schwierig. Als ge-
löscht markierte Daten und dessen Speicherzellen werden durch den TRIM-Befehl
(inklusive Garbage-Collection) nicht nur aus dem „Verzeichnis “ gelöscht und damit
die Referenz zu den Daten, sondern es werden die Speicherzellen entleert, wodurch
die Information permanent gelöscht wird. Es gibt aber auch die Möglichkeit den
TRIM-Befehl zu deaktivieren, das hat zur Folge, dass die Daten nur im „Verzeich-
nis“ gelöscht werden, also nur die Referenzen. Erst wenn die Zellen mit neuen Daten
beschrieben werden, werden diese vorher geleert und können erst in diesem geleerten
Zustand neu beschrieben werden. Also ist es erst ab diesem Zeitpunkt nicht mehr
möglich, die als gelöscht markierten Daten auszulesen.
3.4 Hybride
Ein weiterer Ansatz ist der Einsatz von sogenannten Solid State Hybrid Drive
(SSHD), also Hybridfestplatten, bei denen der Flash-Speicher nur als Schreibpuffer
zur Steigerung der Performance fungiert. Der Einsatz dieser Festplatten würde dem
Nutzer eine höhere Schreibgeschwindigkeit und einen geringeren Stromverbrauch
bringen und durch die Speicherung der Daten auf einem Magnetspeicher dennoch
die Vorteile einer HDD gepaart mit der Schnelligkeit einer SSD [6].
3.5 Zusammenfassung
Grundsätzlich ist es möglich von Festplatten die Daten, auch wenn diese vermeintlich
vom Anwender oder System gelöscht wurden, wiederherzustellen. Bei einer HDD ist
die Wiederherstellung möglich, bis die entsprechenden Blöcke überschrieben werden.
Hier gilt, je häufiger das Überschreiben stattgefunden hat, je wahrscheinlicher ist
die Vernichtung der Daten auf der Festplatte.
Bei der SSD gibt es zwei Möglichkeiten. Zum ist der TRIM-Befehl und die Garbage-
Collection aktiv und wird vom entsprechenden Betriebssystem angesprochen, dann
ist die Wahrscheinlichkeit, dass die Daten wiederhergestellt werden können sehr
gering, da hier die Speicherzellen auch physikalisch geleert werden. Wenn hingegen
der TRIM-Befehl nicht aktiv genutzt wird, so verhalten sich die Möglichkeiten der
17
Wiederherstellung ähnlich die der HDD. Es ist hier ebenfalls möglich, die Daten
auch wenn vermeintlich vom Anwender gelöscht wiederherzustellen.
18
Kapitel 4. Analyse eines Datenträgerverbundes
4 Analyse eines Datenträgerverbundes
4.1 Einleitung
Bei einer Redundant Array of Independent Disks (RAID)-Konfiguration handelt es

sich um den Verbund mehrerer physikalischer Festplatten oder Partitionen zu einer
logischen Festplatte oder Partition.
Derartige RAID-Verbunde finden sich häufig auf den Computern eines Beschuldig-
ten.
RAID-Verbunde werden von diesen eingerichtet um eines von zwei Ziele zu errei-
chen: Die Verfügbarkeit von Daten gegen Ausfälle zu erhöhen oder die Zugriffsge-
schwindigkeit auf die Daten zu verbessern. Hierbei ist es auch möglich beide Ziele
zu kombinieren. Die Erhöhung der Zugriffsgeschwindigkeit wird erreicht, indem die
Daten zu gleichen Teilen auf mehreren Festplatten verteilt werden. Hier spricht
man vom „Striping“ (dt.: „Streifen“). Eine mögliche Konfiguration (RAID-0) ist in
Bild 4.1 dargestellt. Die Erhöhung der Verfügbarkeit erreicht man durch das Spie-
geln (en.: „Mirroring“, mögliche Konfiguration RAID-1) oder durch Berechnung von
Paritäten von zwei oder mehreren „Streifen“ (mögliche Konfiguration: RAID-5, Sie-
he Bild 4.2). Beide oben genannte Ziele können erreicht werden, indem z. B. eine
RAID-Konfiguration gewählt wird, die beides kombiniert (z. B. RAID-10, Siehe Bild
4.3). Neben den vorgenannten gängigen RAID-Layouts, existieren einige weitere teils
Bild 4.1: Schematische Darstellung einer RAID-0 Konfiguration mit zwei Datenträgern,
Quelle: Wikipedia [7]
19
Bild 4.2: Schematische Darstellung einer RAID-1 und einer RAID-5 Konfiguration mit
zwei bzw. vier Datenträgern, Quelle: Wikipedia [7]
Bild 4.3: Schematische Darstellung einer RAID-10 Konfiguration mit vier Datenträgern,
exotisch anmutende Layouts, bei denen die Systemadministratoren im Einzelfall be-

sonders hohe Anforderungen festgelegt haben.
Ein RAID 51 (Siehe Bild 4.4) wäre etwa die Spiegelung zweier RAID5 Verbunde.
Bei dieser Konfiguration wäre der Ausfall von drei der mindestens sechs Festplatten
möglich, ohne dass die Verfügbarkeit der Daten eingeschränkt wäre. Die verfügbare
Kapazität wäre bei sechs Platten identischer Größe jedoch auf nur 33% begrenzt.
Eine weniger exotische Konfiguration, die dennoch mehrere Ausfälle kompensieren
kann bildet das RAID-6. Bei diesem RAID-Layout wird beim Einsatz von vier oder
mehr Platten der Ausfall von zwei Platten kompensiert, ohne dass die Verfügbarkeit
der Daten beeinträchtigt wird. Bei einem RAID-6 mit vier Festplatten stünden also
Bild 4.4: Schematische Darstellung einer RAID-51 Konfiguration mit sechs Datenträgern,
20
Bild 4.5: Schematische Darstellung einer RAID-6 Konfiguration mit fünf Datenträgern,
mindestens 50% der Kapazität der Festplatten zur Verfügung. RAID-Systeme lassen
sich hinsichtlich ihrer Implementierung im System unterscheiden.
Einerseits existieren Hardware-RAID Systeme. Bei derartigen Systemen kümmert
sich ein eigener Controller, dass die Daten im Sinne des RAID-Layouts korrekt auf
den physikalischen Festplatten verteilt werden. Gegenüber dem Computersystem
erscheinen die Vielzahl physikalischer Festplatten jedoch als eine einzige logische
Platte, die auch als solche dann vom Betriebssystem behandelt werden.
Neben dem Hardware-RAID System existieren auch Software-RAID Lösungen.
Diese werden also vom Betriebssystem bzw. von Diensten und Prozessen des
Computer-Systems verwaltet und letztlich ebenfalls als eine logische Platte bereit-
gestellt.
Eine Misch-Lösung beider Implementierungen stellen s. g. „Host-RAID“ Systeme
dar, die in der untersten Preisspanne kommerzieller Lösungen anzusiedeln sind. Sie
werden im Linux-Jargon oft als „Fake-RAIDs“ [8] bezeichnet, da sie letzten Endes,
wie beim Software-RAID, ebenfalls die Ressourcen des Computers beanspruchen.
Hierbei sind sie jedoch ebenfalls an den Controller der Hardware gebunden. Sie
kombinieren somit streng genommen die Nachteile beider o. g. Lösungen.
Sie finden sich heute auf diversen Mainboards vorinstalliert, so dass sie weiterhin eine
gewisse Relevanz haben, sich jedoch im Vorgehen nicht sonderlich von Hardware-
RAID Systemen unterscheiden.
In den beiden folgenden Kapiteln wird anhand eines konkreten Beispiels das Vorge-
hen bei der forensischen Analyse von Festplatten eines Software-RAID und bei der
Analyse eines Hardware-RAID Systems beschrieben.
4.2 Hardware-RAID
Hardware-RAIDs sind Software-RAIDs in Punkto Flexibilität und bei der Leistung

zur Wiederherstellung („rebuild“) von Daten i. d. R. im Nachteil. Zum Einsatz
21
kommen sie i. d. R. noch dort, wo es um möglichst hohe Schreib-Leistung, bei zeit-

gleich möglichst geringem Ressourcen-Bedarf des Betriebssystems ankommt. Dies
wird durch verschiedene Strategien erreicht, wie dem asynchronen Schreiben von
Paritätsinformationen, einer dedizierter Central Processing Unit (CPU) und einem
(ggf. durch eine Batterie gepufferten) Schreibcache.
Die o. g. Faktoren führen dazu, dass verschiedene Algorithmen den verschiedenen
RAID-Controllern zugrunde liegen.
Zugleich setzen solche Hardware-RAIDs im Gegensatz zu Software-RAIDs häufig auf
proprietäre geschlossene Standards zur Speicherung der Meta-Informationen. Selbst
innerhalb derselben Hersteller ist eine Kompatibilität der Controller nicht immer
sichergestellt.
Idealerweise sollte daher das Auslesen von Datenträgern mit demselben Controller
stattfinden, mit dem die Daten auch auf die Platten geschrieben wurden.
Dies ist in der Praxis aber nicht immer ohne weiteres möglich (etwa bei Ausfall des
Controllers) oder bedarf zumindest einer größeren Vorbereitung (etwa beim Zugriff
auf größere Storage Rack Server).
Daher besteht der Wunsch, möglichst ohne die originären Hardware-Controller Da-
tenträger zumindest auslesen zu können, so dass die installierten Dateisysteme für
den Forensiker zugänglich werden.
Tatsächlich existieren Software-Produkte, die sich genau dieser Herausforderung
stellen. Darunter X-Ways, R-Studio, dmde oder dmraid. Die Kosten für die Produkte
schwanken von rund 1.000 EUR pro Lizenz für X-Ways oder R-Studio (commercial
license) bis hin zu kostenlosen Lösung mit dmraid.
Für diese Arbeit wurde ein RAID Controller JMB394 von JMicron [9] genutzt, der
u.a. das RAID-Level 0, 1, 5 und 10 unterstützte, das hier zum Einsatz kam. Dieser
Controller war im Produkt „Sharkoon 5-Bay RAID Station“ installiert. Betrieben
wurden drei Festplatten im RAID 5. Dieses Verbund wurde via USB 3.0 an einem
Windows PC installiert und mit einer NTFS Partition über 1 GB formatiert. Die
Platten des RAIDs wurden einzeln forensisch erfasst und sollen analysiert werden.
Für die Analyse wurden die Produkte X-Ways und dmraid im Vorhinein ausge-
schlossen. Das erstgenannte Produkt stand aus Kostengründen nicht zur Verfügung.
Das Tool dmraid ist zwar in vielen Linux-Distributionen enthalten, die sich auf
forensische Analyse spezialisiert haben und stand somit auch grundsätzlich zur Ver-
fügung. Ein Blick in die man-pages offenbarte aber, dass - je nach Version - der o.
g. RAID-Controller zwar verfügbar war, jedoch nicht das gewählte RAID-Level 5
unterstützte.
Die Produkte X-Ways, R-Studio und dmde werben damit ein RAID anhand der
22
Bild 4.6: Imagedatei öffnen in R-Studio
vorliegenden Festplatten auf Basis von heuristischen Algorithmen identifizieren und

auslesen zu können.
Bei dmde gelang dies zwar nicht, es ist aber nicht auszuschließen, dass hier ein
Anwender-Fehler vorlag. Die Benutzeranleitungen und Sekundar-Quellen erwiesen
sich hier leider nicht als hilfreich.
Für die folgenden Schritte wurde R-Studio [10] eingesetzt. Dieses Tool ist zwar mit
899 USD für eine „commercial use“ Lizenz, auch eines der teureren, jedoch steht
eine kostenlose Variante zur Verfügung, die es erlaubt Daten bis 250 KB online zu
rekonstruieren. Das Erstellen eines logischen Abbildes des Dateisystems auf Basis
der logischen Abbilder des rekonstruierten RAID-Verbundes war ebenfalls uneinge-
schränkt möglich.
Im Folgenden wird davon ausgegangen, dass der Forensiker am betroffenen Com-
puter drei Festplatten vorfindet, zu denen er jeweils ein Abbild erstellen konnte,
welche jeweils für die weitere Analyse genutzt werden können. Die Abbilder liegen
im EnCase6 Format vor.
4.2.1 Schritt 1: Einbinden der Abbilder
Zunächst werden die Abbilder unter Nutzung von xmount ausgelesen und dessen
Inhalt im Dateisystem des Forensikers gemountet.
1 > xmount -- in ewf hdd1 . E01 / mnt / disk1
4 > ls - rR / mnt / disk *
5 / mnt / disk3 :
6 hdd3 . info hdd3 . dd
7
8 / mnt / disk2 :
10
11 / mnt / disk1 :
4.2.2 Schritt 2: Öffnen der Abbilder in R-Studio
Zunächst müssen die Abbilder in R-Studio über den Button „Image öffnen“ eingele-
sen werden (Siehe Bild 4.6). Der Dialog „Imagedatei öffnen“, der nun gestartet wird,
23
Bild 4.7: R-Studio: Imagedatei öffnen
erwartet zunächst Dateitypen, mit denen hier nicht gearbeitet wurde. R-Studio
erwartet hier allen voran, die eigenen proprietären Image-Dateitypen *.rdr (Siehe
Bild 4.7). Das stellt jedoch kein Problem dar, da alternativ auch die weitaus
verbreiterten DD-Dateien ausgewählt werden können, nachdem im Auswahlmenü
„Dateien des Typs“ die Suchmaske „Alle Dateien ( * )“ ausgewählt wurde (Siehe
Bild 4.8).
4.2.3 Schritt 3: Modellierung des RAID-Layouts
Nun kann R-Studio seine Stärke ausspielen, indem es den Anwender unterstützt,
das korrekte RAID-Layout zu ermitteln. Zunächst wählt der Anwender im Menü
„Virtuelles RAID erstellen“ den etwas unglücklich beschrifteten Untermenüpunkt
„Virtuellen Block erstellenRAID& Automatisch Erkennen“ (Siehe Bild 4.9).
In der Baum-Darstellung der „Geräte-Ansicht“ erscheint nun ein neuer Zweig „Virtu-
elle Volumesets und RAIDs“. Hier wählt der Anwender den ersten Unterknoten aus.
Bei der hier dynamisch vergebenen ebenfalls unglücklichen Beschriftung herrscht
Verwechslungsgefahr. An der Stelle, wo in der folgenden Abbildung „Virtual Block
RAID 1“ zu lesen ist, bildet die Ziffer eine Sequenz, die nichts mit dem RAID-Level
zu tun hat, das zu diesem Zeitpunkt noch ermittelt werden muss (Siehe Bild 4.10).
Auf der rechten Seite wird nun ein Bereich „Parent“ angeboten, über den nun die
Teile des RAID-Verbundes zusammengestellt und die Konfiguration bestimmt wer-
den kann (Siehe Bild 4.11). Hierzu wählt der Anwender den offensichtlichen Button
24
Bild 4.8: Button Image öffnen in R-Studio
Bild 4.9: Virtuellen Block erstellen in R-Studio
Bild 4.10: Die Geräte-Ansicht von R-Studio
25
Bild 4.11: R-Studio: Der Bereich parent
Bild 4.12: R-Studio: RAID-Parameter
„Automatische Erkennung“ aus. Der folgende Dialog erscheint und bietet nach einer
gewissen Analyse-Zeit dem Anwender valide RAID-Layouts aus, die der Anwender
auswählen und mit dem Button „Anwenden“ bestätigen muss (Siehe Bild 4.12).
Hierbei kann es dazu kommen, dass mehrere mögliche Layouts kompatibel sind und
angewandt werden können. Letztlich obliegt es dann dem Anwender, das korrek-
te Layout zu wählen. Hierbei hilft es, dass R-Studio mit wenigen Klicks und ohne
spürbare zusätzliche Ladezeit das Layout wechseln kann, um Alternativen durchzu-
probieren.
Ferner unterstützen hierbei die Funktionen RAID-Konsistenz prüfen (Siehe Bild
4.13) oder der Menüpunkt Scannen (Siehe Bild 4.14).
Über die Funktion RAID-Konsistenz prüfen, wird ermittelt, ob die Blöcke konsis-
tent sind - also ob Spiegelungen tatsächlich identisch und ob Paritäten tatsächlich
korrekt errechnet werden.
26
Bild 4.13: R-Studio: RAID-Konsistenz
Bild 4.14: R-Studio: Menüpunkt scannen...
27
Bild 4.15: R-Studio: Darstellung der RAID-Konsistenz
Bild 4.16: R-Studio: Parameter für die Scannen-Funktion
Abbildung 4.15 stellt eine positiv verlaufende Konsistenz-Prüfung dar. Grüne Mar-
kierungen sind hierbei korrekt errechnete Blöcke und weiße Blöcke sind leer bzw.
mit Nullen belegt, so dass diese Bereiche weiß hinterlegt werden. Bei der Funktion
„Scannen“ ermittelt R-Studio valide Blöcke, die auf ein bestimmtes Dateisystem
oder einen bestimmten Dateitypen hinweisen. Dieser Prozess kann sehr zeitaufwän-
dig sein, daher lohnt es sich zu überlegen, ob Dateisysteme ausgeschlossen werden
können und ob man wirklich nach allen Dateitypen suchen möchte oder vielleicht
nur nach speziellen - z. B. Office Dokumenten oder Bildern.
In Abbildung 4.16 wurden Dateisysteme vorausgewählt, die bei einem Windows-PC
üblich wären. Über den Button „Bekannte Dateitypen“ lassen sich einzelne Dateity-
pen oder -Gruppen an- und abwählen (Siehe Bild 4.17). Da die Laufzeiten tatsächlich
28
Bild 4.17: R-Studio: Dateitypen beim Scannen auswählen
Bild 4.18: R-Studio: Übersicht des Fortschritts beim Scannen
erheblich sein können, lohnt es sich - für die Identifikation des RAID Layouts - auch
den zu analysierenden Bereich einzuschränken und bei der Scanansicht „Einfach
(nur Scanfortschritt; schneller.)“ auszuwählen. (Siehe Bild 4.18) Nach einem solchen
Scan stehen dem Anwender bereits Möglichkeiten zur Verfügung durch die logische
Struktur des Dateisystems zu navigieren und Dateien jeweils wiederherzustellen bzw.
einzusehen.
Nachdem der Anwender jenes RAID-Layout ausgewählt hat, das ein konsistentes
RAID liefert, valide Dateisysteme erkennt und keine - oder möglichst wenige - kor-
rupte einzelnen Dateien ermittelt, wird der Anwender diesen Zustand exportieren
wollen. Dies ermöglicht ihm die physikalische Abstraktionsebene des RAID-Systems
zu entfernen und dessen logische Abbildung zu erzeugen (Siehe Bild 4.19). Hierzu
öffnet der Anwender das Menü zum Eintrag „Virtual Block RAID 1“ und wählt den
Menü-Eintrag „Image erstellen. . . “ aus.
Im folgenden Dialog bietet R-Studio erneut primär das eigene proprietäre Image-
Format an.
29
Bild 4.19: R-Studio: Image erstellen
Bild 4.20: R-Studio: Byte-Für-Byte Image erstellen
Neben der Tatsache, dass dieses den Anwender an das R-Studio Produkt-Portfolio
bindet, erlaubt das Format im Vergleich zu EnCase6 ein nur schwaches Kompressi-
onsverhältnis. Es bietet auch ansonsten wenige Zusatzfeatures, die uns - die Autoren
- dazu verleiten würden, dieses Format dennoch zu empfehlen.
Für eine Aufbewahrung und/oder forensische Weiterverarbeitung empfehlen wir
daher viel mehr den Umweg über ein Byte-für-Byte-Image, dass im Anschluss
mit einem geeigneten Tool platzsparend komprimiert und weiterverarbeitet wer-
den kann (Siehe Bild 4.20). Womöglich hilfreich kann jedoch noch sein, die „Scan-
Informationen“ im entsprechenden Reiter zu speichern (Siehe Bild 4.21).
30
Bild 4.21: R-Studio: Scan Informationen speichern
4.3 Software Lösungen unter Linux
4.3.1 Software-RAID
In diesem Kapitel geht es um eine Software RAID Konfiguration, bei der wir da-
von ausgehen, dass sie auf Basis des weit verbreiteten Multiple Disk (MD) vorliegt.
MDADM ist das entsprechende Administrationstool [11].
Die möglichen Konfigurationsmöglichkeiten können vielseitig sein, denn es ist mög-
lich mit MDADM verschiedenste RAID Layouts zu definieren und miteinander zu
verschachteln. Es können sowohl einzelne Dateien, ganze RAID-Verbunde, Partitio-
nen und auch ganze Festplatten mit einander verbunden werden.
Die beiden letztgenannten Optionen sind jedoch die häufigsten Anwendungsfälle
und daher bereits Grund genug, dass ein Forensiker zunächst ein Abbild sämtlicher
Platten erstellen sollte.
Im Folgenden wird davon ausgegangen, dass der Forensiker am betroffenen Compu-
ter fünf Festplatten vorfindet, zu denen er jeweils ein Image erstellen konnte, das
jeweils nun für die weitere Analyse genutzt werden kann.
Die Abbilder liegen im EnCase6 Format vor. Das gewählte Analyse-System verfügt
über die SleuthKit Software-Sammlung.
Schritt 1: Einbinden der Abbilder
Zunächst werden die Abbilder unter Nutzung von xmount ausgelesen und dessen
Inhalt im Dateisystem des Forensikers gemountet.
Hierbei ist es wichtig, den Parameter --cache zu verwenden, um eine s. g. Over-
lay Datei anzulegen. Eine derartige Datei erlaubt es dem System bei der späteren
31
Einbindung der Datenträger Schreibbefehle entgegen zu nehmen. Jedoch werden die

Schreibbefehle nicht im Datenträger-Abbild geschrieben, sondern in einer separaten
Schicht - dem Overlay - umgesetzt. Dies erst erlaubt es später die Datenträger via
MDADM zu mounten - ohne, dass die originalen Abbilder beschädigt werden.
1 > xmount -- cache cache1 . ovl -- in ewf hdd1 . E01 / mnt / disk1
Im Dateisystem finden sich nun RAW- bzw. DD-Files von den jeweiligen Platten,
die nun über losetup einem loopback Device zugeordnet werden. Die ursprünglichen
Datenträger stehen somit fortan als Blockdevice zur Verfügung.
1 > losetup / dev / loop1 / mnt / disk1 / hdd1 . dd
Schritt 2: Identifikation von MDADM Volumes
Durch Eingabe des folgenden Befehls, ermittelt MDADM das RAID-Layout des
jeweiligen Blockdevices.
1 > mdadm -- examine / dev / loop1
Die Ausgabe des Befehls lautet für die erste beliebige Platte
1 / dev / loop1 :
2 Magic : a92b4efc
3 Version : 1.2
4 Feature Map : 0 x0
5 Array UUID : 6041 aacf :9 d4400c5 :4 e5253d7 :1 b3e05d7
6 Name : suspect :0
7 Creation Time : Sat Apr 13 17:57:05 2019
8 Raid Level : raid6
9 Raid Devices : 5
10
11 Avail Dev Size : 16758784 (7.99 GiB 8.58 GB )
12 Array Size : 25138176 (23.97 GiB 25.74 GB )
13 Data Offset : 18432 sectors
14 Super Offset : 8 sectors
15 Unused Space : before =18352 sectors , after =0 sectors
16 State : clean
17 Device UUID : fd6ed775 : c28fb7a1 : f547b069 :848 f14be
18
19 Update Time : Sat Apr 13 18:05:41 2019
20 Bad Block Log : 512 entries available at offset 16 sectors
21 Checksum : 91 d8e17e - correct
32
22 Events : 129
23
24 Layout : left - symmetric
25 Chunk Size : 512 K
26
27 Device Role : Active device 1
28 Array State : AAAAA ( ’A ’ == active , ’. ’ == missing , ’R ’ == replacing )
In der Ausgabe lässt sich feststellen, dass die vorliegende Platte hdd1.E01 Teil
eines RAID-6 Verbundes ist. Dieser Verbund besteht aus fünf einzelnen Platten
- wahrscheinlich die vier verbleibenden Asservate hdd2.E01 bis hdd5.E01. Letzte
Gewissheit erhält man, wenn man den gleichen Befehl mit den Blockdevices aller
Festplatten-Abbilder wiederholt.
In der Ausgabe erfährt der Forensiker außerdem, dass die Kapazität des logischen
Laufwerks rund 24 GiB umfasst, während die Größe der einzelnen physikalischen
Platten bei jeweils rund 8 GiB lagen.
Weitere 16 GB nutzt RAID-6 zur Abbildung von zwei Paritäten, die benötigt werden,
um eine doppelte Ausfallsicherheit zu implementieren. Da der Verbund konsistent
ist - davon zeugt die korrekt Prüfsumme und das Array State AAAAA - genügt
es, wenn der Forensiker fortan mit drei der fünf Platten arbeitet. Dieses Vorgehen
schont IO Bandbreiten, Speicherkapazitäten und damit letztlich in der folgenden
Bearbeitung auch Zeit.
Es steht dem Forensiker aber frei, alle fünf Abbilder zum RAID-6 zu verbinden.
Schritt 3: Einbinden des RAID-Verbundes
In Schritt 2 wurde festgestellt, dass die fünf Plattenabbilder von einem logischen
RAID-6-Verbund stammen. Daher lassen diese sich ressourcensparend einbinden,
indem drei beliebige Platten des Verbundes gemountet werden.
1 > mdadm -- assemble -- r e a d o n l y -- run / dev / md0 / dev / loop1 / dev / loop2 / dev / loop3
2 mdadm : / dev / md0 has been started with 3 drives ( out of 5) .
Schritt 4: Volumen Analyse
Nun kann der Forensiker ermitteln, mit welchem Dateisystem er es zu tun hat. Auf
Basis dieser Erkenntnis, lässt sich das weitere Vorgehen bestimmen. Dazu lässt sich
z. B. der Befehl fsstat aus dem SleuthKit verwenden.
1 > fsstat -t / dev / md0
2 ext4
33
Es wurde ermittelt, dass auf dem Software-RAID das Dateisystem „ext4“ eingesetzt
wurde.
Es lassen sich nun weitere Analysen des Volumens durchführen, ohne dass dieses
eingebunden werden muss. Beispielsweise lassen sich mit dem Carving-Tool foremost
Dateien eines gewissen Dateityps anhand der Header-Informationen ermitteln und
extrahieren. Da foremost nicht auf das Dateisystem schauen kann, entspricht die
Nummer im Dateinamen der extrahierten Dateien dem Anfangsblock der jeweiligen
Datei:
1 > foremost -T -t jpeg / dev / md0
2 Processing : / dev / md0
3 |**********************************************************************
4 ***********************************************************************
5 ****************|
6 > cd output / jpeg
7 > ls
8 00270576. jpg 00273955. jpg 17063504. jpg 25431160. jpg 25468552. jpg
9 00270692. jpg 00376832. jpg 17068664. jpg 25439144. jpg 25477184. jpg
10 00272024. jpg 17039368. jpg
Schritt 5: Mount des logischen Dateisystems
Die vorliegenden Datenträger-Abbilder wurden bislang als Platten eines Software-

RAIDs identifiziert, in einem RAID-Verbund erfolgreich erneut logisch zusammen-
gefasst und können nun auch gemountet werden.
Da in diesem Fall ein Linux Dateisystem vorliegt, können wir dieses unmittelbar
mappen, sobald der Pfad angelegt wurde.
1 > mkdir / mnt / suspect
2 > mount / dev / md0 / mnt / suspect
3 > ls - lh
4 insgesamt 4 ,3 M
5 -rw -r - -r - - 1 root root 220 K Apr 13 18:00 Btrfs . pdf
6 -rw -r - -r - - 1 root root 198 K Apr 13 18:00 Dd . pdf
7 drwxr - xr - x 2 root root 4 ,0 K Apr 13 18:01 fernweh
8 drwxr - xr - x 2 root root 4 ,0 K Apr 13 18:01 happy
9 -rw -r - -r - - 1 root root 5 ,6 K Apr 13 18:05 hashdeep . txt
10 -rw -r - -r - - 1 root root 0 Apr 13 18:00 H o c h s c h u l e _ W i s m a r . pdf
11 -rw -r - -r - - 1 root root 189 K Apr 13 18:00 L o g i c a l _ V o l u m e _ M a n a g e r . pdf
12 drwx - - - - - - 2 root root 16 K Apr 13 17:58 lost + found
13 -rw -r - -r - - 1 root root 141 K Apr 13 18:00 Mdadm . pdf
14 drwxr - xr - x 2 root root 4 ,0 K Apr 13 18:01 metropolen
15 -rw -r - -r - - 1 root root 0 Apr 13 18:00 NTFS . pdf
16 -rw -r - -r - - 1 root root 0 Apr 13 18:00 One - Time - Pad . pdf
17 -rw -r - -r - - 1 root root 0 Apr 13 18:00 Polizei - IT - Anwendungen . pdf
18 -rw -r - -r - - 1 root root 960 K Apr 13 18:00 RAID . pdf
19 -rw -r - -r - - 1 root root 148 K Apr 13 18:00 ReFS . pdf
20 -rw -r - -r - - 1 root root 152 K Apr 13 18:00 The _Sleuth_ Kit . pdf
21 -rw -r - -r - - 1 root root 1 ,6 M Apr 13 18:00 Ubuntu . pdf
34
22 -rw -r - -r - - 1 root root 495 K Apr 13 18:00 VirtualBox . pdf

23 -rw -r - -r - - 1 root root 187 K Apr 13 18:00 ZFS . pdf
35
4.3.2 Logical Volume Manager (LVM)
Der Logical Volume Manager ist ein softwarebasierte Speicherlösung die in den Li-
nuxkernel integriert ist. Logical Volume Manager (LVM) stellt logische Volumen
bereit die von physischen Datenträgern abstrahiert und unabhängig sind. Es kann
als Ergänzung zu MD angesehen werden und besitzt eine flexible Architektur.
Funktionsweise
Die von LVM bereitgestellten Volumen sind flexibel und skalierbar. Sie können über
mehrere physische Datenträger verteilt und zur Laufzeit in ihrer Größe angepasst
werden. Häufig wird LVM zusammen mit MD verwendet, aber einige Anbieter inte-
grieren eigene RAID-Funktionalitäten. Diese sind in einigen Distributionen bereits
integriert oder können nachträglich installiert werden. Von logischen Volumen kön-
nen Snapshots angefertigt werden. In einem angelegten Snapshot werden alle Ände-
rungen blockweise in ein neues referenzierendes, logisches Volumen geschrieben.
Partitionen die in die LVM-Verwaltung integriert sind werden in der Master Boot
Record (MBR) Partitionstabelle mit dem Typ 0x8e gekennzeichnet. Die kleinste
Speichereinheit im LVM wird Physical Extent genannt. Sie ist auf den physischen
Datenträgern verteilt. Eine veränderbare Anzahl an Physical Extent bildet eine Vo-
lume Group. In dieser Gruppe können mehrere logische Volumes abgelegt und an-
schließend dem System zugeordnet werden. LVM hat keinen Einfluss auf dem dar-
über eingesetzten Dateisystem. Wird das Volume in seiner Größe angepasst muss
das Dateisystem dies unterstützen [12, S. 160–161].
Speichern und Einbinden
Das Duplizieren der LVM-Volumen für die forensische Auswertung ist einfach. Die
Konfiguration ist unter /etc/lvm/ abgelegt. Hier finden sich auch Archive von alten
Konfigurationen. Bei aktivem System ist es möglich beispielweise mit dd, das Volume
zu kopieren. Die LVM-Partitionen sind unter /dev/VOLUMEGROUPNAME/VO-
LUME verfügbar. Dieses Vorgehen ist ineffizient, da Snapshots und Volumen in ihrer
gesamten Größe gespeichert werden. Zusätzlich gehen Metainformationen zur LVM-
Konfiguration verloren. Mit dem Befehl vgimportclone wird eine neu benannte Kopie
der originalen Volume Group angelegt. Somit kann das Original kopiert werden.
Auf diese Methode kann im Normalfall verzichtet werden. Sämtliche Informationen
über alle Datenträger, Volume Groups und Volumes liegen zusätzlich am Anfang
36
Bild 4.22: LVM Architektur [13]
37
jeder der oben genannten LVM-Partitionen (0x8e). Es empfiehlt sich alle physi-
schen Datenträger zu duplizieren. Im Anschluss werden die Duplikate im System
des Forensikers mittels folgender Befehle eingebunden. Zu beachten ist das mögliche
MD-RAID Aktionen vorher ausgeführt werden müssen.
1 > vgscan # Sucht nach Volume Groups
2 > vgdisplay # Listet die Volume Groups auf
3 > lvs # Liefert M e t h a d a t e n zu den Volume Groups
4 > ll / dev / VOLUMENGROUP / # Zeigt alle v e r f u e g b a r e n Volumen an
Bild 4.23: Volume Groups und Volumes identifizieren
Auf Bild 4.24 sind die bereitgestellten Partitionen zu sehen. Da LVM keine Par-
titionstabellen anlegt ist es möglich, mit fsstat in die Struktur des Dateisystems
einzusehen.
Eine Analyse des Snapshots in Bild 4.25 zeigt auf, dass das Dateisystem formatiert
wurde. Im Original ist das Volume mit Ext4 formatiert. Der Befehl fls zeigt dass
eine verdächtige Datei namens evil.exe existiert.
38
Bild 4.24: Volumes und Dateisysteme
Bild 4.25: Dateisystem des Snapshots
39
4.4 Software Lösungen unter Windows
4.4.1 LDM
Logical Disk Manager ist eine Funktionalität die es ermöglicht mehrere verschiedene
Datenträger in ein einzigen logischen Datenträger zu verbinden. Es können dabei die
RAID-Level 0, 1 und 5 gewählt werden. Um einen Datenträger in LDM einzubinden
muss eine MBR-Partition des Typs 0x42 vorliegen. Am Ende jeder Partition befindet
sich die proprietär aufgebaute LDM Datenbank. Weiterführende Informationen sind
in Kapietel 7 aus [12, S. 162–170] einzusehen. Das freie Linuxprogramm ldmtool
ist für die Rekonstruktion empfehlenswert. An dieser Stelle wird LDM nicht weiter
thematisiert, dieses wurde durch die Windows Storage Spaces ersetzt.
4.4.2 WSS
Die Windows Storage Spaces sind eine softwarebasierte Speicherlösung von Micro-
soft. Sie wurde mit Windows Server 2016 eingeführt. Mit Windows Server 2019
wurde Windows Storage Spaces durch Storage Space Direct (S2D) auf eine Storage
Area Network Ebene erweitert.
Funktionsweise
Datenträger die für Windows Storage Spaces verwendet werden sind mit
einer Globally Unique Identifier (GUID)-PartitionTable aufbereitet. In die-
ser sind zwei Partitionen registriert. Microsoft Reserved Partition (GUID:
E3C9E3160B5C4DB8817DF92DF00215AE) [12, S. 143] und Speicherpool (GUID:
8FAF5CE780F6EE4CAFA3B001E56EFC2D). Es folgen Metainformationen über
den Speicherpool. Dazu zählen u. a. die Anzahl physischer Laufwerke, der Resilienz-
Typ und die Größe des bereitgestellten Speichers. Resilienz ist die Fähigkeit, bei
Störungen die Aufgabenerfüllung aufrecht zu erhalten.
Adäquat zu LDM und im Gegensatz zu LVM wird bei WSS eine virtuelle Festplatte
und keine Partition bereitgestellt. Diese beginnt mit einem GPT-Header, welcher
auf eine Partition verweist die wiederum mit einer spezielle Version von NTFS oder
Resilient File System (ReFS) formatiert ist. Diese Informationen liegen im RAW-
Format auf den fünf schnellsten Datenträgern des WSS-Verbundes. Selbst wenn der
Ermittler nur eine dieser Festplatten besitzt, stehen ihm sämtliche NTFS Metadaten
40
über die gespeicherten Dateien zur Verfügung. ReFS ist ein von Microsoft entwickel-
tes Dateisystem welches für die Verwendung von Netzwerkspeicher empfohlen wird.
Bild 4.26: GPT-Tabelle der physischen Disk
41
Bild 4.27: GPT-Tabelle der virtuellen Disk
Bild 4.28: GPT-Tabelle auf physischer Disk identifiziert
Die Skalierung und Redundanz der Daten werden hier auf Dateisystemebene durch-
geführt. Dazu wird das Speichermedium anschließend in 256 MB große Blöcke einge-
teilt. Microsoft nennt diese Slaps. Wenn keine Redundanz konfiguriert ist, werden die
Slaps gleichmäßig auf die Datenträger verteilt. WSS bietet zusätzlich vier verschie-
dene Resilienzen an. Die einfache oder doppelte Kopie legen einen 256 MB Block
auf weiteren Datenträgern ab. Dies ist performanter als die Paritätsberechnung,
beansprucht aber viel Speicherkapazität. Alternativ kann eine einfache oder dop-
pelte Parität eingesetzt werden da über alle genutzten Datenträger ein Paritätsslap
berechnet wird. Das erhöht die Speichereffizienz des Systems. Sollte ein Laufwerk
ausfallen, sofern genügend Speicherplatz auf den gesunden Datenträgern vorhan-
den ist, werden die Paritäten bzw. Spiegelungen auf den vorhandenen Laufwerken
umgehend rekonstruiert. Anschließend ist das System vor dem Ausfall weiterer Da-
tenträger geschützt. Storage Space Direct bietet eine Kombination aus Kopie und
Parität, um Speichereffizienz und -geschwindigkeit zu verbessern [14] [15].
42
Bild 4.29: NTFS Master File Table der virtueller Disk
Bild 4.30: NTFS Master File Table auf phsischer Disk identifiziert
43
Speichern und Einbinden
Das Duplizieren von WSS-Datenträgern ist ebenfalls einfach. Ist das System, dessen
Daten zu speichern sind, zugänglich, kann die virtuelle Festplatte mit den geeigneten
Mitteln gesichert werden. Das Programm DiskDumper erstellt ein RAW-Image des
gewünschten Laufwerks und berechnet anschließend den MD5-Hash. Für die Aus-
wertung von Offline-Datenträgern empfiehlt es sich, diese in einem Auswertesystem
mit einem aktuellen Windows schreibgeschützt einzubinden. Windows erkennt die
Datenträger und bindet den Storage Space entsprechend ein. Diese Vorgehensweise
ist vorteilhaft, da die genauen Funktionsweise des WSS von Microsoft nicht öffent-
lich zugänglich sind. Somit besteht hierbei die höchste Wahrscheinlichkeit, dass alle
Daten zugänglich sind.
Alternativ gibt es Softwareprodukte, die die Windows Storage Spaces dennoch ein-
binden können. Die Entwickler von R-Studio haben den Aufbau der WSS rekon-
struiert, sodass sie die Konfiguration zuverlässig interpretieren und das Laufwerk
anschließend bereitstellen können. Diese Funktion ist in der kostenpflichtigen Ver-
sion verfügbar. Daher wird im Rahmen dieser Projektarbeit nicht weiter darauf
eingegangen.
Bild 4.31: Datenträger sichern mit DiskDumper
44
4.5 Zusammenfassung
Zusammenfassend ist festzuhalten, dass das Wiederherstellen verteilter Speicher-

konfigurationen sehr vom verwendeten Produkt abhängt. Bei Open Source Lösun-
gen ist das Wiederherstellen der Datenstruktur kein Hindernis. Durch die Vielzahl
von RAID-Herstellern ist es empfehlenswert die von RAID-Controller bereitgestellte
Disk mit Hilfe des eigenen Forensik-Systems zu duplizieren. Bei proprietären Spei-
cherlösungen, wie Microsofts Windows Storage Spaces, ist zu empfehlen eine Kopie
während des laufenden Windows-Systems zu erstellen. Das ist die zuverlässigste
Option.
45
Kapitel 5. Verschlüsselte Datenträger
5 Verschlüsselte Datenträger
5.1 Einleitung
Heutzutage stehen für die am Markt relevanten Betriebssysteme integrierte Mög-

lichkeiten zur Verfügung, mit geringem Aufwand, sowohl im Computersystem einge-
baute als auch extern angeschlossene, Datenträger zu verschlüsseln. Besonders auf
Notebooks und für mobile Datenträger im Enterprise-Umfeld wird der Einsatz von
Verschlüsselungen empfohlen. Zusätzlich können, bei entsprechendem Schutzbedarf,
auch stationäre Arbeitsplatzrechner und sogar Server verschlüsselt werden [16].
Auch im privaten Umfeld sind die Hürden, eine Datenträgerverschlüsselung ein-
zusetzen, überschaubar. So bietet Apple seit OS X Lion eine, im Betriebssystem
integrierte, Festplattenverschlüsselung (FileVault2) an, welche mit wenigen Klicks
eingeschaltet werden kann [17]. Beliebte Linux Distributionen bieten einfache, grafi-
sche Einrichtungstools für die Festplattenverschlüsselung mit Bordmitteln [18] und
für Windows kann Microsoft die BitLocker-Geräteverschlüsselung sogar automatisch
aktivieren, wenn die Hardware es unterstützt [19].
Aufgrund der Sicherheitsempfehlungen für Unternehmen sowie den einfach einzu-
richten und zum Teil auch automatisch aktiven Verschlüsselungstools für privat ge-
nutzte Geräte steigt die Wahrscheinlichkeit, bei der forensischen Analyse von Com-
putersystemen auf verschlüsselte Datenträger zu treffen.
In diesem Kapitel werden die in Windows, Linux und macOS integrierten Verschlüs-
selungstools vorgestellt und betrachtet, wie eine damit verschlüsselte Systemparti-
tion zur Analyse der enthaltenen Daten entschlüsselt werden kann.
5.2 Festplattenverschlüsselung
Um Daten auf Datenträgern zu verschlüsseln gibt es mehrere Ansätze. Zum einen

können einzelne Dateien verschlüsselt und in dieser Form, wie jede andere Datei, im
Dateisystem des Speichermediums abgelegt werden (z. B. Windows Encrypting File
System (EFS), Encrypted Filesystem (EncFS), ZIP mit Verschlüsselung). Zum an-
deren kann ein gesamter Datenträger bzw. eine Partition verschlüsselt werden. Das
46
Dateisystem befindet sich in diesem Fall eine logische Schicht über der Verschlüsse-
lung. Diese Technik sorgt dafür, dass ein Image einer so verschlüsselten Partition nur
unleserliche Daten enthält, die vor der weiteren forensischen Analyse entschlüsselt
werden müssen, um auf das Dateisystem zugreifen zu können.
In dieser Arbeit liegt der Fokus auf der Entschlüsselung vollständig verschlüsselter
Betriebssystem-Partitionen.
5.3 Verschlüsselungstools
Am Markt sind eine Vielzahl von Verschlüsselungsprogrammen verfügbar, mit de-

nen Datenträger blockweise verschlüsselt werden können. In diesem Abschnitt wird
für jedes aktuelle, populäre Desktop-Computer Betriebssystem (Windows, Linux,
macOS) die jeweils integrierte (kann je nach Betriebssystemedition/ Distribution
abweichen) Verschlüsselungsmethode vorgestellt. Zusätzlich wird das, für alle Be-
triebssysteme verfügbare, VeraCrypt betrachtet.
5.3.1 Microsoft BitLocker
Überblick
Microsoft BitLocker ist eine Festplattenverschlüsselung, die Microsoft seit Windows

Vista/ Windows Server 2008 als Betriebssystemkomponente ausliefert. BitLo-
cker ist in der Lage neben portablen Geräten und Datenpartitionen auch die
Betriebssystempartition zu verschlüsseln. Dafür wird eine kleine, unverschlüsselte
Systempartition angelegt, von der zuerst gebootet wird. Das dort abgelegte System
entschlüsselt und lädt danach das eigentliche Betriebssystem aus der verschlüsselten
Betriebssystempartition [20].
Die zu verschlüsselnde Partition wird mit Hilfe eines symmetrischen Schlüssels, dem
Full Volume Encryption Key (FVEK), verschlüsselt. Der FVEK wiederum wird
mit dem so genannten Volume Master Key (VMK) verschlüsselt. Der VMK wird
ebenfalls verschlüsselt. Die Art des Schlüssels kann dabei variieren. Computer, die
über ein Trusted Platform Module (TPM) verfügen, können dieses zur Verschlüs-
selung des VMK nutzen. Alternativ (oder auch zusätzlich) kann der Schlüssel mit
einem Kennwort geschützt werden. Vom VMK können mehrere, mit jeweils einem
anderen Schlüssel verschlüsselte, Kopien angelegt werden [21, S. 7]. Das ermöglicht
es z. B. das System im normalen Betrieb mittels des Schlüssels aus dem TPM zu
entschlüsseln aber auch einen Wiederherstellungsschlüssel zu erzeugen, der an einer
47
Bild 5.1: BitLocker Key Architecture. Entnommen aus: [21, S. 9]
anderen Stelle abgelegt wird, falls die Entschlüsselung per TPM (z. B. wegen eines
Hardwaredefekts oder einer Integritätsverletzung) scheitert. Bild 5.1 zeigt eine
Übersicht der möglichen Schlüssel. Der verschlüsselte FVEK sowie die Kopien des
verschlüsselten VMK werden in einer unverschlüsselten Datenstruktur (BitLocker
Metadaten) an drei Stellen (Anfang, Mitte, Ende) auf der ansonsten verschlüsselten
Partition abgelegt. Die BitLocker Metadaten-Strukturen beginnen mit der Signatur
„-FVE-FS-“ [22, S. 4]. Wird diese Signatur in einem Partitionsimage gefunden, so
ist die Partition höchstwahrscheinlich mit BitLocker verschlüsselt.
Schlüsselgewinnung
Damit das Image einer mit BitLocker verschlüsselten Partition entschlüsselt werden
kann, wird entweder der FVEK, der VMK oder ein Schlüssel für den VMK be-
nötigt. Alle Schlüssel, die zur Laufzeit unverschlüsselt im Arbeitsspeicher abgelegt
sind, werden, wenn BitLocker sie zur Entschlüsselung gerade nicht benötigt, über-
schrieben [21, S. 13]. Da der VMK nur für einen kurzen Moment zum Entschlüsseln
des FVEK benötigt wird, ist es unwahrscheinlich den VMK im Random-Access Me-
mory (RAM) auffinden zu können. Der FVEK jedoch wird während der gesamten
Laufzeit des Systems im RAM gehalten und kann aus einem Memory Dump ausge-
lesen werden [23]. Auf diese und andere Techniken zur Gewinnung des FVEK aus
einem laufenden System/ RAM Image oder einem Angriff auf das TPM wird in
48
Bild 5.2: Partitionstabelle einer Festplatte mit einer BitLocker-Partition
dieser Arbeit nicht eingegangen.

Für die Entschlüsselung wird angenommen, dass ein Wiederherstellungsschlüssel
bekannt ist. Diese werden in Unternehmen z. B. im ActiveDirectory oder einer
Schlüsselverwaltungsdatenbank eines Drittanbieters abgelegt. Darüber hinaus kön-
nen auch externe Speichermedien (z. B. USB-Sticks) als Schlüsselspeicher dienen.
Zuletzt bietet BitLocker auch die Möglichkeit einen Schlüssel auszudrucken oder
in einem Microsoft-Konto in der Cloud abzulegen [24]. Für die Analyse der Daten
muss zusätzlich zum Image der verschlüsselten Partition demnach auch ein Schlüssel
gefunden werden.
Entschlüsselung
Für diese Arbeit wurde die Betriebssystempartition einer Windows 10 Virtual

Machine (VM) (ohne TPM) mit BitLocker verschlüsselt. Der VMK wird durch
ein Startpasswort geschützt. Zusätzlich wurde (automatisch) ein Wiederherstel-
lungsschlüssel erstellt. Im Anschluss wurde die virtuelle Festplatte an eine Ubun-
tu Linux VM angehängt und mit dd als RAW-Image kopiert. Mit mmls aus der
Programmsammlung “The Sleuth Kit„ wird die Partitionstabelle betrachtet (Bild
5.2). Aufgrund der Größe der Partitionen wird geschlossen, dass es sich bei der
größeren New Technology File System (NTFS) Partition um die Betriebssystem-
Partition handelt. Diese wird an ein Loop-Device gebunden. Mit Hilfe des head
Befehls wird der Beginn der Partition ausgelesen. Anhand der Signatur „-FVE-
FS-“ (Bild 5.3) ist erkennbar, dass es sich tatsächlich um die mit BitLocker ver-
schlüsselte Partition handelt. Um die Partition weiter zu analysieren wird dislo-
cker (https://github.com/Aorimn/dislocker) eingesetzt. Der Befehl dislocker-
metadata gibt weitere Informationen über die verschlüsselte Partition aus (Bild 5.4).
49
Bild 5.3: BitLocker Signatur am Beginn der Partition
Bild 5.4: Metadaten der mit BitLocker verschlüsselten Partition
Die verschlüsselte Partition wird mittels dislocker-fuse und dem, beim Einschalten
der Verschlüsslung erstellten, Recovery Key entschlüsselt und danach eingehängt.
Dislocker unterstützt verschiedene Arten von Schlüsseln (siehe Abschnitt „Schlüs-
selgewinnung“) um die Partition zu entschlüsseln. Mit dem Parameter „-r“ wird die
Partition nur lesend eingebunden, um Veränderungen zu vermeiden. Wie in Bild 5.5
erkennbar, kann nun auf den Inhalt der Partition zugegriffen werden.
5.3.2 FileVault 2
Überblick
FileVault2 ist ein in macOS integriertes Verschlüsselungstool. Seit Version 2 unter-

stützt FileVault die Verschlüsselung des Betriebssystem-Volumes [17]. Moderne Ver-
sionen von macOS nutzen das Apple-eigene Dateisystem Apple File System (APFS)
für die Systemfestplatte/SSD. APFS legt auf dieser Platte einen so genannten Con-
tainer (entspricht einer Partition) an. Dieser Container enthält bei einem mit Fi-
50
Bild 5.5: BitLocker verschlüsselten Partition entschlüsselt einhängen
leVault verschlüsselten Betriebssystem mindestens drei Volumes. Ein Volume ist

verschlüsselt und enthält das Betriebssystem, ein Volume ist nicht verschlüsselt und
enthält die Daten, die zum Start des Betriebssystems notwendig sind (Preboot) und
ein drittes Volume ist ein Recovery Volume [25].
Bei der Aktivierung von FileVault wird im Preboot-Volume 1 die Datei „Encrypte-
dRoot.plist.wipekey“ erstellt. Es handelt sich dabei um ein XML-File, dessen Inhalt
zum größten Teil mit einem - im Header des zugehörigen System-Volumes befind-
lichen - Schlüssel verschlüsselt ist. Diese Datei enthält den Volume Key, mit dem
das System-Volume verschlüsselt ist. Der Volume Key wiederum ist mit einem Key-
Encryption-Key verschlüsselt. Vom Key-Encryption-Key existieren mehrere Kopi-
en, welche mit jeweils unterschiedlichen Schlüsseln verschlüsselt sind. Diese Schlüs-
sel können Passwörter der Systembenutzer, ein Recovery-Key oder ein Zertifikat
sein [26].
Apple-Geräte mit eingebautem T2-Chip erzeugen eine zusätzliche Hürde bei der Er-
stellung eines Images der Systemfestplatte/SSD. Alle Zugriffe auf das Medium laufen
über den T2-Chip und werden dort mit einem an die Hardware gebundenen Schlüssel
verschlüsselt. In diesem Fall wird die Hardware, zu welcher der Datenträger gehört
benötigt, um das Medium zu entschlüsseln. Innerhalb dieser Verschlüsselung kann
zusätzlich noch eine FileVault Verschlüsselung aktiv sein [27]. Auf dieses Szenario
(Verschlüsselung mit T2-Chip) wird in dieser Arbeit nicht eingegangen.
Schlüsselgewinnung
Beim Einschalten von FileVault wird ein Recovery-Key erzeugt. Dieser kann ent-
weder lokal ausgegeben und z. B. ausgedruckt oder in einen iCloud-Account hoch-
geladen werden. Besteht Zugriff auf den iCloud Account des Gerätebesitzers, kann
1
In der Quelle [26] wird beschrieben, dass die Datei sich in der Recovery-Partition befindet. Bei
dem für diese Arbeit installierten System (macOS 10.14 Mojave in einer VMWare VM) war die
Datei jedoch im Preboot-Volume abgelegt.
51
Bild 5.6: APFS/ FileVault2 Partitionstabelle - mmls
der Account unter Umständen zum Abrufen des Wiederherstellungsschlüssel genutzt

werden [28]. Neben dem Recovery Key kann das Passwort eines Benutzeraccounts,
der zum Entschlüsseln des Volumes berechtigt ist, verwendet werden. Darüber hin-
aus kann (besonders in Enterprise Umgebungen) ein Zertifikat zur Entschlüsselung
hinterlegt werden [26].
Liegt ein RAM-Dump des zu entschlüsselnden Systems vor, kann der Volume Key
auch daraus extrahiert werden [29]. Für diese Arbeit wird jedoch angenommen, dass
der Recovery-Key bekannt ist.
Entschlüsselung
Für diese Arbeit wurde eine VMWare VM mit macOS 10.14 installiert und das
System-Volume mit FileVault verschlüsselt. Der Recovery-Key wurde nicht in der
iCloud abgelegt sondern am Bildschirm ausgegeben. Die Partitionstabelle der VM
wird, mit mmls betrachtet, nur unzureichend dargestellt (Bild 5.6), da mmls in der
eingesetzten Version nicht mit APFS umgehen kann. Um weitere Informationen über
die im Image enthaltenen Partitionen, Container und Volumes zu erhalten, wird die
apfs-fuse Toolsammlung genutzt (https://github.com/sgan81/apfs-fuse). Mit
dem enthaltenen apfsutil können die Volumes im APFS angezeigt werden (Bild 5.7).
Unter Angabe des Recovery-Keys (oder eines Passworts) kann das verschlüsselte
System-Volume mit apfs-fuse eingebunden werden (Bild 5.8). Der Zugriff erfolgt in
der genutzten Programmversion (vom 20 April 2019) nur lesend und die Software
befindet sich noch im experimentellen Stadium.
52
Bild 5.7: APFS/ FileVault2 Partitions-/ Volumeinformationen - apfsutil
Bild 5.8: FileVault2 verschlüsselte Partition einbinden
53
5.3.3 LUKS/ dm-crypt
Überblick
DM-Crypt ist ein, im aktuellen Linux-Kernel enthaltenes, Modul um Daten ver-

schlüsselt auf Block-Devices zu schreiben und davon zu lesen [30]. DM-Crypt wird
durch LUKS um einen Rahmen erweitert, der das Schlüsselmanagement standar-
disiert und vereinfacht. LUKS arbeitet auch mit anderen Verschlüsselungsmodulen
zusammen [31, S. 1]. In diesem Kapitel wird „LUKS“ jedoch synonym für die Kom-
bination aus DM-Crypt und LUKS2 verwendet.
LUKS ermöglicht es, sowohl verschlüsselte Containerdateien zu erzeugen als auch
ganze Partitionen und Festplatten zu verschlüsseln. Dazu wird ein Header erzeugt,
der Metadaten zur Konfiguration der Verschlüsselung enthält. Der Header ist erkenn-
bar an der Signatur „LUKS“ und beginnt mit einem Binärobjekt, welches grund-
legende Daten zur eingesetzten Verschlüsselung enthält. Darauf folgt eine JSON
Struktur, welche unter anderem Informationen über die verwendeten Keyslots und
deren Speicherort enthält. Ein Keyslot ist eine Datenstruktur, die den Schlüssel
zur mit dm-crypt erzeugten Datenverschlüsselung in verschlüsselter Form enthält.
LUKS2 unterstützt bis zu 32 Keyslots, also Schlüssel um auf den dm-crypt-Schlüssel
zuzugreifen [32].
Diese Schlüssel können Passwörter sein, es sind aber auch Schlüsseldateien auf ex-
ternen Datenträgern (auch im nicht allokierten Bereich), Hardwaretoken, Schlüssel
im TPM oder andere Verfahren denkbar.
Seit LUKS2 ist der Header redundant vorhanden (nur der Header, nicht die Keys-
lots) und es ist möglich, den Header auch außerhalb der verschlüsselten Partition
aufzubewahren [32]. Damit würde die Signatur „LUKS“ als Identifikationsmerkmal
auf dem Datenträger fehlen.
Schlüsselgewinnung
Da die Schlüssel der LUKS Keyslots sehr unterschiedliche Daten an verschiedensten

Orten sein können, gibt es keine allgemeingültige Vorgehensweise um die Schlüssel
aufzuspüren. Ist das System jedoch noch eingeschaltet und kann bedient werden,
so können die Schlüssel mittels dmsetup table –showkeys aus dem laufenden System
ausgelesen werden. Mit den so gewonnen Informationen kann ein eigener Schlüssel
für einen Keyslot erzeugt werden [33].
Liegt zu dem verschlüsselten Datenträger ein RAM-Dump des Systems von einem
54
Bild 5.9: Ubuntu Installationsoptionen
Zeitpunkt vor, zu dem die Daten entschlüsselt waren, so kann der Schlüssel auch
daraus gewonnen werden [34]. Für diese Arbeit wird jedoch angenommen, dass ein
Schlüssel für einen LUKS Keyslot vorliegt.
Entschlüsselung
Für diese Arbeit wurde eine Ubuntu 19.04 Desktop Installation mit den im In-
stallationsdialog (Bild 5.9) angebotenen Verschlüsselungsoptionen verschlüsselt. In
dem verschlüsselten Bereich auf der Festplatte wurde mit Hilfe von LVM eine Vo-
lume Group angelegt. Darin befinden sich die /root- und die swap-Partition. Dies
wird erreicht, indem die abgebildeten Optionen während der Installation angewählt
werden. Von dem installierte System wurde mit ewfacquire ein Image (Dateiname
„image.e*“) erstellt. Dieses wird nun ausgewertet.
Im ersten Schritt wird die Partitionstabelle des Images mit mmls betrachtet (Bild
5.10). Es werden zwei „Linux-Partitionen“ erkannt. In der ersten ist ein minimales
Linux zum Booten des eigentlichen Betriebssystems enthalten. Dieses befindet sich,
wie in Bild 5.11 erkennbar, verschlüsselt in der zweiten Partition, deren Dateisys-
tem (wegen der Verschlüsselung) nicht bestimmt werden kann. Um die verschlüssel-
te Partition analysieren zu können, wird das mit ewfacquire erstellte Image mittels
Xmount bereitgestellt (siehe 5.12). Im Anschluss wird die verschlüsselte Partition
als loop-Device eingebunden (Bild 5.13). An der Signatur „LUKS“ am Partitionsbe-
ginn ist erkennbar, dass es sich tatsächlich um die verschlüsselte Partition handelt.
Mit dem Tool cryptsetup werden die Metadaten der verschlüsselten Partition an-
gezeigt (Bild 5.14). Damit das verschlüsselte Dateisystem lesbar wird, wird es mit
55
Bild 5.10: Partitonstabelle des verschlüsselten Ubuntu
Bild 5.11: Dateisysteme der Linux Partitionen
Bild 5.12: EWF Image mit Xmount einbinden
Bild 5.13: LUKS Partition als Loop-Device bereitstellen
56
Bild 5.14: LUKS Header mit cryptsetup anzeigen
57
Bild 5.15: Partition entschlüsseln und LVM Volumes mappen
cryptsetup entschlüsselt. Die entschlüsselte Partition wird unter „/dev/mapper“ ein-

gehängt. Da bei der Installation des Betriebssystems LVM verwendet wurde, kann
noch nicht auf die Daten der gemappten Partition zugegriffen werden. Mittels lvm
pvscan werden die eingebundenen Datenträger nach vom LVM verwalteten Devi-
ces durchsucht. Diese werden ebenfalls unter „/dev/mapper“ eingehängt. Die Daten
können nun analysiert werden (Bild 5.15).
5.3.4 VeraCrypt
Überblick
VeraCrypt ist ein freies, auf TrueCrypt basierendes, Verschlüsselungstool. Es ist für
Windows, Linux und macOS verfügbar und kann sowohl verschlüsselte Container
erstellen als auch ganze Partitionen/ Speichermedien verschlüsseln. Daneben kann
ein installiertes Windows vollständig verschlüsselt werden (pre-boot authenticati-
on) [35]. Eine solche Konfiguration kann daran erkannt werden, dass der VeraCrypt-
Bootloader am Anfang der Festplatte abgelegt wird. Der Bootloader kann jedoch
auch auf einem externen Medium gespeichert werden (VeraCrypt Rescue Disk) [36].
Grundsätzlich verfolgt VeraCrypt den Ansatz, dass neben der Verschlüsselung auch
das Vorhandensein der verschlüsselten Daten möglichst schlecht erkennbar ist. Es
wird deshalb auf eine unverschlüsselt lesbare Signatur zu Beginn einer verschlüssel-
ten Partition verzichtet. Darüber hinaus ist es möglich, versteckte Container anzu-
legen.
Eine mit VeraCrypt verschlüsselte Partition beginnt mit einem Header, welcher den
eigentlichen Schlüssel zur Verschlüsselung der Daten enthält. Der Header selber ist
ebenfalls verschlüsselt [37]. Um den Header zu verschlüsseln, können bei der System-
verschlüsselung nur Passwörter genutzt werden [38]. Die Architektur unterstützt nur
58
einen Schlüssel pro verschlüsseltem Medium. Um die Sicherheit zu erhöhen kann -

zusätzlich zum Passwort - ein Personal Iterations Multiplier (PIM) angegeben wer-
den. Dieser beeinflusst die Anzahl der Iterationen der Funktion, die aus dem an-
gegebenen Passwort den eigentlichen kryptographischen Schlüssel für den Header
erzeugt [39]. Wird kein PIM angegeben, wird eine Standardanzahl an Iterationen
der Schlüsselableitungsfunktion genutzt.
Schlüsselgewinnung
Der Schlüssel zur Entschlüsselung des VeraCrypt Headers kann bei einer System-
verschlüsselung nur ein Passwort - optional erweitert durch ein PIM - sein. Einen
Recovery-Key gibt es nicht - lediglich eine Rescue Disk, welchen den Header zum
Zeitpunkt der Erstellung der Recovery Disk enthält. Das Passwort kann unter Um-
ständen ein anderes sein, als das aktuell genutzte, wenn die Disk nach einer Pass-
wortänderung nicht vernichtet und neu erstellt wurde.
Liegt ein Memory Dump des Systems bei entschlüsselter Partition vor, kann dar-
aus der Schlüssel für die Daten extrahiert werden [40]. Läuft das System noch mit
entschlüsselter Partition und kann es bedient werden, kann - bei vorhandenen ad-
ministrativen Berechtigungen - das Entschlüsselungspasswort auf einen bekannten
Wert gesetzt werden [41]. Für diese Arbeit wird davon ausgegangen, dass das Pass-
wort bekannt ist und kein PIM vergeben wurde.
Entschlüsselung
Für diese Arbeit wurde eine Windows 10 Installation mittels VeraCrypt verschlüs-
selt. Dabei wurde mit der Option „Die Windows System-Partition verschlüsseln“ ge-
arbeitet. Von der gesamten Festplatte wurde mit dd ein RAW Image (veracrypt.img)
erstellt. Die Partitionsstruktur, mit mmls betrachtet, ist in Bild 5.16 abgebildet.
Um die verschlüsselte Partition öffnen zu können, genügt es nicht nur sie alleine als
Loop-Device einzuhängen (Bild 5.17). Es wird ein partitioniertes Gerät und keine
einzelne Partition erwartet. Dies wird erreicht, indem losetup mit dem Parameter
„-P“ aufgerufen wird. Der Parameter „-f“ wählt automatisch das nächste, freie Loop-
Device. Nachdem das Image mit allen Partitionen als Loop-Device eingehängt ist,
kann die verschlüsselte Betriebssystem-Partition mit VeraCrypt entschlüsselt und
gemountet werden. Dabei ist darauf zu achten, dass wie in Bild 5.18 der Parameter
„–mount-options=ro,system“ angegeben wird, damit die Partition ReadOnly einge-
bunden und als verschlüsselte Systempartition mit pre-boot authentication erkannt
59
Bild 5.16: Partitionstabelle des mit VeraCrypt verschlüsselten Windows
Bild 5.17: Image mit Partitionen als Loop-Device einbinden
wird. Bei der Verschlüsselung wurde der PIM nicht gesetzt und Schlüsseldateien
können für dieses Szenario nicht genutzt werden. Somit muss lediglich das Passwort
zur Entschlüsselung angegeben werden.
Eine alternative Möglichkeit die Partition zu mounten ist cryptsetup. Dafür muss
das Image ebenfalls vollständig als Loop-Device eingehängt werden (siehe Bild 5.17).
cryptsetup wird nun so aufgerufen, dass es eine, mit VeraCrypt verschlüsselte, Sy-
stempartition öffnen soll. Die entschlüsselte Partition wird unter „/dev/mapper“
eingehängt und kann gemountet werden. Diese Variante ist in Bild 5.19 zu sehen.
Bild 5.18: VeraCrypt Partition einbinden
60
Bild 5.19: VeraCrypt Partition mit cryptsetup einbinden
5.4 Zusammenfassung
In diesem Kapitel wurde eine Übersicht über die im Betriebssystem integrierten

Verschlüsselungstools in Windows, Linux und macOS sowie das Tool VeraCrypt
gegeben. Alle haben die Tatsache gemeinsam, dass der Master Key, mit dem die
Systempartition tatsächlich verschlüsselt wird, für die Entschlüsselung bei der fo-
rensischen Analyse nur dann eine Rolle spielt, wenn er aus dem laufenden System
oder einem Speicherabbild gewonnen werden muss/ kann. Wird für die forensische
Analyse ein heruntergefahrenes (also vollständig abgeschaltetes) System vorgefun-
den zu welchem kein RAM-Dump verfügbar ist, ist es zielführender die Schlüssel,
mit denen der Master Key (direkt oder indirekt - je nach Schlüsselverwaltung des
genutzten Tools) verschlüsselt wurde, herauszufinden.
Stammt das zu analysierende System aus einer Enterprise-Umgebung und handelt
es sich um eine Windows oder macOS Installation, bestehen gute Chancen, dass
über die IT-Ableitung ein Recovery-Key bezogen werden kann. Sowohl BitLocker
als auch FileVault sehen explizit die Möglichkeit vor, solche Schlüssel zentral zu ver-
walten. Auch für eine, mit LUKS geschützte, Linux Installation kann ein Recovery
Key vorliegen. Bei VeraCrypt ist dies ausgeschlossen, da für die Entschlüsselung des
Master Keys nur ein einzelnes, „normales“ Passwort genutzt werden kann.
Sowohl Microsoft als auch Apple bieten für ihre Verschlüsselungstools die Möglich-
keit, einen Wiederherstellungsschlüssel in der Cloud abzulegen. Besteht Zugriff auf
ein solches Cloud-Konto, welches mit dem zu analysierenden Gerät in Verbindung
steht, könnte dort ein Recovery-Key abgelegt sein. BitLocker und LUKS bieten
darüber hinaus die Möglichkeit, Schlüssel auf externen Speichermedien (z. B. USB-
Sticks) zu hinterlegen. Nach solchen Geräten sollte bei der Sicherung des zu analy-
sierenden Systems Ausschau gehalten werden.
Zuletzt bleibt noch die Möglichkeit, dass ein Recovery-Key oder ein Passwort zur
Entschlüsselung in ausgedruckter/ aufgeschriebener Form vorliegt.
Für die Entschlüsselung der Datenträger (bzw. daraus entstandener Images) stehen
unterschiedliche Tools zur Verfügung. Pro Verschlüsselungstool wurde mindestens
61
ein freies Programm zur Entschlüsselung vorgestellt. Bei modernen Apple-Geräten

mit T2 Chip muss beachtet werden, dass der eingebaute Datenträger unter Umstän-
den nur mit einem Schlüssel gelesen werden kann, der fest im Chip einprogrammiert
ist.
62
Kapitel 6. Fazit
6 Fazit
Zusammenfassend lässt sich sagen, dass die Forensik strengen Reglements in Bezug
auf gesetzliche Regelungen, als auch ethisch und moralisch richtigem Handeln,
unterlegen ist. Dies gilt nicht nur für behördliche Ermittlungen, welche besonders
streng geregelt sind, sondern auch bei Ermittlungen im „privaten“ Umfeld. In
jedem Fall ist die Dokumentation, eine damit verbundene Nachvollziehbarkeit der
Ermittlungen, hier an erster Stelle zu nennen. Dieses stellt eine Rechtssicherheit
(Beweissicherheit) her. Die Integrität der Daten muss in jedem Fall gewahrt
werden, wofür Write-Blocker zum Einsatz kommen, damit bei der Analyse die
Unveränderlichkeit der Daten garantiert werden kann.
Aufgrund vieler vorhandener RAID-Systeme/ -Level ist eine pauschale Aussage

zur Wiederherstellbarkeit der Daten bzw. des Systems nicht möglich. Hier ist
eine Vielzahl von Tools vorhanden, welche sowohl auf verschiedenen Plattformen
lauffähig sind, als auch verschiedene RAID-Level unterstützen. Somit hängt die
Tiefe der Analyse vom verwendeten Tool ab. Das hier verwendete Tool R-Studio
bietet einen sehr großen Funktionsumfang, ist jedoch kostenpflichtig - will man den
kompletten Funktionsumfang nutzen. Ebenso ist es auf allen gängigen Betriebssys-
temen einsetzbar.
Für die blockweise Datenträgerverschlüsselung gibt es diverse Tools, welche eine

Verschlüsselung der Betriebssystempartition vornehmen können (z. B. Microsoft
BitLocker, LUKS). Eine Entschlüsselung der Partition zur weiteren Analyse der
Daten stellte keine nennenswerten Probleme dar. Vorausgesetzt ist die Verfüg-
barkeit eines Passwortes/ Passphrase, welches zum Schutz des kryptographischen
Festplattenschlüssels verwendet wurde. Die entsprechenden Passwörter können u.
a. durch Hacking, Phishing oder mit Hilfe der IT-Abteilung o. ä. beschafft werden.
Die an eine bestimmte Hardware gebundene Verschlüsselung, beziehungsweise die
damit verbundene Entschlüsselung, stellt eine größere Herausforderung dar. Hier
gibt es einen Chipsatz (z. B. Apple T2-Chip), welcher die Entschlüsselung der
63
Kapitel 6. Fazit
Datenträger nur mit der dazugehörigen Hardware vornehmen kann. Somit können
Datenträger eines Rechners nicht ohne den dazugehörigen Chip entschlüsselt werden.
Zu den Datenträgern an sich lässt sich zusammenfassend sagen, dass bei der Rekon-
struktion von Daten auf Flash-Speichern größere Probleme auftreten als bei HDDs.
Eine Wiederherstellung verborgener Daten ist kaum oder gar nicht möglich ist, so-
fern der TRIM-Befehl und die Garbage Collection aktiv sind. Ist der TRIM-Befehl
deaktiviert, so wird die Garbage-Collection nicht angesprochen. Dadurch bleiben die
Daten einer Speicherzelle bis zum nächsten Schreibprozess in dieser Zelle erhalten.
64
Literaturverzeichnis
[1] Geschonneck, Alexander: Computer-Forensik: Computerstraftaten erkennen,

ermitteln, aufklären. 6., aktualisierte und erweiterte Auflage. Heidelberg, Ger-
many : dpunkt.verlag, 2014 (iX-Edition). – ISBN 9783864901331
[2] Hans-Peter Merkel: Die Afflib als Ersatz für proprietäre Forensiktools. In:
Linux-Magazin 2009 (2009), Nr. 08
[3] Bundesamt für Sicherheit in der Informationstechnik: Leitfaden

"IT-Forensik". https://www.bsi.bund.de/SharedDocs/Downloads/DE/
BSI/Cyber-Sicherheit/Themen/Leitfaden_IT-Forensik.pdf?__blob=
publicationFile&v=2. Version: März 2011
[4] Hudy, Felix: Macht sich der private IT-Forensiker bei seinen Ermitt-
lungen strafbar? https://www.datenschutzbeauftragter-info.de/
macht-sich-der-private-it-forensiker-bei-seinen-ermittlungen-strafbar/.
Version: 18.01.2017
[5] Ackermann ; Clages ; Roll: Handbuch der Kriminalistik: Kriminalistik

für Praxis und Ausbildung. 5. Stuttgart : Richard Boorberg, 2019. – ISBN
9783415060258
[6] Scherer, Daniel: Forensische Analyse von Flash-Speichern: Ba-

chelorarbeit von Daniel Scherer. 1. CreateSpace Indepen-
dent Publishing Platform, 17.06.2015 https://www.amazon.de/
Forensische-Analyse-von-Flash-Speichern-Bachelorarbeit-ebook/
dp/B00ZV8C590/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=. – ISBN
1514376466
[7] Wikipedia: RAID. https://de.wikipedia.org/wiki/RAID,
[8] Ubuntu: FakeRaidHowto. https://help.ubuntu.com/community/

FakeRaidHowto, unbekannt
[9] Sharkoon: Spezifikation Sharkoon 5-Bay RAID Station. http://de.

sharkoon.com/product/1238/12909#specs,
65
[10] R-Studio: R-Studio Homepage. https://r-studio.com,
[11] Wikipedia: Mdadm. https://de.wikipedia.org/wiki/Mdadm,
[12] Carrier, Brian: File system forensic analysis. 10. print. Upper Saddle River,
NJ : Addison-Wesley, 2011. – ISBN 0321268172
[13] greenstack: greenstack VLM. https://greenstack.files.wordpress.

com/2014/09/lvm.png,
[14] Cosmos Darwin ; TECHNET (Hrsg.): Deep Dive: The Sto-

rage Pool in Storage Spaces Direct. TECHNET : https:
//techcommunity.microsoft.com/t5/Storage-at-Microsoft/
Deep-Dive-The-Storage-Pool-in-Storage-Spaces-Direct/ba-p/425959,
2016
[15] cosmosdarwin: Fault tolerance and storage efficiency in Storage Spaces Di-
rect. TECHNET : https://docs.microsoft.com/en-us/windows-server/
storage/storage-spaces/storage-spaces-fault-tolerance#examples,
2017
[16] BSI: IT-Grundschutz: M 4.433 Einsatz von Datenträgerverschlüs-

selung. https://www.bsi.bund.de/DE/Themen/ITGrundschutz/
ITGrundschutzKataloge/Inhalt/_content/m/m04/m04433.html?nn=
6610622, 15. EL Stand 2016
[17] Apple Inc.: Das Startvolume Ihres Mac mit FileVault verschlüsseln. https:
//support.apple.com/de-de/HT204837, Januar 03, 2018
[18] Apfelböck, Hermann: Linux-Verschlüsselung: So sichern

Sie Ihre Daten ab. https://www.pcwelt.de/ratgeber/
Linux-Verschluesselung-Daten-absichern-9802537.html, 29.01.2018
[19] Microsoft ; Microsoft Docs (Hrsg.): Overview of BitLo-

cker Device Encryption in Windows 10. https://docs.microsoft.
com/en-us/windows/security/information-protection/bitlocker/
bitlocker-device-encryption-overview-windows-10, 28.02.2019
[20] Microsoft Docs: BitLocker: BitLocker overview. https://docs.

microsoft.com/en-us/windows/security/information-protection/
bitlocker/bitlocker-overview, 26.01.2018
66
[21] Microsoft Corporation: BitLockerTM Drive Encryption Security Po-

licy: For FIPS 140-2 Validation. https://csrc.nist.gov/csrc/media/
projects/cryptographic-module-validation-program/documents/
security-policies/140sp947.pdf, 31.08.2011
[22] Kornblum, Jesse D.: Implementing BitLocker Drive Encryption for forensic
analysis. In: Digital Investigation 5 (2009), Nr. 3-4, S. 75–84. http://dx.doi.
org/10.1016/j.diin.2009.01.001. – DOI 10.1016/j.diin.2009.01.001. – ISSN
17422876
[23] Marcin Ulikowski: Volatility Framework plugin for extracting BitLocker

FVEK. https://github.com/elceef/bitlocker, 16.05.2016
[24] Microsoft Docs: Prepare your organization for BitLo-

cker: Planning and policies. https://docs.microsoft.com/
en-us/windows/security/information-protection/bitlocker/
prepare-your-organization-for-bitlocker-planning-and-policies,
24.04.2019
[25] Apple Inc.: macOS Sicherheit–Überblick für die IT. https://www.apple.

com/de/business/resources/docs/macOS_Security_Overview.pdf,
[26] Metz, Joachim ; Choudary, Omar ; Grobert, Felix: IFIP Advances in Infor-
mation and Communication Technology. Bd. v.410: Security Analysis and De-
cryption of Filevault 2: 9th IFIP WG 11. 9 International Conference on Digital
Forensics, Orlando, FL, USA, January 28-30, 2013, Revised Selected Papers.
Berlin/Heidelberg : Springer Berlin Heidelberg, 2013. – ISBN 9783642411472
[27] Urban, Julie: Examining Mac Data from Hardware With the Ap-
ple T2 Chip. https://www.blackbagtech.com/blog/2018/08/21/
examining-mac-data-hardware-apple-t2-chip/, 21.08.2018
[28] Afonin, Oleg: Breaking FileVault 2 Encryption Through iCloud. https:

//blog.elcomsoft.com/2016/08/breaking-filevault-2-encryption/,
29.08.2016
[29] Chicken, Tribal: Extracting FileVault 2 Keys with Volatility. https:

//tribalchicken.io/extracting-filevault-2-keys-with-volatility/,
13.02.2016
[30] Broz, Milan: dm-crypt: Linux kernel device-mapper crypto target. https:
//gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt, 23.04.2019
67
[31] Fruhwirth, Clemens: LUKS1 On-Disk Format Specification: Version 1.2.3.
[32] Broz, Milan: LUKS2 On-Disk Format Specification: Version 1.0.0.
[33] Natarajan, Ramesh: 10 Linux cryptsetup Examples for LUKS Key Manage-
ment (How to Add, Remove, Change, Reset LUKS encryption Key). https:
//www.thegeekstuff.com/2016/03/cryptsetup-lukskey/, 01.03.2016
[34] Pettersson, Torbjörn: Cryptographic key recovery from Linux memory dumps
[35] VeraCrypt: VeraCrypt: Free Open source disk encryption with strong security
for the Paranoid. https://www.veracrypt.fr/en/Home.html, 13.09.2018
[36] VeraCrypt: VeraCrypt - Documentation: System Encryption. https://www.

veracrypt.fr/en/System%20Encryption.html, 30.06.2017
[37] VeraCrypt: VeraCrypt - Documentation: VeraCrypt Volume Format Spe-

cification. https://www.veracrypt.fr/en/VeraCrypt%20Volume%20Format%
20Specification.html, 30.06.2017
[38] VeraCrypt: VeraCrypt - Documentation: Keyfiles. https://www.

veracrypt.fr/en/Keyfiles%20in%20VeraCrypt.html, 30.06.2017
[39] VeraCrypt: VeraCrypt - Documentation: PIM. https://www.veracrypt.

fr/en/Personal%20Iterations%20Multiplier%20%28PIM%29.html,
30.06.2017
[40] VeraCrypt: VeraCrypt - Documentation: Memory Dump Files. https://

www.veracrypt.fr/en/Memory%20Dump%20Files.html, 30.05.2017
[41] VeraCrypt: VeraCrypt - Documentation: Using VeraCrypt Without Ad-

ministrator Privileges. https://www.veracrypt.fr/en/Using%20VeraCrypt%
20Without%20Administrator%20Privileges.html, 30.06.2017
68
Abbildungsverzeichnis
4.1 Schematische Darstellung einer RAID-0 Konfiguration mit zwei Da-

tenträgern, Quelle: Wikipedia [7] . . . . . . . . . . . . . . . . . . . . 19
4.2 Schematische Darstellung einer RAID-1 und einer RAID-5 Konfigu-
ration mit zwei bzw. vier Datenträgern, Quelle: Wikipedia [7] . . . . . 20
4.3 Schematische Darstellung einer RAID-10 Konfiguration mit vier Da-
4.4 Schematische Darstellung einer RAID-51 Konfiguration mit sechs Da-
4.5 Schematische Darstellung einer RAID-6 Konfiguration mit fünf Da-
4.6 Imagedatei öffnen in R-Studio . . . . . . . . . . . . . . . . . . . . . . 23
4.7 R-Studio: Imagedatei öffnen . . . . . . . . . . . . . . . . . . . . . . . 24
4.8 Button Image öffnen in R-Studio . . . . . . . . . . . . . . . . . . . . 25
4.9 Virtuellen Block erstellen in R-Studio . . . . . . . . . . . . . . . . . . 25
4.10 Die Geräte-Ansicht von R-Studio . . . . . . . . . . . . . . . . . . . . 25
4.11 R-Studio: Der Bereich parent . . . . . . . . . . . . . . . . . . . . . . 26
4.12 R-Studio: RAID-Parameter . . . . . . . . . . . . . . . . . . . . . . . . 26
4.13 R-Studio: RAID-Konsistenz . . . . . . . . . . . . . . . . . . . . . . . 27
4.14 R-Studio: Menüpunkt scannen... . . . . . . . . . . . . . . . . . . . . . 27
4.15 R-Studio: Darstellung der RAID-Konsistenz . . . . . . . . . . . . . . 28
4.16 R-Studio: Parameter für die Scannen-Funktion . . . . . . . . . . . . . 28
4.17 R-Studio: Dateitypen beim Scannen auswählen . . . . . . . . . . . . . 29
4.18 R-Studio: Übersicht des Fortschritts beim Scannen . . . . . . . . . . . 29
4.19 R-Studio: Image erstellen . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.20 R-Studio: Byte-Für-Byte Image erstellen . . . . . . . . . . . . . . . . 30
4.21 R-Studio: Scan Informationen speichern . . . . . . . . . . . . . . . . . 31
4.22 LVM Architektur [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.23 Volume Groups und Volumes identifizieren . . . . . . . . . . . . . . . 38
4.24 Volumes und Dateisysteme . . . . . . . . . . . . . . . . . . . . . . . . 39
4.25 Dateisystem des Snapshots . . . . . . . . . . . . . . . . . . . . . . . . 39
4.26 GPT-Tabelle der physischen Disk . . . . . . . . . . . . . . . . . . . . 41
4.27 GPT-Tabelle der virtuellen Disk . . . . . . . . . . . . . . . . . . . . . 42
4.28 GPT-Tabelle auf physischer Disk identifiziert . . . . . . . . . . . . . . 42
4.29 NTFS Master File Table der virtueller Disk . . . . . . . . . . . . . . 43
4.30 NTFS Master File Table auf phsischer Disk identifiziert . . . . . . . . 43
4.31 Datenträger sichern mit DiskDumper . . . . . . . . . . . . . . . . . . 44
5.1 BitLocker Key Architecture. Entnommen aus: [21, S. 9] . . . . . . . . 48

5.2 Partitionstabelle einer Festplatte mit einer BitLocker-Partition . . . . 49
69
5.3 BitLocker Signatur am Beginn der Partition . . . . . . . . . . . . . . 50

5.4 Metadaten der mit BitLocker verschlüsselten Partition . . . . . . . . 50
5.5 BitLocker verschlüsselten Partition entschlüsselt einhängen . . . . . . 51
5.6 APFS/ FileVault2 Partitionstabelle - mmls . . . . . . . . . . . . . . . 52
5.7 APFS/ FileVault2 Partitions-/ Volumeinformationen - apfsutil . . . . 53
5.8 FileVault2 verschlüsselte Partition einbinden . . . . . . . . . . . . . . 53
5.9 Ubuntu Installationsoptionen . . . . . . . . . . . . . . . . . . . . . . 55
5.10 Partitonstabelle des verschlüsselten Ubuntu . . . . . . . . . . . . . . 56
5.11 Dateisysteme der Linux Partitionen . . . . . . . . . . . . . . . . . . . 56
5.12 EWF Image mit Xmount einbinden . . . . . . . . . . . . . . . . . . . 56
5.13 LUKS Partition als Loop-Device bereitstellen . . . . . . . . . . . . . 56
5.14 LUKS Header mit cryptsetup anzeigen . . . . . . . . . . . . . . . . . 57
5.15 Partition entschlüsseln und LVM Volumes mappen . . . . . . . . . . . 58
5.16 Partitionstabelle des mit VeraCrypt verschlüsselten Windows . . . . . 60
5.17 Image mit Partitionen als Loop-Device einbinden . . . . . . . . . . . 60
5.18 VeraCrypt Partition einbinden . . . . . . . . . . . . . . . . . . . . . . 60
5.19 VeraCrypt Partition mit cryptsetup einbinden . . . . . . . . . . . . . 61
70
Abkürzungsverzeichnis
AFF Advanced Forensic Format

APFS Apple File System
BDSG Bundesdatenschutzgesetz
BKAG Bundeskriminalamtsgesetze
CPU Central Processing Unit
DSGVO Datenschutzgrundverordnung
EEPROM Electrically Earsable Programmable Read-Only Memory
EFS Encrypting File System
EncFS Encrypted Filesystem
EWF Expert Witness Format
FVEK Full Volume Encryption Key
GG Grundgesetz
GUID Globally Unique Identifier
HDD Hard Drive Disk
LDM Logical Disk Manager
LUKS Linux Unified Key Setup
LVM Logical Volume Manager
MBR Master Boot Record
MD Multiple Disk
NTFS New Technology File System
PIM Personal Iterations Multiplier
PolG Polizeigesetz
RAID Redundant Array of Independent Disks
RAM Random-Access Memory
ReFS Resilient File System
S2D Storage Space Direct
71
SSD Solid-State-Drive
SSHD Solid State Hybrid Drive
StGB Strafgesetzbuch
StPO Strafprozessordnung
TPM Trusted Platform Module
VM Virtual Machine
VMK Volume Master Key
WSS Windows Storage Spaces
72
Selbstständigkeitserklärung
Selbstständigkeitserklärung
Hiermit erklären wir, dass wir die hier vorliegende Arbeit selbstständig, ohne uner-
laubte fremde Hilfe und nur unter Verwendung der aufgeführten Hilfsmittel ange-
fertigt haben.
Ort, Datum Unterschrift
73

Aufbereitung Besonderer Speicherkonfigurationen Als Analysefähiges Material (RAID, LVM, WSS, Verschlüsselung)

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Aufbereitung Besonderer Speicherkonfigurationen Als Analysefähiges Material (RAID, LVM, WSS, Verschlüsselung)

Hochgeladen von

Copyright:

Verfügbare Formate

Hochschule Wismar

University of Applied Sciences

Aufbereitung besonderer Speicherkonfigurationen als analysefähiges

Eingereicht am: 6. Juli 2019

von: Melanie Wetzig

4 Analyse eines Datenträgerverbundes 19

4.4 Software Lösungen unter Windows . . . . . . . . . . . . . . . . . . . 40

1.1 Motivation und Zielstellung

Der Ingenieursstudiengang IT-Forensik legt in seiner technischen Ausrichtung

1.2 Anforderung an den Ermittlungsprozess

Jedes Ergebnis und Zwischenergebnis muss, bei gleicher Herangehensweisen und

Die Beweisspuren müssen entsprechend nachvollziehbar aufgearbeitet werden, dass

Jeder Schritt im Ablauf der Beweissichtung, Beweiserhebung und der Beweisbewer-

1.3 Einordnung in Ermittlungsprozess

Eine Ermittlung im Zusammenhang mit Computerkriminalität kann mit Hilfe des

Für eine forensische Datenduplizierung ist es wichtig sicherzustellen, dass weder

im Originalzustand vorhanden. Hardware-Writeblocker werden von vielen handels-

Neben den verbreiteten großen Softwarelösungen zur Imageerstellung, gibt es eine

1.5.1 Rohdatenformat (RAW)

1.5.2 Expert Witness Format (EWF)

1.5.3 Advanced Forensic Format (AFF)

• die Verarbeitung und Nutzung

• die Berichtigung, Löschung und Sperrung

• Benachrichtigungs- und Auskunftspflichten

• sowie Haftungs- und Strafvorschriften

Diese grundlegenden rechtlichen Rahmenbedingungen sind in diversen Gesetzen,

2.2 Private Ermittlungen

2.3 Behördliche Ermittlungen

Bei behördlichen Ermittlungen gibt es sehr viele spezifische Gesetze, Verordnungen

Warum ist es interessant sich verschiedene Speichermedien/Speichertypen anzu-

weniger als Festplatte im herkömmlichen Sinne (Nutzung im Computer als Speicher

3.2.1 Speicherung auf einer HDD

3.2.2 Löschen von Daten auf einer HDD

3.2.3 Forensische Relevanz

3.3.1 Speicherung auf einer SSD

Flash-Speicher ist blockweise organisiert. Typischerweise hat ein Speicherblock 128

3.3.2 Löschen von Daten auf einer SSD

3.3.3 Forensische Relevanz

4 Analyse eines Datenträgerverbundes

Bei einer Redundant Array of Independent Disks (RAID)-Konfiguration handelt es

exotisch anmutende Layouts, bei denen die Systemadministratoren im Einzelfall be-

Hardware-RAIDs sind Software-RAIDs in Punkto Flexibilität und bei der Leistung

kommen sie i. d. R. noch dort, wo es um möglichst hohe Schreib-Leistung, bei zeit-

Bild 4.6: Imagedatei öffnen in R-Studio

vorliegenden Festplatten auf Basis von heuristischen Algorithmen identifizieren und

4.2.1 Schritt 1: Einbinden der Abbilder

4.2.2 Schritt 2: Öffnen der Abbilder in R-Studio

Bild 4.7: R-Studio: Imagedatei öffnen

4.2.3 Schritt 3: Modellierung des RAID-Layouts

Bild 4.8: Button Image öffnen in R-Studio

Bild 4.9: Virtuellen Block erstellen in R-Studio

Bild 4.10: Die Geräte-Ansicht von R-Studio

Bild 4.11: R-Studio: Der Bereich parent

Bild 4.12: R-Studio: RAID-Parameter

Bild 4.13: R-Studio: RAID-Konsistenz

Bild 4.14: R-Studio: Menüpunkt scannen...

Bild 4.15: R-Studio: Darstellung der RAID-Konsistenz

Bild 4.16: R-Studio: Parameter für die Scannen-Funktion

Bild 4.17: R-Studio: Dateitypen beim Scannen auswählen

Bild 4.18: R-Studio: Übersicht des Fortschritts beim Scannen

Bild 4.19: R-Studio: Image erstellen

Bild 4.20: R-Studio: Byte-Für-Byte Image erstellen

Bild 4.21: R-Studio: Scan Informationen speichern