Sharp Edges GAME SECURITY NOTES

Why PC Anti-Cheat Thinking Doesn't Transfer to Mobile

2026-09-16 09:55 Game Security #Mobile Game Security #Reverse Engineering #Runtime Protection

Imagine a developer who spent five years on a PC shooter joining a mobile team and asking where the kernel driver goes. It is a reasonable question from someone whose last project shipped with Easy Anti-Cheat or BattlEye loading at boot. The answer — there is no equivalent kernel-driver path for an ordinary Android app — usually arrives without much explanation of why, which leaves the impression that mobile is simply behind.

That impression leads somewhere unproductive. A team that believes mobile lacks a capability PC has will spend its effort looking for the closest available substitute, and will treat whatever it finds as a compromise rather than as a design constraint worth planning around.

Here, “PC anti-cheat” refers primarily to the Windows kernel-driver model common in PC games, while Android is the worked example because its application and kernel boundaries are unusually well documented in public platform material. The broader point is about carrying that Windows model into mobile environments whose privilege boundaries are set by the platform.

Kernel access is not something an application brings with it on either platform. Windows permits kernel-mode drivers under platform-defined conditions, while Android does not provide an equivalent path to ordinary third-party applications. The comparison turns on where each platform draws the privilege boundary and how access to it is governed, not whether one of them has a capability the other is missing.

Getting that right changes the question a team asks. It stops being “how do we get kernel-level detection on Android” and becomes “how much confidence does this particular judgment need, and where does the platform let me produce it.”

What PC Anti-Cheat Actually Gets

Kernel-level anti-cheat runs in Ring 0. Games, launchers, and ordinary applications run in Ring 3, the user mode ring. From Ring 0, software can observe low-level system calls, driver activity, and memory interactions that a user-mode process cannot reach.

For this comparison, the important difference is privilege rather than an inherently “smarter” detection model. Kernel-mode software runs from a position where more system activity is visible than it is to an ordinary user-mode process.

This layer has been covered thoroughly elsewhere and does not need another treatment here. What matters for a mobile team is the next question, which gets asked much less often.

That Capability Is Granted, and the Terms Are Tightening

Where does a PC anti-cheat driver's privilege come from? Not from the driver. Microsoft's documentation is direct about it: starting with Windows 10 version 1607 , Windows will not load any new kernel-mode driver that is not signed through the Dev Portal, and since Windows 10 and Windows Server 2016 kernel-mode drivers must be signed by the Windows Hardware Dev Center Dashboard, a process that requires an extended validation certificate.

A company that wants to ship a kernel driver has to be admitted. It needs an EV certificate, a registered Hardware Dev Center account, and a submission that passes. The privilege exists because Windows extends it under conditions Microsoft sets.

Those conditions have been tightening, including very recently. Windows previously trusted drivers signed through the cross-signing program. That program has expired, and Microsoft began phasing out default trust for those drivers with the April 2026 security updates . The policy starts in evaluation mode: the kernel monitors and audits driver loading before enforcement is activated, while an explicit allowlist preserves trust for a small number of widely used, reputable cross-signed drivers. The change applies to Windows 11 versions 24H2, 25H2, and 26H1, and Windows Server 2025. For systems covered by the April 2026 driver policy, the Windows Hardware Compatibility Program (WHCP) is the standard trusted path for new kernel drivers; its support documentation describes how Code Integrity records diagnostic data and event log entries as the policy is evaluated and enforced.

Read that as what it is. Windows permits kernel-mode drivers under platform-defined conditions, and Microsoft is tightening one previously accepted trust path for signed drivers already in the field. In this part of Windows driver policy, the direction is toward tighter admission and trust requirements for Ring 0, not broader access.

Which reframes the comparison with mobile. Windows permits kernel-mode drivers under platform-defined conditions. Android, used here as the mobile worked example, does not provide an equivalent vendor-controlled kernel-driver path to ordinary third-party applications. The useful comparison is therefore not “capable” versus “limited,” but where each platform draws the privilege boundary and how access to it is governed.

Why Android Draws the Privilege Boundary Differently

Android's constraints on applications are documented by the people who designed them. The Android Platform Security Model, written by Android security team members with academic collaborators, lists the attack-surface reductions that shaped what an app can reach.

