SANS Digital Forensics and Incident Response Blog

Facebook Memory Forensics

OK, like everyone I joined facebook just to get updates on my high school reunion. (Who knew you could also use it as a possible alibi.)

But then, after writing pdgmail and pdymail and seeing all the neat personal information in facebook...tada pdfbook! Memory parsing to grab facebook info.

Like it's predecessors pdgmail and pdymail, I'm following the simple construct that memory strings are easy to get to and yield a treasure of information given today's web 2.0 world of javascript, dhtml, json, etc. Facebook, it turns out doesn't seem to cough up xml like yahoo, or json like gmail but rather unique class ID strings in it's html.

What does this mean to forensics? Well with a memory dump from any of the popular memory dumping tools, strings -el and pdfbook you can get:

  • status updates
  • facebook emails
  • lists of friends
  • likely owners of the memory image

Friends come with their unique facebook ID's like:

Story from friend: id:6815841748: Name:Barack Obama

Facebook emails are raw html with authors, dates, etc like so :

FacebookEmailDetail author: Storm Large url:
FacebookEmailDetail Date: October 29 at 9:41am
FacebookEmailDetail Body: Nov 19.2009 - 8:30PM
Molly Malones - Los Angeles, California
More info:

Facebook recent activity is like so:

RecentActivity:Jeff became a fan of Fishbone.

Status updates show up like so:

StoryMessage:Jeff Bryner 2 gamble @the airport or not, that is the question.

If you're really lucky the memory image will contain enough html to produce what pdfbook recognizes as a 'delete' button which is only passed out to the owner of the html content. In other words, you are allowed to delete your posts on facebook, pdfbook recognizes this and your facebook userid, correlates it and deduces that the likely owner of the memory image is:

Likely Owner of fbook memory artifacts: FacebookUserID:1421688057 Name:Jeff Bryner

A sample usage:

on a windows or linux box, use pd from ala:
pd -p 2345> 2345.dump

where 2345 is the process ID of running instance of IE/firefox/browser of your choice.

You can also use any memory imaging software like mdd, win32dd, etc. to grab the whole memory on the box rather than just one process. You can also use common memory repositories like pagefile.sys, hiberfile.sys, etc.

I'll refer the reader to the memory imaging tool reference at the forensic wiki.

Transfer the dumped memory to linux and do:

strings -el 2345.dump> memorystrings.txt
pdfbook -f memorystrings.txt

It'll find what it can out of the memory image and spit out it's findings to standard out. Grep your way to facebook happiness or redirect the output to a file for later viewing.

As this is mosly html parsing, it's very brittle; meaning that a change in the classID of one of the facebook UI components breaks this program. Matter of fact it's already broken once since the UI rework of 10/2009. So it will work for awhile until they redesign and I'm out of sync. Maybe I'll post it to sourceforge or github so you all can update as you see fit.

Along those lines, look for the diary of pdfbook creation with explanation of it's regex goodness at the newly created freshly created this month! Dissect and contribute your own regex hacks for finding stuff you recognize in your own facebook memory images.

Related Blog Posts:

Facebook Forensics

Jeff Bryner , GCFA Gold #137, also holds the CISSP and GCIH certifications, occasionally teaches for SANS, performs forensics, intrusion analysis, and security architecture work on a daily basis and runs just for fun.


Posted November 20, 2009 at 11:29 AM | Permalink | Reply


mdd has a very important "cache poisoning/memory leak" bug you can see system cache growing very significantly in the taskmgr.
You forget to mention win64dd which is the x64 version of windd.
King regards,

Posted November 20, 2009 at 6:08 PM | Permalink | Reply

Ken Pryor

This is just very cool, Jeff. I've been on Facebook today, so perhaps I should image my ram and try this out. I haven't worked a case involving Facebook''yet''but I'm sure it's only a matter of time.

Posted November 20, 2009 at 7:10 PM | Permalink | Reply

Paul Bruner

You have some great articles. The comments were disabled on the Pointsec articel you had, but I thought I might help since we deal with pointsec all the time here.
I had recently found out that there is a Pointsec plug in for BartPE ( Sort of a windows on CD. Its picky as you have to have the same pointsec.sys file as the system, but it allows you to get into the drive without the process of decryption.
You basically boot the pointsec part of the drive and type in the admin information, then press Ctrl-F9 and press ok. You then can boot off the cd and it will load the correct drive for you to access the drive. It helps us as most easy fixes is just running chkdsk.
As I said, love the blog. going to try the decryption method you have for vmware. Save us alot of time in trying to recover somones data off a bad drive.

Posted December 4, 2009 at 12:19 AM | Permalink | Reply

Some Guy

So who has actually used this or other memory forensic techniques to grab case relevant data?

Posted July 8, 2011 at 12:05 PM | Permalink | Reply

Anthony Lai

Dear SANS fellows, we have published our latest research on Facebook Forensics. You could find it from -> announcement -> Facebook Forensics Paper Published.

Posted July 8, 2011 at 3:29 PM | Permalink | Reply


Awesome; I read that paper yesterday, great work!

Posted July 8, 2011 at 3:32 PM | Permalink

Anthony Lai

Jeff, thank you and you rock indeed as you trigger this topic and we just work out in more details to contribute to this knowledge domain.