How to access memory dumps in volatility3

[resposo]

Hello, everyone I am now trying to develop psxview using Volatility 3. I have completed the implementation of certain functions, but I have a question while developing them, so I wrote a question.

Question:

1. I'm curious about the principle of volatility3 accessing memory dump files (I'm having a hard time finding related data)

2. I wonder if volatility3 looks up pages across the memory dump file when accessing (lookup) the "page" of the memory dump (if so, isn't it inefficient?)

Thank you for reading this long article I hope you have a lucky day

[ikelos]

Hi @resposo ,

Thanks for your questions, I'll hopefully be able to clarify them a little for you:

1. Volatility 3 takes raw memory images (often referred to as memory dumps) and internally refers to them as layers. The layers can stack on top of one another, so first any layers required to turn the file data from a specific file format into a raw physical memory image are applied. Then on top of that, the mapping used by the architecture (at the moment, only really Intel x86/x64 mapping is available) creates a layer of virtual memory (using data within the physical memory, just like normal hardware). If you specifically mean a memory dump file created by Microsoft during a crash or similar, that's a particular file format, does not usually contain all of physical memory and we don't support those at the moment (and we may never be able to).

2. Volatility 3 does look up pages across a memory dump, the virtual layer makes the memory look contiguous, but each read traverses the page table, just like the architecture would, in order to arrive at the correct location in physical memory (and then through the file formats if the data is not a raw dump), so each read of a virtual address results in the correct data being read from the original data, provided that the map was correctly identified. It isn't particularly inefficient, although since it's carried out by python rather than hardware there will obviously be a performance impact. We've taken several steps to ensure that scanning across the whole virtual space is efficient, even when some operating systems include a large number of empty pages within the page table. You can run commands for yourself and determine whether they're efficient or not, but we've certainly improved the runtime significantly over volatility 2, in large part due to smaller scans of memory, the use of symbols to directly locate particular structures and strategic use of caching since we no longer support "live" memory analysis (ie, reading from an interface attached to a running computer).

I hope that helps answer your questions? If you have more questions like this, you're likely to get a more interactive response though our slack channel...

[resposo]

Thank you for your kind answer to the previous question. While developing plugins, I have another question I know psscan scans the entire page (allocation, non-allocation), but I'm wondering how to scan the entire page. Also, I'd like to implement a plug-in that only scans non-allocated areas, do you have any advice or resources for reference? @ikelos

[ikelos]

For windows there is a memmap plugin that might be able to nicely give you the allocated/unallocated memory map. The strings plugin also goes through determining which parts of memory are in which processes so that hits can be attributed to a particular allocation of memory, which might also be useful. More than this would be quite involved because each process can allocate its own chunks of memory and so even though something may look unallocated fom one perspective, it might be allocated from another.

Sorry for the delay, but again, if you're just asking questions, you might get more responses by asking on our slack channel (linked above)...