Debugger detection?!

Schildkroete

PEB->BeingDebugged ist auch relativ nützlich

loki1985

in den meisten faellen laeuft es ja auf das isDebuggerPresent raus...

aber da wuerde ich noch ein bisschen anders ansetzen.... erstens den aufruf der funktion nicht hardcoden, sondern erstmal den funktionsnamen und den der DLL irgendwie "generieren"... vielleicht sogar aus nem externen file. und dann dynamisch per getProcAdress oder wie das teil heisst nachladen und rennen lassen...

ist zwar genauso crackbar wie wenn man es hardcodiert, aber ich denke einige cracker wuerde man damit abschrecken... mich auf jeden fall mal

man kann da wirklich viele lustige sachen machen, aber in manchen faellen baut man sich da unabsichtlich stolperfallen. z.B. mit der zeitmessung, was passiert wenn genau in dem moment solche dinge passieren wie virtueller speicher umgelagert wird, oder rechner geht auf standby, oder oder oder... koennte in seltenen faellen nach hinten losgehen....

net 0

Trundle0x7e schrieb:

PEB->BeingDebugged ist auch relativ nützlich

nö, ist das gleiche wie 'IsDebuggerPresent'

BOOL
APIENTRY
IsDebuggerPresent(
    VOID
    )

{
    return NtCurrentPeb()->BeingDebugged;
}

Schildkroete

net schrieb:

Trundle0x7e schrieb:

PEB->BeingDebugged ist auch relativ nützlich

nö, ist das gleiche wie 'IsDebuggerPresent'
BOOL
APIENTRY
IsDebuggerPresent(
    VOID
    )

{
    return NtCurrentPeb()->BeingDebugged;
}

Wenn ich ein Cracker wäre, würde ich ja wohl als aller erstes einen Breakpoint auf genau diese Funktion setzen

net 0

Trundle0x7e schrieb:

Wenn ich ein Cracker wäre, würde ich ja wohl als aller erstes einen Breakpoint auf genau diese Funktion setzen

oder du machst, direkt nach der verbindung mit dem debugger
'PEB->BeingDebugged = FALSE'

Schildkroete

net schrieb:

Trundle0x7e schrieb:

Wenn ich ein Cracker wäre, würde ich ja wohl als aller erstes einen Breakpoint auf genau diese Funktion setzen

oder du machst, direkt nach der verbindung mit dem debugger
'PEB->BeingDebugged = FALSE'

Klar, aber wenn du dir das Niveau von den meisten Crackern anguckst, dann kannst du dir sicher sein, dass sie darauf nicht kommen würden...

Anyway, die einzige 'wirkliche' Möglichkeit sich gegen Debugger zu schützen ist das manuelle zurücksetzen der Debugregister zur Laufzeit oder einfach ein self-debugging...

Termite

Kinders kinders

hat nicht mal vor kuzem jemand mal nen link auf ne präsentation von EADS über Skyp und dessen sicherhetisvorkerungen gepostet? Das ding hatt vileicht sperren drinnen, da beisen sich sogar profies fast die zähne dran aus.

Kompremierter code, verschlüsselter code, ( Programm wird in den speicher entpackt und entschlüsselt, danach das programmteil zum entpacken gelöscht) das in mehreren schritten, so das man breakpoint nicht sauber setzen kann.

Prüfsummen berechnung über programmteile die geprüft werden. ( software breakpoints verursachen prüfsummen fehler )

Laufzeitmessungen

und das gemeinste Sprungvektoren die anhand der prüfsummen berechnet werden. somit verursachen breakpoints zu einem späteren Zeitupunkt hässliche fehler.

und ein paar debug erkennungen waren auch drinnen, wobei der kenreldebugger nicht erkannt wurde.

gruss

Schildkroete

Sowas macht aber der Hobbyentwickler nicht mehr manuell, sondern tolle Programme wie Themidia übernehmen das für einen. Ich bin davon ausgegangen, dass der Threadstarter Code haben möchte, welchern er selbst nach entpacken usw. ausführen möchte

Und sowieso, die von dir beschriebenen Wege helfen aber nicht, einen Debugger zu detecten

Termite

Moin

Sinn und zweck einer debugger erkennung ist doch sicherlich, zu verhindern, das sein program gedebuggt wird. bzw analysiert wird ( hat er glaubich auch andeuten wollem mit "... aber von irgendetwas muss auch ich schließlich leben ..." ) Und einen Debugger zu erkennen kann mitunter nicht immer einfach sein. Einfach nur zu Prüfen ob Int3 funktioniert, verdächtige Prozesso laufen, ... ist nicht alles (z.B. Kerneldebuger) , und läst sich recht einfach finden und auch entfernen. Mit der Debugger erkennung ist es somit alleine nicht getan. Der code bereich sollte zusätzlich noch einmal abgesichert werden genauso wie der eines copierschutzes.

und wieso den code debuggen, wenn ich den Programmcode direckt aus dem programm deassemblieren kann. Dann analysiere ich das programm nach alt väter sitte mit bleistift und papier. dann bringt eine debugger erkennung erzlich wenig.

mein motto ist sowieso verhindern kann man es nie. nur dem gegner schwer machen.

gruss

Schildkroete

Termite schrieb:

Sinn und zweck einer debugger erkennung ist doch sicherlich, zu verhindern, das sein program gedebuggt wird. bzw analysiert wird ( hat er glaubich auch andeuten wollem mit "... aber von irgendetwas muss auch ich schließlich leben ..." ) Und einen Debugger zu erkennen kann mitunter nicht immer einfach sein. Einfach nur zu Prüfen ob Int3 funktioniert, verdächtige Prozesso laufen, ... ist nicht alles (z.B. Kerneldebuger)

Klar, du hast aber in deinem vorigen Beitrag nur von einer VM gesprochen Anyway, ein Packer ist das A und O, aber solange man kein Skype-Budget hat muss man leider auf billige Packer zurückgreifen (welche oft keine VM haben) und so kann man zur Laufzeit einfach den originalen Code herausfinden, wenn man den Debugger nach dem entpacken und den Debug-checks des Packers anhängt. Daher, um dies zu verhindern, muss man eine mehr oder weniger uuverlässige Debugger detection coden, und dies kann man nicht einfach durch checken der checksums der Sections herausbekommen (HW breakpoints sind unsichtbar!). Das einzige was im ring3 einigermaßen klappt ist wiegesagt self-debugging oder ein manuelles Zurücksetzen der Debugregister.

PS: Ring0 debugger detection bei Ring3-Programmen ist reichlich dämlich