Anti Cheat Engine

[Neotracer64]

Wer braucht den gesamten Sourcecode?
Kennst du den Multihack OGC? Was da alles implementiert worden ist?
Ein AC mit dieser Komplexität, wie es ungefähr Cheating Death geschafft hat, wäre schon ziemlich nützlich.

Alle zusätzliche Informationen über das SDK hinaus bekommt man durch Reverse Engineering. Alles was mit gesamten Sourcecode möglich ist, lässt sich (natürlich mit längerer Entwicklungsphase) auch so realisieren.

Man könnte die wichtigsten Engine Functions wrappen, Security Cookies/Prologs einbauen, die Engine teilweise relocaten und schon würden alle bisherigen Cheats unbrauchbar. (OpenGL Wrapper/Hooker müsste man anders begegnen)
Alle weiteren Features, die man dann noch einbaut (Obfuscation, trusted Communication mit einem Server Counterpart, Code Integrity Checks) machen es Cheatcodern das Leben etwas schwieriger gezielt einen Hack gegen dieses AC zu schreiben.

[napsterxx]

... Man oh man dachte das wäre wesentlich leichter... denke ich verscheibe das doch noch ein wenig ^^

[napsterxx]

OK also ich hatte das Projekt ersteimal verworfen gehabt, möchte es nun aber neu angehen. Ich sehe ein, zu detecten ob ein Cheat benutzt wurde ist wohl sehr schwer bis nahezu unmöglich :D Deshalbb möchte ich auf diese Detection eingehen bevor etwas manipuliert wurde. D.h. ich müsste alle laufenden exe dateien scannen mit einer art "Anti (Virus) Cheat" Programm :D oder sowas.

[helgew]

Schau mal welche Module bei den einzelnen Prozessen geladen sind und welche handles sie offen haben.
Ersteres geht mit psAPI.EnumProcessModules letzteres geht mit NtQuerySystemInformation und Strukturen vom Typ SYSTEM_HANDLE_INFORMATION.
Immer auch gut zu wissen ist, mit welchen Rechten Programme laufen, siehe LookupPrivilegeValue.
Schlimme Dinge geschehen erst, wenn ReadProcessMemory mit einem fremden Process-Handle aufgerufen wird ( sodass ein Cheatprogramm in fremden Prozessen lesen kann ).
Das zu verhindern wird wohl mit einem Debugging sämtlicher Prozesse verbunden sein, da es wohl kein Callback gibt, mit dem man diese Funktion überwachen könnte.
So wirst du also jetztlich bei einem heuristischen Scanner landen, der nach solchen Prodzeduraufrufen sucht (die Funktion sitzt in Kernel32.dll, lässt sich also nicht einfach so ersetzen) oder du überwachst permanent, ob irgendein Prozess den Spieleprozess öffnet, dazu lassen sich vielleicht die Object oder ObjectTypeNumber verwenden. Viel Erfolg :thumb:

[napsterxx]

Hey danke :dp:
Das war wirklich eine 1A :warn: Antwort :D
Nun noch eine etwas dümmliche Frage, man könnte ja fast denken diese ist retorisch gemeint :S
Also könnte man auch so machen das man überprüft welches Programm die ReadProcessMemory oder WriteProcessMemory startet bzw. benutzen möchte, und dies über einen Hook dann unterbinden?

[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)

[napsterxx]

Und damit hätte ich das Programm welches diese Prozedur verwendet :D

Also kurz zu meinem Vorhaben, es könnte sein dass daruch alles etwas eindeutiger wird. Also ich bin dabei ein kleines "Ligen" System aufzubauen - Jetzt bitte nicht mir der ESL vergleichen :D - und habe eben auch Regeln.

Zum Beispiel:
Keine Modifikationen dürfen benutzt werden
Keine anderen Hilfsprogramme außer den erlaubten

Dadurc hätte ich eigentlich alle DLLs die auf das Spiel zugreifen dürften, und somit ist klar wenn ich eine andere finde das eine DLL injiziert wurde. Oder nicht? :idea:

Bleibt noch die Möglichkeit via Memory Patching sich unfaire Vorteile zu verschaffen. Da könnte ich entweder per Hook, sofern dies funktioniert zugreifen, oder alle anderen aktuell laufenden Programme auf zugriff zu dieser Adresse/Prozedur überprüfen.
Dadurch wäre eigentlich ein recht breites Spektrum des Cheatens abgedeckt :D - gkaube ich

Nachteil, der Anwender dürfte keine anderen Programme als das Spiel, und erlaubte Hilfsprogramme laufen haben :D

Zitat:

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

Diese Methode finde ich sehr schön, jedoch weis ich nicht wie ich ein Programm als Systemdienst starten kann (ich werde mal suchen) und welche Vorteile ich erziele und wie ich dann weiter machen kann.
Wäre schön, wenn der ein oder andere mir da ein paar genauere Informationen geben könnte :D

[helgew]

Zitat:

Nachteil, der Anwender dürfte keine anderen Programme als das Spiel, und erlaubte Hilfsprogramme laufen haben

bei allen diskutierten Lösungsansätzen sehe ich das Problem eben gerade nicht. die Codemodifikation mit der WriteProcessMemory-DLL läuft völlig autonom und störungsfrei, auch Heapüberwachung und Handle-Monitoring sowie Überwachung der Module ist absolut nicht restriktiv, da ja noch weiter nach Kriterien geprüft wird.
Gefordert ist ja wie ich das sehe sowieso, dass das Anti-Cheat-Programm zu beliebigem Zeitpunkt gestartet werden kann und von da an funktioniert.

[napsterxx]

Das Anti-Cheat Programm ist dann an wenn auch mein kleines Liga Programm gestartet ist. Ich habe es derzeit so gemacht:
In alle Programme (das muss ich noch verbessern - überprüfen ob Read/WriteProcessMemory benutzt werden soll) wird meine DLL injiziert. Diese Hookt dann die Read und WriteprocessMemory Prozedur. Wenn die angegebene PID (ProcessID) nicht dsa angegebene Spiel ist wirt Read/WriteMemoryProcess ausgeführt ansonsten passiert gar nichts. An dieser Stelle besteht natürlich die Möglichkeit auch eine Message auszugeben das ein verdächtiges Programm entdeckt wurde.

Problem: XFire hookt auch die Spiele für Ingame Chat und liest auch Adressen aus - von daher müsste ich eine Whitelist erstellen. Mit dem Systemservice klappt noch nicht ganz, ich habe schon ein Tutorial gelesen, jedoch gibt es bei meinem Delphi leider nicht die Funktion "Neu > Systemservice " oder eben wie das genau hieß.

Mit den DLLs die ein Programm geladen hat mache ich es derzeit so:
Ich überprüfe ob einfach eine andere geladen wurde - wenn ja gibts wieder eine Meldung.

Frage: Wie kann ich einen Systemdienst unter Delphi 2005 Personal erstellen?

[helgew]

Zitat:

Wie kann ich einen Systemdienst unter Delphi 2005 Personal erstellen?

Diese Frage wird dem Threadopener hier beantwortet.