For a recent client project, we took on the apparently straightforward task: dump the contents of physical memory.

There are problems. The main one being that modern operating systems rely heavily (almost exclusively) on virtual memory, which bears little to no relation to physical memory. OS applications are not supposed to care about physical memory; more than that, knowing anything about physical memory layout is considered a security risk. Techniques like ASLR (Address Space Layout Randomization) are employed specifically to prevent code from being placed at known or guessable physical memory locations, as a protection against certain types of malware. Finally, memory and layout is constantly changing: there is no way (short of using out-of-system control, e.g. a hypervisor) of "freezing" machine state and capturing the contents of memory. So care needs to be taken in order to obtain a dump that minimizes "smear", that is, the amount of change in the state of physical memory between the start and the end of the capture process.

This turned out to be an extremely fun and interesting project. First, it requires understanding, at the lowest levels, how CPUs perform memory management, and the interfaces used (paging structures) to expose that to OS control and management. And then the OS itself must be studied: how does it manage the paging structures? How are kernel drivers written and installed, and how are kernel/process interactions best performed? What kinds of OS-internal caches are used? How is file I/O buffered, and what kind of control do we have over that? For example, suppose the OS reserves 20% of RAM for file I/O buffers -- then if we use the default I/O system to write the contents of RAM, we will necessarily overwrite that entire 20%, resulting in very large smear.

So the basics are fun, but then it gets even more interesting. One target application of the tool is security forensics, in which case some care must be taken to protect against a potential adversary on the system with equal privileges to your own. Say, for example, that a rootkit has managed to install itself with the highest level of OS/executive permission, so that in theory it can do anything on the compromised system, including "lie" on queries to the BIOS. Can you build a memory capture tool that will find the rootkit? Even if the rootkit has access to the source code of your capture tool? That last condition -- which was not part of the client project -- makes it an extremely tough task, but still fun to think about.

According to the client, this project will eventually become open source, and we'll share that here when possible.

All of this investigation into low-level hardware and OS operation was not only fun, but inspired us to prioritize writing a bootloader for our R20S project.