Debugger detection wtf?

Hi alle zusammen,
Dieser Thread richtet sich an Leute, die Ahnung von Windows Internals und am besten PEB, Debuggerdetection, NT etc. haben (an alle Linuxer, ihr könnt hier aufhören zu lesen, falls ihr nicht vorhabt, etwas mit Windows zu machen ;))
Keine Angst, da es sich bei mir um einen 64bitler handelt, geht es vorläufig (!) nicht in den ring0.

Mein Problem ist eine äußerst nervige Debuggerdetection beim Spiel S4 League.
Ich dachte erst, sie kommt evtl. durch Themida, aber es scheint doch aus der XTrapVa.dll zu kommen (XTrap^^)...
Um es schon vorweg zu nehmen:

Ich habe folgendes probiert:

-hooken von IsDebuggerPresent
-hooken von NtQueryInformationProcess und habe schon zig Parameter ausprobiert, ob es nun DebugPort, DebugFlags oder ProcessDebugObjectHandle war....kein Erfolg.
Ich bemerkte, dass NtQueryInformationProcess ziemlich oft mit ProcessBasicInformation gecalled wird, und dann fiel mir das BeingDebugged Byte, die NtGlobalFlags und die Heapflags ein.
Nichts, BeingDebugged hat nichts genützt, und bei den Flags gabs nen Crash, als ich manuell etwas dorthin schreiben wollte....entweder habe ich etwas falsch gemacht oder ich darf da nicht einfach was hinschreiben...obwohl manche Ollyscripts machen das ja auch^^
Naja, ich bin mir ziemlich sicher, dass es irgendwie mit dem PE Header überprüft wird, da der ziemlich oft kontrolliert wird....
Übrigens: CheckRemoteDebugger ist sinnlos, da diese Funktion NtQuery... aufruft, und da ich es testweise auch mal in den XTrap Prozess injected habe, ist eine Kontrolle von außerhalb unwahrscheinlich....
-OutputDebugString war es nicht
-Da S4 erst geschlossen wird, wenn man attached, kann FindWindow ausgeschlossen werden, genau wie EnumProcesses...

Ich weiß echt nicht mehr weiter, auch viele Antidebugreferenzen haben mir nur das hier schon aufgezählt...ich bin mir fast sicher, dass es per PEB gemacht wird, aber wenn ich da was zb. an den GlobalFlags verändere, gibts nen Crash.... was könnte ich noch probieren oder wie kann man die Flags richtig verändern?

p.s. wird eigentlich NtExitProcess immer gecalled, wenn man ExitProcess aufruft? Ich hatte mir für die Analyse eine Dll gemacht, die ExitProcess und ExitThread einfach nichts tuen lässt, damit Themida/Xtrap machtlos ist.
Das geht nun plötzlich nicht mehr, also möchte ich mal NtExitProcess etc. probieren. Ist das die einzige Möglichkeit einen Prozess zu schließen (TerminateProcess auch gehooked oder in dem Falle dann auch NtTerminateProcess) oder gibts da noch was anderes?
(Testweise habe ich die dll auch in XTrap injected, und da auch TerminateProcess etc. gehooked ist, ist ein Schließen von außerhalb auszuschließen!)


So, ich hoffe einer ist da recht erfahren und kann mir vielleicht weiterhelfen.
Wäre auf jeden Fall nett ;)
Danke im Voraus

MfG Sm!th

Es gibt da so ein paar Tricks um Debugger zu erkennen.
Beispielsweise kann man die Interrupts benutzen, welche Debugger als Breakpoints nutzen.
Hält die Ausführung an, weiß man das ein Debugger am Prozess klebt (natürlich muss das in einem extra Thread behandelt werden).
Nur um ein Beispiel zu nennen.

Bzw, den Ausführungsstatus des Mainthreads in einem anderen Thread zu überwachen ist sowieso eine sichere Sache um Debugger zu erkennen, die CPU selbst wird wohl kaum jemals die Ausführung anhalten.

Ich schlag das heute mal nach, interessiert mich auch ;)

Quote:

Originally Posted by flo8464 Es gibt da so ein paar Tricks um Debugger zu erkennen. Beispielsweise kann man die Interrupts benutzen, welche Debugger als Breakpoints nutzen. Hält die Ausführung an, weiß man das ein Debugger am Prozess klebt (natürlich muss das in einem extra Thread behandelt werden). Nur um ein Beispiel zu nennen. Bzw, den Ausführungsstatus des Mainthreads in einem anderen Thread zu überwachen ist sowieso eine sichere Sache um Debugger zu erkennen, die CPU selbst wird wohl kaum jemals die Ausführung anhalten. Ich schlag das heute mal nach, interessiert mich auch ;)

