panda
panda copied to clipboard
panda-re
Volatility functionality broken
pypanda volatility commands as get_volatility_symbols() are broken due to a change in Volatility 3 API (volatility pip package is now called "volatility3" and FileConsumerInterface is been replaced (see https://github.com/volatilityfoundation/volatility3/pull/319)
Related to this one there is another bug: the class PandaFileHandler produces errors if you allocate more than 3GB of RAM and crash QEMU. I'm trying to fix it obtaining the RAM (and ROM, but not I/O) regions defined for the machine in order to check directly if the address is a valid one or not. I'm thinking to use info mtree -f as monitor command, but it is not an elegant solution. You know if there is a more elegant way to get the map of all RAM/ROM regions (no I/O)?
After writing the file handler I learned about the pmemaccess monitor command. I believe that's the more common way for volatility to access memory in the first place and might be a better fit.
Which was the Volatility 3 commit used during the implementation of the functionalities in panda?
It seems likely it last worked with the fork of volatility3 that I made (lacraig2/volatility3). The latest commit on master there is 4587de356d9be2e35ed58b4fbde7feb14f695a7c.
I’m considering updating this functionality.
Why not create an interface that live exports the content of the physical memory in an ELF file like dump-guest-memory through a UNIX pipe? in that way we can use volatility directly on that file! We will obtain the automatic support to every version of volatility for each OS! We can reuse the code of dump-guest-memory to implement it...
That existed as a PANDA plugin in v1: https://github.com/moyix/panda/tree/master/qemu/panda_plugins/pmemaccess
It was built for: https://github.com/moyix/panda-malrec
I think we'd support a port to new PANDA.
If I have understood correctly that plugin suppose the physical memory is contiguous (which in general is false), and Volatility access to it as a continuous file, which can (with high probability generate errors or require enormous amount of time to scan it in order to load the correct profile). An ELF file can manage directly discontinuous ranges of physical memory and it is natively supported by Volatility 2/3 and also by drgn as it is a kcore file
That'd be nice to have. You'd essentially need to read the memory regions and construct an ELF file front to be read.