Windd 1.3 Final! (x86 and x64)
EDIT: 1.3.20091113 version contains a fix for incorrect size bug and raw memory dump.
EDIT: 1.3.20091024 version contains a fix for networking feature under Vista and Later.
Download windd 1.3
Win32dd and Win64dd are finally mature enough to be released which is a very good news.
First, I would like to thanks Nicolas Ruff, Andreas Schuster, Scott Noone from OSR Online, Rob T. Lee, Laurent Gaffie, Jimmy Marchetto and Sol_Ksacap for providing either assistance, feedbacks and/or beta-testing for this version.
Compability List:
Raw memory dump:
- Windows 2000 (32-Bits)
- Windows XP (32-Bits and 64-Bits)
- Windows 2003 (32-Bits and 64-Bits)
- Windows Vista (32-Bits and 64-Bits)
- Windows 2008 (32-Bits and 64-Bits)
- Windows 7 (32-Bits and 64-Bits)
- Windows 2008 R2 (32-Bits and 64-Bits)
Microsoft crash dump:
- Windows XP (32-Bits and 64-Bits)
- Windows 2003 (32-Bits and 64-Bits)
- Windows Vista (32-Bits and 64-Bits)
- Windows 2008 (32-Bits and 64-Bits)
- Windows 7 (32-Bits and 64-Bits)
- Windows 2008 R2 (32-Bits and 64-Bits)
Features:
- Raw dump generation
- Standalone Microsoft crash dump generation
- Network support (client + server)
- SMB path support
- MD5, SHA-1 and SHA-256 hash support
- Support 3 mapping methods for both full crash dump and raw memory dump generation
- Support 3 content rules
- Fast
- 32-bits and 64-bits support
- Can hibernate the system.
- Can generate a Blue Screen of the Death
- Support of machine with more than 4GB of RAM.
Microsoft Windows has an internal limitation which does not allow to generate a Microsoft Full Crash dump if the local machine has more than 2GB of physical memory. Of course, this limitation does not affect windd but it was funny and a good surprise to see Windbg correctly works with 8GB Microsoft crash dump (successfuly tested by Jimmy).
Links:
windd main page
Download windd 1.3
How to rule Windbg?
Debug Tutorial Part 4: Writing WINDBG Extensions
Hello Matthieu, tried win32dd on different machines and seems to work very good, on 4gig memory machines the acquisition finished in 3 minutes. Compliments for your work! What we miss in the program is a report or simple log function. Is it possible to get all the info that is on the screen into a textfile? Do we oversee something or is it just not possible.
Greetings from Rotterdam,
John Pas
Hi Mat,
We are testing the latest version here in Utrecht but are running into problems trying to dump over a network. The machines from wich we start the dump to the network crash instantly running win7 and vista. Running it on a XP machine works just fine. Any ideas?
Bart
@John Pas
You could use a command like
win32dd /y /d /f memory.dmp >dumplog.txt
to catch the output.
Bart
Thanks you both for your interest in windd.
Bart Idema is right, thanks for replying to John Pas and for the bug report I will take a look.
We are trying to use this command in here in Portsmouth UK but with lots of errors. I just tried it on my xp machine. I issue the command on one of my dump process to see the effect such as: windd.exe /d /t 236.dmp… I pressed enter key, shows some info…and asked if I like to continue, type “YES” and just rebooted the machine. Please can we get more information on how its working. Also can you please help on this problem as stated below:
We are carrying out analysis on captured image memory of XP machine. We issued the memdmp -f ….-p 236… ,and dumped successfully. Checked the process @ dir exe*.exe and see it as 236.dmp
the problem now is I want to use your volatility ‘dmpchk’ command but having problems. can you email me on the path of the command to use using your volatility ‘dmpchk’. I just like the way volatility makes life easy for all. Keep going with the good job. God bless you all. Looking forward for your reply.
Greetings from Portsmouth
Fummy
PLEAASE CAN ANYONE HELP!
We are carrying out analysis on captured image memory of XP machine. We issued the memdmp -f ….-p 236… ,and dumped successfully. Checked the process @ dir exe*.exe and see it as 236.dmp
the problem now is the volatility ‘dmpchk’ command errors. can anyone help please…. on the command path to use using volatility ‘dmpchk’.
Fummy
First, I have never heard about memdmp. Secondly, dmpchk is an utility from Microsoft. Thirdly, I am not the author of volatility. Forthly, you should read the help information of the utility, the command is:
win32dd.exe /d /f microsoftdump.dmp
for a modern Microsoft dump, to analyze with Windbg.
or
win32dd.exe /f rawdump.bin
for a raw dump.
Hey Matt,
great stuff! The only minor thing I’ve found is a truncated description of the /d – option within the help. Seems to work anyway. ;-)
Cu
Michael
Hello again,
I did some testing and really like this new version very much. The inbuilt network capabilities are splendid.
What I miss is an option to write a log. Currently I use a pipe to create one. The hash functionality is vital for forensic purposes. Sadly the option /s is accepted by both the sender and receiver side of the network connection but only the sender computes a hash. Could you add such procedure for the receiving side too to document that the data was transmitted unchanged anyway.
TNX in advance
Michael
Hi Michael,
Thank you very much for your feedback!
I was not really sure about report-option-feature but it looks like people really appreciate the detailed output of windd about the memory status. I was like “Oh people can still pipe the output so it doesnt really matter” so I added the “/a” option in case people would use piping.
Why would you see a such feature? What would be the difference with the piped report?
Indeed, for the hash function it is only computed from sender side because this is the most critical part. I assumed the received can still use a third party software like hashdeep from Jesse Kornblum (http://jessekornblum.com/tools/)
I updated the help output for “/c”, “/s” and “/a” options.
Thanks!
Hi Matt,
thanks for the quick reply. Thank you also for updating the help. It looks much more pretty now.
Yes people can use piping, I like it too. But there are many investigators with some kind of fear or phobia of command lines especially of piping. So an option /l, automatically creating a log with the same name as the Dumpfile.log could help a little to get over that fear to force them to use such tools. That’s not vital for me but for some of my class members…
The hash computing on the receiving site (piped into a file ;-)) would document the correct network transmission of the dump in one go. Otherwise I have to use md5sum or something else after the acquisition.
You know criminal procedures are procedures in writing…
CU
Michael
Win32dd 1.3 Crash on Windows32 SP3!
Error: InstallDriver cannot start service (Err=0×00000002)
Error: Cannot open \\.\win32dd
I tested it with win32dd of USB-Dongle, CD and HDD. Is the same error!
The System:
Win32 XP Professional SP3 (German)
Athlon AMD64-Dual Core 2100+
4 GB DDR II RAM
No writeblocker
I’m also seeing crashes on x86 xp sp3:
Error: InstallDriver Cannot start service (Err=0×00000002).
-> Error: Cannot open \\.\win32dd.
I’ve also run into the
Error: InstallDriver Cannot start service (Err=0×00000002).
-> Error: Cannot open \\.\win32dd.
I’ve seen it on 32 bit installs of XP SP2 (2 gigs RAM) and SP3 (8 gigs, 32bit system == 4 available). I seem to run into it after killing or interrupting the imaging process. Haven’t found a way to fix / repair it yet.
Look in the registry for “win32dd” delete the key — the associated
path should be the wrong path.
In fact this version is not scriptable.
One you try to win32dd.exe like
> path/win32dd.exe /f pouet.bin
you will get this error every time.
You have to run it from the current directory everytime
> win32dd.exe /f pouet.bin
I really like the fresh perpective you did on the issue. Really was not expecting that when I started off studying. Your concepts were easy to understand that I wondered why I never looked at it before. Glad to know that there’s an individual out there that definitely understands what he’s discussing. Great job