Kann man das ausschließen, wenn das Spiel innerhalb von 10 ms geschlossen wird?
So eine Methode habe ich nämlich aus dem Grund ausgeschlossen^^ Das geht so blitzschnell, da würde wirklich gut die so oft gecallte NtQueryInfo.... zu passen...

Wie könnte man denn den Breakpointcheck umgehen?

Kauf dir das Buch [Only registered and activated users can see links. Click Here To Register...], es ist praktisch eine Bibel für das x86-Reversing und behandelt Anti-Reversingtricks recht genau.

Hier mal ein Beispiel aus dem Buch, wie man einen Debugger anhand der Trapflag an den Eiern packen kann:

Quote:

BOOL exceptionHit = FALSE; __try { _asm { pushfd or dword ptr [esp], 0x100 //Set ther Trap Flag popfd nop } } __except(EXCEPTION_EXECUTE_HANDLER) { exceptionHit = TRUE; } if(!exceptionHit) printf("Debugger detected!");

Was du machen kannst? Nicht, höchstens den Code davor patchen. Wogegen man allerdings auch gegensteuern kann. ;)
Der Prozessor lässt sich leider nicht verarschen.

Es macht 0 (in Worten 0) Sinn, einfach ins blaue zu raten, da es OVER 9000 anti-anti-anti-anti-anti-anti-debugger detections gibt. Schließt sich das Spiel, sobald du einen debugger attachst oder erst, wenn du es weiter ausfuehrst?

Quote:

Originally Posted by rEdoX ... OVER 9000 ...

YTP lässt grüßen? :D

Aber BTT:
Gibts dazu online noch etwas gute "Lektüre"? Würde mich interessieren.

Quote:

Originally Posted by flo8464 Kauf dir das Buch [Only registered and activated users can see links. Click Here To Register...], es ist praktisch eine Bibel für das x86-Reversing und behandelt Anti-Reversingtricks recht genau. Hier mal ein Beispiel aus dem Buch, wie man einen Debugger anhand der Trapflag an den Eiern packen kann: Was du machen kannst? Nicht, höchstens den Code davor patchen. Wogegen man allerdings auch gegensteuern kann. ;) Der Prozessor lässt sich leider nicht verarschen.

Danke wollte sowieso mal nach Buchempfehlungen fragen, die in die Richtung gehen.
Da ich mir nun mit dem Buch von Stroustrup einen halbwegs guten Stil angeeignet habe, kann es nun in Richtung Weiterführendes gehen und für sowas interessiere ich mich sehr.
Aber:
1. ich kann irgendwie kaum glauben, dass bei so einem Spiel so ein Check gemacht wird; ich denke irgendwie es ist was einfaches und irgendwie ist es ja auch komisch das circa 100 Mal pro Sekunde NtQueryInformationProcess mit ProcessBasicInformation gecalled wird^^ aber naja, theoretisch ist alles möglich...
2. kann man nicht irgendwie die Exceptions selbst abfangen?

Naja danke auf jeden Fall schonmal für die Hilfe...

Quote:

Originally Posted by rEdoX Es macht 0 (in Worten 0) Sinn, einfach ins blaue zu raten, da es OVER 9000 anti-anti-anti-anti-anti-anti-debugger detections gibt. Schließt sich das Spiel, sobald du einen debugger attachst oder erst, wenn du es weiter ausfuehrst?

Nur, dass man es recht gut eingrenzen kann zb:

Zu leichte Methoden: weg
Zu komplizierte Methoden: höchst wahrscheinlich weg

Bleibt der mittelmäßige Teil dazwischen und da kann man es auch wieder ein bisschen eingrenzen.

Btw. ich habe euch etwas vorenthalten:

Wenn ich etwas an der PEB Struktur ändere, ohne dass es crasht, wird plötzlich 2 mal NtQuery.... mit ProcessDebugPort gecalled und dann geschlossen!
Allerdings egal, ob ein Debugger attached ist oder nicht; was ich aber dazu sagen sollte:
Solange ich auf der MessageBox nicht auf Ok klicke (es kommt eine MessageBox wenn NtQuery... mit ProcessDebugPort gecalled wird) kann ich mit Olly attachen und die ganzen Threads bleiben auf und Olly pausiert den Prozess O.o
Allerdings sind dann nur noch 4 oder 5 von 40 auf, aber die schon geschlossenen werden anscheinend vorher geschlossen...

Quote:

1. ich kann irgendwie kaum glauben, dass bei so einem Spiel so ein Check gemacht wird; ich denke irgendwie es ist was einfaches und irgendwie ist es ja auch komisch das circa 100 Mal pro Sekunde NtQueryInformationProcess mit ProcessBasicInformation gecalled wird^^ aber naja, theoretisch ist alles möglich...

