Wednesday, July 30, 2014

Book Review: "The Art of Memory Forensics"

I recently received a copy of The Art of Memory Forensics (thanks, Jamie!!), with a request that I write a review of the book.  Being a somewhat outspoken proponent of constructive and thoughtful feedback within the DFIR community, I agreed.

This is the seminal resource/tome on memory analysis, brought to you by THE top minds in the field.  The book covers Windows, Linux, and Mac memory analysis, and as such must be part of every DFIR analyst's reading and reference list.  The book is 858 pages (not including the ToC, Introduction, and index), and is quite literally packed with valuable information.

Some context is necessary...I'm writing this review as someone who has used Volatility for some time, albeit not to it's fullest possible extent.  I'm more of an incident responder, and not so much a malware reverse engineer; I tend to work with some really good malware RE folks and usually go to them for the deeper stuff.  I've converted hibernation files and found some pretty interesting artifacts within the resulting raw memory (my case notes are rife with some of these artifacts), and I've reached to Jamie Levy on several occasions for support.  In addition, I recently completed the five-day Volatility training course.

Also, I spend most of my time working on Windows systems; as such, I cannot offer a great deal of value, nor insight, when it comes to reviewing the information that this book contains on Linux and Mac memory. However, I have worked with some of the folks who provided material for these sections, and I've seen them present at the Open Memory Forensics Workshop (OMFW), and to say that these folks are competent is a gross understatement.

That being said, this book is the most comprehensive reference that covers the topic of memory analysis, from start to finish, available.  The authors begin the book by providing a detailed description of system architecture, as it pertains to memory, discussing address translation and paging (among other topics) before progressing into data structures.  This ground-up approach provides the foundational knowledge that's really required for a complete understanding of memory analysis.  The book then proceeds with a complete walk-through of the Volatility Framework itself, covering topics such as plugins, basic and advanced usage, etc.  There is even a chapter that covers just memory acquisition, addressing tools, tool usage, and hive extraction (using the TSK tools) to assist in profile identification.  All of this information is covered prior to addressing actual memory analysis, so that by the time a reader gets to chapter 5, they should have some understanding of memory structure and how to acquire memory.

Something pointed out in chapter 4 (Memory Acquisition) is worth repeating...that memory acquisition via software is a "topic of heated debate".  While the authors do provide a comprehensive list of software tools that can be used to acquire memory, they also state that the list is not to be viewed as an evaluation, nor should the reader consider the fact that a tool is on the list as an endorsement of that tool.  As such, YMMV based on personal experience...

Throughout the book, the authors bring their incredible wealth of experience to bear in this book, as well.  After all, who better to write a book such as this than the folks who developed the Volatility Framework as a means to meet their own needs in memory analysis, while working on what are arguably the most technologically complex cases seen.  The section on Windows memory forensics covers 14 chapters, and interspersed throughout those chapters are examples of how memory analysis can be used to assist in a wide range of analysis.  Each section starts with an "objectives" section that outlines what the reader can expect to understand once they've completed the section, and many sections provide IRL (or near-IRL) examples of how to use Volatility to support the analysis in question.  As such, the authors are not just providing a "...use this plugin...", as much as they're also providing examples of what the output of the plugin means, and how it pertains to the investigation or analysis in question.

At this point, I've had my copy of the book for a few days, and I've had a ruler and highlighter on hand since I first cracked the spine.  The formatting of the book is such that I've already started adding my own notes to the margins, based on my own exams.  I've found it valuable to go back to case notes and write notes in the margins of the book, adding context from my own exams to what the author's have provided.  This simply increases the value to the book as a reference resource.  In addition, the book is rife with caveats, concerns, and tidbits...such as the section on Timestomping Registry Keys, and what intruders have done that modify the LastWrite time of the Policy\Secrets key in the Security hive.  There's even an entire section on timelining!

If you have an interest in memory analysis, this is THE MUST-HAVE resource!  To say that if you or anyone on your team is analyzing Windows systems and doesn't have this book on your shelf is wrong, is wholly incorrect.  Do NOT keep this book on a shelf...keep it on your desk, and open!  Within the first two weeks of this book arriving into your hands, it should have a well-worn spine, and dirty finger prints and stains on the pages!  If you have a team of analysts, purchase multiple copies and engage the analysts in discussions.  If one of your analysts receives a laptop system for analysis and the report does not include information regarding the analysis of the hibernation file, I would recommend asking them why - they may have a perfectly legitimate reason for not analyzing this file, but if you had read even just a few chapters of this book, you'd understand why memory analysis is too important to ignore.


