[Vol-dev] Method to get absolute physical address

Michael Hale Ligh michael.hale at gmail.com
Tue May 7 00:53:25 CDT 2013

Hi Frédéric,

Thanks for restating the question, I didn't completely understand on
twitter. The good news is that we're planning a slight refactor of the
address space API and basic inheritance scheme. In fact its one of the two
big patches that need to get finished for the 2.3 release. In the patch, we
will be getting rid of the get_addr() and __get_offset() methods that you
described and making a standardized translate() function. The virtual/paged
address spaces will still have a vtop() for virtual to physical
translation, but it will also have a translate() which is essentially an
alias for vtop(). The difference is that all middle layers like VirtualBox,
VMware, Crash, Hibernation, etc which are really run-based address spaces
will use translate() to convert an address within a run to an offset in the
underlying file.

So just to give you a little preview, here's a VirtualBox file loaded in

>>> self.addrspace
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0x104d54510>
>>> self.addrspace.base
<volatility.plugins.addrspaces.vboxelf.VirtualBoxCoreDumpElf64 object at
>>> self.addrspace.base.base
<volatility.plugins.addrspaces.standard.FileAddressSpace object at

After the patch is applied, you can write a function like the following:

>>> def get_absolute_physical_address(addr_space, address):
...   while addr_space.base:
...     address = addr_space.translate(address)
...     addr_space = addr_space.base
...   return address

And you can use it like this:

>>> get_absolute_physical_address(self.addrspace, 0xfffffa8004bf6060)

That should come out to the same thing as the longer, multi-step process
(just shown as an example):

>>> self.addrspace.vtop(0xfffffa8004bf6060)
>>> self.addrspace.base.translate(6073311328L)

The patch is expected to be committed within a week or so, we're finishing
up some final tests and bug fixes!

Hope this helps,

On Mon, May 6, 2013 at 7:37 AM, Frédéric Baguelin <
frederic.baguelin at arxsys.fr> wrote:

> Hi List,
> It's my first post here, so first of all, thanks a lot for this project !
> I'm currently working with Volatility 2.2 (testing with 2.3 too) to link
> it with
> DFF [1]. I've almost finished my module but a co-worker provided me a dump
> acquired via VirtualBox. Thereferore, I used latest vboxelf.py available in
> trunk on the svn but here is the problem:
> DFF'API provides some mechanism to represent file mapping: logical offset,
> size,
> physical offset and underlying file for each chunk of data. This is how we
> are
> able to have access to all exe, dlls and modules without having to extract
> them
> with Volatility. Precisely, I adapted the code used by procexedump to be
> able to
> push each chunk. At least, I have the same sha1 than files created with
> procexedump even if some chunk are overlapping but this is off topic
> So, when having the following layers, everything is ok:
> AS Layer 1 JKIA32PagedMemoryPae ( Kernel AS )
> AS Layer 2 dffAdressSpace ( /Logical files/ds_fuzz_hidden_proc.img )
> __But__ when dealing with the following ones:
> AS Layer 1 JKIA32PagedMemoryPae ( Kernel AS )
> AS Layer 2 VirtualBoxCoreDumpElf64 ( Unnamed AS )
> AS Layer 3 dffAdressSpace ( /Logical
> files/Window7_2013-04-24_18_51_39.310504 )
> Content for each exe, dll and module is wrong. In the code where I push
> chunk
> for each files, I use vtop() method of the corresponding address space but
> since
> there is another level here, I'm missing the last translation of the
> address.
> The vtop() returns what could be seen as a virtual address for the Layer 2.
> So I dug the code of vboxelf.py and saw there was a get_addr() method I
> could
> use but it is not a "standardized" method. The issue would be the same
> with a
> dump acquired with Lime for example (which has __get_offset() method
> itself).
> So here is my question, could it be possible to implement a standard
> method in
> each address space plugins to be able to obtain the corresponding address
> for
> the underlying layer ? Finally, either having a global function iterating
> on
> each layer to provide the "absolute" physical address or something like
> that.
> Regards,
> [1] http://www.digital-forensic.org/
> --
> Frédéric Baguelin    frederic.baguelin at arxsys.fr
> ArxSys SAS, Directeur technique
> Tél: +33 146 362 522
> _______________________________________________
> Vol-dev mailing list
> Vol-dev at volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.volatilityfoundation.org/pipermail/vol-dev/attachments/20130507/04f460ce/attachment.html

More information about the Vol-dev mailing list