search

ufrisk / pcileech-fpga

FPGA modules used together with the PCILeech Direct Memory Access (DMA) Attack Software
917 stars 205 forks source link

Netv2 not reconnecting over UDP #81

Closed johnknaack closed 6 months ago

johnknaack commented 3 years ago

I've been using a AC701/FT601 setup without issue for a bit. I'm able to connect using VMMDLL_Initialize and close my app and then rerun it and reconnection fine. I started doing some testing with a Netv2 and once it has an IP I'm normally able to connect once, maybe twice, but then it stops being able to initialize. I'm doing the following: LPSTR args[] = { (LPSTR)"", (LPSTR)"-device", (LPSTR)"rawudp://ip=192.168.86.85" }; if (!VMMDLL_Initialize(3, args)) { std::cout << "[-] Failed to initialize vmm.dll" << std::endl; return -1; } std::cout << "[+] vmm.dll initialized!" << std::endl; When it fails to connect it seems to exit from inside the VMMDLL_Initialize call because I don't get either of the failed or initialized message.

I put the v4.7 of the XC7A35T image on the Netv2. I'm seeing the same results on 2 different Netv2 cards on two computers. I'm using the newest PCILeech release, v4.8.

When the code above fails to connect so does pcileech probe -device rawudp://ip=192.168.86.85 -v. It gives no output and returns to the prompt. I'm also still able to ping the device even though it fails to connect.

When it gets to this state I have to fully remove power from the PC, a system restart does not work.

Any ideas of why/how the Netv2 gets into the unconnectable state?

ufrisk commented 3 years ago

I'm unsure if this is one or several issues.

The crash behavior is certainly an issue in itself. You should get an error that you were unable to connect at the minimum - i.e. VMMDLL_Initialize should return. I think this may be a separate issue that is triggered by the root cause - that the target system stops responding to the NeTV2.

That the target system stops responding until a power cycle may be related to several things. 1) It responds badly to a bad PCIe TLP packet; it may be cut in half in the application crashes. 2) You read outside physical memory bounds, especially AMD systems are sensitive for this, please try to initialize MemProcFS with additional parameters: -memmap auto to mitigate this. i.e. (LPSTR)"-memmap", (LPSTR)"auto". Maybe this will help in your scenario if lucky?

Can you please let me know of the memmap auto resolves anything?

johnknaack commented 3 years ago

Sure thing, I'll give this a go tomorrow morning once I'm back at my desk.

johnknaack commented 3 years ago

Sorry for the delay. I did try with the additional parameters. When running the debug build it sometimes just fails out like before, no output, and sometimes throws: Access violation executing location 0x0000000000000000. inside VMMDLL_Initialize

ufrisk commented 3 years ago

Thanks, I put up this as a bug due to the crashes. Unfortunately it's a little bit tricky for me to find this since the hardware works on my test systems. I'll try to find a way to trigger the crash and fix it anyway.

A thing that would help is if you could return with the exact version of the leechcore.dll you are experiencing this crash with. Also there should be an "Application Error" entry in the Application Event Log in Windows. Can you please copy that text and paste it here together with the version. It should have test such as "Exception code" and "Fault offset"; but please post the whole thing. An old crash will do fine as long as I get the exact version of the leechcore.dll used when that crash happened.

ufrisk commented 6 months ago

I'm closing this issue due to old age.