Velocidex
WinPmem produces empty RAW Dump
Hello guys, when using the 64-bit Executable from the releases on a device it loads and unloads the driver. Then straight away creates a RAW Dump with the Size of 0 Bytes and exits. The cmd.exe is running elevated. Is there a good reason for this or is this a bug?
This is the STDOUT:
C:\Users\TestAccount\Downloads>.\winpmem_mini_x64_rc2.exe dumper.raw
WinPmem64
Extracting driver to C:\Users\WDAGUtilityAccount\AppData\Local\Temp\pme65F.tmp
Driver Unloaded.
Deleting C:\Users\WDAGUtilityAccount\AppData\Local\Temp\pme65F.tmp
Driver Unloaded.
C:\Users\TestAccount\Downloads>
Can you please try the binary built in https://github.com/Velocidex/WinPmem/issues/53 I found it works a bit better than the release
It's extracting under WDAGUtilityAccount (Windows Defender Application Guard). Could it be blocked, perhaps?
@wallrik Hey, a damn good observation, I didn't notice until you mentioned it. Odd.
Hm. The print verbosity of the usermode app could really be better and ought to be worked over.
Any fixes found on this? I am facing the same issue.
I used the built mentioned by @scudette and that worked :)
Yes, and for everybody else reading, I think we are planning to release a new version that addresses some issues of the past. For now the built mentioned or compiling self from current source addresses most issues.
On an Azure machine or a high tech hardware server + very modern Windows server, please stick to physical memory method. It might be a level 5 paging system. The upcoming version will correctly recognize this. @edit: to be more precise: a system with around 256 TB or more physical memory. If you have that, level 5 might be active and then you have "ntkrla57.exe" in System32 folder. (You can check for this, but only bother when you have that much memory.)
Can you also test the go user space app. This is likely to be the most supported going forward
@vivianezw do let me know if I can contribute to this project on any issue, I would love to see this open source project expand. Although I don't have much experience, I would like to contribute in any way possible.
Here is a new beta version. It will be soon under release binaries (as beta, for a while). It can run on Win7-Win11, and there is a 32 bit and a 64 bit variant. But for a Win7 32 bit OS there is almost no change. Who has a 32 bit windows 7 OS nowadays? Nobody. I guess the only version of use is the 64 bit binary.
I can only test for safety & security. The quality of the dump is the thing I want to know. People with forensic skills needed right now. Test if the resulting dump is of expected quality. Look into the result dump with your tools (volatility) and report if it looks fine?
It's testsigned, you need to do (as admin) bcdedit /set testsigning on, reboot, and then use the minitool. Do bcdedit /set testsigning off afterwards. I guess nobody forgets that thanks to the MS testsigning watermark on the desktop.
PS: Dbgprint is set verbose, you can use dbgview.exe from Microsoft Sysinternals to see all of it (check 'kernel capture' in the menu), if you still get zero dumps.
Winpmem testsigned BETA version: Winpmem_mini_BETA_4.0.1.zip
@vivianezw - Thanks for sharing the beta. I've had a look at some sample captures, and the output looks fine to me.
This includes using Volatility against the resulting dumps and they appear structurally sound.
If there's anything specific you'd like me to look at, then do let me know. Quite keen to get my hands on the latest release.
We wont be able to sign the driver so for now we are stuck with the old signed driver and can only improve the user space side. Probably the most supported going forward is the Go userspace tool and this is now embedded in Velociraptor and can be used directly using https://docs.velociraptor.app/artifact_references/pages/windows.memory.acquisition/