# Cheating with DMA Devices Cheating with DMA devices is fun and safe. Learn how it's done here! ## What is DMA? DMA stands for Direct Memory Access. This is functionality that allows PCIe and other devices to read and write to physical memory without going through the CPU or system OS. ## Why use DMA for Cheating? Unlike what EAC, BE, ESEA, and FACEIT want you to believe. Cheating with a DMA device is far safer than any Kernel Driver cheat and is probably on par with cheating through a VM. It's also a fun challenge ## How Much Does it Cost? You should expect to pay between $300 and $700 USD in order to obtain the hardware. If you are purchasing custom firmware, you can expect to pay between $100 and $300 USD. ## todo more faq i'll eventually add more faq # Device List Information on DMA devices that I have tried out ## Not every device is created equal. Choosing the correct manufacturer and device is critical to DMA development and cheat sales. Devices have their own stability, prices, ease of use, and quality control. In this segment I plan to list all of the DMA devices I have tried or plan to try out with my own DMA cheats. I'll include details on how satisfied I was with the hardware and the customer service, along with information on using and flashing the device. {% hint style="info" %} Some of these devices may be discontinued. I do not recommend purchasing devices from 3rd party vendors. {% endhint %} # Screamer PCIe USB-C (R04) Information on the DMA Device sold by LambdaConcept. ![Screamer PCIe USB-C (R04) as displayed on the LambdaConcept store](/files/-MfUFASqxXfd2Ir5V_Pp) The Screamer PCIe is a PCIe x4 FPGA manufactured and sold by LambdaConcept ([link to store](https://shop.lambdaconcept.com/)). The card features a fast USB 3.0 connection and up to 150 MB/s read/write speeds. It ships with the precompiled pcileech gateware, and a device identifier of 0666. There is a fundamental hardware issue with this device, however. The USB-C port sits too high on the backplate and is **very** often blocked by the case the device sits in. My solution is to sit the card at a slight angle and not bolt down the backplate (I do not recommend this). I purchased two of these cards, with a friend of mine purchasing a subsequent third device. Two of these three devices were defunct upon arriving. LambdaConcept ignored support emails on this topic. Essentially, there is a 50/50 chance the card you purchase from them will be non-functional, and you have no hope of getting in contact with anyone from LambdaConcept to resolve any issues you run into. When the card does work, it seems fairly stable even under a high-temperature environment. My functional card sits directly underneath my RTX 3090 Founders Edition and I have not noticed any major stability problems while gaming. Thanks to the documentation provided by LambdaConcept, flashing the device is fairly simple. Though you will need to purchase a second JTAG board in order to do so. # Building custom gateware Building custom PCILeech-fpga gateware for the Screamer. Gateware is a more accurate term than Firmware for the code we put on the FPGA device. An important part of cheating with a DMA device is building custom gateware. The device gateware is what makes or breaks you. If you try playing a game with the stock gateware, you may get banned. This is because the OS can probe your PCIe lanes and get some information about the devices plugged in. This is most often used to acquire the default device drivers when you plug a new USB expansion card in. ## The PCILeech-FPGA Repo The factory gateware for this device is for PCILeech. This gateware is open-source [on GitHub](https://github.com/ufrisk/pcileech-fpga). When building your first custom gateware, I highly recommend simply customizing this code. For now, Bastian and others have not come up with new approaches to detecting modified versions of this public gateware, so you should be safe. Clone the repository and look into the [ScreamerM2 ](https://github.com/ufrisk/pcileech-fpga/tree/master/ScreamerM2)directory. Here you will find detailed instructions on building and customizing the gateware for your device. ## Xilinx Vivado WebPACK In order to build the custom gateware, you need the free version of Xilinx Vivado. This is available on [Xilinx's website](https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/vivado-design-tools/2020-2.html). It is important that you download version 2020.2 or newer. ### Building PCILeech Gateware To start, I recommend testing your device before building and flashing custom gateware. After you've confirmed the device works (or you're out of options and this is your only hope of making it work), you can follow the build instructions from the [PCILeech-FPGA repo](https://github.com/ufrisk/pcileech-fpga/blob/master/ScreamerM2/build.md) to use Xilinx. I believe it's best to start by building and flashing the factory gateware first, and then coming back to follow the advanced customization instructions. If you would like to follow the customization instructions, you can learn more about them in the Device Spoofing section {% content-ref url="/pages/-MfS1quFqT8jqTK13fLU" %} [Device Spoofing](/anticheat-evasion/pci-configuration-space) {% endcontent-ref %} After you've built your custom gateware, follow the instructions in the flashing custom gateware section. {% content-ref url="/pages/-MfS1jblyuIVH8cWLXEX" %} [Flashing custom gateware](/fpga-devices/devices/screamer-pcie-r04/flashing-custom-gateware) {% endcontent-ref %} # Flashing custom gateware Flashing custom gateware onto the Screamer. Detailed information on flashing custom gateware can be found in the [LambdaConcept documentation](https://docs.lambdaconcept.com/screamer/programming.html). You will also need to follow these [OpenOCD instructions](https://docs.lambdaconcept.com/screamer/openocd.html). ## The JTAG Board LambdaConcept sells a [JTAGSerial ](https://shop.lambdaconcept.com/home/25-jtagserial-pack.html)device. This is required in order to flash custom gateware onto this DMA device. This is not a very user-friendly system and if done incorrectly, could permanently damage the DMA device. ### Using the Board 1. Plug the provided jumper wires into the board and your PCIe device. **Ensure it is in the correct orientation!** 2. Plug the JTAGSerial board into your PC via the provided USB cable. 3. Ensure your PCIe Device is plugged into a PC. Power on that PC. 4. Download the precompiled OpenOCD windows binaries from the [LambdaConcept docs](https://docs.lambdaconcept.com/screamer/openocd.html). 5. Download [Zadig](https://zadig.akeo.ie/). 6. Follow the [WinUSB driver for Windows](https://docs.lambdaconcept.com/screamer/openocd.html#winusb-driver-for-windows) instructions. It is **very important** that you replace the correct driver. This is the **Interface 0** device. 7. Download the [proxy and flashing scripts](https://docs.lambdaconcept.com/screamer/programming.html#get-proxy-and-flashing-scripts) provided by LambdaConcept. 8. Place your custom gateware .bin file in the proxy and flashing scripts folder. 9. Run the flashing script using OpenOCD as outlined by LambdaConcept in [their docs](https://docs.lambdaconcept.com/screamer/programming.html#run-the-flashing-script). 10. Remove the JTAG from your Device and reboot the target machine by fully powering off and back on. ## Post-Flash Actions You should read up on Device Spoofing for details on what actions to take after flashing your device in order to clear your system of any bad identifiers. {% content-ref url="/pages/-MfS1quFqT8jqTK13fLU" %} [Device Spoofing](/anticheat-evasion/pci-configuration-space) {% endcontent-ref %} # Raptor DMA Information on the DMA device sold by Raptor DMA. ![RaptorDMA Device as shown on the raptor-dma store](/files/-MfZ0YQBGgjxZ_KGkYVj) The RaptorDMA device is a PCIe x1 FPGA board with USB-A 3.0 connections. Unlike the Screamer PCIe, the JTAG for this board is built in and can easily be hooked up via a second USB-A interface. RaptorDMA sells their boards with their own customized version of the pcileech gateware. They claim that the gateware is unique per customer. In order to flash your RaptorDMA, they provide their own flashing software. This ensures only their own gateware can be easily flashed to the device. It is possible to flash your own gateware to their device, but it is not described by the manufacturer. I purchased my RaptorDMA from a 3rd party. I strongly urge you do not do the same and buy direct from the manufacturer ([link to store](https://www.raptor-dma.com/)). Some DMA cheat sites like AtomicDMA suggest RaptorDMA is a scam. While they may be *now*, my device *is* legit and *is* the best performing device I have found. Performance on the Raptor is the best I have tested. I can easily pull 400mb/s over this card. It is also very stable & due to this is my current "daily driver". # Building custom gateware Building custom gateware for the Raptor device. Follow the same instructions as for the Screamer R02: [Building custom gateware](/fpga-devices/devices/screamer-pcie-r04/building-custom-gateware) # Flashing custom gateware Flashing the RaptorDMA device with custom gateware via OpenOCD. Follow the same instructions as the Screamer R02: [Flashing custom gateware](/fpga-devices/devices/screamer-pcie-r04/flashing-custom-gateware). ### Correcting for Update Port The RaptorDMA uses a unique update port identifier. In order to use OpenOCD to flash the device over it's update port, you will need to modify the **FTDI\_VID\_PID** entry in the OpenOCD CFG file. ``` ftdi_vid_pid 0x0403 0x6010 ``` Here, we are specifying the USB Device ID for your Update Port. # Ranger DMA (legacy) Information on the DMA device previously sold by Ranger DMA.

