Anti Cheat Engine

[helgew]

Genau an dieser Stelle bin ich dann überfragt. Ich weiß, dass es Callbacks gibt für Dateizugriff und Programmstarts - dass es jedoch welche geben soll, die Prozeduraufrufe überwachen, glaub ich nicht, da so etwas von grundauf nie beabsichtigt war unter Windows.

Man könnte vielleicht durch Anhebung der Zugriffsbeschränkungen auf den Spieleprozess für etwas weniger Angreifbarkeit sorgen, sodass das Cheatprogramm keinen Zugriff mehr bekommt. Die Geschichte mit den Handles ist nur eine Suche nach der "smoking gun", was man auch verpassen könnte und so nie eine Modifikation des Fremdprozesses feststellen wird.

Dazu kommt, dass ein Programm zu bestimmten Anlässen in seinem eigenen Heap herumlesen wird und dabei diese Prozeduraufrufe stattfinden. Wenn du so richtig hart bist, trägst du dein Programm als Systemdienst ein, überwachst jedes startende Programm, disassemblierst es und ersetzt den Kernel32-Aufruf auf WriteProcessMemory mit einer Umleitung auf eine eigene DLL, welche ihrerseits mit Kernel32 kommuniziert und nur beobachtet. An dieser Stelle kannst du dann im Falle eines Fremdzugriffes prüfen, ob der Zielprozess den Dateiname deines Spiels trägt ( bezüglich des Namens einfach nochmal nachfragen, da hab ich schon eine fertige Lösung ). Ja und danach musst du das ganze wieder parsen, linken und builden... eine echte Freude Du hast dir da was vorgenommen *g* (das umcompilieren ist aber die saubere Lösung, was Performance und Stabilität angeht )

PS:
Oh da fällt mir ein, dass jedes Programm zunächst einmal mit GetProcAddress die Einsprungadresse von WriteProcessMemory suchen muss, wenn es nicht nach Index importiert. Wenn du Glück hast (auch da weiß ich nicht alles) sind die Einsprungadressen absolut ( die Module Handles sind auch in Wirklichkeit Pointer, sehr wahrscheinlich absolut (Nachgeschaut:

>task -modulesofp 2572
This process has 69 modules
7C910000 : C:\WINDOWS\system32\ntdll.dll
7C800000 : C:\WINDOWS\system32\kernel32.dll
77180000 : \Device\HarddiskVolume7\WINDOWS\system32\wininet.d ll
77DA0000 : C:\WINDOWS\system32\advapi32.dll
77E50000 : C:\WINDOWS\system32\RPCRT4.dll
...
>task -modulesofp 3200
This process has 47 modules
7C910000 : C:\WINDOWS\system32\ntdll.dll
7C800000 : C:\WINDOWS\system32\kernel32.dll
773A0000 : C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144
ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll
77BE0000 : C:\WINDOWS\system32\msvcrt.dll
77DA0000 : C:\WINDOWS\system32\advapi32.dll
...

jap, wie du siehst ist bei verschiedenen Prozessen das Module-Handle für ntdll und kernel32 gleich und außerdem ein Adresszeiger) und daher kannst du danach im Variablenspeicherbereich eines Prozesses auf gut Glück nach der Einsprungadresse von WriteProcessMemory scannen)