[Vol-users] Problem reading mapped ranges in linux address spaces

Joe Sylve joe.sylve at gmail.com
Wed Jun 19 10:06:42 CDT 2013


Edwin,

If you read the intel manuals, swapping isn't actually terribly
complicated.  You could conceivably implement swapping functionality into
volatility (of course you'd have to pass a swap file or partition as a
parameter).  The problem that I for-see is that you might run into issues
with smearing, since you're collecting memory from a running machine, but
it might be worth the effort.

On Wed, Jun 19, 2013 at 9:13 AM, Edwin Smulders <edwin.smulders at gmail.com>wrote:

> Ahh, that is really too bad, I was pretty sure I had enough memory,
> but I suppose swapping might occur at any moment, even with a good
> amount of free memory.
> Thanks for your answer, it's yet another issue I can include in my thesis
> :)
>
> On 19 June 2013 16:08, Michael Hale Ligh <michael.hale at gmail.com> wrote:
> > Hi Edwin,
> >
> > 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.
> >
> > MHL
> >
> >
> > 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 =
> >> 0x7faf9d9b0e9b
> >>
> >> 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?
> >>
> >> Cheers,
> >> Edwin
> >> _______________________________________________
> >> Vol-users mailing list
> >> Vol-users at volatilityfoundation.org
> >> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> >
> >
> _______________________________________________
> Vol-users mailing list
> Vol-users at volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.volatilityfoundation.org/pipermail/vol-users/attachments/20130619/c65a2835/attachment.html


More information about the Vol-users mailing list