LeetDMA Failed reading memory

[texzone]

Hello,

I have a PC with Windows 10 on it and a newly purchased LeetDMA v2.1 device purchased from Enigma X1. I have a laptop with Windows 10 connected to the Data port on the LeetDMA device, and I am trying to test the connection to ascertain if I can read memory from the DMA card. Unfortunately, I am not too knowledgeable about these cards and how to set them up, and I was hoping for some community help. When running the test provided by Engima here, I get the following error:

(PS: the underlying command that is run here is pcileech.exe -v -device fpga -min 0x100000 display 1)

USB driver successfully installed.

ucrtbase.dll already exists.
ucrtbased.dll already exists.
ucrtbase_clr0400.dll already exists.
ucrtbase_enclave.dll already exists.
vcruntime140.dll already exists.
vcruntime140d.dll already exists.
vcruntime140_1.dll already exists.
vcruntime140_1d.dll already exists.
vcruntime140_clr0400.dll already exists.
ucrtbase.dll already exists.
ucrtbased.dll already exists.
ucrtbase_clr0400.dll already exists.
vcruntime140.dll already exists.
vcruntime140d.dll already exists.
vcruntime140_clr0400.dll already exists.

Starting pcileech test.

DEVICE: FPGA: ScreamerM2 PCIe gen2 x1 [300,25,500] [v4.11,0a00] [ASYNC,NORM]
Memory Display: Failed reading memory at address: 0x0000000000100000.

So, currently, I have tried everything on the help-page (as far as setup goes). Specifically, I have:

1. Disabled Virtualization and made sure Hyper V is turned off.
2. Disabled IOMMU
3. Disabled NX-Bit
4. Disabled Secure Boot
5. Set all PCIE slots to GEN 1

Both the main PC and the target are running on an AMD cpu if that is worth noting. I have tried powercycling a fair couple of times as well as trying different target PCs (well, laptops) to no avail; I doubt that a different secondary laptop will solve the issue. I am not sure how to move forward as the error code is not super helpful (understandably) to a complete newb like me. Should I build and compile PCILeech on the second laptop or the main PC? I doubt this would solve the issue but I imagine it would help with diagnosing it. Any ideas?

It would be super helpful if this error message could be expounded upon; what does it mean? When received, what are usually the likely causes? When I run a speed test, this is what I get:

(PS: the underlying command here that is run is: pcileech.exe -v dump -device fpga -out none)

DEVICE: FPGA: ScreamerM2 PCIe gen1 x1 [300,25,500] [v4.11,0700] [ASYNC,NORM]
FPGA: TINY PCIe TLP algrithm auto-selected!
 Memory Map:
 START              END               #PAGES

 Current Action: Dumping Memory
 Access Mode:    Normal
 Progress:       4096 / 4096 (100%)
 Speed:          512 MB/s
 Address:        0x0000000100000000
 Pages read:     0 / 1048576 (0%)
 Pages failed:   1048576 (100%)
Memory Dump: Successful.

The test makes sense that all pages failed. What is interesting is that I am getting some sort of speed. The second pc (laptop) can see the connection to the DMA board (displayed as "FTDI FT601 USB 3.0 Bridge Device"). My main PC can see the connection as well, under "Other Devices" as "Network Controller" in device manager. The DMA is plugged into a x4 PCI lane. I'm not sure what relevant information to share, but I would love someone's insight on this error and it's meaning.

It might be worth it to mention my specs:

My main PC is running: MB: Asus Rog crosshair VI hero on the latest version CPU: AMD Ryzen 9 3950x GPU: RTX 4090 Windows: Windows 10 Pro Version 22H2 OS Build 19045.2846

Laptop (secondary): Type: lenovo ideapad flex 5 CPU: Ryzen 7 4700U with Radeon Graphics 8 core

[ufrisk]

On a freshly powered up (not rebooted) system can you try:

pcileech.exe display -min 0x1000 -device fpga://algo=1 -v

[texzone]

Hello @ufrisk, thank you so much for the response.

I have just powercycled my PC, and interestingly, I got seemingly positive response from the command you asked:

DEVICE: FPGA: ScreamerM2 PCIe gen1 x1 [300,25,500] [v4.11,0700] [ASYNC,TINY]
Memory Display: Contents for address: 0x0000000000001000
0000    e9 4d 06 00 01 00 00 00  00 00 00 00 3f 00 18 10   .M..........?...
0010    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0020    00 00 00 00 00 00 00 00  00 00 00 00 00 9b 20 00   .............. .
0030    00 00 00 00 00 00 00 00  ff ff 00 00 00 93 cf 00   ................
0040    00 00 00 00 00 00 00 00  ff ff 00 00 00 9b cf 00   ................
0050    00 00 00 00 00 00 00 00  00 10 fe be 00 00 00 00   ................
0060    7c 16 00 00 30 00 da 16  00 00 10 00 00 00 00 00   |...0...........
0070    50 7a 9f 51 02 f8 ff ff  00 70 00 00 ec f7 ff ff   Pz.Q.....p......
0080    06 01 07 00 06 01 07 00  01 49 00 00 00 00 00 00   .........I......
0090    31 00 05 80 00 00 00 00  00 00 00 00 00 00 00 00   1...............
00a0    00 d0 1a 00 00 00 00 00  b8 0e 35 00 00 00 00 00   ..........5.....
00b0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00c0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00d0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00e0    00 00 00 00 00 00 57 00  b0 2f 89 fa 81 c6 ff ff   ......W../......
00f0    00 00 00 00 00 00 ff 0f  00 00 89 fa 81 c6 ff ff   ................

