[Tutorial] DMA CUSTOM FIRMWARE GUIDE

[garagedweller]

Hi, long time lurker here.

The purpose of this guide is to show users how to start making there own custom Firmware

there is so much misinformation and gate keeping going on with the firmware creation process
just because people can sell firmware for hundreds of dollars
Anytime someone asks a question its "read the docs bro" but wont provide a link to the correct doc.
this is the link to the doc if you want to read the doc.
https://docs.xilinx.com/r/en-US/pg054-7series-pcie

ideally you want to change these items listed below to avoid Anticheat detection.
this will not be guide that gets you past Face-it/VGK unless someone wants to contribute information.
(all the old ways are patched it seems and i just dont know how.)

• -DSN
• -subSys ID's
• -Device ID
• -Vendor ID
• -Revision
• -Blocks 0x40 and 0x60 (mentioned often)
• -BAR Address
• -Auto-Clear Status Register / Master Abort Flag

(I WOULD LOVE TO SEE OTHER PEOPLE CONTRIBUTE WITH EASIER/BETTER WAYS TO DO THIS)

So lets hop into it.

________________________________

Step 1:

Prerequisites

you need the newest version of Xlinix Vivado (requires account with AMD)
Visual studio Community (because im using it for this guide and search functions.)
the Default firmware source code found on ulfs github repo's

Links:

Vivado : https://www.xilinx.com/support/download.html
Visual studio : https://visualstudio.microsoft.com/vs/community/
Firmware source : https://github.com/ufrisk/pcileech-fpga
(i will not tell you how to install these, its very simple.)

________________________________
Update incoming by tomorrow, BAR guide is wrong.
Step 2:

Initial Customization:

We need to do some customization before we proceed.
open the PCIeSquirrel folder with visual studio

now lets search the functions we'd like to change

press CTRL+F to search and type rw[20] <= 1;
a file called pcileech_pcie_cfg_a7.sv should be the result with the line listed at 208

So lets change some lines!

lets changes lines 208 and 209 to reflect this:

rw[20] <= 1;
rw[21] <= 1;

and then on line 215 there is the DSN (device serial number) listed as such :

rw[127:64] <= 64'h00000000xxxxxxxx; // +008: cfg_dsn

Lets change those last numbers, you might see it has 35 at the end by default
(Artix 35T the chip)

example :
rw[127:64] <= 64'h0000000042006969; // +008: cfg_dsn

Ok once this is done lets save the all the files completely
(file in top left "save-all")


________________________________

step 3:

Next thing we are going to do is "generate" the project

