'[Vol-dev] Method to get absolute physical address'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vol-dev
Subject:    [Vol-dev] Method to get absolute physical address
From:       frederic.baguelin () arxsys ! fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Baguelin?=)
Date:       2013-05-07 1:21:13
Message-ID: 518900D7.2020107 () arxsys ! fr
[Download RAW message or body]

Hi Michael,

Thanks for your fast answer ! That's exactly what I need, I'm looking forward to
applying this patch :)

Keep up the good work !

Regards,

On 05/07/2013 07:53 AM, Michael Hale Ligh wrote:
> 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.volatilesystems.com/mailman/listinfo/vol-dev
>>
> 

-- 
Fr?d?ric Baguelin    frederic.baguelin@arxsys.fr
ArxSys SAS, Directeur technique
T?l: +33 146 362 522

[prev in list] [next in list] [prev in thread] [next in thread] 