Re: [Vol-users] 29c3 defeating windows memory forensics

Luka, On 1/7/2013 2:52 PM, Luka Milkovic wrote: Moonsols Community Edition appears to support a "/s" option which will generate a cryptographic checksum which may be compared to the actual checksum of the output file. While it is true, as you say, that cryptographic checksums will not detect tampering which occurred prior to the checksum's creation, adding the "/s" option should detect all of the kernel mode attacks which you document. It will force you to attack along the read path (NtMapViewOfSection, MmMapIoSpace and MmMapMemoryDumpMdl) or else to fake both the content and the checksum. I am assuming that Matthieu is generating the checksum before writing the data to disk and not from the output file after it has been written. +1 for Matthieu (maybe). If a "forensic" tool is unable reliably to acquire volatile evidence from an uncompromised system there is no reason to believe that it will perform any better in the face of sophisticated malware. The API's above may fail as part of the ordinary operation of the operating system. If an acquisition tool is unaware that the API has failed or is internally aware but fails silently the investigator will be left to guess whether the contents of the evidence file are an accurate reflection of the state of physical memory at a given moment in time or a reflection of the failure on the part of the acquisition process. Failure to implement a sound forensic process is exploitable, moreover, because a malicious entity has only to mimic a normal read error in the right location to "hide" from the hapless investigator. Just because there may be some sophisticated malware out there will defeat even the most well designed acquisition tool is no excuse for allowing yourself to become a victim of every script kiddie that comes along! Regards, George.