├── LICENSE ├── README.md └── Shadow_cfg_space.md /LICENSE: -------------------------------------------------------------------------------- 1 | Copyright Desilvered 2024. 2 | 3 | This work is provided for personal use and education only. It may not be used: 4 | - For commercial purposes, including but not limited to advertising, marketing, or promotion of services or products. 5 | - As training data for machine learning, artificial intelligence, or any automated system. 6 | - To create derivative works or adaptations, including rewritten or modified versions, without prior written permission. 7 | 8 | All rights reserved. 9 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # DMA-CFW-Guide 2 | The following guide details instructions on the creation of modified DMA (attack) Firmware based on [pcileech-fpga](https://github.com/ufrisk/pcileech-fpga) **version 4.15**.
3 | 4 | > [!TIP] 5 | > * Information overload? [This site](https://www.simonrak.se) has you covered with even more concise broken down steps. Even includes a long video! (cred. Simonrak)
6 | > * Easier method of cloning via ['shadow' config space](https://github.com/Silverr12/DMA-CFW-Guide/blob/main/Shadow_cfg_space.md) 7 | 8 | 9 | #### 📖Why make this guide? 10 | I don't like that there are people intentionally being vague, keeping information secret, or even misleading people to drive 11 | them away from being able to make their own firmware so that they end up buying 100s of dollars worth of custom firmware from 12 | other providers with no way to guarantee quality. 13 | 14 | #### Device Compatibility 15 | This guide uses a squirrel DMA card. Instead of using the Squirrel folder for the project, use the corresponding folder for your DMA card which will be found in the pcileech-fpga-master folder 16 | 17 | - 35T: Squirrel 18 | 19 | - 75T: EnigmaX1 20 | 21 | - 100T: ZDMA 22 | 23 | 24 | #### 🔎 Definitions 25 | __DMA__ 26 | : Direct Memory Access 27 | 28 | __TLP__ 29 | : Transaction Layer Packet 30 | 31 | __DSN__ 32 | : Device Serial Number 33 | 34 | __DW__ 35 | : Double Word | DWORD 36 | 37 | __Donor card__ 38 | : A card that will be used to get IDs/config space and will not be used on your main PC (Eg. PCIE Wifi card) 39 | 40 | __FPGA__ 41 | : Field Programmable Gate Array 42 | 43 | ### ⚠️ Disclaimer 44 | - This guide is not always updated to the scene's best practices, excercise caution when live-testing.
45 | 46 | - This guide does ___not___ detail how to set up software or change computer settings to accommodate DMA cards 47 | 48 | - If you there are concepts you don't understand even after reading through the whole guide, there is a link to a discord server at the bottom 49 | 50 | 51 | ### 📑 CONTENTS 52 | 1. [Requirements](https://github.com/Silverr12/DMA-FW-Guide#1-requirements) 53 | 2. [Gathering the donor information](https://github.com/Silverr12/DMA-FW-Guide#2-gathering-the-donor-information) 54 | 3. [Initial Customisation](https://github.com/Silverr12/DMA-FW-Guide#3-initial-customisation) 55 | 4. [Vivado Project Customisation](https://github.com/Silverr12/DMA-FW-Guide#4-vivado-project-customisation) 56 | 5. [Other Config Space Changes](https://github.com/Silverr12/DMA-CFW-Guide#5-other-config-space-changes) 57 | 6. [TLP Emulation](https://github.com/Silverr12/DMA-CFW-Guide#6-tlp-emulation) 58 | 7. [Interrupts](https://github.com/Silverr12/DMA-CFW-Guide#7-interrupts) 59 | 8. [Building, Flashing & Testing](https://github.com/Silverr12/DMA-CFW-Guide#7-building-flashing--testing) 60 | 61 | ## **1. Requirements** 62 | #### Hardware 63 | - A donor card (explained below) 64 | - A DMA card of course 65 | 66 | #### Software 67 | - A text editor, [Visual Studio](https://visualstudio.microsoft.com/vs/community/) is used in this guide. 68 | - [Xilinx Vivado](https://www.xilinx.com/support/download.html) Will need to make an AMD account to download 69 | - [Pcileech-fpga](https://github.com/ufrisk/pcileech-fpga) Source code for custom firmware 70 | - [Arbor](https://www.mindshare.com/software/Arbor) Will need to make an account to download the trial (14 days)
71 | 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. 72 | - Alternative to Arbor, [Telescan PE](https://www.teledynelecroy.com/protocolanalyzer/pci-express/telescan-pe-software/resources/analysis-software), this one's very similar and completely free but requires a manual review of your registration which can take a bit. 73 | 74 | ## **2. Gathering the donor information** 75 | (Using a donor card will help us later on with TLP emulation to communicate with the device to start a driver for legitimacy)
76 | Due to my limited testing and knowledge, I'll be using a network adapter for all examples continuing
77 | (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 testing specifically for delayed detection waves) 78 | 79 | 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. As most likely in the future, if not already, having 2 devices with 1:1 IDs would be detected and flagged** 80 | 81 | ### Using Arbor 82 | Go into Scan Options under the Local system tab and Press Scan/Rescan, the values selected by default are good enough for us. 83 | Go Into PCI Config and locate your network controller, scroll around in the decode section, and take note of the following things: 84 | 85 | #### All IDs shown below are mine and might not be the same for you 86 | 87 | 88 | 1. Device ID 89 | 90 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/8baec3fe-c4bd-478e-9f95-d262804d6f67) 91 | 92 | 93 | 2. Vendor ID 94 | 95 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/39c7de6d-d8db-4744-b0a0-ddeca0dfd7d7) 96 | 97 | 98 | 3. Revision ID (will show as RevID) 99 | 100 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/c2374ea7-ca9c-47b7-8a8d-4ceff5dffe3b) 101 | 102 | 103 | 4. BAR0 Sizing Value(1/2/3/4/5 too if you have them) 104 | 105 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/19239179-057a-4ed5-a79f-45cf242787a5) 106 | 107 | Click on the square it's in to see the sizing info 108 | 109 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/59a08249-1ce3-49ae-ac98-00e9909ca8e3) 110 | 111 | My size is 16kb so record that 112 | 113 | 5. Subsystem ID 114 | 115 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/94522a95-70bd-4336-8e38-58c0839e38ad) 116 | 117 | 118 | 119 | 6. DSN(listed as Serial Number Register) 120 | 121 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/595ae3e2-4cd8-4b3d-bcfa-cf6a59f289d5) 122 | > [!NOTE] 123 | > There is a good chance your device may not have this extended capability, some other extended capabilities you can implement in the vivado core_top are `VSEC`, `AER`, `VC` & `RBAR` 124 | 125 | Combine your lower and upper DSN registers for our DSN configuration in step 3 126 | 127 | For example, these are my values: 128 | 129 | Serial Number Register (Upper DW): `01 00 00 00`
130 | Serial Number Register (Lower DW): `68 4C E0 00`
131 | 132 | Combine yours in the same format: 133 | 134 | Upper DW + Lower DW = `01 00 00 00 68 4C E0 00` 135 | 136 | 137 | ## **3. Initial Customisation** 138 | 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. 139 | 140 | 141 | ### Using Visual Studio 142 | 1. 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 for `rw[20]` which should be on line 209 to find the master abort flag/auto-clear status register. Change the accompanying 0 to a 1. 143 | 144 | Before 145 | 146 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/48173453/78248ed9-68fc-4f43-929b-339328eae478) 147 | 148 | After 149 | 150 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/48173453/c372cfe9-4736-42db-ab16-18a0de516d9b) 151 | 152 | 2. In the same file `pcileech_pcie_cfg_a7.sv` Ctrl+F `rw[127:64]` which should be on line 215 to find your DSN field listed as `rw[127:64] <= 64'h0000000101000A35; // cfg_dsn`, insert your Serial Number there as such `rw[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. 153 | 154 | Before 155 | 156 | ![image](https://github.com/Silverr12/DMA-FW-Guide/assets/89455475/788170b0-6e4a-4b87-b1a9-31360abc8575) 157 | 158 | After 159 | 160 | ![image](https://github.com/user-attachments/assets/1900a75c-57c1-4217-a858-ae4c6c0265a6) 161 | 162 | this being my DSN 163 | 164 | if your donor card didn't have a DSN, yours should look like 165 | 166 | `rw[127:64] <= 64'h0000000000000000; // +008: cfg_dsn` 167 | 168 | 4. Go ahead and save all the changes you've made 169 | 170 | 171 | ### Generating the Vivado files 172 | 1. Open Vivado and in the top menu, in the search query, search for tcl console and click on it. 173 | 174 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/5a3770ad-b821-49c1-bea8-a79684993abc) 175 | 176 | The console should now open at the bottom of the application. 177 | 178 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/ae96df35-3e46-4f55-8ffd-39b42c8d0972) 179 | 180 | 181 | 2. In the Tcl console, type in `pwd` to see the working directory. It should look something like this `C:/Users/user/AppData/Roaming/Xilinx/Vivado` 182 | 183 | 3. 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)
If you get an error when trying to cd to your project directory, replace all the '\\'s with '/' 184 | 185 | 4. Once you have PCIeSquirrel dir open, in the Tcl console type in `source vivado_generate_project.tcl -notrace` and wait for it to finish 186 | 5. Once the project has been generated, Vivado should automatically open the `pcileech_squirrel.xpr` file. Keep it open on the side for a bit. 187 | 188 | ## **4. Vivado Project Customisation** 189 | 1. 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 labelled `i_pcie_7x_0 : pcie_7x_0`. 190 | 191 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/5617a8f8-6d5a-44af-8f88-703bc7d1f101) 192 | 193 | 2. 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.)_ 194 | 195 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/4b0584ec-9dda-4a2a-a5e1-a6e2eb28c6d1) 196 | 197 | 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. 198 | 199 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/24131586-03d6-4b70-9000-16448a4d8944) 200 | 201 | 3. 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. 202 | 203 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/89455475/1942fa3c-71cf-4466-a9a6-a33b5b38e54d) 204 | 205 | the size of my bar was 16kb so 16kb is what you set it as 206 | 207 | If the size unit is different change the size unit to accommodate the unit of the bar size 208 | 209 | 210 | 211 | 4. Press OK on the bottom right then hit "Generate" on the new window that pops up and wait for it to finish.
212 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/48173453/df292771-63c0-4013-9eaf-bb2c39e52539) 213 | 214 | 5. 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 use `set_property is_managed true [get_files pcie_7x_0.xci]`.) 215 | 216 | 217 | --- 218 | # **Steps 5 and 6** are currently under research and revision, so they are not yet complete or final. Please proceed with caution. 219 | 220 | 221 | 222 | ## **5. Other Config Space Changes** 223 | > [!TIP] 224 | > Please have a look at [shadow_cfg_space.md](https://github.com/Silverr12/DMA-CFW-Guide/blob/main/Shadow_cfg_space.md), It is a much easier way of doing what is described below 225 | 226 | 1. 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 227 | 228 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/48173453/c018b760-cb8f-4c08-9efc-e5a3cdd8ed8d) 229 | 230 | #### - Here is a list of variable names 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 that we've been able to match by name from Arbor. matched by capability, there is:
231 | - (PM) `PM_CAP_VERSION`, `PM_CAP_D1SUPPORT`,`PM_CAP_AUXCURRENT`, `PM_CSR_NOSOFTRST` 232 | - (MSI) `MSI_CAP_64_BIT_ADDR_CAPABLE`, 233 | - (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` 234 | - Fields that can be changed in different files or a GUI that I do not yet know about.
235 | - (PM) `cfg_pmcsr_powerstate` 236 | - (PCIe) `corr_err_reporting_en`, `non_fatal_err_reporting_en`, `fatal_err_reporting_en`, `no_snoop_en`, `Link Status2: Current De-emphasis` 237 | 238 | 239 | #### - It is also advised that you change the block locations of some of the capabilities, this can be done by changing the following variables: 240 | - Capability NEXT Pointers:`CAPABILITIES_PTR`, `MSI_CAP_NEXTPTR`, `PCIE_CAP_NEXTPTR`, `PM_CAP_NEXTPTR` and 241 | - Capability Pointers: `MSI_BASE_PTR`, `PCIE_BASE_PTR`, `PM_BASE_PTR` 242 | 243 | On default pcileech firmware you can locate: **PM at 0x40, MSI at 0x50, and PCIe at 0x60**, The example will be changing them to **PCIe at 0x40, PM at 0xC8 and MSI at 0xD0**, but you can have them at any location really (e.g PCIe at 0x80, PM at 0xD0 and MSI at 0x90) since our computers can and will jump over the empty blocks, all you have to do is make sure the `NEXTPTR`'s line up to the next capability as explained below and that you take note of the capabilities sizes so they don't try to overlap. 244 | - You need your NEXTPTRs lined up starting from your header at 0x00 and going up in the config blocks, for example: 245 | - If I were to change my capabilities blocks around to `PCIe: 0x40 | PM: 0xC8 | MSI: 0xD0` I would simply assign their associated `BASE_PTR` variables as such to the same value. Always make to start at or above 0x40 as our header ends just before it and also make sure your base ptrs always end on 0, 4, or 8 such as 40, 44 68. 246 | - Secondly, I would also have to have my header capability pointer `CAPABILITIES_PTR` point to 40 (which it is by default) since it's our lowest/first to be read in this case, then the `PCIE_CAP_NEXTPTR` will point to C8, `PM_CAP_NEXTPTR` to D0 and `MSI_CAP_NEXTPTR` to 00 to finalise it out, and always make sure it's in order from top to bottom as if you try to point backward in the config space your firmware will not work in some cases. (Extended capabilities such as AER, DSN, LTR, etc also require this configuration if you decide to put them in. But you do not point the regular capabilities into them as they are a separate 'set', besides that they follow the same pointer format as your regular capabilities.) 247 | 248 | 249 | > [!IMPORTANT] 250 | > Once you have completed steps 1-5, you **should, with 98% confidence**, be good to go for systems with lower-end detections 251 | > Your best bet to get past higher-end detection systems is lots of trial and error, many will not reveal their methods unless they want it detected so you are mostly on your own there unfortunately. 252 | 253 | 254 | ## **6. TLP Emulation** 255 | **For now, see:** 256 | 1. [Ekknod's bar controller config](https://github.com/ekknod/pcileech-wifi/blob/main/src/pcileech_tlps128_bar_controller.sv#L850) between line 850-896 for an example 257 | 2. [One of Yxlnq's bar controllers](https://github.com/yxlnqs/diviner-full-emu-v2/blob/5a177e34ae5dae94bb2c023e38301af425ca6e4b/src/pcileech_tlps128_bar_controller.sv#L850) 258 | 259 | Notes to consider: 260 | 261 | 262 | 1. You have two options for obtaining the register addresses for the device you're emulating, your options are: 263 | - Searching to see if your driver is already open source and looking through it, a good starting point is this [Wikipedia](https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers) page that lists open-source/reverse-engineered wireless drivers that you could take values from for your firmware 264 | - **[Hard]** Using a reverse-engineering program of your choice to find the details of your driver for your donor card, you can find the location of the installed driver by navigating to your device in the device manager, going to Properties>Driver>Driver Details, and it should normally be the only .dll file in there. (Mind you unless you are already well versed in the area of reverse engineering, don't commit your time to this) 265 | 266 | ### Resources for general understanding & TLP emulation 267 | 1. https://fpgaemu.readthedocs.io/en/latest/emulation.html 268 | 2. https://docs.xilinx.com/v/u/en-US/pcie_blk_plus_ug341 269 | 3. https://www.fpga4fun.com/PCI-Express4.html 270 | 4. https://www.xillybus.com/tutorials/pci-express-tlp-pcie-primer-tutorial-guide-1 271 | 5. https://ctf.re (<-amazing one) 272 | 273 | ## **7. Interrupts** 274 | Please see [https://github.com/kilmu1337/VGK-DMA-BYPASS](https://github.com/kilmu1337/VGK-DMA-BYPASS) for now 275 | 276 | ## **8. Building, Flashing & Testing** 277 | 278 | 1. Run `source vivado_build.tcl -notrace` in the tcl console to generate the file you'll need to flash onto your card
279 | - You'll find the file in `pcileech_squirrel/pcileech_squirrel.runs/impl_1` named "pchileech_squirrel_top.bin"
280 | 2. Follow the steps on the [official LambdaConcept guide for flashing](https://docs.lambdaconcept.com/screamer/programming.html) **REMINDER: ONLY FOR SQUIRREL** 281 | 3. Run a DMA speed test tool from your second computer (There is a link and download in the discord server) to verify your firmware is working and reading as it should be. 282 | 4. Dump and compare the config space of your new firmware to the **known** signed pcileech default seen below to see if it's overly similar. You should most definitely be right about 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 same across all of them. GLHF 283 | 284 | This is the signature one of the lower-end detection systems supposedly scan for in the config space of the PCIe device: 285 | [More info here](https://dma.lystic.dev/anticheat-evasion/detection-vectors)
286 | `40: 01 48 03 78 08 00 00 00 05 60 80 00 00 00 00 00`
287 | `60: 10 00 02 00 e2 8f XX XX XX XX XX XX 12 f4 03 00`
288 | ("XX" are bytes that they do not care about) 289 | 290 | Another form of detection that may or may not be implemented that could be blocking your firmware is reading your device history, this can be cleaned by following [this](https://dma.lystic.dev/anticheat-evasion/clearing-device-history) post. 291 | 292 | > [!CAUTION] 293 | > **There is a good chance that on your first flash if you went about some of the more 'harder' to navigate steps it will mess something up, don't worry, and look at the troubleshooting below.**
294 | 295 | ### Flashing troubleshooting 296 | - If you mess up your CFW and your game PC won't fully "boot", be because of bios hang or other reasons, you will be able to flash new firmware onto it from your second computer if the card is still powered (normally indicated by LEDs). If your main 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' **(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 there have been rare reports of motherboard corruptions due to this)** 297 | - There are flat-out some motherboards that will be incompatible with some firmware, in some cases this can be resolved my making a manual memory map. 298 | 299 | ### 'Dysfunctional' firmware troubleshooting 300 | - If your speed test prompts something along the lines of `tiny PCIe algorithm`, you have made a mistake somewhere in your configuration space. Your card *will* still function but reads will be slower than they should be which can severely impact performance. 301 | - Changing some functions below acceptable bounds most likely named something including payload/size/speed **can** also slow down the reading speed of your card. The best course of action is to set max read request/payload sizes to 4KB/highest available 302 | - Some motherboards will simply be incompatible with some firmware, most reports have been on gigabyte mobos. 303 | - Sometimes your firmware will allow your device to work but cause a massive slowdown then BSOD your computer if it tries to read it with Arbor or Device Manager. Unfortunately, I don't know exactly where you need to go wrong for this to happen so I recommend re-doing your whole firmware. I suggest keeping a stable firmware that works on your second computer in case this happens. 304 | - Are your changes not saving when making a new .bin file? Try deleting your `pcileech_squirrel.runs` & `pcileech_squirrel.cached` folder or even making and working in a new copy of the stock pcileech-fpga folder every new firmware as good practice 305 | 306 | 307 | ### Once you've read through all this, 308 | If you have any questions, problems with your firmware or suggestions, feel free to join my Discord for support. 309 | [![Discord Banner](https://discord.com/api/guilds/1268006421002453124/widget.png?style=banner2)](https://discord.gg/m9zmBwn8Y5) 310 | 311 | 312 | ### Additional Credits 313 | Ulf Frisk for [pcileech](https://github.com/ufrisk/pcileech)
314 | Ekknod for his [custom pcileech config](https://github.com/ekknod/pcileech-wifi)(You may be able to use this as a base to start off of as well!)
315 | Garagedweller's [Unknown Cheats thread](https://www.unknowncheats.me/forum/anti-cheat-bypass/613135-dma-custom-firmware-guide.html) that inspired me to make this in the first place and whom I credit my interest in this topic to. 316 | 317 | ### Sponsor this project 318 | If you feel this guide has helped you enough to warrant a monetary donation, feel free to donate here:
319 | USDT/trc20: `TDa8PUwAdD9rg84ythjXjN52s8UeaejnFN`
320 | ![usdtaddr](https://github.com/Silverr12/DMA-CFW-Guide/assets/48173453/36a8a6d6-1edd-4289-96b9-a9003a7c4a26)
321 | 322 | LTC: `MMxWW2n5pTbWoY9EakDaTiQ7HKBJy7sxDh`
323 | ![ltcaddr](https://github.com/Silverr12/DMA-CFW-Guide/assets/48173453/e243973f-7b84-42a9-b78a-19a7a12aac98)
324 | or just starring the repo helps **immensely** too <3
325 | also sponsor the [man who's making this all possible](https://github.com/ufrisk)
326 | 327 | -------------------------------------------------------------------------------- /Shadow_cfg_space.md: -------------------------------------------------------------------------------- 1 | ## Shadow_cfg_space 2 | This section of the guide details how to utilise Pcileech's `pcileech_cfgspace.coe` to customise your firmware without the constraints of Xilinx Vivado 3 | 4 | This section of the guide also assumes the reader has read through the main part of the guide, without it you may not understand some steps 5 | 6 | Firslty we'll need to convert our donor device's configuration space to a format thats valid for our .coe file, this can be done using 2 ways, I'll be covering it using the easier method 7 | 8 | 1. Using telescan, save a copy of your donor device's values to a .tlscan file. This can then be converted using this handy [.tlscan to .coe script](https://github.com/Rakeshmonkee/DMA/blob/main/.tlscan%20to%20.coe/telescan_to_coe.py) (instructions for it are in the same repo) 9 | 10 | 2. In the file `src/pcileech_fifo.sv`, change `rw[203] <= 1'b1; // CFGTLP ZERO DATA` to -> `1'b0;`. Additionally if you've already changed `rw[20]` and potentially `rw[21]` in `cfg_a7` in the main section of the guide, you'll want to change those back to 0 11 | 12 | 3. Copy the converted file into your `pcileech_cfgspace.coe`. There are some values you may need to change for it to function on your card, main one is to convert your BAR(s) from the address to the sizing (still in the cfgspace.coe file not the vivado gui, though I recommend using it to see what your bar with your specific size **should** look like), also apply the same rules regarding payload/data sizes as in the main part of the guide. 13 | 14 | 4. After the two files are changed and saved, proceed to generate your Vivado project, inside which we'll be changing just the Vendor & Device IDs in the gui and nothing else. Take care to select "Global" in your synthesis options (as seen in the picture) 15 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/48173453/d997c1e7-ba9b-47e6-b0fb-5a31ee2cf4f8) 16 | 17 | 5. Lock the ip core you just generated and proceed into the `pcie_7x_0_core_top` file, in there change both `EXT_CFG_CAP_PTR` & `EXT_CFG_XP_CAP_PTR` to 01 as seen in the picture, or better yet to 0A if you're proceeding with the writemask step below, keep in mind you will need to manually fill the required values below the area you've set the shadow cfg to take over from.
18 | ![image](https://github.com/Silverr12/DMA-CFW-Guide/assets/48173453/ec79c104-783f-4e56-b82c-2a3dca66b189) 19 | 20 | > [!NOTE] 21 | > The 01 we set for these variables changes where the shadow cfg will take over from in the configuration space, this number we set can be calculated by taking the hex value of the block you want to start from, converting it to decimal, dividing by 4 then converting back to hex. Reference image is below 22 | 23 | ![image](https://github.com/user-attachments/assets/5d897c5b-b0bd-4626-9424-cda7f0b43a28) 24 | 25 | 26 | ## Writemask 27 | One drawback of using the shadowcfg by itself is that it will automatically set all the values set by it to RO or Read-Only, meaning that other sources will not be able to write to those registers which isn't normally seen on regular devices and can be detected, this is why we will employ the use of pcileech's writemask. 28 | 29 | 1. Go back to the `pcileech_fifo.sv` file and change `rw[206] <= 1'b0; // CFGTLP PCIE WRITE ENABLE` to -> `1'b1;` 30 | 31 | 2. Utilising a talented individual's script here [writemask.it](https://github.com/Simonrak/writemask.it), you can with the help of the .coe file you generated in the previous section of the guide make a ready-to-go writemask file which you will want to replace your old `ip/pcileech_cfgspace_writemask.coe` with. 32 | 33 | 3. Generate bitstream using either the console+file or pressing "Generate Bitstream" on the left, wait for it to finish and you're done. 34 | 35 | > [!TIP] 36 | > Some instances of "tiny pcie algo" can be solved by changing the `.cfg_force_mps` parameter in the core top file to match your `DEV_CAP_MAX_PAYLOAD_SUPPORTED`, which when set too low can cause the tiny algo 37 | 38 | ### Credits:
39 | [@kilmu1337](https://github.com/kilmu1337) and his writeup [here](https://github.com/kilmu1337/DMA-FIRMWARE/blob/main/DMA%20FIRMWARE.md)
40 | [@Simonrak](https://github.com/Simonrak) for his .coe to writemask script
41 | (Show some love to both of their efforts) 42 | --------------------------------------------------------------------------------