speicher zugriff umleiten

06/19/2012 18:55 Tyrar#1
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?
06/19/2012 19:25 Nightblizard#2
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.
06/19/2012 20:00 Tyrar#3
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 :(
06/19/2012 23:05 Ende!#4
Du könntest versuchen ein x64er System zu spoofen, damit HS denkt, dass es den ring0 Treiber nicht laden kann.

[Only registered and activated users can see links. Click Here To Register...]

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 .. :p
06/19/2012 23:20 Tyrar#5
Quote:
Originally Posted by Ende! View Post
Du könntest versuchen ein x64er System zu spoofen, damit HS denkt, dass es den ring0 Treiber nicht laden kann.

[Only registered and activated users can see links. Click Here To Register...]

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 .. :p
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
06/19/2012 23:39 Dr. Coxxy#6
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?
06/20/2012 00:00 Tyrar#7
Quote:
Originally Posted by Dr. Coxxy View Post
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 ;)
06/20/2012 01:05 Dr. Coxxy#8
EDIT:

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

Quote:
exception handler werden von den hackshield funktionen überschrieben und damit wären access violations auch nicht zu nutzen!
06/21/2012 02:05 MrSm!th#9
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.

Quote:
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.

Quote:
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?
06/21/2012 17:07 Tyrar#10
Quote:
Originally Posted by MrSm!th View Post
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:
Code:
add al, [ebx]
pop ebx ; <-- hier
aber danke für die tipps, ich werd ma versuchen damit was zu erreichen!
06/21/2012 17:19 link#11
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 [Only registered and activated users can see links. Click Here To Register...].
06/21/2012 21:14 MrSm!th#12
Quote:
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.