7:37 a.m.
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(a)arxsys.fr
ArxSys SAS, Directeur technique
Tél: +33 146 362 522
1:53 a.m.
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(a)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(a)arxsys.fr
ArxSys SAS, Directeur technique
Tél: +33 146 362 522
_______________________________________________
Vol-dev mailing list
Vol-dev(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-dev
9:25 a.m.
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:
--
Frédéric Baguelin frederic.baguelin(a)arxsys.fr
ArxSys SAS, Directeur technique
Tél: +33 146 362 522
>> 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(a)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(a)arxsys.fr
ArxSys SAS, Directeur technique
Tél: +33 146 362 522
_______________________________________________
Vol-dev mailing list
Vol-dev(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-dev
4209
days inactive
4210
days old
vol-dev@lists.volatilityfoundation.org
2 comments
2 participants
participants (2)
-
Frédéric Baguelin -
Michael Hale Ligh