Unable to dump/probe memory after a new file has been created on the victim machine

[B3njey]

Hello,

as the title says, we (a team of students) are currently using PCILeech to dump the memory of a victim laptop to search for artefacts of applications. After booting the victim, it is possible to dump the memory but for some reason if a file (e.g. txt) is created or an entry of a password manager, the process of dumping fails.

Successful probes with parameter -v output following: DEVICE: FPGA: AC701 / FT601 gen2 x1 [300,0,500] [v4.9,0400] [ASYNC,NORM]

After the creation of a file: -v outputverboselv1.txt -vv outputverboselv2.txt -vvv outputverboselv3.txt

We are using:

Attacker Machine:

• Windows 11
• Version: 22H2 Build 22621.963
• PCILeech v4.15
• AMD Ryzen Threadripper 2950X 16-Core Processor

Victim Machine:

• Lenovo P50
• Windows 10
• Version: 21H2 Build 19044.2006
• Intel(R) Core(TM) i7-6700HQ CPU @ 2.60 GHz
• attached on the WLAN module on the inside via PCIe

FPGA: Xilinx Artix 7 FPGA AC701 Evaluation Kit

• DELOCK M.2 Key A+E to Mini PCIe Converter (Flatband in the WLAN Module)
• Diyeeni Mini PCIe to PCIe Converter
• DELOCK PCIe Riser Card x4 to x4 (Connected to the FPGA)

Has anybody had this issue or an idea what the reason behind it could be?

Best regards

[ufrisk]

I don't really know what this may be due to. I'm pretty sure it's not related to the file creation or the password manager though.

Windows nowdays employs DMA protections which may block devices. If dumping works initially I don't think this is the issue.

If you're dumping with Thunderbolt or dumping an AMD system it's very sensitive if you read outside of allowed physical memory ranges and DMA may stop working as per: https://github.com/ufrisk/LeechCore/wiki/Device_FPGA_AMD_Thunderbolt If you haven't already tried it may be interesting to try the memory map.

Also, I've done some minor FPGA stability improvements in the latest PCILeech firmware version v4.11. It's not the cause of this issue though. Also if you haven't tried it already also check out my MemProcFS project.

Another thing that may cause issues is bad cabling. I recommend a high-quality cable adapter like this https://www.aliexpress.com/item/1005003809627656.html Flat cables and some other adapters have been shown to be extremely problematic for me in the past.

[ufrisk]

If you use the AC701 you'd most probably require an x4 connector cable since the one I linked above is not of the "open connector" style. Something like this one https://www.aliexpress.com/item/1005003809611773.html would work better. And if possible try to get a fairly short cable (15cm or so).

[B3njey]

Yeah, DMA protection should be deactivated, even Virtualisation and our only point of reference when it failes is after a "writing" action has been made on the victim system. Yesterday we tried another attacker machine, which temporarily solved the issue but after a few testcases the same issue was back.

Further we don't dump via Thunderbolt nor is our victim machine an AMD system. We dump via PCIe and the system operates on an Intel(R) Core(TM) i7-6700HQ CPU @ 2.60 GHz. Our attack machine has an AMD CPU though.

We use the latest version of PCILeech (v4.15) for our setup. We will check out MemProcFS, maybe that will solve the issue. We also think about changing the victim machine to a system we already used successfully in our last project with PCILeech.

For our adapters, we use the following chain:

• DELOCK M.2 Key A+E to Mini PCIe Converter (Flatband in the WLAN Module)
• Diyeeni Mini PCIe to PCIe Converter
• DELOCK PCIe Riser Card x4 to x4 (Connected to the FPGA) I'm going to add these informations to the initial post so it is all documented in one posting.

Could it change something if we changed the Device PCIe ID of the FPGA?

[ufrisk]

The DELOCK M.2 Key A+E to Mini PCIe Converter (Flatband in the WLAN Module) is absolutely horrible for signal integrity. That you have issues doesn't surprise me one bit. Try to get a better shielded cable like the one I linked and let me know how it goes. My guess is that it will stabilize your experiments a lot if you're replacing that cable.

[B3njey]

That's interesting because we didn't really have a problem with the flatband until now but maybe that would fix some minor issues as well that we had in the project last lastet a half year back now.

As for the issue we had now, it seems to be solved, even without changing the flatband. The only thing that we changed was the activation of the hibernation mode on the victim machine and now it works like a charm. Literally nothing else has been changed.

[ufrisk]

Thanks for the update, and awesome that it seems to be resolved. I still believe it's the cable though. Please get the better cable I linked to you (it's not very expensive).

Since the issue seems to be resolved I'm closing this issue.