Open TCL shell 2022.xx (your version might be differen't dont freak out.)
you should have this after installing vivado.

use cd and point to the project folder
(if this gives you a "error directory not found" reverse the slashes)
example : cd C:/Users/XXXX/Desktop/PCIeSquirrel

We have now moved to the source code folder and we want to build the vivado project
enter the command:

source vivado_generate_project.tcl -notrace

wait for it to finish.

once complete we will have our project file in the directory
PCIeSquirrel\pcileech_squirrel\pcileech_squirrel.xpr

With that built lets move to the next step!

________________________________

step 4:

Customizing within vivado:

Now vivado looks complex, very intimidating.
Dont stress out. make backups, it will be ok

lets double click that project file to open the project in vivado(duh)

In the project manager window you will see a box labeled "sources" with a file tree inside of it.
lets open the tree up and navigate to
pcileech_squirrel_top\i_pcileech_pci_a7
you should now see a "file" called i_pcie_7x_0 with a yellow icon.
lets double click it to "Customize IP"
A big window with a ton of options will appear, we are interested in the "IDs" tab

change these to the device you desire to "mimic"
either find the ID's online or copy ones from a physical device you already own.

for example:

Vendor ID: 10EB
Device ID: 3029
Revision ID: 09 (im pretty sure this can be set to whatever you want.)
Subsystem vendor ID: 10EB (this needs to match the Vendor ID)
Subsystem ID: 0008 (i honestly dont know changing it from a 7 to an 8 doesn't hurt anything)

class codes. if your picking a device that isn't a network card you will need to change these.
Just pick from the dropdown's to match the device you want to mimic

you can find alot of device ID's online with this link : https://pci-ids.ucw.cz/

after your done, hit the OK button on the bottom right of the window

this will pop up another small window
just hit the "Generate" button at the bottom and wait for it to finish.

________________________________

step 5:

Locking the IP core:

We want to lock the "core" so that it can be modified further
when vivado builds the firmware it will overwrite some modified options.
to prevent this we lock it! now it cant be modfied in vivado or by vivado.

At the bottom of vivado you should see a list of tabs, one of them named "Tcl Console"
switch to that tab and enter this :

set_property is_managed false [get_files pcie_7x_0.xci]

You should see a warning in the console stating the file is locked and now user-managed.
aswell the icon in the file tree should have a slash through it.

to unlock the file (if you want to) the command is :

set_property is_managed true [get_files pcie_7x_0.xci]

________________________________

So far we have done as follows:

• DSN : changed
• Master abort flag : set
• Auto status register : set
• vendor ID : Changed
• Device ID : Changed
• Subsystem ID : Changed
• Revision # : Changed

the next steps im not 100% clear on and have been a dice roll on failing or succeeding.

________________________________

Step 6:

SKIP THIS IF YOUR NOT CHANGING BAR/PCIE/MSI INFO

Changing BAR Address:

(feel free to chime in)

so now we need to change the BAR Address
and config blocks 0x48 & 0x60

So lets open back up visual studio (if you closed it)

And Search for (ctrl+F) : "bar_0":

a file should be listed called pcie_7x_0.xci
and @ line 264 the code:

"bar_0": [ { "value": "FFFFF000", "resolve_type": "generated", "usage": "all" } ],

This is the bar address. and we want to change it.
you can mimic a phsyical device you have on hand by dumping the info in linux or with RWeverything64
i wont tell you what to set it at, but FFFFF000 is the default.

Now this could be changed in the source files, before you generate the project
if you go around and change the bar value everywhere else you see it mentioned
by searching the actual bar address of "FFFFF000"
or just change it once here.

(This could take some trial and error depending on your system/device.)

________________________________

Step 6.5:

SKIP THIS IF YOUR NOT CHANGING BAR/PCIE/MSI INFO

Changing MSI/PCI Pointers
(blocks 0x40 and 0x60 as mentioned in other threads)

in vivado with the project opened we need to "Run Synthesis" on the left side bar.
this will generate the strings we'd like to change.
wait for it to finish and another window should pop up when complete you can just hit cancel for now.
(if you know a better way say so!)

now in visual studio (you should just have them both open still at this point.)
lets search and find the MSI/PCIE pointers.
you can find them by searching for example "PCIE_BASE_PTR" and find all mentions of it.

Here is an example of some of the code.
and lets break it down a bit

 parameter [7:0]  MSI_BASE_PTR = 8'h48,
  parameter        MSI_CAP_64_BIT_ADDR_CAPABLE = "TRUE",
  parameter [7:0]  MSI_CAP_ID = 8'h05,
  parameter        integer MSI_CAP_MULTIMSGCAP = 0,
  parameter        integer MSI_CAP_MULTIMSG_EXTENSION = 0,
  parameter [7:0]  MSI_CAP_NEXTPTR = 8'h60,
  parameter        MSI_CAP_ON = "FALSE",
  parameter        MSI_CAP_PER_VECTOR_MASKING_CAPABLE = "TRUE",
  parameter        integer N_FTS_COMCLK_GEN1 = 255,
  parameter        integer N_FTS_COMCLK_GEN2 = 255,
  parameter        integer N_FTS_GEN1 = 255,
  parameter        integer N_FTS_GEN2 = 255,
  parameter [7:0]  PCIE_BASE_PTR = 8'h60,
  parameter [7:0]  PCIE_CAP_CAPABILITY_ID = 8'h10,
  parameter [3:0]  PCIE_CAP_CAPABILITY_VERSION = 4'h2,
  parameter [3:0]  PCIE_CAP_DEVICE_PORT_TYPE = 4'h0,
  parameter [7:0]  PCIE_CAP_NEXTPTR = 8'h9C,
  parameter        PCIE_CAP_ON = "TRUE",

the MSI_BASE_PTR is "8'h48" by default.
then its next pointer (MSI_CAP_NEXTPTR) is "8'h60"
and if we check PCIE_BASE_PTR its "8'h60"
So the MSI Caps essentially just skip into the PCIE Cap
and PCIE_CAP_NEXTPTR is "8'h9c"
(feel free to say otherwise if you know more than i do.)

so essentially we want to change these so they are new values and appear in a different location(pointer)
but be careful to not OVERRIDE ANYTHING ELSE USING A POINTER
i wont tell you what to change these too, trial and error are your friend and well im still in the progress of "trial and erroring" this.

(i am almost 99% certain you need to change the pcileech_cfgspace.coe file if you modify this at all.
which requires a brain in which i do not have. Id love to see someone chime in on it.
Since the contents of the .coe file all start with the beginning of the bar address "FFFFF" i believe it needs to match your actual bar and msi/pcie pointers)

After all this is done. its time to move on.

________________________________

Step 7:

Building the firmware .bin file

inside vivado we want to "generate bitstream" in the bottom left side panel.
this will "build" the firmware bin file
just hit yes/continue until it starts generating, but dont change any options unless you know what your doing.

THIS WILL TAKE SOME TIME!!!

once its complete you will find your firmware bin file inside :
PCIeSquirrel\pcileech_squirrel\pcileech_squirrel.runs\impl_1
it will be named : pcileech_squirrel_top.bin

THIS IS YOUR FIRMWARE, YOU DID IT VIVADO SPIT OUT A SHIT-TON OF ERRORS BUT YOU DID IT!
I am not responsible if you fuck up your computer or DMA card. this is not a flashing guide
(i've killed two X670E motherboards, Praise be thy best buy warranty system)

once your done you can flash the firmware and check how bad you fucked up, or how great you succeeded.

[ESEA]

Nice post

[marquinhoos3]

Very good, especially since it's your first post. Welcome, +rep.

[Zepta]

Sounds like good information! Good job

[garagedweller]

Thanks guys, and on the topic of blocks x40 and x60, im certain you can change them in vivado instead of visual studio.

This image has been resized. Click this bar to view the full image. The original image is sized 958x895.

this aswell as the bar address is something im still working on. and will update the thread once i know what works and what doesn't

if im not mistaken AMD chipset motherboards have some BAR ranges "reserved"
thats why you see people getting firmware's that prevent the system from posting. Some people have had issues on intel aswell but i believe thats a seperate issue.

[bagelnewt]

Great post, tysm for the tutorial this is a big help. When a dma provider claims there board has custom 1/1 firmware, are all these things actually spoofed or did they do a shoddy job (in your guys' experience)? Still prolly gonna make my own firmware but just good to know so I can make my cheat first then care about fw later.

[garagedweller]

Originally Posted by bagelnewt

When a dma provider claims there board has custom 1/1 firmware, are all these things actually spoofed or did they do a shoddy job (in your guys' experience)?

Im not here to bash anyone or discredit them. but this really depends.
alot of the firmware devs like to point fingers and call each other bad providers behind the scenes. and i just dont think its as simple as that.

nothing is spoofed either really but i guess you could call it that. these are the hard-set values of the device & your changing them within the firmware.

Some dev's might put more effort in than others, other devs might be doing as much as posted above or less. but in theory they are all variations of the main source from ulf frisk.

as an example Ekknod (i dont know how to mention him directly yet.) has an amazing source on his github of a HIGHLY MODIFIED firmware for an FPGA device that emulates the driver meant for that device quite well. Its also been posted in another DMA related thread here. i believe it beat VGK and face-it for around 8 days before they started detecting the firmware (i dont know how they are detecting firmware anymore.)


and Valorant/Face-it's anticheat require alot more customization to remain undetected. in the past you used to be able to set the PCIE caps to false and this would confuse valorants AC and allow you to use your DMA card undetected.

[starhook]

amazing!

[privlothvh]

Good information.

[Rylezz]

legend, please update the thread when you get more information, thanks a lot!

[1ntrusion]

You can also use System Information Viewer to dump or see the config space on Windows.

[garagedweller]

Originally Posted by Rylezz

legend, please update the thread when you get more information, thanks a lot!

thanks! and i absolutely will, currently trying to understand bar0 address setting before i make any more comments on it. Seems that maybe the way i've been changing it is incorrect. or atleast not "sticking"

Originally Posted by 1ntrusion

You can also use System Information Viewer to dump or see the config space on Windows.

thank you so much! this will be a big help i've been live booting to a linux USB to use lspci and its been a pain.
I know that a provider just recently put out a tool that is essentially dumping the config of the card from the NonDMA system over USB. after a big firmware ban wave on EAC, has me curious how they are doing it.

[cloudhoter]

thanks bro

[apekros]

Originally Posted by garagedweller

I know that a provider just recently put out a tool that is essentially dumping the config of the card from the NonDMA system over USB. after a big firmware ban wave on EAC, has me curious how they are doing it.

The internals of this might help:

HalGetBusDataByOffset

I haven't looked at that yet, but that seems like a cool side project, thanks for the info that someone is doing that lspci is also open source!

[a179329195]

Very helpful +Rep

[garagedweller]

Originally Posted by apekros

The internals of this might help:

HalGetBusDataByOffset

I haven't looked at that yet, but that seems like a cool side project, thanks for the info that someone is doing that lspci is also open source!

thanks!, and yeah it was being sent around to users to "determine" if there firmware was EAC detected or not
a close friend, is a customer of said provider and passed me the tool.
essentially it just dumps the config space to a txt file and your supposed to send the file back so they can "determine the bytes" and tell you if your firmware is at risk.

i still do not know what was recently "detected" by EAC, but the firmware i made for the forementioned friend passed as "not detected" according to the provider.
the three big DMA card resellers are apparently the victims of this recent EAC detection.

Im currently working on changing just the BAR address so i can update the guide more clearly. maybe you can help clarify,
if i change the bar address from lets say "FFFFF000" to a new value of "891FF000"
(just theoretical replacement value)

Do you think i need to modify the .coe file with the premade config space?
i notice it all starts with FFFFF.

Or will then generating the .bin file actually pass the BAR along correctly? or create errors.

Id love to see some more people much more experienced and closed lip touch on these issues aswell.
im assuming you are REQUIRED to rebuild that .coe file but maybe im wrong.

Will be testing more tomorrow, Exams in the morning!

[Ohenxa2243]

+rep. Amazing write up so far for your first post. I’m currently transitioning to DMA myself (still waiting for my card) so this is some good information for someone like me.

[s0ngidong3]

Great post. +rep!

[spicyninja800]

very useful post, keep us updated. cheers.

something which may allow you to change blocks 0x40 and 0x60 dynamically is the DRP interface. you may be able to set values within the core before it boots online using this. I havent looked into this very much, however someone smarter than me may be able to utilise it properly. From reading comments within pcileech-fgpa, it begins on line 63 of the pcileech_com.sv file. As for what to write here, i would refer to the "Dynamic Reconfiguration Port Interface" part of the documentation and the DRP address map. I wish i could give more info on this but i dont have a DMA device so this is just from reading the documentation. Good luck!

[garagedweller]

Originally Posted by spicyninja800

very useful
~something which may allow you to change blocks 0x40 and 0x60 dynamically is the DRP interface. in pcileech-fgpa, it begins on line 63 of the pcileech_com.sv file. ~

This is some great information and suggestion! & thank you.
reading it and digging more into it,
it definitely sounds like someone might be able to find a method to do such a thing dynamically,
unfortunately i am just not experienced enough to pull it of.

from my understanding however.
the initial_rx array is setting a control bit in the PCIleech FIFO CMD register to bring the PCIe core online after the DRP and configuration actions are completed.
If you want to dynamically change values such as MSI capability pointers, you would typically perform such changes during the initialization phase