mkarimim / volatility

Automatically exported from code.google.com/p/volatility
GNU General Public License v2.0
0 stars 0 forks source link

FileAddressSpace.read does not handle NativeType as length parameter #350

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The FileAddressSpace.read(addr, length) API doesn't handle NativeType. All 
other AS (or at least most of them that I've seen) you can pass a NativeType as 
the length. If you pass a NativeType to FileAddressSpace.read, it directly 
sends it to Python's File I/O read() function, which of course doesn't 
understand NativeType - which results in a failure to read. 

For example:

## addrspace is a kernel AS

>>> ldr = obj.Object("_LDR_DATA_TABLE_ENTRY", offset = 0xfffffa800ccb0890, vm = 
self.addrspace)

## the length is a NativeType whose value is 66

>>> ldr.FullDllName.Length
 [unsigned short]: 66
>>> type(ldr.FullDllName.Length)
<class 'volatility.obj.NativeType'>

## you can pass the NativeType as a length to the kernel AS:

>>> ldr.obj_vm.read(ldr.FullDllName.Buffer, 
ldr.FullDllName.Length).replace('\x00', '')
'\\SystemRoot\\system32\\ntoskrnl.exe'

## the underlying AS is FileAddressSpace:

>>> ldr.obj_vm.base
<volatility.plugins.addrspaces.standard.FileAddressSpace object at 0x102fa5a90>

## translate the address of the buffer

>>> ldr.obj_vm.vtop(ldr.FullDllName.Buffer)
50941872L

## now try to read the string from the File AS using the NativeType as a length:

>>> ldr.obj_vm.base.read(50941872, ldr.FullDllName.Length).replace('\x00', '')
'D\xb0\x0f\xa0\xf8\xff\xff\x18\x1a\n\xcb\x0c\x80\xfa\xff\xff@\x08m\x87\xb4T'

## as you can see, it resulted in strange data. but if you pass an integer 
instead, it works fine:

>>> ldr.obj_vm.base.read(50941872, 66).replace('\x00', '')
'\\SystemRoot\\system32\\ntoskrnl.exe'

## or you can also cast to int()

>>> ldr.obj_vm.base.read(50941872, int(ldr.FullDllName.Length)).replace('\x00', 
'')
'\\SystemRoot\\system32\\ntoskrnl.exe'

Original issue reported on code.google.com by michael.hale@gmail.com on 8 Oct 2012 at 9:34

GoogleCodeExporter commented 8 years ago
Marking this as milestone 2.3 because it shouldn't take much to fix properly 
and can hopefully be completed with the address space code that Ikelos/AW are 
doing.

Original comment by michael.hale@gmail.com on 1 Feb 2013 at 4:18

GoogleCodeExporter commented 8 years ago
This issue was closed by revision r3354.

Original comment by labaru...@gmail.com on 8 Apr 2013 at 10:10