ufrisk / pcileech

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

Speed issues #115

Closed false closed 4 years ago

false commented 4 years ago

Hello,

I noticed a speed issue a while back, I suspect it is a problem with the usb connection. So far I was "fixing" it with a usb-c usb-a hub adapter that somehow helps but it's not perfect. But as of today I would like to use the full available speed of pcileech I am posting this issue. So I made tests today with different combinations, all using a pciescreamer R02 and on different computers but the results seem to always be the same in the end. I tried to eliminate any connection stability issue by always using a direct PCIe connection (no extension / riser), different cables, different ports (usb 3.1, usb-c). So here is the issue, when I use a direct connection (simple usb cable, no adapter), I can dump memory at around 100 MB/s, and sooner or later the usb connection is quickly lost, and most of the time all the next dumps fall to a speed of around 25 MB/s. Moreover when the speed is at 100 MB/s, if I make a probe after that there is a high chance the usb connection "resets" and I get a abnormal number of page read failed. If the speed/conn falls to the 25 MB/s "mode" then the probe will likely never fails. If i manually disconnect the usb cable and reconnect it, most of the time the 100 MB/s speed is back until the next fail/usb disconnection. But sometimes I can't get a 100 MB/s speed back until I reboot the target. I also tried on Linux, and it simplies crash when the connection gets lost. I really feel it is a usb issue as I can notice the usb icon and sound make a quick notification ; the typical "ding ding" sound you hear when you disconnect or connect a usb device on Windows 10. But I can't tell if it's a problem with the drivers or a buffer saturation, or a bad usb command or anything else. It happens on different computers but happens quite fast on a macbook pro. An easy way to reproduce it is to alternate : pcileech.exe dump -v -force -max 0x40000000 pcileech.exe probe

(In my project the problem happens after around 15s of non-stop memory reading)

For info with my adapter (usb-c hub) the speed is around 50 MB/s, and it is very stable, no probe fails, no dump fails. In my project it sometimes happens the usb connection gets lost/restarts but the speed will still be at 50 MB/s, it won't fall. Unfortunately I would like to know if it is possible to have this behaviour with a simple usb cable and the 100 MB/s.

Have you ever experienced this behaviour ?

false commented 4 years ago

I retrieved usb information using FT_CreateDeviceInfoList (from the FTD3XX library) and indeed when the usb conn fails and reconnects, it seems to sometimes reconnect in USB 2 in my case. (FT_CreateDeviceInfoList result after a lost usb conn : Flags: 0x2 [USB 2] | Type: 601 | ID: 0x0403601F | ftHandle=0x0 SerialNumber=000000000001 Description=FTDI SuperSpeed-FIFO Bridge

before : Flags: 0x4 [USB 3] | Type: 601 | ID: 0x0403601F | ftHandle=0x0 SerialNumber=000000000001 Description=FTDI SuperSpeed-FIFO Bridge)

ufrisk commented 4 years ago

Yes, I have noticed this problem on some computers with the PCIeScreamer hardware. I haven't really noticed this much on other hardware (AC701, ScreamerM2).

You can specify a larger delay than typical in the fpga connection string to get a more stable connection in your case. -fpga://tmread=1000,tmwrite=500 or any other value that works for you. Lower values = faster (but may be more unstable in your case).

ufrisk commented 4 years ago

I have a new default read algorithm (if running on Windows). I hope it should be much improved both speed and stability wise. Linux still use the previous read algorithm by default. Please let me know if this should not resolve your issue (also please reopen the issue if it should still be around). Otherwise I wish to thank you for your patience in me delaying the fix so long.