Moin moin

Ich bastel immer noch anner Anti-Cheat Software und änder in nem Spiel zwecks Prävention Variablen die für die Spieldatenverschlüsselung zwischen Client und Server zuständig sind. Das ganze is kein Problem, nur diese Variablen müssen vor den Spielern geheimgehalten werden, da sie sonst per Hexeditor die Cheat Programme der Verschlüsselung angleichen.

Da ich direkt im RAM diese Variablen änder, muss ich für andere Anwendungen die Leserechte für den Prozess sperren und da kommt das riesen Problem. Ich hab keine Ahnung wie ich das machen soll und ob das überhaupt möglich is. Entweder müßt das Programm bemerken wenn ein anderes auf den Prozess zugreift und sich ggf. sofort beenden oder aber die Leserechte müssen komplett gesperrt werden.

Habt ihr sowas scho ma gemacht und/oder wißt wie man bei Prozessen die Leserechte verweigert ??

Vielen Dank scho ma im Vorraus

- Thebe

Schau dir mal die WinAPI Funktion VirtualProtectEx an. Aber bedenke: Was du kannst, können auch die anderen.

Hmm
Ich hab mir das ma angeguckt und es funktioniert in dem Sinne, das ich das Zeug nu nimma auslesen kann. Allerdings funkt es ZU GUT und selbst das Spiel kann nimma auffe Werte zugreifen und startet gar nit erst. Da das Spiel leider die ganze Zeit anne Wert ran muss hab ich nun nen Problem.

Ich hab die Werte mit PAGE_NOACCESS gesperrt und nix kann drauf zugreifen. Wenn ich die Werte mit PAGE_EXECUTE sperre, dann kann das Spiel ohne Probs starten, allerdings kann dann jedes andere Prog auch auffe Werte zugreifen was ja nit im Sinne des Erfinders is.

So und was nu ??

Da läßt dich wohl deine Logik etwas im Stich. Du schließt die Tür ab, damit keine Diebe ins Haus kommen. Dann schmeißt du den Schlüssel weg und wunderst dich, dass du auch nicht mehr reinkommst. Da es keinen Zweitschlüssel bzw. keine andere Tür gibt war es das eben.

Hi!

@thebe: Schau' Dir mal die DebugActiveProcess() API an.
Das ist ganz sicher die Holzhammermethode und wohl in der Praxis nicht zumutbar, aber da Du so verbissen nach einer Lösung suchst....

Das ist eine Fkt., die eigentlich für Debugger gedacht ist, d.h. du kannst auf AVs des Programms reagieren und somit dann die entsprechenden Daten dem Process zur Verfügung stellen.
IMHO etwas overkill in Deinem Fall.

Gruß,
Markus

Das ist scho eher was womit ich was anfangen kann.
Vielen Dank für den Tipp

- Thebe

Hi Thebe!

Meine Vorstellung wäre folgende:

1. Du schützt per VirtualProtectEx() die Datei (siehe Beitrag von Andy)
2. Du "registrierst" Dich als Debugger bei Deinem Zielprogramm (DebugActiveProcess() oder CreateProcess() und dwCreationFlags := DEBUG_PROCESS)
3. Du wartest auf ein 'Debug_Event' per WaitForDebugEvent()
4. Bei ExceptionCode = EXCEPTION_ACCESS_VIOLATION weißt Du, dass das Programm nicht auf seine eigenen Daten zugreifen konnte/durfte. Per VirtualProtectEx() zulassen, einen Step weiterdebuggen (gegebenfalls Instruction Pointer EIP vorher dekrementieren). Danach Zugriff wieder unterdrücken und Programm weiter ausführen.

Das wäre meine Vorstellung (aus dem Bauch heraus). Keine Ahnung, ob es funktioniert. Eins ist klar: Es wird definitiv viel Arbeit auf Dich zukommen und das Programm wird 100%ig ewig ausgebremst werden.

Gruß,
Markus

Um das zu verhindern was du willst, eignet sich sowas wie Fork() und Fibers. Fork ist nicht implementiert, kannste aber selber (zumindest auf NT Plattform). Dazu kannste dir die Cygwin Sourcen mal anschauen. Die implementieren Fork()

Assarbad hat folgendes geschrieben:

Um das zu verhindern was du willst, eignet sich sowas wie Fork() und Fibers.

Und was soll das bringen? Oder haben Fibers eine Funktionalität, die mir entgangen ist. Oder stehe ich einfach auf der Leitung?

Trainer sind oft Programme die ein Spiel starten aber sich dennoch nicht als Debugger ausgeben. Wenn man (zB mit Hilfe von Fibers) den derzeitigen Ausführungskontext kopiert und danach in einem anderen Fiber fortfährt, sollte das einige Trainer aus dem Konzept bringen (und auch einige Autoren von Trainern).

Hi Assarbad.

So wie ich das verstehe, funktioniert das dann aber nur für Deinen eigenen Prozess (Fiber = lightweight thread zur Unterstützung von *nix C++-Code!?). Das Problem von thebe hab' ich aber so verstanden, als ob er eine Anti-Cheat-Software entwickelt, die ein anderes Spiel schützen soll (im Topic taucht ja unter anderem der Begriff "fremder Prozess" auf).

Hab ich was falsch verstanden?

Gruß,
Markus

Okay, sorry. Mein Fehler

Also, du möchtest ein BESTIMMTES anderes Spiel schützen und änderst dazu (ständig?) die Variablen im RAM ?

Das macht du mit einem ANDEREN Programm ?
Und du möchtest den RAM-Zugriff für andere sperren (in den Bereichen) ?

OK, nur so einige Ansätze zum übergehen:

- decompilieren ?
- Ein Fake-Client-Prog schreiben, dass sich über den Zugriff in den geschützten Bereichen freut !
- Wie werden die Variablen geändert ? Nach einer Formel oder Liste ?
Liste: krieg ich aus SourceCode, Formel: krieg ich die Startwerte aus Sourcecode und die Formel ist kein Problem, wenn ich die Communication abhöre
- Wenn ichs UNBEDINGT cracken will: Ausprobieren !
Einfach testen, welcher code was bewirkt.

Beispiel: ZZZ bewirkt, das Spieler schiesst
XXX bewirkt, dass Spieler sich duckt
Also: Firewall programmieren und ZZZ durch XXX ersetzen.
Na OK ist Blödsinn sowas zu machen (ducken anstatt schiessen)
Aber so als Beispiel !
Besseres Beispiel:
Ich bin z.B. allein inner map, dann com abhören, vorwärts gehen, abhören, com-UNTERSCHIED=map !

- Also wenn dus unbedingt verhindern willst, dass jemand das Spiel cheatet, dann müsstest du hier eine Matrix-Verschlüsselung oder so anwenden, und als Verschlüsselungscode dann OneTimePad, ansonsten lachen sich die Hacker ab einer gewissen Spieldauer einen

=> Dein Spiel wird ELENDIGLICH LANGSAM !

Viele Grüsse.

P.S.: Habe schon so eine Anticheat-Software entwickelt und kann leider sagen: Es gibt immer etwas zu übersehen
Ausserdem durften die Player sich über: benötigt min. DSL-Speed (vorher Modem) erfreuen