Extracting RAW pictures from memory dumps

Introduction

Earlier today, while reading my Twitter timeline, I saw some Infosec folks discussing about scripts/tools to identify RAW pictures in memory dumps. I decided, then, to write this blog post and share a small hack that I use to visualize data (including memory dumps).

A few months ago, I wrote a post detailing how to Scan the Internet & Screenshot All the Things, now it's time to Dump the Memory & Screenshot All the Things.

Memory Dumps

The first thing you will want to do is to narrow the analysis to the process containing interesting images/pictures. I'm going to use three different memory dumps here:

Remote Desktop Client - Windows 7 x64 (mstsc.exe)

Let's use the Windows built-in RDP client to connect to an external server and dump the process
memory using procdump:

procdump.exe -ma mstsc.exe mstsc.dmp

Microsoft Paint - Windows 7 x64 (mspaint.exe)

Let's load/save a simple image file on Paint and run procdump again:

procdump.exe -ma mspaint.exe mspaint.dmp

9447 2014 CTF Challenge: coor coor - Windows XP (VirtualBox.exe)

There's an awesome write-up for this CTF challenge here, go read it now if you haven't yet. We are going to use volatility to isolate the VirtualBox memory dump:

python vol.py -f challenge.vmem pslist

python vol.py -f challenge.vmem memdump -p 1568 --dump-dir=dump/

RAW Image Data

Rename the file extensions from *.dmp to *.data, download/install GIMP and open them as "RAW Image Data":

That's it, now you can use GIMP to navigate within the memory dump and analyse the rendered pixels/bitmaps on their corresponding offsets. It's worth mentioning that different images will be rendered using different Image types and variable widths: you may need to adjust these values accordingly.

So what can we spot here?

• On the RDP memory dump, we can retrieve the tiles and Windows displayed during the connection, including IP's, usernames and commands:

Windows commands

Remote Desktop Client Window

RDP session

• The Microsoft Paint picture can be easily spotted: they're upside down because that's the way BMP's are stored:

We need upside down backdoors "this big"

• The most interesting artifacts were collected from the Coor Coor dump. The user was running a TrueCrypt container inside VirtualBox and after some offset adjustment we can see the Pidgin Window, the user account (testicool69@yodawg.9447.plumbing) and a few OTR settings:

While True: width ++ || width--

Notice that the Windows are not perfectly aligned here, but we can see the data by zooming in:

Enhance pls

Looks like our killer is screwed. YEEAAAH.

We can also spot the Window taskbar, just like the volatility screenshot plugin showed us on the previous write-up:

python vol.py -f challenge.vmem screenshot -D screenshot/

It's also possible to spot icons from the running programs, like this one from Virtualbox:

VirtualBox icon

Conclusion

This technique is very common among ROM hackers as they try to find image patterns inside raw game dumps. Check my write-up from Hack.lu 2014 CTF to find more about it. By the way, you can also use Tile Molester instead of GIMP to browse the RAW data.

You may be asking - why not carve the dumps using binwalk and foremost or extract them using the dumpfiles volatility module? If you try it yourself you will notice that they won't find the magic bytes for all those images.

As far as I know, there's no off-the-shelf tool to automagically extract them, but it should't be that hard to write a binwalk/volatility plugin for this based on some heuristics. Binwalk, for example, can find raw deflate/lzma streams by building headers on top of the raw compressed data and writing it back do disk.

I'm no Computer Visualization expert, but here's a few suggestions:

• Set the image width to common display resolutions. The taskbar from the coor coor memory dump could be displayed by setting the width to 1440 points (1440x900 is a common screen resolution).
• Use common window background/patterns as a template to find interesting sections.
• Create a multi-view/side-by-side RAW image browser based on GIMP source code (multiple image types, multiple widths etc).
• Use Google's artificial brain to find cat videos.
• Get a bigger monitor (yeah, it helps).

I hope you all use these skills wisely, avoiding any kind of superfishal investigation like our Lenovo friends.

9447 2014 CTF Write Up: coor coor

The Australian 9447 Security Society CTF took place on November 29-30 and it was yet another fun and really professionally organized CTF. I played with my friends from TheGoonies once again (The Goonies 'R' Good Enough, right?).

I found the task "coor coor" particularly interesting: it was a good way to practice some concepts from the new book I recently bought: The Art of Memory Forensics (authored by @attrc and @gleeda).

Task: coor coor (misc - 400)

A 9447 CTF organizer is giving away flags to friends that he trusts. This memory dump was taken off a competitor's computer after a raid by the pwnpolice.

Download provided: https://s3-us-west-2.amazonaws.com/elasticbeanstalk-us-west-2-467703568171/challenges/coorcoor.tar.bz2

Let's start by identifying the Operating System profile:

python vol.py -f challenge.vmem imageinfo

Let's take screenshot to see what the user was doing:

python vol.py -f challenge.vmem screenshot -D screenshot/

The user was running something inside VirtualBox, let's keep digging:

python vol.py -f challenge.vmem psxview

python vol.py -f challenge.vmem filescan | grep -e "\.tc\|TrueCrypt"

The user was basically running a VirtualBox machine (business2.vdi) from an Encrypted TrueCrypt container (secret.tc). That's why we used psxview to list the system processes before. Note that the lower offsets are used by the Host and the higher ones (after 0x7b760da0) are used by the guest OS. So what was he doing?

python vol.py -f challenge.vmem connscan

The host 54.149.24.114 (yodawg.9447.plumbing) happened to be an IRC server with only one active channel: #9447ctf. We can carve some pidgin logs using foremost:

python vol.py -f challenge.vmem mftparser | grep 9447ctf

foremost challenge.vmem

Private conversations are not logged by default on Pidgin with the OTR extension. We can see a couple of OTR encrypted  messages on the memory dump:

Because of Perfect Forward Secrecy, if you lose control of your private keys, no previous conversation is compromised. I just had the long term signature keys (otr.private_key) and these aren't actually used to encrypt conversations, just to sign the session encryption key. I still needed to retrieve the short term encryption keys from the memory. I got stuck on this phase and spent the whole night trying to figure how to do that.

After some time I decided to get some sleep and keep trying it on the following day. The first thing I did the next day was to re-read the challenge description and I quickly figured it out:

"A 9447 CTF organizer is giving away flags to friends that he trusts."

Because of the way IRC works, I could easily impersonate testicool69 (the trusted frind), connect to the IRC server (yodawg.9447.plumbing:6667) and message acidburn88 (the CTF Admin) asking for the key. So how do I do that?

Pidgin-OTR creates three files during an encrypted communication: otr.private_key, otr.instance_tags and otr.fingerprints. I searched for the term "prpl-irc" on the memory dump, extracted and replaced those files on my own Pidgin installation (%APPDATA%\.purple). There's a Metasploit post-module to retrieve these keys from a live (hacked) system, by the way...

I managed to forge his fingerprint using the stolen private key and got the secret Flag:

9447{forensics_champ!}