FireWire provides a simple and reliable means to image another computer's main memory. In this article I'll briefly talk about the history of direct memory access through FireWire. Also I will explain how to acquire a RAM image using the Helix boot CD.
The FireWire interface was developed by Apple. It is also known as i.Link (Sony) and IEEE 1394.
The Serial Bus Protocol 2 (SBP-2) specifies a method to directly access the main memory of a FireWire node. The Open Host Controller Interface (OHCI) hardware implements the mapping between the FireWire address space and the device's physical memory.
The ability to read and write to another computer's physical memory through the FireWire interface was first exploited by Quinn "The Eskimo" in 2002. His program FireStarter allowed to remotely manipulate the contents of a target Mac's display. For his hack Quinn was awarded the first price at the MacHack Best Hack Contest 2002.
Michael Becher, Maximillian Dornseif and Christian N. Klein explained in their talk 0wn3d by an iPod at PacSec 2004 how FireWire could be used in a forensically sound memory acquisition procedure.
Adam Boileau (aka "Metlstorm") solved the problem of accessing a computer running Microsoft Windows in his presentation at RUXCON 2006. He also released some Python modules and memory acquisition tools.
Boileau's tools were incorporated into the well-known Helix CD v1.9. I will use this CD to demonstrate the acquisition procedure. The tools are located in the /usr/local/pythonraw1394 subdirectory.
First, the driver for raw access to the FireWire interface needs to be loaded:
The raw interface is now available as /dev/raw1394. The ./businfo command allows to inspect all the devices that are hooked up on the FireWire bus. (complete output is available here):
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.) ...
For now there's only one node (see nodeCount in the first row) connected to the bus. As it can be seen above, it's manufacturer is ASUSTEK.
We now reprogram the Control and Status Registers (CSR) in such a way that they mimic an Apple iPod:
./romtool -s 0 ipod.csr
Init firwire, port 0
Updated 1024 byte ROM image from ipod.csr
Now businfo tells us (complete output is available here):
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.) ...
The PC now identifies itself as an iPod.
Now it's the moment to connect our prepared acquisition computer with the target system. As soon as the connection is made, Windows on the target machine may install some drivers (the screenshot shows a German localization).
Here Windows installed an "Apple Computer _Inc. iPod IEEE 1394 SBP2 Device" and a "SBP2 IEEE 1394 Device". Of course one should properly document and account for these changes. Please see the related discussion about "tool marks" at hogly's blog.
Businfo now displays a second device on the FireWire bus (complete output is available here):
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.) ...
We're ready to copy the main memory into a file:
./1394memimage 0 1 /media/sdb1/memory.bin -512M
The resulting memory image is in raw format.
Caution: One should carefully avoid to access non-existent memory. Otherwise the target system will raise a fatal error and bluescreen. On the other hand this could be a good way to shut down the system and start with traditional disk forensics.
02/24/2008: There was a wrong parameter in the invocation of 1394memimage. Thanks to Francesco Schifilliti for reporting.
When attempting to access non-existent memory, some chipsets don't raise a NMI. Instead they return a page filled with 0xff.
There seems to be a memory leak somewhere in 1394memimage or the underlying layers. Right now I can't tell whether this affects only the version on the Helix CD or if there is a general problem. I'd highly appreciate any information on this issue.