<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Memory acquisition and the pagefile(s)</title>
	<atom:link href="http://blog.mandiant.com/archives/1157/feed" rel="self" type="application/rss+xml" />
	<link>https://blog.mandiant.com/archives/1157?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=memory-acquisition-pagefiles-part-ii</link>
	<description>The Ammunition You Need to Find Evil and Solve Crime</description>
	<lastBuildDate>Mon, 06 Feb 2012 23:03:19 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Jamie Butler</title>
		<link>https://blog.mandiant.com/archives/1157/comment-page-1#comment-83</link>
		<dc:creator>Jamie Butler</dc:creator>
		<pubDate>Fri, 23 Jul 2010 16:08:19 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mandiant.com/?p=1157#comment-83</guid>
		<description>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&#039;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</description>
		<content:encoded><![CDATA[<p>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. </p>
<p>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&#8217;s APIs.</p>
<p>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.</p>
<p>Thanks for reading. I look forward to discussing it more.<br />
Jamie</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sebastienbr</title>
		<link>https://blog.mandiant.com/archives/1157/comment-page-1#comment-81</link>
		<dc:creator>sebastienbr</dc:creator>
		<pubDate>Thu, 22 Jul 2010 16:05:50 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mandiant.com/?p=1157#comment-81</guid>
		<description>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. 

&quot;tools typically parse the filesystem for access to the sectors that represent the pagefiles&quot;

First this technique only works with NTFS, right? There&#039;s no solution for FAT32?

Also, if we use NTFS index to acquire pagefile sectors, our acquisition will have hdd slackspace. Here&#039;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&#039;t think so because this slackspace will be analysed in the post-mortem forensic analysis. Also, I don&#039;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</description>
		<content:encoded><![CDATA[<p>Nice post, thanks for sharing information on the pagefile!</p>
<p>To have a complete memory dump, I agree that we need to acquire the pagefile(s) at the same moment we acquire the memory. </p>
<p>But something seems wrong to me with the pagefile acquisition process. </p>
<p>&#8220;tools typically parse the filesystem for access to the sectors that represent the pagefiles&#8221;</p>
<p>First this technique only works with NTFS, right? There&#8217;s no solution for FAT32?</p>
<p>Also, if we use NTFS index to acquire pagefile sectors, our acquisition will have hdd slackspace. Here&#8217;s a quick test I did:</p>
<p>1) Create a new disk on vmware, quick format to ntfs<br />
2) Move the pagefile to the new hdd, reboot<br />
3) Acquire memory + pagefile</p>
<p>Pagefile acquisition is full of 00 (hdd slackspace).</p>
<p>Do we really need to acquire this slackspace for memory analysis? I don&#8217;t think so because this slackspace will be analysed in the post-mortem forensic analysis. Also, I don&#8217;t think this slackspace is relevant to the state of a running computer (live memory analysis).</p>
<p>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?</p>
<p>0) Full memory acquisition<br />
1) Parse the VAD tree of each process and find every virtual page that is in the pagefile<br />
2) Restore those pages from the pagefile to the memory<br />
3) Acquire restored page in memory</p>
<p>Thanks again for the series of post on the pagefile!</p>
<p>Sebastien Bourdon-Richard</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jamie Butler</title>
		<link>https://blog.mandiant.com/archives/1157/comment-page-1#comment-66</link>
		<dc:creator>Jamie Butler</dc:creator>
		<pubDate>Thu, 08 Jul 2010 02:18:45 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mandiant.com/?p=1157#comment-66</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

