The following guide details instructions on the creation of modified DMA (attack) Firmware based on pcileech-fpga version 4.13.
Additionally this is intended to be a build-off of garagedweller's Unknown Cheats thread guide in a more detailed way
If you know what you are doing and are not a beginner check out extra Vivado Customisations
Tip
Video going over steps 1-4: https://www.youtube.com/watch?v=qOPTxYYw63E&ab_channel=RakeshMonkee
I don't like that there are people intentionally being vague, keeping information secret, or even misleading people to drive them away from being able to make their own firmware so that they end up buying 100s of dollars worth of custom firmware from other providers with no way to guarantee quality (I've seen "custom" paid firmware where they've only changed basic IDs lol)
ACs : Anti Cheats
DMA : Direct Memory Access
TLP : Transaction Layer Packet
DSN : Device Serial Number
DW : Double Word | DWORD
Donor card : A card that will be used to get IDs/config space and will not be used on your main PC (Eg. PCIE Wifi card)
-
(Don't expect this to work for Vanguard, Faceit or ESEA in the guide's current state.
-
This guide does not detail how to set up software or change computer settings to accommodate DMA cards)
-
It is assumed that the user following the guide has a basic understanding of custom firmware and so on...
-
If you don't understand a single part of this guide, this guide is not for you as you will likely brick your card. Your best and safest bet is to buy a paid CFW making sure at the very least they have TLP emulation and hope for the best it is a 1:1.
- Requirements
- Gathering the donor information
- Initial Customisation
- Vivado Project Customisation
- Other Config Space Changes
- TLP Emulation
- Building, Flashing & Testing
- A donor card (explained below)
- A DMA card of course
- Visual Studio
- Xilinx Vivado Will need to make an AMD account to download
- Pcileech-fpga Source code for custom firmware
- Arbor Will need to make an account to download the trial (14 days)
The trial can be extended by deleting the appropriate folder in your registry editor, I don't think I can tell you more than that though.
(Using a donor card will help us later on with TLP emulation to communicate with the device to start a driver for legitimacy)
Due to my limited testing and knowledge, I'll be using a network adapter for all examples continuing
(If you know what you are doing and understand the nuances, you can skip buying a donor card entirely, but for first timers I highly recommend this, way better to know you have a guaranteed-to-work product by spending $20 then sit on an alt for 2 weeks waiting for a delay ban to test your fw)
It is suggested to use a cheap piece of hardware to get the IDs and then throw it out. These are used to emulate the DMA card. So don't get the IDs of any existing hardware in your computer and plug them into the firmware. ACs will most likely in the future if not already, detect 2 devices with 1:1 IDs and flag it
Go into Scan Options under the Local system tab and Press Scan/Rescan, the values selected by default are good enough for us. Go Into PCI Config and locate your network controller, scroll around in the decode section and take note of the following things:
- Device ID
- Vendor ID
- Revision ID (will show as RevID)
- BAR0 Sizing Value(1/2/3/4/5 too if you have them)
Click on the square it's in to see the sizing info
My size is 16kb so record that
- Subsystem ID
- DSN(listed as Serial Number Register)
Note
If the Device Serial Number Capability Structure is not shown for your device, make a randomized string of byte-valid characters or 0 it out completely, but that may look a bit suspicious (I believe as long as its not the hard code value PCIleech comes with you should be fine since that's what ACs would scan for, please correct me if I'm wrong though.)
Combine your lower and upper DSN registers for our DSN configuration in step 3
For example, these are my values:
Serial Number Register (Lower DW): 68 4C E0 00
Serial Number Register (Upper DW): 01 00 00 00
Combine yours in the same format:
Lower DW + Upper DW = 68 4C E0 00 01 00 00 00
- We will still need Arbor later for our 0x40 and 0x60 blocks but it'd be convoluting to explain it here so keep it open
Once again due to limited knowledge, I'll be focusing on the PCIeSquirrel section of pcileech at the moment, sorry to those using other firmware.
- Open Vivado and in the top menu, in the search query, search for tcl console and click on it.
The console should now open at the bottom of the application.
-
In the Tcl console, type in
pwd
to see the working directory. It should look something like thisC:/Users/user/AppData/Roaming/Xilinx/Vivado
-
cd back a few times and then cd to the PCIeSquirrel folder in the pcileech-fpga-master project folder. It should look something like this
C:\Users\user\Desktop\pcileech-fpga-master\PCIeSquirrel
. (Desktop is where my project folder is) -
Once you have PCIeSquirrel dir open, in the Tcl console type in
source vivado_generate_project.tcl -notrace
and wait for it to finish -
Once the project has been generated, Vivado should automatically open the
pcileech_squirrel.xpr
file. Keep it open on the side for a bit.
- Open the PCIeSquirrel folder and head to this file
/PCIeSquirrel/src/pcileech_pcie_cfg_a7.sv
. Within this file use Ctrl+F and search the file forrw[20]
which should be on line 209 to find the master abort flag/auto-clear status register. Change the accompanying 0 to a 1 along with the accompanyingrw[21]
.
Before
After
Setting rw[21]
to a 1, allows the DMA card to access the CPU’s memory directly (DMA) or exchange TLPs with peer peripherals (to the extent that the switching entities support that)
- In the same file
pcileech_pcie_cfg_a7.sv
Ctrl+Frw[127:64]
which should be on line 215 to find your DSN field listed asrw[127:64] <= 64'h0000000101000A35; // cfg_dsn
, insert your Serial Number there as suchrw[127:64] <= 64'hXXXXXXXXXXXXXXXX; // cfg_dsn
preserving the 16-character length of the input field, if your DSN is shorter, insert zeroes as seen in the example image.
Before
After
this being my DSN
if your donor card didn't have a DSN, yours should look like
rw[127:64] <= 64'h0000000000000000; // +008: cfg_dsn
- Go ahead and save all the changes you've made
- Once inside Vivado, navigate to the "sources" box and navigate as such
pcileech_squirrel_top
>i_pcileech_pcie_a7 : pcileech_pcie_a7
then double click on the file with the yellow square labelledi_pcie_7x_0 : pcie_7x_0
.
- You should now be in a window called "Re-customize IP", in there, press on the
IDs
tab and enter all the IDs you gathered from your donor board, also note that the "SubSystem Vendor ID" Is just the same as your Vendor ID. (If your donor board is different from a network adapter you may have to adjust some settings in the "Class Code" section below as well.)
To check the class code of your donor card go back to Arbor > scan if needed, else > PCI config > set PCI view to Linear. Your card should be highlighted in green. There will also be a column header called Class. Match that with your card.
- Also go into the "BARs" tab and set the size value you gathered in step 2, note that the Hex Value shown is not meant to be the same as your bar address. You cannot edit this value.
the size of my bar was 16kb so 16kb is what you set it as
If the size unit is different change the size unit to accommodate the unit of the bar size
- Press OK on the bottom right then hit "Generate" on the new window that pops up and wait for it to finish.
- We will lock the core so that when Vivado synthesises and/or builds our project it will not overwrite some things and allow us to edit some things manually we could only do through the interface before, to do this, navigate to the "Tcl Console" located in the top right of the bottom box and enter into there
set_property is_managed false [get_files pcie_7x_0.xci]
, (to unlock it in the future for any purposes useset_property is_managed true [get_files pcie_7x_0.xci]
.)
- In Vivado, navigate to
pcie_7x_0_core_top
as shown in the image, and use the magnifying glass in the top left of the text editor to search for these different lines to match them to your donor card
-
Here is a list of variable names exclusively in the manual Vivado IP core config correlating to values we have confirmed to not break your firmware that you could change to match your donor cards. matched by capability, there is:
- (PM)
PM_CAP_VERSION
,PM_CAP_D1SUPPORT
,PM_CAP_AUXCURRENT
,PM_CSR_NOSOFTRST
- (MSI)
MSI_CAP_64_BIT_ADDR_CAPABLE
, - (PCIe)
PCIE_CAP_DEVICE_PORT_TYPE
,DEV_CAP_MAX_PAYLOAD_SUPPORTED
,DEV_CAP_EXT_TAG_SUPPORTED
,DEV_CAP_ENDPOINT_L0S_LATENCY
,DEV_CAP_ENDPOINT_L1_LATENCY
,LINK_CAP_ASPM_SUPPORT
,LINK_CAP_MAX_LINK_SPEED
,LINK_CAP_MAX_LINK_WIDTH
,LINK_CTRL2_TARGET_LINK_SPEED
- (PM)
-
Fields that can be changed in different files or a GUI that I do not yet know about.
- (PM)
cfg_pmcsr_powerstate
- (PCIe)
corr_err_reporting_en
,non_fatal_err_reporting_en
,fatal_err_reporting_en
,no_snoop_en
,Link Status2: Current De-emphasis
- (PM)
-
Known issue: Changing some functions below acceptable bounds most likely named something including payload/size/speed can slow down the reading speed of your DMA card. If your card is reading slow, these values are the first place you should look to diagnose.
Important
Once you have completed steps 1-5, you should, with 98% confidence, be good to go for BE, EAC, and any other anti-cheat that you can think of that isn't VGK, ACE, Faceit or ESEA, they come in the next step :)
For now, see ekknod's bar controller config from line 803 for an example
Notes to consider:
-
Either some classes of devices do not require drivers or have generic drivers automatically load (or there is something else in the config space entirely that tricks detection) which in either case bypasses some sophisticated or all acs (specifically not known to me at this time), types of device configurations that I have seen with this behaviour are:
- An intel wifi card but classed as a host bridge with the first capability pointer pointing to 0s so none of the other capabilities were read by Arbor and so supposedly by your device also, yet they still exist in the configuration space.
- A Network controller class with invalid device & vendor id, also subsys vendor id not matching (Maybe from some strange randomisation tool?)
-
You don't need to thoroughly understand verilog, though it would definitely come in handy if you do, but if you did you probably wouldn't be reading through this part.
-
Obtain the register addresses for the device you're emulating tlp for, you could do this by reading the brand's datasheet, technical documentation, or programming guide published for the specific hardware, or reading open-source versions of the driver (openbsd and linux come to mind). Another method I've read is using RWEverything to "see the data contained in memory where the BAR's are mapped"
-
In Visual Studio head to
/src/pcileech_tlps128_bar_controller.sv
and use the template file in the repo to implement. (soon to come)
- https://fpgaemu.readthedocs.io/en/latest/infrastructure.html
- https://www.incibe.es/sites/default/files/2023-11/INCIBE-CERT_FIRMWARE_ANALYSIS_SCI_GUIDE_2023_v1.1.pdf
- https://docs.xilinx.com/v/u/en-US/pcie_blk_plus_ug341
- https://www.fpga4fun.com/PCI-Express4.html
- https://www.xillybus.com/tutorials/pci-express-tlp-pcie-primer-tutorial-guide-1
Caution
It is not our fault if you brick your computer / DMA card with bad firmware (It shouldn't happen anyway if you follow the steps correctly).
- Run
source vivado_build.tcl -notrace
in the tcl console to generate the file you'll need to flash onto your card
- You'll find the file in
pcileech_squirrel/pcileech_squirrel.runs/impl_1
named "pchileech_squirrel_top.bin"
- You'll find the file in
- Follow the steps on the official LambdaConcept guide for flashing REMINDER: ONLY FOR SQUIRREL
If you mess up your CFW and your game PC won't fully "boot", be because of bios hang or other reasons, you may be able to flash new firmware onto it from your second computer if the card is still powered (indicated by the green lights). If your run a DMA card speed test on your second computer and the DMA card isn't recognised (doesn't matter if the rest of the speed test goes through or not), I'm 90% sure it's dead, if your first computer won't stay powered on, you have to buy a PCIe riser that will allow you to power your DMA card without it communicating (EXTREMELY NOT RECOMMENDED: if a riser is unavailable you can hotplug the dma card in after your computers fully booted then flash the card, be warned however as this can corrupt your motherboard's bios, and there's a chance you may not be able to repair it)
- Run a DMA speed test tool from your second computer (I cannot tell you where to source this) to verify your firmware is working and reading as it should be.
- Dump and compare the config space of your new firmware to the sigged pcileech default seen below to see if it's overly similar. You should most definitely be right with some values being the same, you have to think about the fact that apart from the serial number and maybe bar address, the configuration space of one type of (for example) network card is going to be the exact same across all of them. So as long as your new firmware's configuration space does not closely resemble the default, you have a legitimate device for all the ACs care. GLHF
This is the signature BE supposedly scan for in the config space of the PCIe device:
More info here
40: 01 48 03 78 08 00 00 00 05 60 80 00 00 00 00 00
60: 10 00 02 00 e2 8f XX XX XX XX XX XX 12 f4 03 00
("XX" are bytes that they do not care about)
and you have any questions, problems with your firmware or suggestions, feel free to join my Discord for support
Ulf Frisk for pcileech
ekknod for his custom pcileech config(You could use this as a base to start off of as well!)