RangerDMA device as shown from the AliExpress store.

The original version of this device is no longer for sale ([link to store](https://www.aliexpress.us/item/3256802726549938.html)). # Building custom gateware Building custom gateware for the Ranger device. Follow the same instructions as for the Screamer R02: [Building custom gateware](/fpga-devices/devices/screamer-pcie-r04/building-custom-gateware) # Flashing custom gateware Flashing the RangerDMA device with custom gateware via OpenOCD. Follow the same instructions as the Screamer R02: [Flashing custom gateware](/fpga-devices/devices/screamer-pcie-r04/flashing-custom-gateware). # CaptainDMA 75T Information on the CaptainDMA 75T device.

CaptainDMA 75T as shown on the CaptainDMA Store.

The CaptainDMA 75T is a variant of Artix-7 75T DMA boards sold by CaptainDMA and their resellers. It comes equipped with a kill switch and two USB-C ports. One port is a USB 3.1 port driven by an FTDI USB FIFO chip. The update port is a CH347; an alternative chip to the standard FTDI JTAG UART silicon. The CH347 makes flashing this device tricky. You need to use vendor supplied software and a custom compiled OpenOCD variant. It made working with this board particularly challenging. When I did manage to figure out flashing, this board smashed my 35T's performance profile. Easily 20% faster than any other device I had tried up to that point. # Building custom gateware Building custom gateware for the Ranger device. TODO # Flashing custom gateware Flashing the RangerDMA device with custom gateware via OpenOCD. TODO # ZDMA Thunderbolt Information on the ZDMA Thunderbolt device.

ZDMA Thunderbolt from their store.

The ZDMA Thunderbolt is the first Thunderbolt device on the market. It offers a massive performance boost over any device on the market. 3-4x faster than the competition. This card is a beast. Being Thunderbolt, the device connects over a PCI interface rather than an FTDI USB port. The benefit is performance, whereas the cost is a Driver required on the Attacker machine. If you're OK installing questionable unsigned drivers on your PC, this thing is great (the driver will soon be signed and vetted by microsoft). The device has **3** USB-C style ports. One is an update port which I have not yet tested. The other **2** ports are both DATA ports for the card, you can use either. # Building custom gateware Building custom gateware for the Ranger device. TODO # Flashing custom gateware Flashing the RangerDMA device with custom gateware via OpenOCD. TODO # Usage Using PCILeech with the Screamer device. ## Plugging in the Device The Screamer needs a PCIe x4 slot or larger to fit into. After plugging in the device, it may be apparent that the USB-C port is slightly obstructed by your case. You'll need to brainstorm a solution for this, either use a PCIe riser bracket, remove the PCIe shield from your case, or something else. ## First Time Startup 1. Ensure both your primary and secondary machines are powered off. 2. Connect the USB-C cable to a USB-3 port on a secondary machine (preferably windows). 3. Power on the secondary machine; log in. 4. Power on the primary machine (with the device plugged in). 5. Open BIOS, turn off IOMMU. Save and exit. 6. Log in to the primary machine. 7. On the secondary machine, you may need to update the USB driver to the [D3XX driver](https://ftdichip.com/drivers/d3xx-drivers/') shipped by FTDI. 8. On the secondary machine, download [PCILeech](https://github.com/ufrisk/pcileech). If that doesn't ship with [LeechCore](https://github.com/ufrisk/LeechCore), you should download that as well. 9. On the secondary machine, run pcileech.exe with the probe argument (see below). 10. PCILeech should start probing the primary machine's memory. You can use CTRL+C to cancel this operation. ```bash ./pcileech.exe probe ``` ### Probe Command Error If your probe command spits out an error. It's possible your USB/PCIe connection is bad, IOMMU is still enabled, the gateware preinstalled was busted, or you received fucked hardware. Check the connections, reboot your machines, and try again. If that does not work, skip to building and flashing your own custom gateware. If you're lucky, loading your own custom gateware will resolve the error. ## Daily Usage At this point, your device is ready to go for hackin. Ensure that your secondary machine is always powered on when you start the primary machine, otherwise, you will run into device initialization issues. # Limitations info on the current limitations of DMA devices. ## Read/Write Speed Limitations DMA devices can come in a wide range of speeds. For DMA cheating, we need high speed, low latency, and very good stability. Sadly, most cards on the market don't provide us with all three of these factors. You can expect about 1000 r/w TLPs per second. This is a really tight restriction for cheating, so we need to be smart about our read operations. If we can read 4096 bytes in one read operation, and from that get multiple pointers or values, that is more efficient than reading each value or pointer on its own. {% hint style="info" %} Ulf Frisk discusses latency and speed on [this](https://github.com/ufrisk/pcileech/issues/56) git issue. {% endhint %} ### See also: {% content-ref url="/pages/-MfS3ZdYn0dkSFbuXUJj" %} [Broken mention](broken://pages/-MfS3ZdYn0dkSFbuXUJj) {% endcontent-ref %} ## IOMMU Limitation The [IOMMU ](https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit)is a middle man between our DMA device and the physical memory. In order for our DMA cards to work, this feature needs to be turned off. {% hint style="info" %} Anticheats do not require IOMMU to be enabled yet. {% endhint %} # Detection Vectors Information on how Anticheats can detect DMA cheats and devices. ## How can Anticheats Detect our Device? Detecting a DMA device is a challenging task. So far, only ESEA has [publically ](https://blog.esea.net/esea-hardware-cheats/)claimed to detect hardware-based cheating. There have been several research papers ([1](https://depositonce.tu-berlin.de/bitstream/11303/4494/1/stewin_patrick.pdf), [2](http://www.cse.chalmers.se/~mckee/papers/iiswc08.pdf), [3](https://www.mulliner.org/collin/publications/p857-stewin.pdf)) on how to detect these devices from a system level, but given how busy the system is while gaming, they are impractical, if not impossible, for any anticheat to implement. A device that is properly configured, and programmed, should be completely undetected until the anticheat developers get their hands on the device. ## PCI Configuration Space Every PCI device has a [configuration space](https://en.wikipedia.org/wiki/PCI_configuration_space). In short, this is a sequence of data that the host can read from the device. This data contains information such as the device id, and device capabilities. Anticheats can probe this information from all PCI devices and check for known bad actors. The only anticheat known to probe the PCI lanes is Vanguard, although it is not known if this is used to check for DMA devices. BattlEye is believed to run a signature scan against the configuration space of PCI devices. ``` 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 ``` They appeared to check lines 40 and 60 for the patterns above. ("XX" are bytes that they do not care about). ## Using Big Data Anticheats could correlate cheat reports with users PCI devices. If enough highly-reported users are all using an unknown PCI device, that could be enough to issue a ban. This is **not** actively being done by any anticheat. ## Xilinx IP Block Detection Most devices on the market, however, can not have their config space completely customized. The devices I have tried are all built on Xilinx PCIe IP. Using Xilinx Vivado, it is impossible to build gateware that contains a completely custom configuration space. With this, anticheats could detect gateware built using Xilinx PCIe IP. This is **not** being done by any anticheat. {% hint style="info" %} There is an interesting issue on the [pcileech git](https://github.com/ufrisk/pcileech/issues/107) regarding this. {% endhint %} ## Device Identifier Detection All of the DMA devices ship with stock gateware. This gateware contains stock device identifiers. Those are almost certainly unique for the device. Anticheats can scan the devices plugged into the system and read the identifiers. If a known DMA device's stock identifier is found, this user is almost certainly a cheater. This **will** get you banned from BattlEye, ESEA, and possibly other anticheats. Device identifiers persist on the Windows system even after the device is unplugged. Anticheat *could* lift previously installed devices & look for factory PCILeech gateware IDs. Check out the "Clearing Device History" page for information on cleaning the Windows OS of previous DMA devices. {% content-ref url="/pages/-MfZADaqKS3m6axomxOs" %} [Clearing Device History](/anticheat-evasion/clearing-device-history) {% endcontent-ref %} ## Integrity Checks When we modify `.text` sections with our DMA device, we can still fall victim to integrity checks. For example, if we try to patch some hook applied by the anticheat, we could be banned when that anticheat checks to see if all it's hooks still exist. # Device Spoofing Information on customizing the PCI Configuration space to spoof device IDs. ## Customizing our Device Identifiers In order to avoid current approaches to DMA device detection, we need to build custom gateware for our device with unique device identifiers. Using Xilinx Vivado, this is extremely easy to do. For devices that use pcileech-fpga, [build instructions](https://github.com/ufrisk/pcileech-fpga/blob/master/ScreamerM2/build.md#customizing-pcie-device-type-vendor-id-and-product-id) can be found with details on how to customize these identifiers. ## Spoofing Real-World Devices Spoofing the identifiers of a real-world PCI device ensures that you don't stumble into some previously device identifiers. It also makes the anticheat's job of differentiating between bad and good devices much more difficult. ### Retrieving Device Identifiers In order to spoof a real-world device, we'll need to extract information about the device. #### Using LSPCI Plug the real PCI device into your system and run [lspci](https://linux.die.net/man/8/lspci). This command enables us to dump PCI device information. For windows users, a Windows variant of lspci can be found [here](https://eternallybored.org/misc/pciutils/). With LSPCI we can dump the entire configuration space of our PCI card. This will enable us to build gateware to spoof this config space. {% hint style="info" %} The device information of your stock Screamer PCIe USB-C (R04) device can be found with the following command: **lspci -d 10ee:0666 -vvv -xxxx** {% endhint %} #### Using Device Manager Simple device identifiers can be extracted using the Device Manager application on Windows. We can't get the entire configuration space, so this approach doesn't provide enough information to fully spoof our target device, but for Xilinx devices, it provides enough. ![Example hardware ids viewed from Device Manager.](/files/-MfZEYZM9nLcBE0xFNyE) ## Customizing the Device Serial Number As part of our anticheat evasion, we'll want to customize the DSN. For pcileech compatible devices, this is outlined as part of the build readme ([example](https://github.com/ufrisk/pcileech-fpga/blob/master/ScreamerM2/build.md#device-serial-number-dsn)). You'll want this to be unique, so don't change it to some meme. # Clearing Device History information on how to clear device history from Windows machines ## Cleaning our System of Device Information While using a DMA device. You will eventually power on a Windows system with the stock gateware installed on your card. Even after flashing your device, this record of the original gateware is kept on the OS. We need to clear this. Start by opening Device Manager. From here, we'll go to View->Show hidden devices. Now, our stock gateware device will be visible under the "Other Devices" subsection. We want to identify our device using its hardware ids and delete it. ![How to remove a disconnected device from Device Manager.](/files/-MfZIQRKjs4D9T0C_3VC) It is very important that you do not forget this step. Anticheats will ban you for having a device history with the stock gateware for most DMA cards. # Advanced Evasion information on advanced evasion techniques that may be possible. ## Device Emulation When spoofing a hardmless PCI device, it is possible that a DMA device could emulate the PCI device in question. With this, the Windows driver for interacting with the spoofed device would be tricked into working as intended, where all actions to the device would be emulated by the attacker and responded to in an accurate manner. ## Custom Configuration Spaces w/ Xilinx Devices As outlined by Ulf Frisk in the [pcileech-fpga repository](https://github.com/ufrisk/pcileech-fpga/blob/master/ScreamerM2/build.md#configuration-space). It is possible to partially override the configuration space of Xilinx PCIe devices. This would allow us to spoof as much of the config space as possible of the harmless PCI device. Anticheats, as well, can create patterns within the configuration space that would trigger bans. By customizing our configuration space, we can avoid these detections provided a pattern doesn't identify the Xilinx IP. # MemProcFS Library How the MemProcFS library helps us write C++ DMA cheats. # Using VMMDLL An overview of useful functionality provided by the VMM library. Describe the VMMDLL C++ API and Library. How we use it, ect. # Windows Kernel Information on interacting with the Windows Kernel from DMA. Info on how to read windows kernel drivers - such as win32k ## Extracting Mouse Coordinates Info on extracting mouse position from Kernel ## Extracting Keyboard State Info on extracting keyboard state from Kernel ### Extracting Window Information Info on extracting things like Window Titles and Window Sizes from kernel