Eine einfache und zuverlässige Methode zur Erstellung von Speicherabbildern ist der Zugriff über FireWire. In diesem Beitrag beschreibe ich die Datensicherung mit Hilfe der Helix Boot CD.
Die Datenübertragungsschnittstelle FireWire wurde zunächst von Apple entwickelt. Sie ist auch unter den Namen i.Link (Sony) und IEEE 1394 bekannt.
Das Serial Bus Protocol 2 (SBP-2) definiert den direkten Zugriff auf den Arbeitsspeicher eines FireWire-Knotens. Das Open Host Controller Interface (OHCI) implementiert diesen Zugriff in Hardware.
Geschichte
Die Fähigkeit, über FireWire den Arbeitsspeicher eines anderen Computer zu lesen und zu verändern, wurde im Jahr 2002 von Quinn "The Eskimo" ausgenutzt, um
von einem anderen Computer aus den Bildschirminhalt eines Macs zu verändern. Für sein Programm FireStarter erhielt er den ersten Preis auf dem MacHack Best Hack Contest 2002.
Auf der PacSec 2004 erwähnten Michael Becher, Maximillian Dornseif und Christian N. Klein in ihrem Beitrag 0wn3d by an iPod erstmals den Nutzen des Speicherzugriffs für die digitale Forensik.
Adam Boileau (aka "Metlstorm") löste in seinem Beitrag für die RUXCON 2006 das Problem des Zugriffs auf Windows-PCs. Außerdem veröffentlichte er Python-Module, die den Zugriff auf FireWire ermöglichen und einige darauf aufbauende Werkzeuge für die Datensicherung.
Datensicherung
Boileaus Werkzeuge fanden unter anderem Eingang in die Helix Boot CD v1.9, die ich zur Sicherung des Hauptspeichers verwende. Die Tools befinden sich dort im Verzeichnis /usr/local/pythonraw1394.
Zunächst muss der Treiber für den Low-Level-Zugriff auf die FireWire-Schnittstelle geladen werden.
cd /usr/local/pythonraw1394
modprobe raw1394
Die Schnittstelle steht nun unter /dev/raw1394 zur Verfügung. Mit dem Kommando ./businfo lässt sich die lokale FireWire-Hardware inspizieren (vollständige Ausgabe hier):
Firewire initialized, with 1 ports available: Enumerating port & node tree... Port(number=0, generation=1, busid=1023, localid=0, nodeCount=1, name='ohci1394') Node(number=0, nodeid=0xffc0) ConfigROM( Length : 16 bytes CRC Length : 16 bytes CRC : 0x836c (Valid) Bus ID : "1394" GUID : 0x00e01800031c7452 Vendor : 0x0000e018 (ASUSTEK COMPUTER INC.) ...
Derzeit ist nur ein Knoten (siehe nodeCount in der ersten Zeile) an den Bus angeschlossen. Als Hersteller erscheint ASUSTEK.
Nun werden die Control and Status Registers (CSR) so umprogrammiert, dass das Gerät als Apple iPod erscheint:
./romtool -s 0 ipod.csr
Init firwire, port 0
Updated 1024 byte ROM image from ipod.csr
Businfo zeigt jetzt dies (vollständige Ausgabe hier):
Firewire initialized, with 1 ports available: Enumerating port & node tree... Port(number=0, generation=1, busid=1023, localid=0, nodeCount=1, name='ohci1394') Node(number=0, nodeid=0xffc0) ConfigROM( Length : 16 bytes CRC Length : 16 bytes CRC : 0x7286 (Valid) Bus ID : "1394" GUID : 0x000a270002aa6ba7 Vendor : 0x00000a27 (Apple Computer, Inc.) ...
Der PC identifiziert sich jetzt also als iPod.
So vorbereitet, kann er jetzt über ein FireWire-Kabel mit dem Zielcomputer verbunden werden. Unmittelbar nach Herstellen der Verbindung wird der Zielcomputer möglicherweise selbsttätig einige Treiber installieren. Die Veränderungen zeigen sich im Gerätemanager:
Installiert wurden hier die Geräte "Apple Computer _Inc. iPod IEEE 1394 SBP2 Device" und ein "SBP2 IEEE 1394 Gerät". Diese Veränderungen sind natürlich zu dokumentieren und in der späteren Analyse zu berücksichtigen.
Businfo zeigt jetzt ein zweites Gerät (vollständige Ausgabe hier):
Firewire initialized, with 1 ports available: Enumerating port & node tree... Port(number=0, generation=4, busid=1023, localid=0, nodeCount=2, name='ohci1394') Node(number=0, nodeid=0xffc0) ... Node(number=1, nodeid=0xffc1) ConfigROM( Length : 16 bytes CRC Length : 16 bytes CRC : 0x9629 (Invalid (0x87ea)) Bus ID : "1394" GUID : 0x000ae4aaaa212722 Vendor : 0x00000ae4 (Wistron Corp.) Link Speed : 2 (S400) Max Record Size : 10 (2048 bytes) Isochronous Capable : 1 (Yes) Bus Master Capable : 1 (Yes) Cycle Master Capable : 1 (Yes) Cycle Master Clock Accuracy : 0 ppm Isochronous Resource Manager Capable : 1 (Yes) Root Directory: 32 bytes, crc: 0x10cb (Invalid (0x0a69)) 0 (Immediate Value), 12 (Node Capabilities): 0x83c0 0 (Immediate Value), 28 (Unknown 28): 0x50f2 0 (Immediate Value), 29 (Unknown 29): 0x2 0 (Immediate Value), 30 (Unknown 30): 0x0 0 (Immediate Value), 3 (Module Vendor ID): 0x50f2 (MICROSOFT CORP.)
Der Arbeitsspeicherinhalt kann jetzt kopiert werden:
./1394memimage 0 1 /media/sdb1/memory.bin -512M
Das Abbild ist in der Art, wie es auch das Dienstprogramm dd auf dem Zielcomputer erstellt hätte.
Man muss allerdings aufpassen, nicht auf unbestückte Speicherbereiche zuzugreifen. Ansonsten reagiert das Zielsystem mit einem fatalen Fehler:
24.02.2008: In der Kommandozeile für 1394memimage befand sich ein Fehler. Dank an Francesco Schifilliti für den Hinweis.
Manche Chipsätze lösen beim Zugriff auf nicht existenten Speicher offenbar keinen NMI aus, sondern liefern eine mit 0xff gefüllte Speicherseite.
Offenbar gibt es in 1394memimage oder den darunter liegenden Schichten ein Speicherleck. Ich weiß zur Zeit nicht, ob dies nur die Fassung auf der Helix-CD betrifft, oder ob das Problem auch in anderen Umgebungen auftritt. Über Hinweise hierzu würde ich mich freuen.
