ROPMEMU is a framework to analyze, dissect and decompile complex code-reuse attacks. It adopts a set of different techniques to analyze ROP chains and reconstruct their equivalent code in a form that can be analyzed by traditional reverse engineering tools. In particular, it is based on memory forensics (as its input is a physical memory dump), code emulation (to faithfully rebuild the original ROP chain), multi-path execution (to extract the ROP chain payload), CFG recovery (to rebuild the original control flow), and a number of compiler transformations (to simplify the final instructions of the ROP chain). Specifically, the memory forensics part is based on Volatility plugins. The emulation and the multi-path part is implemented through the Unicorn emulator. […]
Tag: volatility
book review: The Art of Memory Forensics
I just read The Art of Memory Forensics. Great book! I’m reviewing the book w/r/t/ firmware coverage. As the book promises, it covers OS-level memory issues. It wasn’t scoped to cover firmware and hardware issues, and only has a bit on this topic.
In a nutshell, the book teaches you Intel x86/x64 memory, and how Microsoft Windows, Apple Mac OS X, and Linux use memory, for forensic examinations. From this scope, the book is excellent, very well-written coverage of Intel memory details, hard to find other documentation that describes it so well. There focuses more on Windows than Unix-flavored OSes. It is well-written, better than most technology books.
…But Hacking Team’s UEFI-centric malware is an example that OS-level memory forensics are not the state of the art anymore, forensics needs to cover firmware a LOT better.
I’m not picking on this book or Volatility, I mean in general, computer forensics is too OS/app-focused.
This book does not cover hardware/firmware-level memory forensics.
There is no BIOS UEFI, ACPI, or firmware in Index. There is no coverage of OptionROMs, Expansion ROMs, SMM, UEFI variables, etc.
There is one brief mention of EFI (not UEFI), a OSX-centric reference, using the OSXPmem and MacMemoryReader tools. No UEFI coverage outside Mac hardware.
There is no ACPI in Index, but there are a few ACPI references in the output of a handful of tools, mostly just to show the address of the tables.
On page 72, covering memory acquisition, it briefly mentions DMA, Firewire, Thunderbolt, ExpressCard, and PCI, and an US$8K WindowSCOPE tool.
On page 659, when discussing Linux memory resources, and how APIC can remap memory, the book says:
“Malware can hook the APIC data structures to redirect control flow of interrupts to attacker-controlled handler functions. Inspecting the memory maps can help you understand where the hoooks are pointing and their impact on thei system. Besides the APIC, a number of other hardware devies have also been targetted by malware, such as video cards and PCI network cards.”
That paragraph is about as low-level as the book gets, w/r/t hardware/firmware.
On pages 658-661, there is a brief section on ‘detecting hardware manipulation’, Linux-centric, with linux_dmesg and linux_iomem plugins. There is brief tangent on patching LiME to capture physical memory outside of system RAM range, they could be covering other tools that don’t need patching, not just focusing on tools which have Volatility plugins.
Again, this book wasn’t focuses on firmware, just OS-level forensics. This book is GREAT for OS-level forensics.
To be as constructive as possible, I’m hoping that the second edition of this book includes:
* Expand the system model from the ring0/ring3 model to include negative rings, more detail to silicon, firmware, and virtualized levels.
* Mention of unacquirable memory, such as data stored in TPM chip. Perhaps SMM’s LockBox.
* Like PE discussion has a section on packing, some IBVs have proprietary compression algorithms for their firmware.
* ARM, AArch32 and AARch64 memory, not just Intel systems.
* Expand disk coverage from Windows-centric NTFS to also include MBR and GPT partitions, and a bit more on non-NTFS file systems.
* There is brief mention of virtual machine software, VMWare, VirtualBox, Xen/KVM, QEMU. Second edition should have more discussion on virtual hardware/firmware issues, including ESP and pre-OS installed .efi drivers via UEFI Shell startup.ns.
* UEFI Shell pre-OS environment as a target, along with OS-level targets, including the shell commands to dump memory. Discuss the basics of capturing memory with tools like CHIPSEC, analysing ROMs with tools like UEFITool, UEFI Firmware Parser, and others, to search for strings, and figure out what modules are in the system.
* Discussion of Terse Executable (TE) variant of PE, which UEFI uses, along with Capsule update, firmware volume, FFS, and other containers for images.
* Discusses pre-OS memory issues along with OS memory issues. Enumerate the various forms of memory UEFI treats special, before and after OS handoff.
* There is brief discussion of malware hiding in video RAM. Add section discussing Option ROMs, Expansion ROMs, USB firmware, and additional firmware drivers/services optionally loaded via ESP and OEM/IHV flash. Discussion on different hardware busses that have these OpROMs, FFS and other formats used for storing drivers. Clarfication of the pre-UEFI ‘blobs’ and the UEFI PEIMs/DXE/UEFI drivers stored there.
* Discuss ACPI tables and how malware can use it, cover areas like WBPT which has Windows-centric PE executable image(s) in them.
* Cover UEFI’s variables, the different kinds and how they’re differently stored in memory and on disk/flash.
In summary, this book is great for OS-level memory forensics and using Volatility. I hope the second edition features a UEFI-aware Volatility and covers memory forensics for ‘negative rings’. And I hope the person who wrote the very nice Intel memory introduction does the same thing for ARM memory.
Book aside, Volatility also should port their project to run w/i UEFI Shell with UEFI’s Python, so it can directly acquire memory from this environment, and forensic examiners can use Volatility as a pre-OS tool, which has the best access to hardware/firmware areas where malware may be hiding. Also, Volatility needs plugins for CHIPSEC, UEFI Firmware Parser, and a half dozen other Python firmware parsing tools.
http://dl.acm.org/citation.cfm?id=2621971
http://www.wiley.com/WileyCDA/WileyTitle/productCd-1118825098.html
https://github.com/volatilityfoundation
http://www.volatilityfoundation.org/
2015 Volatility Plugin Contest open
There’s a LOT of UEFI firmware-centric stuff that could be added to Volatility. I hope some creative security researchers consider some of the ‘low-hanging fruit’, they are offering $$ as reward for the code. 🙂 Integration with CHIPSEC’s library for forensic examination. Tianocore’s GUIDs and structure signatures, TE image format (small tweaks to PE+), firmware volume and capsule and related container formats. I wonder if Volatility can be ported to UEFI’s CPython 2.7x, so it can be used inside UEFI, and have much more access to the system? If not ported, then a bridge to an OS-level Volatility talking to CPython inside an OVMF? There’s a lot of existing Python code on exising Github projects that could be refactored, as well.
http://www.volatilityfoundation.org/#!2015/c1qp0
Home of The Volatility Foundation | Volatility Memory Forensics
