Extract images from process memory dumps

The memdump command from Volatility can be used to extract all memory pages corresponding to a process. In the resulting dump we can search for objects based on their signatures. The dump could also be mounted as a virtual disk and searched with specialized forensic software, like EnCase, that recognizes and extracts objects easily from a database of signatures.

For some file types it’s easy to search manually and extract them because they are defined by a header and a trailer (e.g. JPEG files always start with the magic number 0xFF D8 FF followed by E0, E1, E2, E3, E8 or DB and end with 0xFF D9). For others, their header must be parsed, length and other parameters extracted and then the content can be dumped. Some file types (Adobe PDF) can contain multiple end-of-file markers, so this is something that should be taken into account.
We’ll take a look at the memory pages of the main process of Chrome browser, the parent of the other spawned tabs:

c:\>volatility.exe -f win32dd_mem_dump250612.bin –profile=WinXPSP3x86
pslist | grep -i chrome
0x89fff388 chrome.exe 680 2732 29 1738 2012-06-25 10:58:40
0x8a1d3338 chrome.exe 1140 680 7 93 2012-06-25 10:58:50
0x8a000da0 chrome.exe 304 680 7 94 2012-06-25 10:58:51
[ . . . ]

The second column represents the PID and the third one the parent PID. We’ll use it to dump the process memory. The following command will create a 500 MB dump file called PID.dmp in the specified folder:

c:\>volatility.exe -f win32dd_mem_dump250612.bin –profile=WinXPSP3x86
memdump -p 680 -D dmp/

Next we proceed to extraction of different objects from here. I’ve made a python proof of concept script (extract_jpg.py) to detect JPEG images based on header magic number and the trailer. The main purpose of this would be to detect forensic evidence regarding user activity in all or just specific processes. Another thing that can be detected is the presence of some malware that periodically makes captures of the screen, compresses them and send them through the network. Spyware programs aim to capture un-sniffable authentication information also, like passwords introduced from virtual on screen keyboards with the mouse instead of using the keyboard, as used by some online banking systems.

• Analysing the output file produced by memdump command for process 680 (with strings or BinText), we see clearly that some information from the half gigabyte outputted cannot belong to Chrome’s browser. But this is not a problem when scanning for objects in it.
• Running the mentioned extract_jpg.py script on the 680.dmp file produced around 250 jpeg images.

  > python extract_jpg.py 680.dmp
  Found possible jpeg header at 0x1562000
  Found possible jpeg trailer at 0x1563931
  Found possible jpeg header at 0x15ee480
  Found possible jpeg trailer at 0x15ee8e9
  [ . . . ]
  

• When viewing the images with an external editor, we detect the presence of unexplainable small (212x132 pixels) screen captures of the browser window. This may be just a false alarm (as the images are very small, almost undistinguishable, and most login fields don’t show the password), but it still raises some questions.

In this particular case, it was just a false alarm :) There is a Chrome feature to remember recently visited websites, and display their preview for the user at startup. Besides extracting jpeg images and other objects (gif files, documents) we could also run the strings command on the memory dump, just as an initial check, a preliminary search with some word filters like username/password/virus/hack/... or others, depending on what we want to find.
Even though analysing memory dumps can’t solve many problems by itself, it can offer quite a lot of information to work with and get a profile of the user’s activity. It’s a relatively new field and still new things are discovered, for the forensics to keep the pace with evolving anti-forensics techniques.