Rilevazione o prevenzione delle iniezioni di memoria del processo su Windows (anti-hack)

Ooooohh, adoro domande come questa.

A destra, in primo piano:

we are hosting a game server

Bam, eccoti. Se il client deve inviare l'aggiornamento di stato al server di gioco prima che questo venga trasferito ad altri client, si ha la possibilità di analizzare lo stato del gioco per le modifiche. Ciò significa che è possibile rilevare i modelli anomali. Ad esempio, se all'improvviso vedi un enorme cambiamento di valore in oro, puoi chiudere l'utente fuori dal gioco.

Ci sono molti approcci statistici che puoi adottare. A parte l'ovvio "cambiamento enorme" o "azione impossibile", puoi applicare più soluzioni a lungo termine - come l'oro nel tempo. Supponendo che io conosca il trucco "non aggiungere ingenti quantità di oro al mio personaggio" potrei incrementare l'oro in quantità sicure nel tempo. Ottimo, se spingo sempre il limite. Tuttavia, quell'aumento costante non sarà correlato all'oro equivalente guadagnato in un gameplay coerente, quindi ... di nuovo, rileva e chiudi l'account.

La chiave qui è che queste sono cose che puoi fare sul lato server di cui l'utente finale non può fare nulla, anche se hanno manipolato lo stato del gioco.

Ora, sulle tue domande lato Win32. Innanzitutto, non penso che WriteProcessMemory sia una chiamata particolarmente valida per qualsiasi DLL, fatta eccezione per i debugger (che sostituiranno le istruzioni nel codice - questo è il modo in cui i breakpoint impostati dai debugger funzionano), tuttavia, non c'è modo puoi sostituirlo in modo affidabile per ogni chiamata sul sistema senza scrivere quello che è effettivamente un rootkit, vale a dire che influenzerai tutti, non solo te stesso. Quindi questa non è davvero un'opzione.

Una cosa che potresti fare - e non è un'impresa da poco - è controllare periodicamente la tua memoria eseguibile per le modifiche. Per ulteriori informazioni, consultare Codice di manomissione / autoprotezione sulla codeproject. Fondamentalmente, invoca periodicamente questo e blocca il gioco se rilevi eventuali modifiche.

Potresti anche considerare la firma del codice - non è ridicolmente costoso e fornisce un sistema integrato in Windows per impedire modifiche eseguibili offline.

Se memorizzi lo stato salvato localmente, potresti prendere in considerazione il salvataggio dei checksum e inviarli agli account del tuo server. No, questo non è a prova di proiettile, ma aggiunge ulteriore complessità.

Se hai intenzione di implementare una di queste funzionalità, dovrai alzare un po 'la barriera e rendere difficile la disattivazione, il salto o il funzionamento dei meccanismi di protezione da parte del cracker. Cerchiamo di essere chiari: se qualcuno è determinato abbastanza, hai finito, ma puoi almeno rendere le loro vite molto dolorose.

Il top articule per il reverse engineering sul mio elenco di letture è anche dal codice progetto . La guida è molto approfondita e dovrebbe darti una base eccellente in ciò che puoi fare per confondere e altrimenti disturbare i debugger. Passerò attraverso uno di essi, che penso sia fantastico:

 SetUnhandledExceptionFilter(UnhandledExcepFilter);
 __asm{xor eax, eax}
 __asm{div eax}

Questo è male. Fondamentalmente, come spiega l'articolo, UnhandledExceptionHandler viene chiamato su un processo non di debug come gestore di ultima istanza; tuttavia, in questo caso cancelliamo deliberatamente eax , quindi dividiamo per zero. Ciò causerà un errore del processore, che il sistema operativo invia al gestore delle eccezioni dell'eseguibile, solo se è collegato un debugger. Se è collegato un debugger, il debugger viene notificato e l'eseguibile si chiude.

Ovviamente, è abbastanza facile per un utente malintenzionato sostituire div eax con una o più istruzioni nop o qualcosa del genere, il che significa che l'esecuzione si limiterà a scorrere, ma una piccola auto-verifica lo riprende abbastanza facilmente.

Quindi, in conclusione quindi:

• Il mio primo consiglio sarebbe quello di provare a rilevare cheat sul lato server. Qui, tieni tutte le chiavi. Potresti anche introdurre queste modifiche "oscure", cioè controllare e vedere chi sta barando, quindi analizzare i loro stati per vedere se funziona, senza interromperli.
• Quindi, proverei periodicamente la verifica di sé in diverse forme:
  • In memoria, per quanto sia affidabile, dell'eseguibile.
  • In memoria, per quanto sia affidabile, delle strutture dati critiche.
  • Anche l'eseguibile su disco.
• Infine, ho letto la guida alla reverse engineering dall'inizio alla fine e ho visto che cosa puoi applicare al tuo eseguibile. Mi rendo conto che hai detto che non puoi modificare il tuo eseguibile, ma onestamente, a meno che tu non lo faccia, è probabile che tu sia contrario. Dopo tutto, un secondo "processo di osservazione" può essere ucciso da un aggressore.