UltimateAntiCheat — integrity attestation fork (archived)

A derivative of AlSch092/UltimateAnticheat, extended with client integrity attestation, a keyed transport, and a server that manages detections instead of only receiving them.

Archived on purpose. Work stopped in August 2025 and the machine it ran on is gone. Nothing here is maintained, and none of it has been built or tested since. It is published as a record of what was done, and because AGPL-3.0 is the licence it was always under.

The default branch is mie-modifiche. That is the complete work; main is only the copy it started from.

Attribution

This is not a GitHub fork, so no lineage banner appears above. To be explicit: the anti-cheat engine, the detection framework, the anti-debug and anti-tamper machinery and the original project design are AlSch092's work. Everything listed under What this adds is mine, built on top.

Licensed AGPL-3.0, same as upstream. The original LICENSE and copyright are unchanged.

The idea

A client cannot be trusted to judge itself. Whatever checks it runs, a patched client reports that everything is fine, and a verdict computed on the attacker's machine is worth nothing. So the split here is that the client reports evidence and the server decides what the evidence means.

That single choice is what the rest follows from. The client sends hashes of its own modules rather than a pass/fail, and the expected values live on the server, where they can't be read or edited by whoever owns the machine. The process blacklist is distributed at runtime instead of compiled in, so the client never carries the list of what it's looking for, and the list can change without shipping a new build. Detections are persisted rather than only acted on, because the interesting signal is usually a pattern across sessions, not a single hit.

The transport is XOR with a shared key, and it's worth being precise about what that is: it raises the cost of casually reading or replaying the protocol. It is not confidentiality, and it was never meant to be. Anyone determined and local gets the key out of the binary.

None of this makes a usermode anti-cheat unbeatable, which nothing does. It moves the decision to the one place the attacker doesn't control.

What this adds

Upstream ships a free client with a server that is essentially a stub. The commercial value in that project sits on the server side, and this fork builds that side out.

Area	What this adds
Client integrity attestation	The client reports SHA-256 hashes of its own modules; the server checks them against an expected set instead of trusting the client's verdict. The hash table and the key are regenerated by post-build scripts on every build, never maintained by hand. Common/SHA256Utils.*, Common/sha256_hashes.hpp, Network/ExpectedHashes.cs, script/sha256_hashes.ps1, script/ExportAndCopyXorKey.ps1
Keyed transport, both ends	A shared XOR key applied symmetrically on the C++ client and the C# server, with the key generated out of band rather than compiled in. Common/XorKey.*, Network/XorKey.cs
Server-side management	Process blacklists distributed from the server instead of baked into the binary, detections persisted to SQL, and a TCP proxy in front of the listener. Network/BlacklistManager.cs, Network/DatabaseLogger.cs, Network/TcpProxy.cs
Client API layer	A separate surface between the anti-cheat core and its callers, which upstream does not have. API/API.*
Patch distribution	Client and hash-table updates are built and shipped as signed, hash-verified patches by a standalone tool from a companion project, not maintained here. script/Duff-tool/ — source in shaiya-updater (Updater.Tool/DuffToolCli).

Beyond those, most of the client was reworked: of 208 files, 27 are still identical to upstream.

Related

Same Shaiya toolchain as PSM_Cmd-SecureCommandChannel — same author, same period, no code shared between them.

State

Built against upstream as of early August 2025 — the last upstream commit before this fork stopped is 009451f (7 Aug 2025).

Upstream reorganised its tree into Core/ and Common/ on 30 August 2025, three weeks later, so file paths here do not line up with current upstream. Nothing was carried over after that point.

Toolchain at the time: Visual Studio 17 2022, C++ client on Windows x64, .NET Framework 4.7.2 server. Whether any of it still builds today is untested. The build steps that were in use are kept in BUILD-NOTES.md.

Branches

Branch	Contents
mie-modifiche	The full work: modified client plus the C# server. Default branch.
Backup-mie-modifiche	Snapshot taken before a sync, kept as-is.
main	The copy this started from, already carrying local build changes. Not a clean upstream mirror.
shaiya_client	Trimmed client build for one deployment.
shaiya_server	The server on its own, with no shared history.

Keys and configuration values in the tree belong to a test environment that no longer exists.

If you want to use this

Take upstream instead. It is actively maintained, it has moved on considerably, and it is the project that deserves the stars. What is worth reading here is the server-side design: what a client can be asked to prove about itself, and why the server has to be the one holding the answer.