Schon mal angeschaut was mit den Informationen aus den Calls gemacht wird?
Ein statisches Disassembler kann ja auch ganz hilfreich sein ;)

Quote:

2. kann man nicht irgendwie die Exceptions selbst abfangen?

Ich denke der Exception-Handler lässt sich überschreiben, kenne mich damit aber leider nicht aus.

Quote:

Originally Posted by flo8464 Schon mal angeschaut was mit den Informationen aus den Calls gemacht wird? Ein statisches Disassembler kann ja auch ganz hilfreich sein ;) Ich denke der Exception-Handler lässt sich überschreiben, kenne mich damit aber leider nicht aus.

wie kann ich denn nachsehen, was damit gemacht wird?
wie meinst du statisches disassembler?

Quote:

Originally Posted by MrSm!th wie kann ich denn nachsehen, was damit gemacht wird? wie meinst du statisches disassembler?

Naja, ein Disassembler wie zum Beispiel IDApro.
Der analysiert den Code nur und führt ihn nicht aus. Da könntest du doch mal gemütlich reversen, was das Programm mit den Results aus NtQueryInformationProcess macht.

Quote:

Originally Posted by flo8464 Naja, ein Disassembler wie zum Beispiel IDApro. Der analysiert den Code nur und führt ihn nicht aus. Da könntest du doch mal gemütlich reversen, was das Programm mit den Results aus NtQueryInformationProcess macht.

ne, ist gepackt mit Themida
Hab ich das noch nicht geschrieben? :D
Deswegen habe ich mir ja auch eine Dll gemacht, die ExitThread und ExitProcess nichts tun lässt, damit ich eben attachen kann, ohne dass Themida alles killt.
Das geht aber plötzlich nicht mehr; ich werde es mal mit NtExitThread und NtExitProcess probieren, aber falls das nicht geht, habe ich keine Ahnung wie ich das Schließen verhindern kann (außer Kernel mode, aber so weit, wollte ich dafür nicht gehen...)

Uhhh, bei Themida kannst du dir sicher sein, dass 50 verschiedene ekelhafte Anti-Debugging Tricks verwendet werden. :P

Quote:

Originally Posted by flo8464 Uhhh, bei Themida kannst du dir sicher sein, dass 50 verschiedene ekelhafte Anti-Debugging Tricks verwendet werden. :P

Joa und ich habe gehört, dass auch die aktuelle Version NtQueryInformationProcess nutzt (und bei Game deception gab man mir den Tipp, ich solle NtQuery... hooken und Olly ein bisschen modden; fertig. Ok, das war dann wohl eine ältere Version, aber ich kann mir das so schlecht vorstellen, dass innerhalb von 2-3 Versionen 48 andere Checks dazu kamen >.<), aber wohl nicht mit DebugPort oder DebugFlags....
DebugPort nur, wenn ich etwas in der PEB struct verändere (nicht beim BeingDebugged Byte) und dann killt sich S4 so oder so, ob mit oder ohne Debugger.

Könntest du mir vielleicht mal einen kleinen Codeausschnitt geben, wie ich zb. die GlobalFlags und die HeapFlags ohne einen Crash manipulieren kann? Auch wenn das nicht hilft gegen den Debugger, ich möchte wissen, warum das da bei mir crasht >.<

p.s. Es gab aber schon einen Check, bevor der Client mit Themida gepackt war! Da gabs dann nen Disconnect, also war da auch schon vorher irgendeine Art mieser Check, außerhalb der Liga von IsDebuggerPresent^^


btw. das mit dem Buch ist so eine Sache.
Ich bin zwar ziemlich gut in Englisch und verstehe die meisten Tuts und lese auch englische Bücher, aber bei einem Buch übers reversen...auf Englisch....naja werd mal sehen, so schwer kanns nicht zu verstehen sein :D


edit:

für die, dies interessiert:

Habe noch etwas schönes gefunden:

LdrShutdownProcess
und
LdrShutdownThread ;)
die werde ich dann nach NtExitProcess etc. probieren...


edit:

*push*^^

Also die Frage steht immer noch, kennt sich hier vielleicht jemand mit Themida aus und kann mir sagen, was evtl. typisch für die ist?

Btw. NtQueryInformation Process können wir nun 80%ig komplett ausschließen (also nichtmal einer der 50 debugger check^^ allerdings nur 80%ig), denn NtQuery... wird deswegen so oft gecalled, weil damit CE etc. gefunden werden.
Genau so oft wird nämlich auch OpenProcess gecalled und ich denke nicht, dass damit der eigene Prozess geöffnet wird :D