Visualizing Recovered Executables from Memory Images

[Nytro]

[h=1]Visualizing Recovered Executables from Memory Images[/h]jessekornblum (jessekornblum) wrote,

I like to use a picture to help explain how we can recover executables from memory images. For example, here's the image I was using 2008:

This post will explain what's happening in that picture—how PE executables are loaded and recovered—and provide a different visualization of the process. Instead of just a stylized representation, we can produce pictures from actual data. This post explains how to do that and the tools used in the process.

When executables are loaded from the disk, Windows uses the PE header to determine how many pages, and with which permissions, will be allocated for each section. The header describes the size and location of each section on the disk and its size and location in memory. Because the sections needs to page aligned in memory, but not on the disk, this generally results in some space being added between the sections when they're loaded into memory. There are also changes made in memory due to relocations and imported functions.

When we recover executables from memory, we can use the PE header to map the sections back to their size and locations as they were on the disk. Generally memory forensics tools don't undo the other modifications made by the Windows loader. The changes made in memory remain the new version we recover. In addition, due to paging and other limitations we don't always get all of the pages of the executable from memory. They could have been paged out, are invalid, or were never loaded in the first place.

That's a tidy description of the picture above. The reality, of course, is a little messier. I've used my colorize and filecompare tools to produce visualizations for an executable on the disk, what it looked like in memory, and what it looked like when recovered from the memory image. In addition to those tools, I used the Volatility™ memory forensics framework [1] and the Picasion tool for making animated gifs [2]. For the memory image, I'm using the xp-laptop memory image from the NIST CFReDS project [3]. In particular, we'll be looking at cmd.exe, process 3256.

Here's a representation of the original executable from the disk as produced with colorize. This image is a little different than some of the others I've posted before. Instead of being vertically oriented, it's horizontal. The data starts at the top left, and then goes down and then right. I've also changed the images to be 512 pixels wide instead of the default 100. I made the image this way to make it appear similar to the image at the start of this post. Here's the command I used to generate the picture:

$ colorize -o -w 512 cmd.exe

and here's the result: http://jessekornblum.com/tools/colorize/img/cmd.exe.bmp

It gets interesting when we compare this picture to the data we can recover from the memory image. First, we can recover the in-memory representation of the executable using the Volatility™ plugin procmemdump. In the files generated by this plugin the pages are memory aligned, not disk aligned. Here's the command line to run the plugin:

$ python vol.py -f cases/xp-laptop-2005-07-04-1430.vmem --profile=WinXPSP2x86 procmemdump --pid=3256 --dump-dir=output

Volatile Systems Volatility Framework 2.3_alpha Process(V) ImageBase Name Result ---------- ---------- -------------------- ------ 0x8153f480 0x4ad00000 cmd.exe OK: executable.3256.exe

Here's how we can colorize it:

$ mv executable.3256.exe executable-procmemdump.3256.exe

$ colorize -o -w 512 executable-procmemdump.3256.exe

Which leads to this result: http://jessekornblum.com/tools/colorize/img/executable-procmemdump.3256.exe.bmp

There's a lot going on here, but things will get more clear with a third image. For the third picture we'll recover the executable again, but this time realigning the sections back to how there were on the disk. This is done by parsing the PE header in memory and using it to undo some of the changes made when it was loaded. We can do this using the procexedump plugin, like this:

$ python vol.py -f xp-laptop-2005-07-04-1430.vmem --profile=WinXPSP2x86 procexedump --pid=3256 --dump-dir=output

Volatile Systems Volatility Framework 2.3_alpha Process(V) ImageBase Name Result ---------- ---------- -------------------- ------ 0x8153f480 0x4ad00000 cmd.exe OK: executable.3256.exe

We repeat the process for colorizing this sample:

$ mv executable.3256.exe executable-procexedump.3256.exe

$ colorize -o -w 512 executable-procexedump.3256.exe

Which produces this image: http://jessekornblum.com/tools/colorize/img/executable-procexedump.3256.exe.bmp

First, let's compare the recovered executable back to the original. Even before we start our visualizations, we can see there were changes between the original and this version. The MD5 hashes of the two files are different:

$ md5deep -b cmd.exe executable-procexedump.3256.exe

eeb024f2c81f0d55936fb825d21a91d6 cmd.exe ff8a9a332a9471e1bf8d5cebb941fc66 executable-procexedump.3256.exe

Amazingly, however, they match using fuzzy hashing via the ssdeep tool [4]:

$ ssdeep -bda cmd.exe executable-procexedump.3256.exe

executable-procexedump.3256.exe matches cmd.exe (66)

There's also a match with the sdhash similarity detection tool [5]:

$ sdhash -g -t 0 cmd.exe executable-procexedump.3256.exe

cmd.exe|executable-procexedump.3256.exe|046

(You haven't heard of sdhash? Don't get tunnel vision! There are many similarity detection tools.)

Those matches are good signs. But attempting to compare the colorized image of the recovered executable back to the original is a little tricky. To make it easier, I made a kind of blink comparator. The free site Picasion allows you to make animated GIFs from submitted pictures. Combined with some annotations on the pictures, here's the result:

There are two important things to notice here. First, we didn't recover all of the executable. The bands of black which appear on the left-hand side in the recovered image are pages which weren't found in memory. Also notice how much of the data from the end of the file is missing, too. Almost all of it! (Isn't it amazing that fuzzy hashing can still generate a match between these two files?)

The second thing to notice is the changes in the data. It's a little hard to see in the GIF, but you can get a better view using the filecompare and colorize tools together. We can compare the two files at the byte level and then colorize the result:

$ filecompare -b 1 cmd.exe executable-procexedump.3256.exe > orig-to-exe.dat

$ colorize -o - w 512 orig-to-exe.dat

Here's the result: http://jessekornblum.com/tools/colorize/img/orig-to-exe.dat.bmp

Here we can clearly see, in red, the changes throughout the file. The blocks of mostly red, or heavily speckled red, and the places where we weren't able to recover data from the memory image. Because some of the values in the original executable were zeros, those appear to match the zeros we recovered from the memory image--hence the speckled pattern. The changes to the executable you can clearly see a pattern of dashed red lines.

Finally, we can visualize the changes between the in-memory representation of the file and the disk representation the file. I've made another animated GIF, this time between these versions of the executable as recovered by procexedump and procmemdump:

The most obvious difference between these two pictures is the black band on the left-hand side of the image. That's the space, created by the realignment from disk to memory, being added by the Windows loader to page align the first section of the executable.

---

[h=3]References[/h][1] The Volatility™ framework, https://code.google.com/p/volatility/. Volatility™ is a trademark of Verizon. Jesse Kornblum is not sponsored or approved by, or affiliated with Verizon.

[2] Picasion.com, Picasion GIF maker - Create GIF animations online - Make an Animated GIF.

[3] The Computer Forensic Reference Data Sets project, National Institute of Standards and Technology, The CFReDS Project.

[4] Jesse Kornblum, ssdeep, Fuzzy Hashing and ssdeep.

[5] Vassil Roussev, sdhash, http://sdhash.org/.

Sursa: jessekornblum: Visualizing Recovered Executables from Memory Images