`kernel::find_winver` hangs at reading nt major/minor version using memflow-pcileech

[holly-hacker]

When running the ps_win32 example from memflow-pcileech, it seems to hang when getting the windows NT version. I can't do much testing due to using a weird setup on nixos, but with some println debugging I narrowed it down to this read for nt_major_version in src/kernel/ntos.rs.

This is the full output until the hang:

[+] using FTDI device: 0403:601f (bus 2, device 11)
[+] FTDIFTDI SuperSpeed-FIFO Bridge000000000001
DEVICE: FPGA: ScreamerM2 PCIe gen2 x1 [300,25,500] [v4.14,0200] [ASYNC,NORM]
[2024-08-16T14:41:54Z INFO  memflow_win32::win32::kernel_info] arch=X86(64, false) kernel_hint=fffff80077e11a80 dtb=1bb000
[2024-08-16T14:41:54Z INFO  memflow_win32::win32::kernel_info] base=fffff80077a00000 size=17068032
[2024-08-16T14:41:54Z INFO  memflow_win32::win32::kernel_info] kernel_guid=Some(Win32Guid { file_name: "ntkrnlmp.pdb", guid: "EEFAC795A46ECB8E8267C6C0ABAF1CE91" })
[2024-08-16T14:41:54Z INFO  memflow_win32::kernel::ntos] trying to find NtBuildNumber export
[2024-08-16T14:41:54Z INFO  memflow_win32::kernel::ntos] NtBuildNumber found at 0xc0cbc0
[2024-08-16T14:41:54Z INFO  memflow_win32::kernel::ntos] trying to find RtlGetVersion export
[2024-08-16T14:41:54Z INFO  memflow_win32::kernel::ntos] RtlGetVersion found at 0x689430
[2024-08-16T14:41:54Z INFO  memflow_win32::kernel::ntos] nt_build_number: 4026554471

Possibly relevant info:

• Host is running NixOS with the ft601 LeechCore plugin compiled from here, added to the working directory
• Target is running Windows 11 Pro N 23H2 (OS Build 22631.3880)
• DMA device is a CaptainDMA M.2 with the official PCILeech M.2 firmware v4.14

My apologies if this belongs in memflow-pcileech, I'm not sure if the issue is outdated offsets or something related to the fpga interface.

[ko1N]

What version of memflow are you using? I remember there was an issue quite similiar to this and i thought we solved it already. My assumption is that theres a not properly aligned read going through to memflow-pcileech.

Do you need to power cycle the card after this to do any further reads?

[holly-hacker]

I remember using the latest commit on the default branch, and I could reproduce this output multiple times without power cycling the card. I can try to do more detailed testing in ~6 hours to give more details info like exact commit messages.

[holly-hacker]

I'm using commit 1962329fd046658ce1c96f555957e739c592f533 of memflow-pcileech which is currently the latest commit. It specifies memflow 0.2 (pulls 0.2.3) and memflow-win32 0.2 (pulls 0.2.0). I tried using a git dependency but got a version conflict with some toml dependency.

[holly-hacker]

I just tried again by updating my target device to the latest windows version (23H2 22631.4602) and using a git dependency to memflow-win32 commit 7b4b7e290f347958ce929eec5705c2d9cf1486c1 (which is the current latest), and the issue still seems to persist.

To make sure the issue isn't with my PCI device, I also used pcileech to create a memorydump and memprocfs was able to report a list of processes and an OS version, and the OS version it reports is 10.0.22621 (which matches what ver outputs). For some reason my target device reboots when running the memory dump, but the dump seems to work mostly fine (probably an out of bound read of some kind?).