Full Memory Crash Dumps vs. Raw Dumps: Which Is Best for Memory Analysis for Incident Response ?
This memory analysis post is authored by Matt Suiche (Director, Memory, IR & R&D).
Memory Analysis is Essential for Incident Response
Memory analysis is an essential component of incident response and network forensics. It involves leveraging various tools to capture and analyze memory dumps to uncover malicious activity, malicious code, and other forensically relevant evidence.
Memory analysis allows you to investigate beyond what traditional EDR solutions can provide, which is especially important when investigating fileless malware and living off the land (LOTL) attacks. Memory dumps contain information not always accessible by EDR solutions, giving you detailed insight into what has been done on a system, even though the malicious activity may have already been removed.
Memory analysis has been referred to by many names, including memory forensics, post-mortem analysis, incident response, virtual machine introspection, and troubleshooting. To encompass all of these related practices, I refer to this field as simply memory analysis.
As well, the field of memory analysis has evolved significantly since the 1970s. In this post, I will take you through a brief history of the first memory analysis tools used by troubleshooters to debug systems. We’ll look at why raw dump files (plain memory images that do not contain file headers or additional context) were commonly used, and often still are today, despite posing drawbacks compared to crash dumps for incident response, and why crash dumps are superior.
The Evolution of Memory Forensics
The use of memory dumps to capture an image of a system memory dates back to the ‘70s, when IBM systems were the first to employ this technique. In the late ‘90s, Microsoft released Windows NT Support Tools for NT4, which included the powerful WinDbg debugger. This tool is still being used today for debugging applications and analyzing Microsoft crash dumps (MEMORY.dmp) generated by the infamous Microsoft Windows Blue Screen of Death (BSOD) we have all seen numerous times in our lives.
In 2000, Mark Russinovich, now CTO of Microsoft Azure, released LiveKd as part of his book Inside Windows 2000, 3rd Edition. This tool allowed for running Kd and WinDbg on a live system by creating a virtual crash dump file. In 2010, I published LiveCloudKd, which used a similar mechanism for Hyper-V virtual machines. This was later also implemented in LiveKd 5.0 by Mark and Ken Johnson.
UNIX systems have a long history of using core dumps for troubleshooting. Sam Gwydir, in his 2017 presentation on BSD core dump history, discussed the introduction of doadump() more than 40 years ago, which enabled UNIX core dumps to be stored to magnetic tapes and eventually to hard disks, files, and networks.
Goodbye BSOD: Generating Crash Dumps With DumpIt
In 2007, I released win32dd, an open-source tool for generating full memory dumps. This tool addressed an issue of existing tools, which could not properly read physical memory layouts, often resulting in the Blue Screen of Death (BSOD). This was done by documenting and using the introduction of the new Microsoft MmGetPhysicalMemoryRanges API and implementing it inside win32dd.
Later, win32dd became a closed-source tool, renamed DumpIt, and focused on generating full memory crash dumps for interoperability reasons. Raw dumps generation remained a legacy feature. (Now, you can download MAGNET DumpIt for Windows from the Magnet Forensics Free Tool page, and MAGNET DumpIt for Linux from GitHub.)
Around that time, the tools and products created by the security community, such as HBGary, Komoku’s volatools, Volatility, and Mandiant Redline, enabled the continued usage of raw memory dumps instead of Microsoft crash dumps. Out of all of the different types of Windows memory images, the most popular were always generated by the operating systems as Microsoft Windows crash dumps (MEMORY.dmp, full, kernel, process) or as the Windows hibernation file (hiberfil.sys).
Crash Dumps vs. Raw Dumps for Memory Analysis
Crash dumps, also known as core dumps, are a type of full memory dump. They are interoperable with other tools like crash, drgn, or WinDbg. They contain additional information in the header, and they can also contain a full copy of the memory. For this reason, they are superior to raw dumps and are the preferred format for memory analysis.
Crash/core dump files are the foundation of troubleshooting for Microsoft Windows, Linux, and BSD systems. They are composed of a file header, which is parsed by troubleshooting tools developed by system engineers, and multiple formats—full memory, kernel, or userland—which vary in size depending on the amount of memory in the system. For example, multi-TBs of RAM are becoming more common in critical assets.
Debug symbols for the target kernel are often necessary when analyzing crash/core dump files. Fortunately, these files do not have to be understood ahead of time; they can be analyzed off a live system and archived for future comparison or analysis. This is a valuable resource for troubleshooters and analysts.
Memory images are used for a variety of purposes, including troubleshooting, memory snapshots in various operating systems (e.g. Windows hibernation files, which can be uncompressed with hibr2bin for Windows (2008 Slides), or swsusp2bin for Linux, and as hypervisor snapshots and checkpoints (.VMRS files with Microsoft Hyper-V Runtime State).
Generate Full Memory Crash Dumps: Get MAGNET DumpIt for Windows & MAGNET DumpIt for Linux
Start generating full memory crash dumps of Windows and Linux systems with our free tools:
Additional Resources
- Blog: How to Conquer Memory Analysis for Incident Response, Threat Hunting and Compromise Assessment
- Volatile Memory IR With Comae Beta From Magnet Idea Lab
To learn more about how Magnet Forensics can help you and your incident responders quickly uncover and report on the root cause of cyber security incidents, visit our incident response page for more resources.