ufrisk / pcileech

Direct Memory Access (DMA) Attack Software
GNU Affero General Public License v3.0
4.87k stars 718 forks source link

Failed Memory Dump on USB 3 #169

Closed RhysUCP closed 3 years ago

RhysUCP commented 3 years ago

Hello Ulf,

Firstly, I’d like to thank you for your hard work and dedication as I understand these are your hobby projects. I’m quite new to this so please forgive me if I make a beginner mistake.

I’m currently using a Raptor card that is plugged into a PCIe x1 slot on the target machine. I have disabled virtualisation, VT-d and XD bit in the BIOS.

The Raptor is connected via a USB 3.0 cable to a USB 3.0 port on the attacker machine. I have cloned and successfully compiled the latest versions of PCILeech, MemProcFS and LeechCore on the attacker machine.

So far, I am able to use pcileech.exe probe -device fpga and other commands such as display, pagedisplay and testmemreadwrite that returns successful.

>pcileech.exe probe -device fpga

 Memory Map:
 START              END               #PAGES
 0000000000000000 - 000000000009ffff  000000a0
 00000000000c0000 - 000000008fafffff  0008fa40
 0000000100000000 - 000000086effffff  0076f000

 Current Action: Probing Memory
 Access Mode:    Normal
 Progress:       34544 / 34544 (100%)
 Speed:          227 MB/s
 Address:        0x000000086F000000
 Pages read:     8383200 / 8843264 (94%)
 Pages failed:   460064 (5%)
Memory Probe: Completed.
>pcileech testmemreadwrite

Memory Test Read: starting, reading 1000 times from address: 0x00000000
Memory Test Read: SUCCESS!
Memory Test Write: starting, reading/writing 100 times from address: 0x00000000
Memory Test Write: Success!

The issue I am having is when it comes to doing a full memory dump. pcileech.exe dump -device fpga runs successful for anywhere between 0% and 3%, then it hangs for a few seconds and the rest of the dump fails. Two examples below:

>pcileech.exe dump -device fpga -out none -force

 Current Action: Dumping Memory
 Access Mode:    Normal
 Progress:       34544 / 34544 (100%)
 Speed:          595 MB/s
 Address:        0x0000000100000000
 Pages read:     4096 / 8843264 (0%)
 Pages failed:   8839168 (99%)
Memory Dump: Successful.

>pcileech.exe dump -device fpga -out none

 Current Action: Dumping Memory
 Access Mode:    Normal
 Progress:       34544 / 34544 (100%)
 Speed:          566 MB/s
 Address:        0x0000000100000000
 Pages read:     12288 / 8843264 (0%)
 Pages failed:   8830976 (99%)
Memory Dump: Successful.

I have read through the issues and tried multiple suggestions but none of them seemed to work. I tried:

I believe this may be an issue caused by the USB because the memory dump works when I plug the card into a 2.0 port. Of course, it is much slower which is why I’d prefer to get the USB 3.0 working.

USB 2.0:

>pcileech.exe dump -device fpga -out none

 Current Action: Dumping Memory
 Access Mode:    Normal
 Progress:       34544 / 34544 (100%)
 Speed:          22 MB/s
 Address:        0x0000000100000000
 Pages read:     8383136 / 8843264 (94%)
 Pages failed:   460128 (5%)
Memory Dump: Successful.

pslist works on both USB versions but is much more responsive on USB 2. It can take over a minute on USB 3 but only takes a couple of seconds on USB 2 to display the processes.

I’ve purchased a USB 3.0 PCIe expansion card in hope of fixing the problem but it doesn’t solve anything and sometimes makes it worse as shown:

>pcileech pslist

MemProcFS: Failed to initialize memory process file system in call to vmm.dll!VMMDLL_Initialize
UMD: Failed initializing required MemProcFS/vmm.dll

>pcileech pslist -v -vv

PCILEECH: Failed to connect to the device.

The target computer will need a restart before I can communicate with the device again once it fails to connect.

Additional Information: Attacker machine is quite old and is using an ASUS M5A99X R2.0 EVO running Windows 10 (19042.867). I believe this motherboard uses an ASMedia 1042 chip for USB 3. USB expansion card is a FebSmart FS-U2-PRO.

Do you have any suggestions or ideas of what I can do or what might be causing the issue?

Thank you.

ufrisk commented 3 years ago

Please understand that this is basically a hobby project of mine (even if I recently tried to make it into something more). I see lots of people buy expensive hardware of which I receive absolutely nothing out of. I'm pretty much left with supporting other peoples businesses for free.

With that being said it's a bit strange that USB2 is working while not USB3. It could be a cable issue (stranger things have happened). Also you can try to dump with additional options such as:

pcileech.exe -device fpga://pciegen=1,algo=1 dump -out none or pcileech.exe -device fpga://pciegen=1,readsize=0x8000 dump -out none

You'll find some additional options listed at: https://github.com/ufrisk/LeechCore/wiki/Device_FPGA