However, as you may suspect, the original command still results in the same error code.

[ufrisk]

It's good, that memory read seems to be working.

On a freshly powered up (not rebooted) system can you now try:

pcileech.exe display -min 0x1000 -device fpga -v

[texzone]

Very interesting, this is what happens now:

> .\pcileech.exe display -min 0x1000 -device fpga://algo=1 -v

DEVICE: FPGA: ScreamerM2 PCIe gen1 x1 [300,25,500] [v4.11,0700] [ASYNC,TINY]
Memory Display: Failed reading memory at address: 0x0000000000001000.

> .\pcileech.exe display -min 0x1000 -device fpga -v

DEVICE: FPGA: ScreamerM2 PCIe gen1 x1 [300,25,500] [v4.11,0700] [ASYNC,TINY]
Memory Display: Failed reading memory at address: 0x0000000000001000.

I wonder why this is happening. I am going to give it five or so more attempts of powercycling and see if I get any output for the above two commands.

[texzone]

Very interesting eh?

> .\pcileech.exe display -min 0x1000 -device fpga://algo=1 -v

DEVICE: FPGA: ScreamerM2 PCIe gen1 x1 [300,25,500] [v4.11,0700] [ASYNC,TINY]
Memory Display: Contents for address: 0x0000000000001000
0000    e9 4d 06 00 01 00 00 00  00 00 00 00 3f 00 18 10   .M..........?...
0010    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0020    00 00 00 00 00 00 00 00  00 00 00 00 00 9b 20 00   .............. .
0030    00 00 00 00 00 00 00 00  ff ff 00 00 00 93 cf 00   ................
0040    00 00 00 00 00 00 00 00  ff ff 00 00 00 9b cf 00   ................
0050    00 00 00 00 00 00 00 00  00 10 fe be 00 00 00 00   ................
0060    7c 16 00 00 30 00 da 16  00 00 10 00 00 00 00 00   |...0...........
0070    50 7a 3f 2f 03 f8 ff ff  00 70 00 80 e3 f7 ff ff   Pz?/.....p......
0080    06 01 07 00 06 01 07 00  01 49 00 00 00 00 00 00   .........I......
0090    31 00 05 80 00 00 00 00  00 00 00 00 00 00 00 00   1...............
00a0    00 d0 1a 00 00 00 00 00  b8 0e 35 00 00 00 00 00   ..........5.....
00b0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00c0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00d0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00e0    00 00 00 00 00 00 57 00  b0 2f 89 81 80 86 ff ff   ......W../......
00f0    00 00 00 00 00 00 ff 0f  00 00 89 81 80 86 ff ff   ................

> .\pcileech.exe display -min 0x1000 -device fpga -v         
DEVICE: FPGA: ScreamerM2 PCIe gen1 x1 [300,25,500] [v4.11,0700] [ASYNC,NORM]
Memory Display: Failed reading memory at address: 0x0000000000001000.

> .\pcileech.exe display -min 0x1000 -device fpga://algo=1 -v

DEVICE: FPGA: ScreamerM2 PCIe gen1 x1 [300,25,500] [v4.11,0700] [ASYNC,TINY]
Memory Display: Failed reading memory at address: 0x0000000000001000.

~It seems like as soon as I login, I have a couple of (seconds?) and the read works. After that timeframe it does not work. Maybe.~

Scratch that, Im not sure whats going on to be honest. The first command seems to be consistently working when I run it at the beginning of boot (when I login to windows and even before then). The second command is not working at all. The first command works consistently and subsequent calls work as well. They work for some time even.

The moment I call the second command, I get that error. Then, I can no longer call the first command successfully.

[ufrisk]

I believe normal reads are not working properly. Reads with -device fpga://algo=1 works. It stops working if you do a normal read. My guess is that if you do pcileech.exe display -min 0x1000 -device fpga://algo=1 -v wait some more and do another couple of those reads (with algo=1) it will continue to work.

The algo=1 algorithm is slower than the normal algorithm, but it should most probably work if using this exclusively. I have some plans to boost the speed of the algo=1 in the next few months.

