Re: [Vol-users] 29c3 defeating windows memory forensics
9 Jan
2013
9 Jan
'13
3:06 p.m.
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)
write(buffer, size)
On Wed, Jan 9, 2013 at 11:49 AM, Luka Milkovic <milkovic.luka(a)gmail.com>wrote:
Hi George,
On Wed, Jan 9, 2013 at 6:29 PM, George M. Garner Jr.
<ggarner_online(a)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
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).
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
ZwWriteFile).
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?
Cheers,
Luka
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
Attachments:
- attachment.html (text/html — 2.4 KB)