I am not sure if this is the correct place to ask this question. Please let me know where the correct place is.
Cheating in online video games has been a relatively big problem for players, especially for those who aren’t cheating. As most anti-cheat software move into the kernel land, the cheats moved into the kernel land as well. The most popular anti-cheat software such as BattlEye, EAC, ESEA and FaceIt have already kernel-mode drivers. As a result, in order to avoid detection, some cheaters and cheat developers move into the hardware based cheats. They buy a PCIe DMA hardware such as PCIeScreamer or Spartan SP605. They install this device into the computer on which they play the video game. The device also has a USB port which allows you to connect it to another computer. They connect one end of the device into another computer and initiate the memory manipulation from another computer. Interestingly, this sort of technology also seem to be very useful for malware analysis.
I know some people say that cheating is kind of a grey area. I do not find it ethical, but from a technical perspective I have been very much interested in learning how they do it. I am not sure if you consider this sort of software as malware. In some other online platforms, they will not allow people to discuss this sort of information. Please forgive me if this is forbidden here on this forum too.
So, my question is how does the anti-cheat software detect PCIe DMA cheating hardware? A company named ESEA claim they can even detect the PCIe hardware even if the hardware ID is spoofed:
“While the pictured hardware can be used in a DMA attack, the specific device featured in the media is starting to become less popular in the cheat scene, primarily due to the inability to easily modify its hardware identifiers. Other hardware devices used are detected by the ESEA Client using more sophisticated methods, regardless of if the device attempts to spoof itself as another legitimate device or not.”
So, I’m going to expand your question to be: How could we know if a given PCI device is on our machine, ignoring the vendor ID and device ID.
There are a number of heuristics one could devise. For example, you could look for a specific pattern of BARs (BAR 0 has a memory range of size X, BAR 1 size Y, BAR 3 size Z, etc)… you could add other distinguishing characteristics as well: Number of MSIs, specific set of capabilities, and the like.
Naturally, this only gets you some much accuracy.
If a specific driver is used for the hardware, you could try to identify it as well… checksumming blocks of code or whatever.
They also specifically mention no driver is needed both in the video and the Github page:
“PCILeech uses PCIe hardware devices to read and write target system memory. This is achieved by using DMA over PCIe. No drivers are needed on the target system.”
It’s a pure hardware attack (not just limited to games or whatever): you plug a board with an FPGA module into your PCIe bus… it slurps all of memory, can then analyze its content, and plop back whatever it wants.
From a cyber-attack perspective scary but ultimately pretty uninteresting, given you need to be able to plug the device into somebody’s system board. Note that attacks via Thunderbolt (such as on an unsuspecting system while the user is away and logged off) are prevented by Windows using both IOMMU and the policy of not recognizing new Thunderbolt devices when nomuser is logged on.
It’s a pure hardware attack (not just limited to games or whatever): you plug a board with an FPGA module into your
PCIe bus… it slurps all of memory, can then analyze its content, and plop back whatever it wants.
Apparently, I am just missing something, but how can a PCIe device start a DMA transfer from/to the machine it is plugged in if no one on this machine instructs it to do so? No matter how you look at it, you still need someone on your target system to program your device’s BARs in order to make it usable, right.
The only thing that gets into my head is that, once the whole thing is meant to work transparently to the target system, the “spying” device starts DMA transfers on its own initiative, i.e. without any instructions coming from the target machine and with all the logic being actually implemented by FPGA. If this is the case, then preventing this kind of attack by any software component that resides on the target machine itself may be “rather problematic”, so to say…
It’s a pure hardware attack (not just limited to games or whatever): you plug a board with an FPGA module into your
PCIe bus… it slurps all of memory, can then analyze its content, and plop back whatever it wants.
Apparently, I am just missing something, but how can a PCIe device start a DMA transfer from/to the machine it is plugged in if no one on this machine instructs it to do so? No matter how you look at it, you still need someone on your target system to program your device’s BARs in order to make it usable, right.
The only thing that gets into my head is that, once the whole thing is meant to work transparently to the target system, the “spying” device starts DMA transfers on its own initiative, i.e. without any instructions coming from the target machine and with all the logic being actually implemented by FPGA. If this is the case, then preventing this kind of attack by any software component that resides on the target machine itself may be “rather problematic”, so to say…
Anton Bassov
Did you watch the video whose link I provided? There have to be two machines. One target machine and the other is the attacking machine. The PCIe FPGA is have to be connected into two machines. The device is inserted into the target machine. The device also has a USB port. You connect one end of the USB cable to this USB port. The other end of the USB cable connects to the attacking machine.
without any instructions coming from the target machine and with all the logic being actually implemented by FPGA
See… you answered your own question.
This is a well-known attack vector. It’s nothing new, and it’s nothing specific to video games or cheats.
Let me expand on what I wrote earlier:
(Still ignoring the game/cheat space in which I have neither expertise nor any passing interest) This type of hack has generally been deemed “uninteresting” because it requires physical access to the machine… and to open it up and stuff a PCIe card inside. If you let people do that, well, good luck. All bets are off.
The only thing that has made this remotely interesting again is Thunderbolt: The fact that you could essentially plug-in a random PCIe device via an external connector and “have your way” with the machine. This opened the door to the possibility of somebody wandering into a vacant office, plugging in a device that makes a copy of everything in memory or implants a virus, and unplugging the device in – like – 10 seconds (or the time it takes Windows to recognize the device and make it active… which is considerably longer in the real-world… but go with it). Sooooo… Windows won’t enable such devices (a) if a user is not logged-in and active on the machine, (b) if the device’s access is not intermediated by an IOMMU.
preventing this kind of attack by any software component that resides on the target machine itself may be “rather problematic”
And THIS is why IOMMUs are used to prevent these sorts of things. The IOMMU is setup so that only memory ranges specifically setup/authorized by the host can be addressed by the device.
Did you watch the video whose link I provided? There have to be two machines. One target machine and the other
is the attacking machine. The PCIe FPGA is have to be connected into two machines. The device is inserted into the target machine.
The device also has a USB port. You connect one end of the USB cable to this USB port. The other end of the USB cable connects
to the attacking machine.
Well, we have already established this part right on the link provided in your original post …
What I am trying to understand now is how “target machine - spying board” interactions actually work at the low level from both machine’s and board’s perspective …
FPGA gets the requests from the attacker PC via USB, and these requests are, basically, identical to the ones that it would otherwise get from the host system via its BARs. Therefore, it can initiate DMA transaction without any involvement on the host’s part. However, a “small” question is still left.More on it below…
And THIS is why IOMMUs are used to prevent these sorts of things.
You seem to have just read my mind…
The only reason why I was not-so-sure about the whole thing is because of " how does the device know which memory ranges to access if it has no communication with the host OS whatsoever" question. Although this question may sound easy in itself, the possible presence of IOMMU adds another level of complication to the whole thing…
FPGA gets the requests from the attacker PC via USB
In this particular example, yes. But it could just generate such requests itself, as well, if it was smart enough. There could be an ancillary processor on the board with the FPGA as well, yes? Again… I’m ignoring the game/cheat thing, cuz… who cares.
Although this question may sound easy in itself, the possible presence of IOMMU adds another level of complication to the whole thing
Right. And “by design”… right?
Without an IOMMU simple: Device starts slurping memory at PA 0 until the end of memory is reached. Job is done.
With an IOMMU not so simple: Device has no clue what PA (actually Device Bus Logical Address) to use, because it doesn’t know what mappings the host has enabled. Sooooo… it tries to slurp starting at 0 and this is not allowed, cuz it’s not within the IOMMU-mapped range. So… IOMMU good.