© Ivan Opacak, 123RF

Der Xmount-Entwickler Daniel Gillen, von Beruf Forensiker der Luxemburger Strafverfolgung, liefert mit seiner Version 0.7 ein Update, das auch das Wiederherstellen von Raid-Verbünden einfacher macht, weil es Optionen bietet, die ganze Partitionen scheinbar on the Fly verschieben.

In der vorigen Ausgabe des Linux-Magazins zeigte ein Artikel, wie Admins kritische Dateisysteme, die nur als Raid-Verbund vorliegen, wiederbeleben und sie temporär oder auch dauerhaft virtualisieren. Der Forensiker Daniel Gillen stellte jetzt dem Linux-Magazin eine aktualisierte Vorabversion seines Tools Xmount ([1], auf der DELUG-DVD) zur Verfügung, das dies noch deutlich einfacher zu machen verspricht.

Das EWF-Image auf der DVD enthält ein Debian-System mit einem LAMP-Server. Es wurde auf einem Hardware-Raid 1 installiert, samt SQL-Datenbank und (als Beispiel) sehnsüchtig vermissten Daten in der DB. Um an diese heranzukommen, muss der Admin entweder die Datenbankdateien extrahieren oder das System virtualisieren. Entpackt präsentiert sich in der Datei »lamp.E01« eine 40-GByte-Festplatte, doch im EWF-Format bleiben gerade mal 2 GByte davon übrig. Wie in dem Artikel [3] beschrieben, stellt die Raid-Struktur den Admin schon bei einfachen Aufgaben vor ein Problem:

mmls lamp.E01
Cannot determine partition type

Mmls zeigt weder MBR- noch GPT-Informationen an. Der Sigfind-Befehl aus dem Sleuthkit findet den nach hinten verschobenen MBR, damit kann Mmls dann arbeiten (Listing 1).

01 sigfind -o 510 55AA lamp.E01
02 Block size: 512  Offset: 510  Signature: 55AA
03 Block: 8792 (-)
04 Block: 8399448 (+8390656)
05 Block: 9582302 (+1182854)
06 Block: 9730098 (+147796)
07
08 mmls -o 8792 lamp.E01
09 DOS Partition Table
10 Offset Sector: 8792
11 Units are in 512-byte sectors
12
13      Slot    Start        End          Length       Description
14 00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
15 01:  -----   0000000000   0000002047   0000002048   Unallocated
16 02:  00:00   0000002048   0007813119   0007811072   Linux Swap / Solaris x86 (0x82)
17 03:  00:01   0007813120   0066406399   0058593280   Linux (0x83)
18 04:  00:02   0066406400   0076171263   0009764864   Linux (0x83)
19 05:  -----   0076171264   0078133791   0001962528   Unallocated

Die korrekten Partitionsinformationen liegen also vor, Xmount kann das Image jetzt in eine Virtualbox-Festplatte vom Typ ».vdi« konvertieren. Das Booten würde so aber noch nicht funktionieren, da der Hypervisor nichts mit dem verlagerten MBR (ohne Raid-Controller) anfangen kann.

Xmount 0.7 verschiebt

Anders sähe die Situation aber aus, ließe sich die virtuelle Festplatte einfach um 8792 Sektoren nach oben verschieben. Genau hier kommt nun die neue Version von Xmount ins Spiel. Sehnsüchtig von Forensikern erwartet: Jetzt versteht das Tool die Option »– offset« , die genau dies bewerkstelligt, siehe Listing 2.

01 # xmount -?
02   --offset <off> : Move the output image data start <off> bytes into the input image.
03
04 # xmount --in ewf --out vdi --cache /tmp/lamp.ovl --offset $((8792*512)) lamp.E01 /ewfmo

Im Verzeichnis »/ewf« liegt nun eine bootfähige ».vdi« -Festplatte, die sich in ein neues Gastsystem einbinden lässt. Erste Startversuche werden allerdings meist nicht erfolgreich sein, da noch ein wenig Feinschliff notwendig ist. So muss in dem vorliegenden Beispiel der Admin in Virtualbox unter »System« noch »PAE« aktivieren.

Andere Hardware-Umgebungen, beispielsweise virtualisierte Windows-Server, verlangen eventuell gar noch den Austausch der Festplattentreiber. Dabei hilft Daniel Gillens Programm Opengates [4], das er ebenfalls über die Webseite http://1 verfügbar macht.

Abbildung 1 zeigt den erfolgreichen Bootvorgang. Hat alles geklappt, dann ist der LAMP-Server in der virtuellen Maschine einsatzklar und lässt sich via Phpmyadmin analysieren und administrieren (Abbildung 2). Die IP-Adresse bezieht die VM über DHCP, alle Passwörter für Root (in »/etc/passwd« , MySQL und Phpmyadmin lauten »linux« .

Abbildung 1: Die Gastmaschine bootet erfolgreich.

Abbildung 2: In der Testumgebung findet sich Phpmyadmin unter der URL »http://192.168.2.149/phpmyadmin«.

Datenbank-Extraktion

Anschließend kann der Admin die Daten aus der Datenbank extrahieren, inklusive der Tabellen. Dazu taugen verschiedene Verfahren:

• Export über Phpmyadmin – bei großen Tabellen meist problematisch.
• Export über MySQL und das CLI-Interface.
• Einfaches Kopieren von »/var/lib/mysql/sakila« mit allen Dateien auf ein neues System.

Hierbei muss der Admin die Rechte anpassen, in der Regel muss der Benutzer »mysql« Eigentümer sein und Schreibrechte besitzen.

KVM, Virtualbox, VMware: Für fast alle Hypervisoren

Auch wer nicht auf Virtualbox setzt kann mit Hilfe von Xmount arbeiten. Was moderne Hypervisoren angeht, haben die Entwickler ganze Arbeit geleistet: Sowohl KVM- als auch VMware-Images kann Xmount verwenden, die Hilfe listet für den hier maßgeblichen »–out« -Parameter:

--out <otype> : Output  image format.<otype> can be "dd", "dmg", "vdi","vhd", "vmdk(s)"

»dd« steht dabei für ein RAW-File, »dmg« ist Apples Disk Image Format, »vdi« das von Virtualbox bevorzugte.

Das Format »vhd« (Virtual Hard Drive) nutzt beispielsweise Microsoft Virtual PC, während die Erweiterung »vmdk(s)« für ein oder mehrere VMware-Abbilder sorgt.

Fazit

Das Warten hat sich gelohnt : Die nächste Version von Xmount bringt schon zwei Features mit, die Admins und Forensiker schon länger herbeisehnen. Bei Redaktionsschluss stand sie zwar noch nicht offiziell bereit, doch die Entwickler versprachen, zum Erscheinungstermin dieses Magazins mindestens eine aktuelle Beta-, eventuell gar die finale Version auf http://1 anzubieten.