Suche Tipps und Ansätze, um ein Anti-Cheat-Tool zu coden

Ich habe jetzt seit Wochen bereits im Internet nach guten Ansätzen gesucht. Ich bin seit einer Ewigkeit beim überlegen, wie ich diese Cheats zu fassen bekomme. Es ist dabei egal für welches Spiel. Ich habe alles getestet. Von einer Überwachung der Prozesse bis hin zu einer Überwachung der geladenen DLL-Spieldateien im laufenden Spieleprocess. Ich habe sogar versucht, die Festplatten zu durchsuchen (Was wohl am meisten Performance geschluckt hat). Aber nun bin ich verzweifelt.

Ich benötige Ideen und Ansätze sowie Tipps.

Ich möchte auch nicht, das man mich nun falsch versteht. Ich möchte keine Code-Snippets, es sei denn jemand möchte sie mir zur Verfügung stellen. mein Hauptinteresse sind Schlagwörter, Tipps, Lösungsansätze und vielleicht sogar den einen oder anderen Link mit Hilfsmaterial.

Das Anti-Cheat Tool ist für LAN's und vielleicht für die eine oder anderen Onlineliga gedacht.

Aktuell arbeite ich mich in C/C++ ein und bin auch dabei, mir ASM anzusehen. Aber selbst da scheitere ich schon. Ist so etwas gänzlich unmöglich mit C#, wobei es ja schon eingesetzte Software dieser Art in VB gibt? Muss ich wirklich alles in C/C++ coden oder sogar ganz auf ASM gehen? Gibt es ansonsten auch noch eine andere Programmiersprache für solche zwecke? Taugt vielleicht sogar PureBasic mit dem InlineASM dafür?

Mittlerweile macht es mich wirklich fertig, aber ich will dieses AC-Tool programmieren, da ich den Betrügern zumindest da wo ich administriere keine Chance geben will. Das ist mir absolut wichtig. Ich benötige nur Inspiration.

Vielleicht läuft hier ja in der Community der ein oder andere aus der Szene rum, der mir helfen kann und auch möchte.

*PS* - Ich habe ein Problem mit englischer Grammatik. Selbstverständlich bin ich über jeden Link, egal ob Deutsch oder Englisch dankbar. Ich warne nur vor, wenn ich englische Links bekomme, das für mich das lesen schwierig ist und daher das ganze etwas länger dauert, bis ich antworte ^^ Nur mal so nebenbei.

Hallo fullsizeDeveloper,

wenn ich dich richtig verstehe, dann willst du ein Programm schreiben, das andere Prozesse (Spiele) darauf hin überwacht, dass dort keine Cheats eingesetzt werden. Richtig? Ich denke, das sollte mit C# möglich sein, auch wenn du vermutlich viel Win32/DllImport verwenden musst.

Was die Ideen und Ansätze angeht, ist mir nicht ganz klar, ob es die mehr um generelle Konzepte oder mehr um Hinweise zur Umsetzung angeht. Wenn du z.B. schreibst "Überwachung der geladenen DLL-Spieldateien", was ist damit das Problem? Hast du diese Überwachung hinbekommen und suchst jetzt noch nach weiteren Prüfmöglichkeiten (z.B. Prüfung der ausführbaren Dateien des Spiels durch Hashs) oder suchst du nach Hinweise, wie du die "Überwachung der geladenen DLL-Spieldateien" realisieren kannst? Worum geht es dir also konkret?

herbivore

wenn es sich um Lan´s handelt, so kannst du aus dem aktuellen spiel alle dateien abgreifen und einen hash für jede datei bilden. Das selbe machst du für die geladenen dll´s (speicherabbild) und vergleichst diesen mit denen der anderen spieler. wenn es unterschiede gibt, dann cheatet jemand. wenn nicht, dann cheaten alle oder keiner.

Alles an Hinweisen ist für mich wichtig. Egal ob es nur generelle Konzepte sind oder bereits Umsetzungen, Also folgendes habe ich bereits getestet. Ich erkläre es mal am Spielprozess von HL2 (Counter-Strike Source).

