AntiCheat ClientSide Source

[fsck]

AD: Mt2009 - Mobile & PC - 30 January 2026 CHECK THE PRESENTATION!

A client-sided anti-cheat developed during a freelance project to "plug-in" to a proprietary client for a private server. Includes memory integrity checks, thread execution restrictions, hook detection, memory honeypots, and more.

*Memory Integrity Check​

Gathers a collection of memory pages initially within the game's module (anticheat::cheat_monitor::init) and generates a CRC32 hash based on the memory contents of each page (calc_vpt_hashes) - each validated every cycle (anticheat::cheat_monitor::check_pages).

*Thread Blocking​

Hooks RtlUserThreadStart and checks if the designated address of execution for the thread is within the correct memory bounds. In this case, it is called "image-only execution", where only threads within the primary image (and some other excluded images such as ucrtbased.dll) are allowed to have threads run. If a thread is running outside of these bounds then it is detected as malicious inside an invalid execution space. This also prevents debuggers from attaching the process since RtlUserThreadStart is executed before DbgUiRemoteBreakIn is called which executes outside of the secure boundaries.

*Memory Honeypots​

Memory honeypots are created within the init routine, where memory pages aren't yet accessed, but when they are (which they shouldn't be), it is detected. Prevents "cheat" scanners.

*Anti-Debugging​

Checks the PEB directly (instead of using IsDebuggerPresent, which can be easily looked up) for the value of the BeingDebugged flag as well as the value of NtGlobalFlag. Prone to just directly modifying the BeingDebugged flag to bypass this check though. DbgUiRemoteBreakIn is blocked because debug threads can't be executed in the process (DebugActiveProcess executes a thread within the process, but our process has memory bounds checking, simplified when thread scanning is mentioned.)

TBA: Arbitrary Vectored Exception Handling Detection

*Protected Functions​

Similar in concept to a memory integrity check, but specifically detects if Winsock routines designated as "protected" are hooked/modified, preventing user-mode packet modification and reading by software such as WPE Pro and rPE.

*Process Scanner​

Scans each process based on the contents (process name, window name) and unique memory signature.

*Module Scanner​

Scans the loaded modules in the process for any with blacklisted names.

Download

[Hidden content]

t

 

[khuffash]

ty

 

[pask2412]

Un anti-cheat lato client sviluppato durante un progetto freelance per "collegarsi" a un client proprietario per un server privato. Include controlli dell'integrità della memoria, restrizioni sull'esecuzione dei thread, rilevamento degli hook, honeypot di memoria e altro ancora.

*Controllo dell'integrità della memoria​

Raccoglie inizialmente una raccolta di pagine di memoria all'interno del modulo del gioco (anticheat::cheat_monitor::init) e genera un hash CRC32 basato sul contenuto di memoria di ciascuna pagina (calc_vpt_hashes) - ciascuna convalidata ad ogni ciclo (anticheat::cheat_monitor::check_pages) .

*Blocco del thread​

Esegue l'hook di RtlUserThreadStart e controlla se l'indirizzo di esecuzione designato per il thread rientra nei limiti di memoria corretti. In questo caso, si parla di "esecuzione di sola immagine", in cui solo i thread all'interno dell'immagine primaria (e alcune altre immagini escluse come ucrtbased.dll) possono eseguire i thread. Se un thread è in esecuzione al di fuori di questi limiti, viene rilevato come dannoso all'interno di uno spazio di esecuzione non valido. Ciò impedisce inoltre ai debugger di allegare il processo poiché RtlUserThreadStart viene eseguito prima che venga chiamato DbgUiRemoteBreakIn che viene eseguito all'esterno dei limiti sicuri.

*Honeypot di memoria​

Gli honeypot di memoria vengono creati all'interno della routine di init, dove non è ancora stato effettuato l'accesso alle pagine di memoria, ma quando lo sono (cosa che non dovrebbero essere), vengono rilevate. Previene gli scanner "cheat".

*Anti-debug​

Controlla direttamente il PEB (invece di utilizzare IsDebuggerPresent, che può essere facilmente cercato) per il valore del flag BeingDebugged nonché per il valore di NtGlobalFlag. Tuttavia è incline a modificare direttamente il flag BeingDebugged per ignorare questo controllo. DbgUiRemoteBreakIn è bloccato perché i thread di debug non possono essere eseguiti nel processo (DebugActiveProcess esegue un thread all'interno del processo, ma il nostro processo dispone di un controllo dei limiti di memoria, semplificato quando viene menzionata la scansione dei thread).

Da definire: rilevamento della gestione delle eccezioni vettoriali arbitrarie

*Funzioni protette​

Simile nel concetto a un controllo dell'integrità della memoria, ma rileva specificamente se le routine Winsock designate come "protette" vengono agganciate/modificate, impedendo la modifica dei pacchetti in modalità utente e la lettura da parte di software come WPE Pro e rPE.

*Scanner di processo​

Esegue la scansione di ciascun processo in base al contenuto (nome del processo, nome della finestra) e alla firma della memoria univoca.

*Scansione moduli​

Esegue la scansione dei moduli caricati nel processo per individuare eventuali nomi nella lista nera.

Scaricamento

[Contenuto nascosto]

Ty

 

[DeaddVader]

thx

 

[RMS]

nice