search

ufrisk / pcileech-fpga

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

Base Address Register [AMD] #133

Closed ekknod closed 1 year ago

ekknod commented 1 year ago

Hi. I have made own simple BAR support by using your shadow space as base.

it's something like this simple:

wire            snoop_valid_rd = snoop_valid_rdwr & 
                                ((snoop_data[31:25] == 7'b0000010) | (snoop_data[31:25] == 7'b0000000));          // Fmt[2:0]=000b (3 DW header, no data), CfgRd0/CfgRd1=0010xb

wire            snoop_valid_wr = snoop_valid_rdwr & 
                                ((snoop_data[31:25] == 7'b0100010) | (snoop_data[31:25] == 7'b0100000));          // Fmt[2:0]=010b (3 DW header, data), CfgWr0/CfgWr1=0010xb

Anyways. this is working fine with Intel machines, but not with AMD. At first i was really sure it was actual this code fault, since its very lazy way but later tried actual well made BAR support, and it had the same issue.

BAR support is required to communicate with device driver to properly mimic real device, this already works for Intel machines. This is done just for researching purposes. I'm personally trying to find ways how cheaters can circumvent anti-cheats and how anti-cheats can potentially then catch them.

The issue: Intel can read all addresses from BAR. Amd can only read addresses (0x00, 0x80,0x100,0x180) (weird pattern)

Edit: if i remember correctly, BAR writes did work for any addresses even with AMD.

ufrisk commented 1 year ago

You could use the leechcorepyc python library to see any TLPs received if set up properly https://github.com/ufrisk/LeechCore/wiki/LeechCore_API_Python

MWr is a posted TLP (i.e. no reply is required) so those would always "succeed" if implementing a dummy BAR.

As for the MRd I suspect there may be an alignment issue. Make sure the CplD TLP sent in response to a MRd never crosses a 0x80 boundary. If it does you may have to fragment it into two CplD responses.

I have some thoughts about implementing this in software (but it will be much slower than doing it on the FPGA), maybe much too slow, but it would also be easier to customize responses for research purposes.

ekknod commented 1 year ago

Code is now publicly available. I did make own repository, hopefully you don't mind. https://github.com/ekknod/pcileech-wifi/

ufrisk commented 1 year ago

This is very nice, I'll take a good look once I'm back home from vacation (in a weeks time). I'm sure this will be useful for quite a few others 👍

ekknod commented 1 year ago

I have added AMD support now to wifi project. I decided to change approach to PIO module (provided by xilinx). Seems to work okay. I changed your Multiplexer little bit to support PIO. I bet it could be implemented better as well.

https://github.com/ekknod/pcileech-wifi/blob/main/src/pcileech_pcie_tlp_a7.sv#L111

ufrisk commented 1 year ago

This is some super awesome news 👍 Project completed then I guess?

Having full support (at least for smaller BARs) in the firmware opens up so many possibilities. And if you have some networking board emulation working it's super interesting for some research as well :)

I hope to finish up my slower API-based software implementation in the next few weeks, but it's quite boring to add support to all the different programming language APIs I provide. Also, I want to get some other changes in there as well...

ekknod commented 1 year ago

"Project completed then I guess?" That's correct. It was minimal project, what did little bit get out of hands since needed to do more than originally was planned to. classic scenario.

"I hope to finish up my slower API-based software implementation in the next few weeks, but it's quite boring to add support to all the different programming language APIs I provide. Also, I want to get some other changes in there as well..." Ah.. I can feel the pain. That's indeed boring and easy to make errors.