Home Contact

M-unition

The Ammunition You Need to Find Evil and Solve Crime

About Us

Welcome to M-unition, the MANDIANT blog. Here we share our insights about the tools we create and use to find evil and solve crime.

Memory acquisition and the pagefile(s)

Written by Jamie Butler

In the past, I have discussed how in reality there may be as many as 16 pagefiles on a single host. The next question is, “How much data could be contained in all these pagefiles”? Why does this matter? Well, the more data in the pagefiles, the longer they will take to acquire.
 
The size of the pagefiles usually depends on the amount of RAM in the host. If you allow Windows to automatically configure the pagefile(s), it will typically recommend that the total size of the pagefiles should be 1.5 times the size of RAM. Here is an example of the recommended settings on a host with 3.5 GB of memory.

The recommended total pagefile size is 5,371 MB or approximately 1.5 times 3.5 GB. However, you can configure the pagefiles manually. Some Web sites suggest making the size of the pagefile(s) as much as 3 times the size of RAM. This is what Microsoft has suggested as the maximum size for better performance on Windows XP.
 
As pagefiles get bigger, they will take longer to acquire. Let’s look at how large they could be in x64 / EM64T, which is generically referred to as 64bit. On 64bit Windows hosts, 32bits or 2^32 are used to represent the offset in the pagefile where the page was stored. Each page in the pagefile is 4096 bytes or 2^12. We know there can be as many as 16 pagefiles or 2^4. Putting it all together:
 
(Pagefile Offset) * (Page Size) * (Number of Pagefiles) = Total Size of Paging Data
 
(2^32) * (2^12) * (2^4) = Total Size of Paging Data
 
2^48 = Total Size of Paging Data
 
281,474,976,710,656 = Total Size of Paging Data
 
256 TB = Total Size of Paging Data

Now, I know 256 TB is not going to be typical, but acquiring even 4 GB to 12 GB of paging files can take a long time. The pagefiles are in use and locked by the operating system. To gain access, tools typically parse the filesystem for access to the sectors that represent the pagefiles. This prolongs the time required to acquire the files.
 
Next time in this series, we will discuss more about time and its implication on the paging files. If this series is boring you, the memory forensics class at Black Hat contains more hands-on applications and use cases. This year, Aaron LeMasters, author of Web Historian 2.0, will be helping with the class. I hope to see you there.

Tags: , , ,

. 07 Jul 10 | General
«
»


Reader's Comments

  1. Jamie Butler | July 7th, 2010 at 9:18 pm

    Yes, Peter and I are still working on Memoryze for Windows 7 64bit. Peter made a lot of progress today. Beta should be available for Black Hat.

  2. sebastienbr | July 22nd, 2010 at 11:05 am

    Nice post, thanks for sharing information on the pagefile!

    To have a complete memory dump, I agree that we need to acquire the pagefile(s) at the same moment we acquire the memory.

    But something seems wrong to me with the pagefile acquisition process.

    “tools typically parse the filesystem for access to the sectors that represent the pagefiles”

    First this technique only works with NTFS, right? There’s no solution for FAT32?

    Also, if we use NTFS index to acquire pagefile sectors, our acquisition will have hdd slackspace. Here’s a quick test I did:

    1) Create a new disk on vmware, quick format to ntfs
    2) Move the pagefile to the new hdd, reboot
    3) Acquire memory + pagefile

    Pagefile acquisition is full of 00 (hdd slackspace).

    Do we really need to acquire this slackspace for memory analysis? I don’t think so because this slackspace will be analysed in the post-mortem forensic analysis. Also, I don’t think this slackspace is relevant to the state of a running computer (live memory analysis).

    When the CPU do a virtual to physical address translation, he knows that the page is in the pagefile when the last bit of the PDE (page directory entry) is 0. Can that be a better way to acquire the pagefile?

    0) Full memory acquisition
    1) Parse the VAD tree of each process and find every virtual page that is in the pagefile
    2) Restore those pages from the pagefile to the memory
    3) Acquire restored page in memory

    Thanks again for the series of post on the pagefile!

    Sebastien Bourdon-Richard

  3. Jamie Butler | July 23rd, 2010 at 11:08 am

    Parsing the filesystem for sectors that represent the pagefiles works on both NTFS and FAT/16/32. I will not go into all the details because Brian Carrier already wrote that book. You can use the Sleuth Kit binaries to validate this.

    Also, the slack space is not involved because the file has not been deleted. I can create an abstraction layer to read the pagefiles with an offset into the pagefile and a size just like the OS’s APIs.

    You are correct that we do not know what page is paged out until the moment of translation (last bit of PTE is 0). This presents the biggest problem. Timing is everything, and the pagefiles are changing as we acquire and translate. That is why Memoryze only uses the pagefiles during a Live analysis. If we encounter a single page paged out at the moment of translation, we read the pagefile in question. That way the lag time is milliseconds instead of minutes.

    Thanks for reading. I look forward to discussing it more.
    Jamie



Leave a Reply

You must be logged in to post a comment.