Exploiting System Management Mode (SMM) for Undetectable Game Cheats

This is not the first time that I have presented something SMM-related on this blog. For more information about SMM in general, please check out the older blog post from 2022 over here!

Introduction: Sounds from the Basement

Game cheating is an ever-evolving industry, continuously trying to stay a couple of steps ahead of anti-cheat developers. I recently held a talk about a new way of cheating in video games in a Finnish hacker conference “Disobey” (something similar to BlackHat and DEFCON, just in Finland and not quite as hc ). In the talk, we explored leveraging System Management Mode (SMM) — the high-privileged execution mode within modern x86_64 CPUs — to run game cheats entirely outside the reach of conventional detection methods. Today we are releasing this cheat - extended to be a complete cheat framework - as open-source.

This post will break down the core ideas from the talk and discuss how SMM can be abused for game cheating, why it is so effective, and what security professionals can do about it. The post also introduces the main idea and architecture of our Plouton framework.

If you are one of those “talk is cheap, show me the code!” -guys, and don’t want to read along, you can find the project from Github.

Understanding System Management Mode (SMM)

SMM is a special execution mode in x86_64 processor architectures, originally intended for firmware-level operations such as power management and hardware control. Unlike standard user-mode applications (ring 3), kernel-level code (ring 0), or even hypervisors (ring -1), SMM runs in ring -2, an isolated environment invisible to the operating system. Since it operates below all traditional anti cheats (ring0, maybe in future they might invade the hypervisor too?), it should be well-undetected from them. Again, if you want to know more about SMM, its effectiveness and challenges, please see the old blog post.

Why SMM is the Perfect Environment for Cheats

• Completely Isolated Execution: Code running in SMM is invisible to normal system processes, including anti-cheat, antivirus software and even hypervisor.
• Full Memory Access: Since SMM has unrestricted access to system memory, it can access game data without requiring injection, kernel drivers or DMA devices.
• No Security Checks: Unlike modern kernel drivers that must be signed and verified, SMM code execution/module loading does not undergo such scrutiny. You can do whatever you want with your motherboard’s UEFI firmware. Attention: It is very easy to brick your device!

From Idea to a Working SMM Cheat

We set out a plan to create a fully functional game cheat leveraging SMM, going through the following development process:

1. Setting Up an SMM Development Environment

Since we required to modify the UEFI firmware image, where the SMM modules reside, we used the EDK II UEFI development kit to create and then replace an existing SMM module with our custom code. EDK II is de-facto standard UEFI implementation for commercial motherboard vendors, so building with it generates compatible code with most commercial firmwares. There are also other implementations, such as LibreBoot, that we are not targeting here.

2. Testing with “Hello World”

The first successful test was a simple “Hello World” program executed in SMM, proving that we could run our own code in SMM.

3. Memory Access & Game Interaction

With access to full system memory, the next step was figuring out how to read and modify game state information, such as player positions and health values, which are stored in memory as structured data. For this, we used the same base as the SMM rootkit, since it can read and parse Windows kernel structures and so on.

4. Implementing Cheat Features

We focused on two primary cheat functionalities:

• Aimbot: Aims on behalf of the player by modifying mouse input data.
• Sound ESP: Provides positional awareness of enemy players by modifying system sound output, allowing subtle cheating.

5. Overcoming Technical Challenges

Running a cheat in SMM presented several obstacles:

• Floating-Point Arithmetic: Since SMM does not initialize floating-point registers, custom fixed-point math libraries had to be used.
• Frequent Execution: Unlike traditional cheats that run continuously, SMM execution is event-driven. The solution? Triggering SMM execution through USB interrupts, effectively hijacking mouse and audio input/output in the process :-)

Intoducing Plouton

Plouton was the master of the underworld, and thus he was able to command the riches of the earth and the souls of the dead.

Plouton is the name of our System Management Mode (SMM) (ring-2, “underworld”) PC game cheat framework. You can find its source code and furher documentation here.

Completely in SMM

Plouton works completely in SMM. It doesn’t require usermode application or any component running in a higher privilege level than ring -2 (SMM). It interacts with the game by read / writing its memory by accessing it via physical memory space. For this, virtual-to-physical translations need to be done. This is achieved by finding and parsing the Windows’ NTKernel and its structures. From there we can find directory bases (PML4) for each usermode process. By parsing this information we can translate the memory addresses. To achieve cheating features, we intercept and modify raw USB packets of real hardware devices. This way we can emulate for example mouse movement and create a working aimbot.

Why framework?

Instead of releaseing just a PoC for a single game and single PC configuration, we decided to turn the project into an easily-extendable framework. The main objective of it is so that every user could implement “drivers” for their own USB devices. This is done by creating device drivers in the “hardware” section of the code. The end-user can also add their favorite games easily, making the framework also easily extendable to support more games. This can be done by implementing game parsing & cheating logic in the “targets” part of the code.

How Can SMM Cheats Be Detected?

Since SMM is so deeply embedded in system firmware, detecting cheats running in this environment is extremely difficult. However, researchers proposed several potential countermeasures:

1. Memory Honeypots

Anti-cheat systems could place fake entity data in memory to see if any process accesses them, potentially flagging suspicious behavior. By measuring CPU cache timing of these honeypot memory regions, anti-cheat software might be able to infer whether unexpected memory reads (originating from SMM, DMA or something else low-level) are occurring.

2. SPI Firmware Analysis

Dumping and analyzing the SPI NOR Flash memory that stores SMM modules could reveal unauthorized modifications.

While these techniques could help, none are foolproof, especially against highly sophisticated attackers.

Conclusion: The Future of Cheating and Anti-Cheat Warfare

With anti-cheat developers continuously improving their detection mechanisms, we think that cheat developers are forced to move into lower and more obscure CPU execution layers. The use of SMM for game cheating represents a major shift in sophistication, making it nearly impossible for current detection software to counter.

For security professionals and professional gaming community, the Plouton framework highlights the growing need for real and enforced hardware-level security measures and better firmware integrity validation.