Closed RhysUCP closed 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.
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?
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).
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.
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.
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:
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.
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 asdisplay
,pagedisplay
andtestmemreadwrite
that returns successful.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:I have read through the issues and tried multiple suggestions but none of them seemed to work. I tried:
-device fpga://pciegen=1,tmread=1000,tmwrite=1000,tmprobe=1000,readsize=0x10000
which made it much slower but still failed.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:
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:
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.