Acquisition (5): FireWire

| 1 Comment

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.

History

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.

Memory Acquisition

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:

cd /usr/local/pythonraw1394

modprobe raw1394

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).

Windows may install some new drivers

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.

Hardware malfunction - bluescreen

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.

1 Comment

Hi Andreas,
I've experimented the acquisition of a RAM using pythonraw1394. I've followed exactly the steps that you mentioned on your post, but at the last step "./1394memimage 0 0 ..." I've got the following error "Unable to read 4096 bytes at 0x00000000 on port: 0 node 0".
I've tried on two different PC, but with the same error.

Can you give me some advice, please?

Thanks in advance,
Francesco

Archives

Imprint

This blog is a project of:
Andreas Schuster
Im Äuelchen 45
D-53177 Bonn
impressum@forensikblog.de

Copyright © 2005-2012 by
Andreas Schuster
All rights reserved.
Powered by Movable Type 5.12