Three of them matter for this discussion. SELinux restrictions on the ioctl system call were introduced because 59% of all app-reachable kernel vulnerabilities came through ioctl(), and the restrictions limit how far a potential kernel vulnerability can be reached from user space. App access to debugfs was removed, accounting for 9% of app-reachable kernel vulnerabilities. And all apps run under a seccomp filter intended to reduce kernel attack surface — the paper notes that seccomp complements SELinux policy at a different granularity of system call.

Those changes were introduced to shrink the kernel attack surface reachable from applications. They were not anti-cheat measures. An anti-cheat SDK is subject to the same application boundaries because those platform controls apply to application code as a category.

That is the turn worth sitting with. On Android, the mechanisms that limit what app-side security code can observe are also mechanisms the platform uses to reduce the kernel attack surface reachable from applications. Broadly reopening those kernel interfaces to application code would weaken the same isolation mechanisms that reduce kernel attack surface.

Comparison of Windows and Android privilege boundaries for anti-cheat and application security.

Figure 1. Where each platform draws the privilege line

What Can Still Be Observed Under Those Constraints

None of that leaves an Android team with nothing. It leaves them with a smaller and differently shaped observation surface, which is worth describing accurately rather than treating as a shortfall.

An earlier article here worked through what an in-process check can and cannot observe when it runs in an address space the attacker controls. The conclusion there applies directly: a check running inside the game process observes a describable class of operations, and the useful output is a boundary statement rather than a verdict about whether it works.

On Android, a normal third-party app has no vendor-controlled kernel-mode rung to move the check into. For vendor-controlled on-device checks, that constraint is not simply another stage in an escalation path — it is effectively the floor. That is why describing the observation surface precisely matters more here than it does on PC.

Platform Constraints Decide Where Judgments Can Live

The practical consequence is about placement. Some judgments need more confidence than an in-process signal can supply. For an ordinary third-party Android app, there is no vendor-controlled privileged local position to move them to, so those decisions may need to move off the client.

That is the territory an earlier article mapped out — which security responsibilities can be met on the device and which require something outside it. The point to carry forward here is narrower than that model: the platform is what determines the menu. Android's application-to-kernel boundary is upstream of many architectural choices an Android team makes about where a judgment gets produced.

Ring 0 Is Not the Floor

There is a symmetrical error to avoid, and it is the one a PC-experienced developer is most likely to make: treating Ring 0 as the bottom of the stack, where the argument stops. It is an easy assumption to carry, because on Windows the kernel is where the escalation has historically ended.

The April 2026 driver change is one reason not to. A driver-signing trust path that the platform can deprecate is not a permanent architectural guarantee. Any architecture built on the assumption that today's driver admission and trust terms will remain unchanged has an unpriced dependency in it.

Research points at the same conclusion from a different direction. In a February 2025 paper, Panicos Karkallis and Jorge Blasco Alís described cheats built on virtual machine introspection, showing how direct memory and interrupt access to a guest operating system lets a cheat bypass both user-level and kernel-level anti-cheat. They implemented the approach against Team Fortress 2, BlackSquad, and Fortnite, which together ship five different anti-cheat systems, and state — with the qualifier their paper uses — that to the best of their knowledge theirs is the first work demonstrating virtual machine introspection used for game cheating.

One academic implementation cannot establish how common this is in the wild, and it should not be read as a rate. What it establishes is structural: an observer positioned below the kernel sees the kernel's activity the way a kernel driver sees a user-mode process. Move the observation point down a level and there is another level beneath it. The relevant question is not simply how deep a check runs, but how much the platform will let it see, and what the answer is worth.

What to Reconsider When Moving From PC to Mobile

A team carrying PC habits into a mobile project usually starts by looking for tooling. The more productive starting point is a different question, asked per judgment rather than per product.

For any given decision — is this client modified, is this purchase legitimate, is this score real — the question is how much confidence the decision requires before it is acted on, and where the platform permits that confidence to be produced. Some judgments are fine with a client-side signal that raises the cost of a common attack. Others affect other players or real money and need to be resolved somewhere the client cannot rewrite the answer.

On PC, a team may be able to respond to some user-mode blind spots by moving checks into a kernel driver. On Android, that escalation path is unavailable to ordinary applications, making the mismatch especially visible. The broader lesson for mobile is not to search for a one-for-one replacement for each layer of the PC anti-cheat stack. Start instead with the privilege boundary the target platform actually exposes, then decide where each judgment can be made with enough confidence.

References

← Back to list