Re: [Vol-users] Understanding memmap output

Hi Adam, "Where is this virtual memory being stored" does not really make sense - the virtual memory is virtualized - meaning it does not exist in reality and hence needs no storage. As the process accesses addresses in the virtual memory space, the kernel pages this memory in on demand from either the pagefile, or regular files on disk. Whilst you may disable page files, the OS will always be able to use the files on disk. Therefore, it is very possible (in fact likely) that not all the addressable memory for a process will be available in the memory image. The most common effect of this is when you try to dump out a process executable, e.g. with pedump, dlldump, etc. You may find pages which are not resident and hence can not be dumped from the memory image alone. Some references to help explain this: https://volatility.googlecode.com/svn/branches/scudette/docs/references.html http://www.youtube.com/watch?v=9aC7yIYwvAY And more information about memory layout: http://dfrws.org/2013/proceedings/DFRWS2013-13.pdf Michael. On 31 August 2013 00:33, Adam Bridge <adam.bridge(a)yahoo.com> wrote: > Hi Michael, > > Thank you again - I really can't thank you enough for your willingness > to help! > So, I shall definitely make this my last clarifying questions... :) > > Given "Any process running under 32 bit Windows versions gets a set of > virtual memory addresses going from 0 to 4 GB, no matter how much RAM is > actually installed on the computer."[1], if, as in my example, the > pagefile has been disabled, "where" is this virtual memory being stored? > Or is it that if the pagefile.sys is turned off, it can only commit to > 512MB, so after 512MB of allocation the system will basically fall over? > The virtual 4GB becomes irrelevant and unobtainable? > > [1] > http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileE… > (I kinda put this in to demonstrate that I am trying to find the answers > myself - I'm not just relying on your kindness!) > > Adam > > On 30/08/13 22:55, Michael Cohen wrote: >> Hi Adam, >> that depends by what you mean by "all the memory the process is >> using". If you mean "All addressable virtual memory" then the answer >> is no. Processes usually map files into memory in such a way that if >> the process accesses the mapped region of memory, a page fault occurs >> and the page is read from disk into memory - so the process thinks >> that the file is all mapped into memory at the same time. But since >> the file does not exist in the physical memory until its needed, then >> you wont see that in the capture. This process is kind of similar to >> paging to the page file, except that when mapping files from disk, the >> kernel does not need to write the data into the pagefile since it can >> just re-read it from the filesystem if it is needed again. >> >> Michael. >> >> >> >> On 30 August 2013 23:47, Adam Bridge <adam.bridge(a)yahoo.com> wrote: >>> Michael, >>> >>> Thanks again - that really helps, and makes sense! >>> >>> For clarity, given this is a Win7SP1x86 machine where I have disabled >>> PAE and disabled pagefile, is it correct to conclude that ALL of the >>> memory that this process is using is in the capture? (I gave it 512MB >>> RAM and captured all the RAM.) >>> >>> Adam >>> >>> On 30/08/13 22:27, Michael Cohen wrote: >>>> Adam, >>>> Virtual memory is not contiguous. memmap will show you the regions >>>> which are mapped to physical memory and the offset in the virtual >>>> address space where they are mapped into. The simple answer is that >>>> the process's virtual address range from 0x00000000-0x00010000 does >>>> not exist - all this means is that if the process was to reference >>>> addresses in that range, the processor will issue a page fault, and be >>>> killed. >>>> >>>> Note also that for 64 bit processes, the address space is much larger >>>> than 4GB (2^^48 actually). >>>> >>>> Michael. >>>> >>>> On 30 August 2013 22:50, Adam Bridge <adam.bridge(a)yahoo.com> wrote: >>>>> Hi all, >>>>> >>>>> Hoping for some more newbie assistance! >>>>> >>>>> I have a sample from Win7SP1x86. >>>>> When I took the capture I had notepad.exe running. >>>>> >>>>> Using pslist(1) I identified the pid and used this with memmap(2). >>>>> (1) python vol.py -f win7.raw --profile=Win7SP1x86 pslist >>>>> (2) python vol.py -f win7.raw --profile=Win7SP1x86 memmap -p 1260 >>>>> >>>>> So really two questions: >>>>> >>>>> 1> Why does the first entry show a virtual offset of 0x00010000? Why >>>>> isn't it 0x00000000? Where are the first 0x00010000 bytes of this >>>>> process's virtual memory? >>>>> >>>>> 2> (and I know this is gonna be a face palm moment) Why aren't the >>>>> virtual memory offsets contiguous? If this is a dump of the process's >>>>> virtual memory shouldn't it be one big lump of 4GB? What's the obvious >>>>> thing I'm missing? (Is it simply that notepad.exe isn't using all 4GB so >>>>> the empty pages have been ignored?) >>>>> >>>>> Thank you! >>>>> >>>>> Adam >>>>> >>>>> -- >>>>> Have you sent me your PGP Public Key yet? >>>>> >>>>> _______________________________________________ >>>>> Vol-users mailing list >>>>> Vol-users(a)volatilityfoundation.org >>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >>> -- >>> Have you sent me your PGP Public Key yet? >>> > -- > Have you sent me your PGP Public Key yet? >