[Vol-users] 29c3 defeating windows memory forensics
msuiche at gmail.com
Wed Jan 9 14:06:45 CST 2013
I just read the email quickly.
The checksum is being computed before writting on disk. There is no reason
to read the file to compute the checksum.
buffer = readmem(pa, size)
chksum += checksum(buffer, size)
On Wed, Jan 9, 2013 at 11:49 AM, Luka Milkovic <milkovic.luka at gmail.com>wrote:
> Hi George,
> On Wed, Jan 9, 2013 at 6:29 PM, George M. Garner Jr.
> <ggarner_online at gmgsystemsinc.com> 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
> > the read path (NtMapViewOfSection, MmMapIoSpace and MmMapMemoryDumpMdl)
> > else to fake both the content and the checksum. I am assuming that
> > is generating the checksum before writing the data to disk and not from
> > output file after it has been written. +1 for Matthieu (maybe).
> Unfortunately, that's not the case:(
> The reason is that the checksum is calculated on the buffer *after* it
> has been written to the file (basically the next call after
> When Dementia is used, checksum of the dump created by win32dd equals
> to the one printed out in the console.
> Matthieu, what do you think about making the checksum before writing
> the buffer to dump?
> Vol-users mailing list
> Vol-users at volatilityfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vol-users