32bit version of winpmem.exe fails on 64bit Win 10

[johnlp]

Built from source on Master, 11/4/20, VS 2019 16.7.1
64bit exe works as expected
32bit exe on 64bit Win 10, version 2004 build 19041.572 (bare hardware) fails with following output:

**D:\Work\DevProjects\PmemMaster\kernel\executable\Debug>winpmem.exe d:\temp\ram32-1.raw
WinPmem64
Extracting driver to C:\Users\John\AppData\Local\Temp\pmeD628.tmp
Driver Unloaded.
Loaded Driver C:\Users\John\AppData\Local\Temp\pmeD628.tmp.
Deleting C:\Users\John\AppData\Local\Temp\pmeD628.tmp
Failed to get memory geometry,: The program issued a command but the command length is incorrect.

The system time is: 16:46:30
Driver Unloaded.**

Also, when run on a Win 7 32 VM (version 6.1 Build 7601: Service Pack 1), it initially fails by incorrectly selecting the PTE method. Out as follows:

**C:\Users\Adam\Downloads\PMem\win32>winpmem.exe C:\Users\Adam\Downloads\PMem\win3
2\ramcapturepmem20200103.raw
WinPmem32
extract_driver

• service_name: pmem
• filename: C:\Users\Adam\AppData\Local\Temp\pme5D76.tmp
• Extracting driver to C:\Users\Adam\AppData\Local\Temp\pme5D76.tmp
  Driver Unloaded.
  Loaded Driver C:\Users\Adam\AppData\Local\Temp\pme5D76.tmp.
  Deleting C:\Users\Adam\AppData\Local\Temp\pme5D76.tmp
  Failed to set acquisition mode 2 : A device attached to the system is not functi
  oning.

PTE Remapping
Driver Unloaded.**

When run with the -1 option, forcing to PhysicalMemory method, ram capture succeeds.

[vivianezw]

You didn't read #12 did you?

[johnlp]

I did read #12. #12 suggests that PTE is not available 32bit, but thought one of the other modes might work, making some capture available from a 32 bit app. Also, that PTE is selected by default on a 32bit Win7 (causing a failure) seems independent of PTE not working from a 32bit app on a 64bit OS.

[scudette]

We probably should be setting the correct default based on the arch here:

WinPmem/kernel/executable/main.cpp

Line 85 in 134441c

unsigned __int32 mode = PMEM_MODE_PTE;

[vivianezw]

Agreed. Add that to the current todo list? (Needs to be done some time before February, preferably with some time for public testing).

[vivianezw]

Wait, that was not even the problem. (but true nevertheless.) There's more to it. He wrote: 64bit exe works as expected. 32bit exe on 64bit Win 10, version 2004 build 19041.572 (bare hardware) fails with following output: [...]

He executed the 32 bit exe on a 64 bit OS. It already was a 64 bit OS and PTE was the right choice, and the 32 bit usermode program did correctly load the Winpmem64 driver, and the 64 bit driver started...

The error was Failed to get memory geometry,: The program issued a command but the command length is incorrect. That is a STATUS LENGTH MISMATCH error, the input buffer was incorrectly formatted in only the 32 bit usermode part executable.
From the first look, maybe some sizeof() or similar screwed it.

[vivianezw]

I wonder if that also happens with my testsigned version, because I tested it on 32 Bit and it worked.

[johnlp]

2 different issues. One is failure of 32bit app on 64bit OS (bad geometry). 2nd is the wrong default selection of PTE method when running 32bit app on 32bit OS. "Also, when run on a Win 7 32 VM (version 6.1 Build 7601: Service Pack 1), it initially fails by incorrectly selecting the PTE method. Output as follows..." See the initial comment.

[vivianezw]

and you compiled them from this latest source?

The first is an error in the usermode component (the second also, but trivial, it's simply not implemented and that should be the message back to the user). For the first one, the driver rejected the input buffer as badly formatted. Maybe a missing precompiler statement or a bad sizeof(int), or something like that, that would only screw it for 32 bit compilation.

If I ever find some time, the first one would be on my priority list. ;)

[scudette]

This is obvious - running any 32 bit binaries on 64 bit windows is not supported and never will be - the 32 bit binaries have different struct layouts for communicating with the driver and therefore can not parse the ioctl packet.

This is not a supported use case - perhaps we could refuse to run in that case?

[vivianezw]

We could

1. refuse to run and tell user to use the other one.
2. adapt the struct to be formatted correctly in the 32 bit executable. (e.g., by Precompiler statement)
3. Spawn the 64 bit version if the user started the 32 bit version.

[scudette]

1 is the easiest thing to do. 2 wont work because the binary is compiled for 32 bit so any ifdef will select the 32 bit structs - it is just run on 64 bit at runtime. So we could support this scenario but it would mean having 2 separate structs built in and choosing the right one at runtime.

3 might work but seems a bit like a hack - we would need to include the 64 bit binary in the 32 bit binary as a resource.

[johnlp]

If running 32bit exe on 64bit OS is not supported, fair enough. Maybe the How to Use section on the github page should be updated. It states "There are two winpmem executables: winpmem_mini_x86.exe and winpmem_mini_x64.exe. Both versions contain both drivers (32 and 64 bit versions)." Since even the 32bit version contains both drivers, it suggests that the above scenario is supported.

[vletoux]

If that can I help, I think I fixed it.

First, I'm allocating a buffer which is large enough to handle both 32 and 64 bits output.

Then, if running 32bits under 64bits, I'm copying partially the structure, else copy it fully

The trick is that the variable field KPCR which is causing the problem, is not used in the program

[vivianezw]

That could be solved easily, it's only the usermode code. I think the problem is the math in the amd64 switch. Shouldn't that be 64 instead of 32 in the math of RtlCopyMemory? We do not even need to throw them out.

I used to think the KCPRs were of some use in the now antiquated volatility 2, but I never knew exactly why we have these KPCRs in the code. :D We might as well throw them out if no follow-up tool needs them anymore.

[vletoux]

yes, removing KPCR should fix definitively the problem, but if I recompiled it, I needed a kernel mode signature, that why I proposed a fix.
The 32 offset, is computed with 64 - 32 (so from the 64 bits version minus the 32 bits version), not from the 32 version.