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(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

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(a)gmail.com> wrote: _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

I have a small follow-up question; Am I correct in my understanding that a shared library can be (seemingly) swapped out for one process, but not for another? For example, because the relevant PTE has not been restored yet? I've read https://www.kernel.org/doc/gorman/html/understand/understand014.html but since it's written from a 'running system' point of view, it's not quite clear to me yet. Cheers, Edwin On 19 June 2013 17:06, Joe Sylve <joe.sylve(a)gmail.com> wrote: > 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(a)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(a)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(a)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(a)volatilityfoundation.org >> >> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >> > >> > >> _______________________________________________ >> Vol-users mailing list >> Vol-users(a)volatilityfoundation.org >> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >