speicher zugriff umleiten

[Tyrar]

ich habe da grad ein kleines problem, es gibt da eine funktion die ich hooken muss, allerdings wird diese func gecheckt ob die geändert ist. ich habe mir schon überlegt nen exception handler in jedem thread zu installieren und der funktion die execute rechte zu entziehen, damit ich in dem exception handler dann direkt zu meiner func springen kann. hardware breakpoints sind keine lösung, die werden automatisch entfernt!

jemand ne idee?

[Nightblizard]

Es wäre hilfreich zu wissen welche Maßnahmen das anti-cheat System ergreift.
Spontan würde ich die Funktion hooken, die den Arbeitsspeicher überprüft und dann ganz einfach meine Funktion immer als "Okay" melden.

[Tyrar]

geht um aktuelles hackshield, themida protected und mit kernelmode schutz!
exception handler werden von den hackshield funktionen überschrieben und damit wären access violations auch nicht zu nutzen!

aber mir bleibt anscheinend keine andere wahl als direkt die check func zu hooken

[Ende!]

Du könntest versuchen ein x64er System zu spoofen, damit HS denkt, dass es den ring0 Treiber nicht laden kann.



Das ist die offizielle API zum Abfragen, ob es sich um einen Wow64 Prozess handelt. Soweit ich das recht in Erinnerung habe, ruft diese dann intern NtQueryInformationProcess auf, um an die entsprechenden Informationen zu gelangen. An deiner Stelle würde ich also mal dort ansetzen.

PS:
Das ist, insofern es funktioniert, vermutlich keine permanente Lösung, da es zur Unterscheidung der 32 und 64 Bit-Version von Windows Möglichkeiten wie Sand am Meer gibt. Man sollte aber ja annehmen, dass die Leute bei AhnLab erstmal auf die offizielle Variante zurückgreifen .. bis sie dann merken, dass das ein Punkt für mögliche Angriffe ist ..

[Tyrar]

Originally Posted by Ende!

Du könntest versuchen ein x64er System zu spoofen, damit HS denkt, dass es den ring0 Treiber nicht laden kann.



Das ist die offizielle API zum Abfragen, ob es sich um einen Wow64 Prozess handelt. Soweit ich das recht in Erinnerung habe, ruft diese dann intern NtQueryInformationProcess auf, um an die entsprechenden Informationen zu gelangen. An deiner Stelle würde ich also mal dort ansetzen.

PS:
Das ist, insofern es funktioniert, vermutlich keine permanente Lösung, da es zur Unterscheidung der 32 und 64 Bit-Version von Windows Möglichkeiten wie Sand am Meer gibt. Man sollte aber ja annehmen, dass die Leute bei AhnLab erstmal auf die offizielle Variante zurückgreifen .. bis sie dann merken, dass das ein Punkt für mögliche Angriffe ist ..

grundsätzlich wäre das natürlich möglich, allerdings haben die einen signierten treiber, damit würde maximal der treiber garnicht erst geladen werden was zu falschen heartbeat packets führen würde...
2 möglichkeiten die wohl bleiben sind:
packets emulieren
check funcs hooken

[Dr. Coxxy]

in der funktion auf irgendeine weise eine exception auslösen (z.b. in ner dauerschleife im thread nen pointer der in der funktion benutzt wird auf NULL setzen), die dann in nem exception handler abfangen und den fehler wieder korrigieren.
etc.

sicher, dass die ganze funktion gecheckt wird, und net nur der anfang auf nen e9?

[Tyrar]

Originally Posted by Dr. Coxxy

in der funktion auf irgendeine weise eine exception auslösen (z.b. in ner dauerschleife im thread nen pointer der in der funktion benutzt wird auf NULL setzen), die dann in nem exception handler abfangen und den fehler wieder korrigieren.
etc.

sicher, dass die ganze funktion gecheckt wird, und net nur der anfang auf nen e9?

verstehe grad nicht worauf du mit der dauerschleife hinaus willst

checksum der gesamten wichtigen funktionen, da ist dann egal was ich da rein schreibe

[Dr. Coxxy]

EDIT:

vergiss es, ich kann mal wieder net lesen und hab das hier komplett übersehen:

exception handler werden von den hackshield funktionen überschrieben und damit wären access violations auch nicht zu nutzen!

[MrSm!th]

Die Signatur des Treibers ist ziemlich egal, der Patchguard verbietet Kernel Patches jeglicher Art, weshalb Anti-Cheat Treiber auf x64 unmöglich sind.

HWBPs werden entfernt, ja? Versuch doch einen HWBP auf SetThreadContext und einen auf GetThreadContext bzw. auf die internen Funktionen zu setzen, um zu verhindern, dass jemand deine HWBPs sieht bzw. sie überschreiben kann.

Werden alle HWBPs entfernt oder nur die on execute? Du könntest auch einen on read machen und dann immer das originale Byte stattdessen zurückgeben bzw. dadurch die Funktion finden, die den Memory checkt und diese patchen.

Access Violations wären ohnehin ***** lahm geworden.

Werden alle Exception Handler überschrieben, also auch die Vectored oder nur die Unhandled Variante?

Ansonsten könntest du ja auch da nen HWBP platzieren, hast ja 4 Stück.

treiber garnicht erst geladen werden was zu falschen heartbeat packets führen würde...

Nein, tut es nicht, da es legitim ist, dass er nicht geladen wird.

Ich musste damals lediglich die Hack Detection abschalten und die Sache war gegessen. Das ging in S4 sogar ohne den Callback zu finden, weil man einfach den Part noppen/überspringen konnte, der die "Hack Detected" Message angezeigt und dann ExitProcess aufgerufen hat.

checksum der gesamten wichtigen funktionen, da ist dann egal was ich da rein schreibe

Ist es eine Windows API oder eine Spielfunktion?
Bei APIs kann es auch manchmal helfen, die interne Variante zu hooken, weil nur die Win32 Version gecheckt wird.

Aber du bist sicher, dass die ganze Funktion mithilfe einer Checksum (die sich übrigens sogar leicht modifizieren ließe) bzw. eines Hashes geprüft wird und nicht nur die ersten Bytes?

[Tyrar]

Originally Posted by MrSm!th

Die Signatur des Treibers ist ziemlich egal, der Patchguard verbietet Kernel Patches jeglicher Art, weshalb Anti-Cheat Treiber auf x64 unmöglich sind.

HWBPs werden entfernt, ja? Versuch doch einen HWBP auf SetThreadContext und einen auf GetThreadContext bzw. auf die internen Funktionen zu setzen, um zu verhindern, dass jemand deine HWBPs sieht bzw. sie überschreiben kann.

Werden alle HWBPs entfernt oder nur die on execute? Du könntest auch einen on read machen und dann immer das originale Byte stattdessen zurückgeben bzw. dadurch die Funktion finden, die den Memory checkt und diese patchen.

Access Violations wären ohnehin arsch lahm geworden.

Werden alle Exception Handler überschrieben, also auch die Vectored oder nur die Unhandled Variante?

Ansonsten könntest du ja auch da nen HWBP platzieren, hast ja 4 Stück.

Nein, tut es nicht, da es legitim ist, dass er nicht geladen wird.

Ich musste damals lediglich die Hack Detection abschalten und die Sache war gegessen. Das ging in S4 sogar ohne den Callback zu finden, weil man einfach den Part noppen/überspringen konnte, der die "Hack Detected" Message angezeigt und dann ExitProcess aufgerufen hat.

Ist es eine Windows API oder eine Spielfunktion?
Bei APIs kann es auch manchmal helfen, die interne Variante zu hooken, weil nur die Win32 Version gecheckt wird.

Aber du bist sicher, dass die ganze Funktion mithilfe einer Checksum (die sich übrigens sogar leicht modifizieren ließe) bzw. eines Hashes geprüft wird und nicht nur die ersten Bytes?

access violations wären bei checks für alle 30secs noch akzeptabel
hwbps an die internen funktionen zu setzen habe ich noch nicht probiert, werde ich mal machen!

sobald der treiber nicht geladen wurde und/oder nicht darauf zugegriffen werden kann gibts da auch nen fail!
den treiber habe ich so modifiziert, dass ich auf den prozess auch vollen zugriff habe! zu debug zwecken definitiv sehr nützlich.

checksums werden von spielfunktionen/hs funktionen/winapi funktionen geprüft. interessanter weise werden die unhandled exception methoden gecalled (allerdings nur bei hwbps)! wenn ich einen read access bp setze, ist die exception address:

add al, [ebx]
pop ebx ; <-- hier

aber danke für die tipps, ich werd ma versuchen damit was zu erreichen!

[link]

Soweit ich weiß, ist die offizielle x64 Methode, sich "in's System einzuhooken", Filter über ObRegisterCallbacks zu installieren.
Auf diese Weise funktionieren auch x64 AVs. Der Spielraum ist natürlich stark eingeschränkt im Vergleich zu x86, aber ohne Funktion sind sie nicht und natürlich auch nicht unmöglich.

Du könntest evtl. auch, um dich nicht mit den Check-Funktionen herumschlagen zu müssen, PatchGuard auf deinem System deaktivieren und die Funktionen zum Abfragen der HW BPs sowie dem Löschen der Exception Handler in der SSDT hooken, sodass deine Hooks erhalten bleiben dürften.
Nicht unbedingt eine dauerhafte, noch sehr stabile Methode, aber zum Testen wär's ein Versuch wert.

Einen PatchGuard Bypass findest du .

[MrSm!th]

sobald der treiber nicht geladen wurde und/oder nicht darauf zugegriffen werden kann gibts da auch nen fail!
den treiber habe ich so modifiziert, dass ich auf den prozess auch vollen zugriff habe! zu debug zwecken definitiv sehr nützlich.

Das mag sein, er kann aber keine effektiven Veränderungen am Kernel vornehmen.

edit:

Ah danke link, wusste ich gar nicht. Wieder was neues gelernt.