Michael,
Thanks for the email!  If possible, it would be a great help if you could
find a way to create a test case that you could send us. Otherwise, this
will be extremely difficult for us to validate considering we don't have
access to the data or XWF.
You may want to write a script that hashes the pages of the converted
samples and compares the differences.  This would provide more insight
into what may be happening.
You may also want to consider moving the discussion to vol-dev or jumping
on the irc channel.
Thanks for contributing!
AW
On Tue, 7 Jul 2009, Michael Felber , Steufa Chemnitz, IT-Forensik wrote:
  Hello Aaron,
 nice to hear that a RAM forensics geek like Jesse takes part to the
 Volatility project.
 So I'll follow you call an report a possible bug:
 I assume, that the hiberfil-decompression plug-in does not work fully
 correctly. Currently I use the SVN-version of volatility.
 I had already posted the differences between a X-Ways-Forensics-decompressed
 hibernation file and a svn-release decompressed one, both mapped with X-Ways
 Forensics.
 I am sorry not be allowed to provide the original files for testing. You
 have to be content with my poor tests. But if you want me to do further
 tests, so please don't hesitate.
 Today I took volatility itself to verify that issue:
 A piped output for the files-command has 950 lines (vol) or 1119 lines
 (XWF). (q&d, ok)
 The vol-version contains garbled file handles like
 File   [a long line of \x00]
 File   \u8b10\uff01\u4090\u8b00\u8b1c8\u2454\u8b1c\uff01
 Or definitely corrupted PID's
 Pid: 3810479584
 ************************************************************************
 Pid: 1095783255
 ************************************************************************
 Pid: 3925770345
 ************************************************************************
 Pid: 2768774260
 ************************************************************************
 The XWF-decompressed version does inspire more confidence without strange
 entries.
 A pslist-command generated large negative handle-counts or to huge numbers
 of handles for some processes in the vol-version but not for those in the
 XWF-version. For the corrupted processes within the vol-version it is not
 possible to dump the memmap (error message attached) but for the same pid in
 the XWF-version it works fine.
 The number of recognized processes (72) is identical in both files.
 IMHO Volatility does not decompress the hiberfil.sys properly.
 Has anybody a clue of some kind of integrity testing of a memory dump?
 Cu
 Michael
 -----Ursprüngliche Nachricht-----
 Von: vol-users-bounces(a)volatilityfoundation.org
 [mailto:vol-users-bounces@volatilityfoundation.org] Im Auftrag von AAron Walters
 Gesendet: Montag, 6. Juli 2009 06:32
 An: vol-users(a)volatilityfoundation.org
 Betreff: [Vol-users] Volatility Call for Bugs
 Jesse Kornblum, our favorite geek raised by wolves, has graciously agreed
 to help prepare the next release of Volatility.  Please take some time and
 report any bugs you may have encountered. It's great to see people willing
 to step up and contribute back to the community! Remember, Volatility is
 powered by the people! If you are waiting for something to get worked on,
 it will get done a lot faster the more you are willing to contribute.
 Shouts to Jesse!
 
http://jessekornblum.livejournal.com/253092.html
 Thanks,
 AW
 _______________________________________________
 Vol-users mailing list
 Vol-users(a)volatilityfoundation.org
 
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users