matt said...

Thanks for posting your review. I am going to order my copy now.

Ken Pryor said...

Nice review! I've been not so patiently awaiting my copy of the book and it finally arrived yesterday. I've only had time to read the introduction so far, but I have no doubt this will be a great learning experience.

Unknown said...

Hello! Can you help me please, I am working with volatility and can t find ver. 2.4 just released!

Joachim Metz said...

I had a quick read of the content and my option of the book, wait for the errata or the revised version.

There are errors in the current version book that should not be made by "THE top minds in the field".

H. Carvey said...


Can you elaborate?

Andrew Case said...


2.4 can be downloaded from here:!24/c12wa

and the Github repo is here:


The errata you found is already posted on the book's page:!amf/cmg5

Joachim Metz said...

E.g. have a look at and the same section in the book explaining the mactime output. Tell me what is wrong in the book and tell me why this mistake is problematic in a book with "forensics" in the title.

Joachim Metz said...

Luckily the authors are quick to put an errata online:

But seeing I did not read it detailed attention, I wonder how much more of these are in there.

H. Carvey said...


I'm at a bit of a loss does the errata listed at invalidate the entire book?

You suggested in your first comment that folks wait for the corrected book to come out...I'm a bit unclear as to how just those items listed in the errata.txt file would invalidate the book...

Joachim Metz said...

The error made is, from the perspective of digital forensics, so fundamentally incorrect it does not suit to be in a "forensic" book.

Questioning the validity of the of the book is not the same as "invalidate the book"; not sure how you derived that. My statement is that one is better of for it to be reviewed a bit more, especially from the forensic point of view.

What if someone copied this and it ended up in a court report?
What if this book is used as course material and people are thought incorrect?

You mentioned before that we as a community should take responsibility for mentoring/educating the next generation of DFIR specialist. Let's make sure we do that correctly, and show that forensics is about validating your findings.

H. Carvey said...

...not sure how you derived that.

Pretty simply, actually. You'd said, "...and my option of the book, wait for the errata or the revised version." Given that you had submitted the errata already (which was already available), the only other "option" anyone could come away with is to invalidate the current edition of the book and wait for the revised edition.

I think that it is also interesting that you'd say, "What if someone copied this and it ended up in a court report?
What if this book is used as course material and people are thought incorrect?", and then shortly thereafter say, " that forensics is about validating your findings."

I completely agree with your last statement, but I would think that it would obviate the first two...if an analyst were validating their findings, they wouldn't copy it directly into a court report without validating the information first.

Joachim Metz said...

> if an analyst were validating their findings,
> they wouldn't copy it directly into a court report without validating the information first.

So then the question becomes what if a "authoritative source" e.g. a forensics book says you should interpret your findings in a certain way. And you've been thought your findings should be interpreted in the same way. And what if a large part of the forensics community gives their public support to the book. Why not just assume the book is correct, since "THE top minds in the field" are saying so.

In this case there are sources that contradict the book, and you as an analyst can find out about them. But what if there are none?

> the only other "option" anyone could come away with is to invalidate
> the current edition of the book and wait for the revised edition.
Not sure I'd reason in such absolute terms as "only"; it is quibbling about semantics. I think the point is clear. If you're serious about reading this book wait until it has been scrutinized more.

Unknown said...


I read that on Windows 8 ASLR can be disabled in HKLM\SYSTEM\CurrentControlSet\SessionManager\MemoryManagement with inseration of the new Key MoveImages and the values of 0.

On Windows 8.1 there is MemoryManagement in Registry Key:

HKLM\CurrentControlSet\Control\SessionManager\Memory Management.

Then I read on another site that on Windows 8.1 disabling of ASLR is not possible.

Do you know if this is so?

I tried to do the same on Windows 8.1 but it doesn’t work.

Thanks und many Greetings,

Thorsten Kaufmann

H. Carvey said...


Do you know if this is so?

No, I don't. Do you have a link or some reference? Have you brought this up with the good folks over at the Volatility Foundation?

Unknown said...

Hi Harlan,

my sources are


I brought this up to the Volatility Foundation two days ago, but didn´t get any answer yet.

H. Carvey said...


Maybe you just need to be patient. I know that several of the Volatility team were in Australia recently, teaching for a week. Teaching can be arduous, if not exhausting...couple that with the flights to and from Australia, and I would bet that they're recovering. I remember going to Singapore a couple of years ago, and spent 15 hrs in one seat.

Two days ago was Friday here on the East Coast of the US...give the Volatility folks some time get back and get settled and rested.