Ich liste mir alle Dateien (DLL's etc.) auf, die an dem Prozess HL2 hängen. Da dies am Ende in einem Array steht, gehe ich die Dateien mit foreach durch und überprüfe diese mit Hashes. Bei einigen Hacks klappt das sogar gut. Ich muss das ganze allerdings etwas zuverlässiger machen, da eine etwas kenntlichere Person mit einem Hex-Editor im Cheat ein paar Strings ändern könnte, um somit die Dateien zu manipulieren. Und dann stimmen die Hashes wieder nicht.

Andere Cheats hängen sich wiederum nicht an das Spiel sondern Pflanzen sich wo anders ein. Wenn ich dann alle Prozesse und deren DLL's durchgehe, wird das allerdings nicht für eine gute Performance sprechen, da es im Spiel Laggs verursacht.

Als eigenständige Prozesse gibt es keine Hacks mehr wirklich. Somit ist die Prozessliste nichtssagend, da der Loader direkt nach der Einpflanzung der DLL verschwindet.

wenn es sich um Lan´s handelt, so kannst du aus dem aktuellen spiel alle dateien abgreifen und einen hash für jede datei bilden. Das selbe machst du für die geladenen dll´s (speicherabbild) und vergleichst diesen mit denen der anderen spieler. wenn es unterschiede gibt, dann cheatet jemand. wenn nicht, dann cheaten alle oder keiner.

Das verwirrt mich jetzt gerade. Redest du da nun genau von Netzwerkpaketen oder vom Arbeitsspeicher? Wenn es um das Netzwerk geht, dann muss ich passen, da ich in keinster Weise weiß, wie ich so etwas überwachen kann. Bezüglich des Arbeitsspeichers müsste ich ja wissen, wo sich die Hacks im RAM parken. Ich kann mir vorstellen, wenn ich den RAM sagen wir mal alá Heuristik durchsuche, das ich dann wieder ein Performanceproblem bekomme. Oder irre ich mich da vielleicht auch? Und wenn nicht, gibt es da vielleicht bestimmte Befehle in der API, mit denen das zu erledigen ist bzw. habt ihr einen Tip, wo ich danach suchen kann?

Du hast mich falsch verstanden. Du sollst dir nicht die Hashes aller dll´s aller Spiele merken und für die Prüfung verwenden... Das ist viel zu aufwändig...

Du sollst Hashes aus den geladenen Dll´s generieren und mit denen der anderen spielteilnehmern vergleichen. Bei unstimmigkeiten wurde definitiv manipuliert, da die spiele schon von sich aus auf Versionsgleichheit prüfen.

Andere Cheats hängen sich wiederum nicht an das Spiel sondern Pflanzen sich wo anders ein.

Wenn sie nicht das Spiel selbst manipulieren, dann sind es auch keine Cheats. Wenn sie das Spiel auf unerlaubte weise manipulieren, dann müssen sie per Dll-Injection arbeiten. Und das kann man ohne weiteres aufdecken.

Eine weitere möglichkeit bietet die manipulation oder den austausch bestehender Dll´s und das lässt sich mit der genannten Hash-Vergleichsmethode auch aufdecken.

Eine dritte möglicheit sind die Manipulation von z.b. Lua-Scripten usw... da wird es schwieriger, da du hier genau definieren musst, welche dateien für einen Hashvergleich relevant sind.

Du sollst Hashes aus den geladenen Dll´s generieren und mit denen der anderen spielteilnehmern vergleichen. Bei unstimmigkeiten wurde definitiv manipuliert, da die spiele schon von sich aus auf Versionsgleichheit prüfen.

Aaaachsooo ^^
Das ist genial. Mit einer guten Kommunikationsmethode würde das auch im Internet gehen. Das ist sehr gut und so Diabolisch wie auch Böse ^^
Sehr geile Idee. Vielen dank.

Wenn sie nicht das Spiel selbst manipulieren, dann sind es auch keine Cheats. Wenn sie das Spiel auf unerlaubte weise manipulieren, dann müssen sie per Dll-Injection arbeiten. Und das kann man ohne weiteres aufdecken.

Naja ... Cheats sind im allgemeinen in der Szene der Begriff für das Betrügen und somit werden auch Hacks dort Cheats genannt. Selbstverständlich geht es nicht auch, sondern überwiegend um Hacks. Aber wie genau kann man denn eine Injection aufdecken? Denn wenn die Datei nirgends auftaucht, kann ich ja schlecht geziehlt danach suchen. Dann müsste ich ja mit dem Ram arbeiten. Oder habe ich dich da jetzt wieder falsch verstanden? ^^

Ich bitte um Nachsicht. Bisher habe ich nur normale Tools geschrieben, die auch nur mit sich selber arbeiten und nicht andere Sachen überwachen. ^^

Müsste eine injecte'de DLL nicht unter den "geladenen Modulen" des Prozesses auftauchen? Nur ne wilde Vermutung, hab mich damit nicht explizit außeinandergesetzt ^^

foreach (System.Diagnostics.Process process in System.Diagnostics.Process.GetProcesses())
            {
                try
                {
                    foreach (System.Diagnostics.ProcessModule module in process.Modules)
                    {
                        MessageBox.Show(process.ProcessName + ": " + module.ModuleName);
                    }
                }
                catch (Exception ex)
                {
                    MessageBox.Show(ex.ToString());   
                }
            }

Kleiner Tipp am Rande:
Bei Spielen wie z.B. CS werden Cheats / Hacks im Ring 0 (Sprich Kernelmode) gestartet.... das verhindert herkömmlichen Scanprogrammen (wie z.B. in der Theorie auch das von Blizzard geladene Warden) auf den Prozess zuzugreifen, da die Rechte dazu nicht ausreichen. (Siehe den oben genannten try / catch Block, beim Versuch auf einen Windows-Dienst zuzugreifen).

Deshalb könnte es ratsam sein, den Anti-Cheatschutz auch als Treiber laufen zu lassen.

Müsste eine injecte'de DLL nicht unter den "geladenen Modulen" des Prozesses auftauchen? Nur ne wilde Vermutung, hab mich damit nicht explizit außeinandergesetzt ^^

Das ist eine gute Frage. Das kann ich auch net so genau sagen.

Bei Spielen wie z.B. CS werden Cheats / Hacks im Ring 0 (Sprich Kernelmode) gestartet.... das verhindert herkömmlichen Scanprogrammen (wie z.B. in der Theorie auch das von Blizzard geladene Warden) auf den Prozess zuzugreifen, da die Rechte dazu nicht ausreichen. (Siehe den oben genannten try / catch Block, beim Versuch auf einen Windows-Dienst zuzugreifen).

Als Service könnte man es theoretisch auch einpflegen. Ich vermute allerdings, das der Zugriff auf die Ring0 Hacks damit nicht besser wird. Die besten Methoden, ein AC zu coden ist denke ich in ASM oder C/C++, da es dann 1. sehr systemnah ist (zwecks Performance) und zum 2. das Programm auch systemnäher angesiedelt werden kann.

Außerdem kann ja nur der Loader im Grunde Ring0 sein. Denn der Hack muss sich ja ans Spiel hängen, um an die nötigen Informationen zu kommen. Denn der RAM wird dynamisch verwaltet und somit kann der Hack ja nie genau wissen, wo er die für sich befindlichen Daten findet.

Ich werde mich nun ranmachen und mal einige Sachen implementieren. Habe mir bereits eine nette Sammlung von Prüfwegen angelegt und bereits dafür nötige snippets geschrieben. Ich werde einfach mal eines nach dem anderen in eine Consolenanwendung packen und testen.

Müsste eine injecte'de DLL nicht unter den "geladenen Modulen" des Prozesses auftauchen?

Exakt. Entweder das oder eine bestehende DLL ist plötzlich größer/kleiner als normal.

Jedoch gibt es nachwievor einige Schwächen in diesem System:

Treiberhacks, die nicht das Spiel betreffen, sondern den Grafikkartentreiber Kann man so nicht aufdecken.
Wie bei den CS Anti-Cheat-Tools ist es auch ein leichtes, das Anti-Cheat-Tool selbst zu hacken.
Uvm...

Im wesentlichen musst du dich erstmal gezielt damit auseinandersetzen, wie Programme gehackt werden können und was es da für Methoden gibt. Dann erst wirst du in der Lage sein, ein mäßig wirksames Tool zu schreiben. Mäßig deshalb, weil auch die großen Sicherheitsexperten von den bestehenden Tools nachwievor den Kampf verlieren.

Ach ja und bei dem hier:

Du sollst Hashes aus den geladenen Dll´s generieren und mit denen der anderen spielteilnehmern vergleichen. Bei unstimmigkeiten wurde definitiv manipuliert, da die spiele schon von sich aus auf Versionsgleichheit prüfen.

Funktioniert nicht zwischen x86 und x64 Systemen, wenn das Spiel selbst x64 auch unterstützt, da das dann 2 verschiedene Versionsgleiche Compilate sind, die jedoch andere Hashcodes produzieren würden.

Müsste eine injecte'de DLL nicht unter den "geladenen Modulen" des Prozesses auftauchen?

1. Es ist ohne probleme möglich, unmanaged-dlls in den speicher zu laden, ohne die offiziellen funktionen zu benutzen.
2. man kann loadlibrary benutzen und die header anschließend maskieren.

Beides kann man als fertigen sourcecode im internet finden.

Ist nur die frage, ob die cheats den code verwenden.