Re: [Vol-users] Anti-forensic resilient memory acquisition [was: An evaluation platform for forensic memory acquisition software.]

Hi George, Reading the referenced Intel manual we see: <quote> The PAT allows any memory type to be specified in the page tables, and therefore it is possible to have a single physical page mapped to two or more different linear addresses, each with different memory types. Intel does not support this practice because it may lead to undefined operations that can result in a system failure. </quote> So indeed you are correct is saying that mapping pages with incompatible attributes is not recommended. We read further to understand why: <quote> In particular, a WC page must never be aliased to a cacheable page because WC writes may not check the processor caches. </quote> So this seems to again suggest this is only a problem when writing to the page. Corruption occurs only when memory is modified - i.e. written to. If we only ever read the memory there is no possibility that our reading of memory can cause any memory to change? Note that the PTE remapping technique is precisely the same as firewire acquisition technique - in that case the DMA controller creates a mapping into the physical address space (usually with no caching attributes) to read the memory that is mapped at whatever caching attribute it happens to be at. It will almost certainly conflict with the cache attribute the OS is using. It is true that the OS will normally not let you create conflicting mapping. For example, http://msdn.microsoft.com/en-us/library/windows/hardware/ff566481%28v=vs.85… <quote> ZwMapViewOfSection routine can fail with: STATUS_CONFLICTING_ADDRESSES The specified address range conflicts with an address range already reserved, or the specified cache attribute type conflicts with the address range's existing cache attribute. For example, if the memory being mapped lies within a large page that is already mapped as fully cached, then it is illegal to request to map this memory as noncached or write combined. </quote> This occurs because the OS is trying to ensure that cache coherency is maintained both for old users of the page and the new users of the page. This is an example where calling the APIs will actually fail to create a mapping at all - so rather than being able to take an image with an incoherent cache (maybe slightly out of sync), now we can not read this page at all. I suppose an imaging tool can retry the mapping with all different cache attributes until it works? By using the MMU translation directly we bypass these restrictions placed by the OS - providing we understand the ramifications, we should be ok. Im not sure I can do much with the anecdotal evidence you present of windows 2000? How do you know that cache attribute mismatch caused the instability? If your tool called the OS APIs its likely that the OS APIs themselves caused buggy behaviour (when calling the OS APIs you have no idea what code is actually running right?). Please dont get me wrong, I am not saying that our technique is foolproof and super stable. I have no evidence of that, since this is a research project and did not have the wide field testing we need to give it (on all kinds of hardware). I am just saying that your logical argument seems to be built on anecdotal evidence and does not really sit well with my understanding of how CPU caching works. It may be that you are right in practice but we have not experienced instability in our testing so far. It is a complex field and requires more research. I am just pointing out that your argument with conflicting cache attributes does not seem to apply to the case of read only imaging of physical memory. Michael. On 19 August 2013 21:58, George M. Garner Jr. &lt;ggarner_online(a)gmgsystemsinc.com&gt; wrote: