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 volshell:

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

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)
5591050168L

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

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

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,
MHL


On Mon, May 6, 2013 at 7:37 AM, Frédéric Baguelin <frederic.baguelin@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@arxsys.fr
ArxSys SAS, Directeur technique
Tél: +33 146 362 522
_______________________________________________
Vol-dev mailing list
Vol-dev@volatilesystems.com
http://lists.volatilityfoundation.org/mailman/listinfo/vol-dev