Historical memory dumping techniques: Memory dumping over FireWire - UMA issues

By Arne Vidstrom

May 15, 2019

It's highly unlikely that a computer you need to dump the memory of has a FireWire port nowadays. During the years 2004 to 2006, I did quite a lot of computer forensics research as part of my job at the Swedish Defense Research Agency. Among many other things, we were interested in physical memory dumping techniques, and one technique that we tried to perfect was dumping over a FireWire interface. In 2006 I continued to work on it at my spare time, and I wrote a blog post about UMA issues with FireWire memory dumping.

When researching forensic memory dumping using FireWire, I stumbled across a problem when dumping parts of the physical memory space. Every time I tried to dump parts of the Upper Memory Area (a0000h to fffffh), the target computer froze completely. During my summer vacation, I decided to figure out the reason.

Architectural overview

To understand why dumping from the UMA can be a problem, we need to take a look at the architecture of a typical PC with an Intel chipset and FireWire support. As the figure below illustrates, the processor is connected to a Memory Controller Hub (MCH), which in turn is connected to an I/O Controller Hub (ICH). The system PCI bus, where the FireWire controller resides, is connected to the ICH.

Dumping the Upper Memory Area

The c0000h to fffffh range of the UMA is primarily intended to be used for ROM memory. The MCH allows the thirteen areas (one 64 kB and twelve 16 kB) that together build the range to be configured separately. Each area can be read-mapped to either ROM or main memory, and write-mapped to either ROM or main memory. Let us consider the special case where an area is read-mapped to ROM and write-mapped to main memory. Let us further assume that the processor for some reason has a modified cache line for this area.

Now we try to perform a memory dump over FireWire. The FireWire controller will at some point request a read from the previously mentioned area. When the processor snoops the read, it will see that it has a corresponding cache line in the modified state, and issue an implicit writeback. What happens is that the processor transfers the data since it has the most up-to-date copy. Since the area is configured as only read-mapped to main memory, the ICH will become the target of the implicit writeback. The MCH will then hang because it is not designed to handle implicit writebacks to the ICH.


The particular situation described above is perhaps not so common. In any case, it is crucial to understand that for some configurations, a memory dump over FireWire will lock the target computer before the dump has a chance to finish. The easiest solution is simply to skip the UMA range. In most configurations I have encountered so far, none of the areas in the UMA are mapped entirely to main memory. However, there are systems with one or more of the areas mapped entirely to main memory - both read and write - and used as ordinary memory. Even in such systems, we will never miss more than 1/4 MB of memory by skipping the UMA.