10:13 a.m.
As MHL said this can definitely occur. For now the best choice you
have is try to use linux_find_file to pull the file from the page
(disk) cache in memory. This will recover the file as it is on disk,
but you could conceivably write something that overlays the missing
pages from a particular process' address space with the corresponding
page from the page cache.
On Thu, Jul 11, 2013 at 6:27 AM, Edwin Smulders
<edwin.smulders(a)gmail.com> wrote:
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:
_______________________________________________
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:
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