Others have had bad interactions with some "custom firmware" and their mobo. Sometimes changing bios settings or a bios upgrade will work. Sometimes it works if flashing the default pcileech firmware which I provide here: https://github.com/ufrisk/pcileech-fpga/tree/master/PCIeSquirrel

[texzone]

I see. Can you comment on some potential BIOS settings that are likely to be the culprit here?

[ufrisk]

Not really, but you can try a bios upgrade (if it's not on the most recent already). And you have virtualization disabled already.

If the bios upgrade does not work it's most likely it's that the custom firmware have a bad interaction with your computer (that the default firmware will work). If that does not work it may also be that your computer is incompatible with the normal reads.

If I were to guess on anything it would be on the custom firmware not being totally compatible with your computer.

-device fpga://algo=1 will work though, it's just notably slower. And like I mentioned previously I have some plans to look into it over the next few months, but it's not likely to ever be as fast as the normal algorithm.

[texzone]

Thank you very much for your help ufrisk, I appreciate all your advice. My bios is (unfortunately?) on the latest version. I am clearly in the market for an excellent DMA device, but I am woefully ignorant about how exactly to determine what would be compatible with my machine. If you would be so kind, are there any pointers you could offer on that? How can I determine what cards are best compatible with my machine?

[ufrisk]

I had very few people asking me about this in the past. I don't have a clear picture of it, but there is a reason why I added the alternative algorithm (which works in your case).

If it's a firmware interaction issue reflashing with the default firmware may work for testing. If that's the case it's not a hardware issue with the LeetDMA or the Screamer - but rather a firmware issue.

[texzone]

Thank you so much ufrisk. You have been a wonderful help!

[ufrisk]

Thanks, and best wishes with resolving these issues. If you ever find out what it was that caused the issue please let me know.

[texzone]

After doing a lot of digging and testing on multiple different devices, I think you are correct that the firmware is the issue. It would be super cool if you could tell me how people write their own "Custom Firmware." Is there a guide on how to do this? Issue is, I don't even have the original firmware for the card, so I don't think I can reflash it. Also want to avoid using something super public because it will likely be detected by the agencies I am trying to fool

Thank you @ufrisk

[ufrisk]

Unfortunately it's not an easy thing to tell.

But a good start would be to build the default PCIeSquirrel fpga project I have at the pcileech-fpga project.

Then make changes and test, each build takes like an hour, and to get everything 100% top notch to clone some hardware completely you may need to do 100+ builds. It's a very long and tedious job. At least if you wish to do it pretty much perfectly.

[texzone]

Holy shit, I thought you just needed to change the DSN and get the DMAs config space to match another hardware's config space... and then some of the component IDs like the vendor ID and device ID and you were pretty much good to go...

[ufrisk]

Getting the config space to match isn't that easy since the Xilinx PCIe core controls some parts of the config space and it's quite a bit of work getting it 100% right from what I've heard, at least if you wish to do it to perfection.

It's way easier to do it a bit sloppy, but it will still be a couple of builds and some work to get it right.

[texzone]

God damn it. Thank you again @ufrisk, guess I'll just smash my toes against the wall

[ufrisk]

I hope things will be alright, and best wishes with this.

And as I mentioned previously my plan is to look into improving upon the algo=1 alternative algorithm soonish.

[ufrisk]

update, I had another guy having success with: -device fpga://algo=2

that I quite don't understand, and I never heard about anyone having that behavior before, but you can try it as well, the algo=2 is only slightly less performant than the default one and should be mostly ok.

[texzone]

update, I had another guy having success with: -device fpga://algo=2

that I quite don't understand, and I never heard about anyone having that behavior before, but you can try it as well, the algo=2 is only slightly less performant than the default one and should be mostly ok.

That was actually one of the first things I tried - unfortunately, it did not work and led to the same error. You know, I am starting to think that I may have a partially dead board. A $500 paperweight, if you will. I am now trying to flash the card with its original firmware, but for the life of me I cannot get OpenOCD or Vivado Hardware Manager to flash the board.

OpenOCD says

Open On-Chip Debugger 0.12.0 (2023-02-02) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Error: libusb_claim_interface() failed with LIBUSB_ERROR_NOT_SUPPORTED
Error: unable to open ftdi device with vid 1a86, pid 55dd, description '', serial '' at bus location '*'

It seems to find it, but cannot interact with it. Device Manager can see the connection under "Universal Serial Bus devices > USB To UART+JTAG" after I used ZDag to install the drivers.

Vivado just cannot find the board at all. Neither the Hardware Manager nor the Tcl CMD. Quickly reaching my wits end with this device haha

[ufrisk]

I think the LeetDMA may use another chip according to this thread: https://github.com/ufrisk/pcileech-fpga/issues/119 and that you would have to configure OpenOCD in another way.

If you need additional info around it I'm afraid you'd have to contact LeetDMA about it.