[Vol-users] Problem reading mapped ranges in linux address spaces
Michael Hale Ligh
michael.hale at gmail.com
Wed Jun 19 09:08:00 CDT 2013
This is the effect of swapping. When you dump a vma region to disk, we
zero-pad pages that are swapped to retain the original size and offsets in
the vma region. You can call proc_as.is_valid_address(0x7faf9d9b0e9b) and
if its False then the page containing that address is in the pagefile. You
can also use proc_as.zread() instead of read() which will automatically
zero-pad pages that are not memory resident.
On Wed, Jun 19, 2013 at 9:15 AM, Edwin Smulders <edwin.smulders at gmail.com>wrote:
> Hi all,
> I am having a problem reading certain values in an address space. I
> know for certain that the range I am trying to read is mapped, i.e.
> there is a vma for it.
> The specific range in this case is shown in the vma list as this:
> 1206 0x00007faf9d98f000 0x00007faf9db4d000 r-x 0x0
> 8 1 241 /lib/x86_64-linux-gnu/libc-2.17.so
> The offset in this range that I am trying to read is 0x21e9b =
> the call may look like this: proc_as.read(0x7faf9d9b0e9b, 10)
> and it will return None, meaning it could not read that address.
> Using the linux_dump_map I exported the whole range and there's a
> pretty big empty (inaccessible) chunk in the middle, which appears as
> 0-bytes in the export. I know for a fact that my libc does not have a
> big area of 0-bytes, so this is pretty weird. It also works just fine
> for other processes in the same dump (so using the same libc).
> For research purposes I make my memory dumps with virtualbox, so I
> don't think it's an issue with memory corruption; as far as i can
> tell, virtualbox makes complete snapshots.
> Does anyone know what might cause this problem?
> Vol-users mailing list
> Vol-users at volatilityfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vol-users