Anti Cheat Engine

[napsterxx]

Moinsen,
ich wollte eine allgemeine Anti Cheat Engine (im kleinen Stil) programmieren. Sie soll wenn sie fertig ist und funktioniert dem User sage dass er gerade Cheatet. Die Engine soll nur für Games wie CS sein wo man mit einer DLL z.B. injezieren muss. Deshlab dachte ich überprüfe welche DLLs das Programm geladen hat und ob es die selben sind. Kann mir jemand einen kleinen Stubs in Richtung einer guten Lösung geben?^^

[himitsu]

Ein paar Probleme wirst du aber dennoch bekommen.

Es ist zwar möglich auszulesen welche DLLs eine EXE läd, aber welche DLLs diese DLLs wiederum laden weiß man damit nicht

und dann wird z.B. bei mir in "jedes" Programm eine DLL von meiner Maus injeziert.

es ist also garnicht so einfach zu entscheiden welche DLLs "nötig" sind und welche zweck's Cheat drin sind.

[Neotracer64]

Wie möchtest du prüfen ob die DLL legitim ist?
Es könnte sich zum Beispiel um DLLs von Third-Party Apps handeln. Extensions für Tastatur oder Maustreiber zum Beispiel.

Also musst du eine Whitelist erstellen. Das hat widerum den Nachteil, dass du viele False Positives detectest, und eine Blacklist natürlich, dass zu viele False Negatives erwischst.

Dazu kommt, dass es mittlerweise schon soweit ist, dass die meisten Cheats den PE-Header ihrer DLL wipen und sich aus den 3 Linked Module Listen austragen. So kannst du die DLL eigentlich nicht mehr finden, dann musst du auf Signaturen zurückgreifen als Blacklist... Du erkennst das Dilemma?

Um einen wirksamen Anticheat zu schreiben musst du schon tief in die HL-Engine gehen, so wie es das einzig "erfolgreiche" AC-Tool gemacht hat. (Cheating Death)
Und zwar heisst es hier nicht, den Cheat detecten, sondern verhindern, dass der Cheat überhaupt die Engine manipuliert. Prävention ist also viel geeigneter zur Bekämpfung.

//EDIT: slow ;)

[vlees91]

Hmmm. was macht VAC2 denn?
Ist das nicht auch direkt in der Engine? (Ja, der blockierts nicht, bannt aber nach ca. 2 wochen den account)

[PaddyL]

Und wieso sollte man nicht ohne DLL injecten können? Geht ganz simpel mit Threads. Wenn du nicht selbst Autor des Spiels bist kannst du es so ziemlich vergessen das richtig zu machen.

[Neotracer64]

Zitat:

VAC2 [...] Ist das nicht auch direkt in der Engine?

Nein. Es liest nur rum und checkt Code Integrität und sucht nach Blacklisted Signaturen von Cheats.

Man kann Cheats nicht für ein und allemal aufhalten, aber man kann es immer ein Stück weit schwieriger machen.

Zitat:

Wenn du nicht selbst Autor des Spiels bist kannst du es so ziemlich vergessen das richtig zu machen.

Wieso?
Das HL SDK sollte übrigens alles vereinfachen. ;)

[vlees91]

Und ausserdem muss es ja irgendwann moeglich sein, dass es ein Computer schafft so zu spielen wie ein Mensch, und das ganze ueber einen externen Computer funktioniert der per WebCam (haha) das Spiel sieht und mit nem Robotarm die Maus und Tastatur bedient. :drunken:

[napsterxx]

Uff also gibt es kein wirkliches Kochrezept, um das zu lösen. Und was für möglichkeiten gäbe es noch neben dem AC die relativ sicher sind?

[himitsu]

Zitat:

Zitat von vlees91

und das ganze ueber einen externen Computer funktioniert der per WebCam (haha) das Spiel sieht und mit nem Robotarm die Maus und Tastatur bedient. :drunken:

ala VM 'ne virtuelle Maus/Tastatur/Monitor

[PaddyL]

Zitat:

Zitat von Neotracer64

Das HL SDK sollte übrigens alles vereinfachen. ;)

Hast du es dir auch ganz genau angesehen? Das HL SDK ist ein Template für DLL Files zum Erstellen von HL(2) Mods, nicht mehr und nicht weniger als vollkommen eigenständigen (sprich von anderen Mos - etwa CS(S) unabhängigen) Mods.

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

[napsterxx]

ja da ist nur ein Problem :D Der Dienst ist nun gestartet aber ich habe keine Ahnung wie OnExecute ausgeführt werden soll.

[sx2008]

Anti Cheat Engine scheint mir vom Namen her unpassend.
Eine Engine ist doch im Bereich Software eine Bibliothek, die etwas bewegt
wie z.B. Erzeugen von 3D Grafik oder Verwalten, Bewegen und Darstellen von Sprites.
Anti Cheat Massnahmen bewegen nichts und sind nicht aktiv oder produktiv an einem Spiel beteiligt.

[napsterxx]

Da nimmts aber einer ganz genau :stupid:
Dann ist es ein AntiCheat Programm :D
Trotzdem bleibt das Problem mit OnExecute^^

[fr4gz]

hi napsterxxi
Ich versuch auch schon die ganze zeit eine kleine Detection für mein anticheat tool zu programmieren.
deshalb die frage.. wie genau hast du das mit den Read/WriteProcessMemory gelöst .. ich komm da einfach nicht weiter

vl kannst du mir ja ein paar tipps geben :)

lg

[BullsEye]

Aha, sind wir jetzt alle hier auf einem AntiCheat Trip?! Wird ja immer schlimmer :sure:

Naja Spaß beiseite. Wenn ihr beide schon an sowas bastelt, warum tut ihr euch nicht einfach mal zusammen? Ich denke ihr könntet eure Erfahrungen etc austauschen und dann wird das Projekt sicherlich auch erfolgreicher ;)