It may also be a good idea to specify a memory map, or if memory map auto works: pcileech.exe -device fpga -memmap auto dump -out none

In the past I had troubles with AMD; and I got a Ryzen to check it out last summer. I wouldn't be surprised if there are lingering issues around older Athlon & Opteron systems. But I don't have a test system for this.

Good Luck and please let me know if it works better with any of the above options.

If you find my tools useful please consider sponsoring my project here on Github. Thank You.

RhysUCP commented 3 years ago

Thanks for your quick reply. Sorry to hear that; I would've thought that the businesses would support you nicely.

Indeed, I couldn't find anyone else having issues only with USB 3. I have tried both your commands and I didn't get any results back from the first, even after waiting a good while.

>pcileech.exe -device fpga://pciegen=1,algo=1 dump -out none

 Current Action: Dumping Memory
 Access Mode:    Normal
 Progress:       0 / 34544 (0%)
 Speed:          0 kB/s
 Address:        0x0000000100000000
 Pages read:     0 / 8843264 (0%)
 Pages failed:   0 (0%)
>pcileech.exe -device fpga://pciegen=1,readsize=0x8000 dump -out none

 Current Action: Dumping Memory
 Access Mode:    Normal
 Progress:       34544 / 34544 (100%)
 Speed:          244 MB/s
 Address:        0x0000000100000000
 Pages read:     608 / 8843264 (0%)
 Pages failed:   8842656 (99%)
Memory Dump: Successful.

I previously tried to use -memmap auto with no success but this time it managed to get a successful dump, but unfortunately it doesn't seem to be consistent.

>pcileech.exe -device fpga -memmap auto dump -out none

 Current Action: Dumping Memory
 Access Mode:    Normal
 Progress:       34544 / 34544 (100%)
 Speed:          95 MB/s
 Address:        0x0000000100000000
 Pages read:     8372892 / 8843264 (94%)
 Pages failed:   470372 (5%)
Memory Dump: Successful.

>pcileech.exe -device fpga -memmap auto dump -out none

MemProcFS: Failed to initialize memory process file system in call to vmm.dll!VMMDLL_Initialize
PCILEECH: Invalid memory map: 'auto'.
PCILEECH: Failed to connect to the device.

Yes, I read that people were having issues with Ryzen systems, although I only saw them having issues when AMD was the target computer rather than the attacker. Sorry, I forgot to mention my target computer is using an Intel 6700k with 32GB RAM.

Anyway, I think you are correct about it either being something strange with the cable or an old AMD / USB issue but at least it managed to work once. Also, is 95 MB/s an expected speed for dumping over USB 3?

ufrisk commented 3 years ago

I misunderstood your issue; the fact that the attacker is an older AMD should not matter. A 6700k should not cause issues like this.

My best guess is that it's related to the USB somehow but I don't have a test system so it's only going to be guesses from my side.

95MB/s looks pretty normal albeit on the slower side. It's usually between 120-150MB/s; but it may run slower on systems with slower CPUs (or disk if dumping to disk; you have the none specified so it should not be the case here).

RhysUCP commented 3 years ago

No worries. I don't currently have a spare USB 3 cable to see if that's the issue either, although if it worked at least once then perhaps it isn't the cause?

Alright, I could help test it by pasting in any code changes if you come to think of any. I'll also keep trying different configurations to see if I can find the root cause.

That's good to know, I do believe one core was at near maximum usage so that would explain the slight speed difference which isn't a problem at all.

Thanks again.

ufrisk commented 3 years ago

Thanks for the update,

The issue would probably require more than a couple copy/pastes. I would really need a hardware to look into this. Also seeing it's an older, not very common, system having these issues it may also be that my time is spent better elsewhere. If you should happen to find the culprit I'd be very happy to incorporate the fix and do some additional copy/paste testing if needed.

RhysUCP commented 3 years ago

I've finally managed to fix my issue.

I am able to get successful dumps every time at around 159MB/s when using the Intel machine as both the attacker and target system. This lead me to believe that there is definitely something wrong with the older USB 3.0 chipset implementation on the AMD motherboard.

After researching the expansion card's chipset, I found out that it is also from a relatively long time ago (~1/2 years within the release date of the motherboard).

I updated to the latest firmware available for the ASM1042 controller but this didn’t help much (possibly helped a little but it’s hard to observe). I ended up borrowing from a friend a much newer USB 3.1 expansion card that has an ASM3142 chipset and now it is all fully working :grin:

ufrisk commented 3 years ago

Huge thanks for the update around this. It's nice for me to know it's not an issue with the PCILeech itself and not with the PCIe side of things on the AMD either (as far as we know it at least).

I wish you the best of luck with your DMA attacking/research now in the future when you got it to work. 159MB/s is a very nice speed =) Also please let me know if you should run into any strangeness in the future or wish for new features.

If you should find my project useful please consider sponsoring it for as low as $2, Github is doubling any sponsorship.