Anti-Debugging
-
Hallo
Ich schreibe derzeit einen Anti-Debugging-Schutz für eine meiner Applikationen und würde mir gerne euren Rat einholen. Ein Großteil wird in C geschrieben und die wesentlichen Schutz-Mechanismen in Assembler.
Erstmal eine Frage. Angenommen ich implementiere einen noch so guten Weg, um festzustellen, ob die Anwendung debugged wird. Am Ende habe ich meinetwegen aus meinem Inline-Assembler einen Wert gewonnen:BYTE BeingDebugged = 0; __asm { ... mov BeingDebugged, al } if (BeingDebugged) ExitProcess(1)Was hindert einen Reverse Engineerer nun daran einfach das ExitProcess "auszunoppen" oder den entsprechenden Vergleich (durch cmp + jnz) zu verändern?
Lässt sich eine höhere Sicherheit also nur durch Obfuscation + Junk-Code erzielen?Zur 2. Frage: Ich habe mir überlegt meinen Anti-Debugging Assembler-Code als ShellCode darzustellen und ihn in dieser Weise in meinem Programm zu verwenden:
char szShellCode[] = "Hier steht Shellcode!"; int main(int argc, char **argv) { int (*func)(); func = (int (*)()) code; (int)(*func)(); }Der Zweck hierbei ist, dass ich den Shellcode verschlüsseln werde (am Anfang einfach per XOR) und dann jeweils immer nur eine Anweisung (zB
mov ah, bl) entschlüssel und wie oben angegeben ausführe und danach wieder verschlüssel. Somit liegt dem Reverser zu keiner Zeit ein vollständiger Dump vor. Was haltet ihr von der Idee + den Ansätzen der Umsetzung? Funktioniert das Ganze auf diese Art und Weise? (die Anweisungen in dem Code-Bsp 2 werden ja auch die Register verändern, sodass die Shellcode-Anweisungen nicht mehr korrekt arbeiten können?)MfG, 0x2A
-
Einen 100%igen Schutz gibt es nicht.
Da haben sich schon sehr schlaue Köpfe (mehr oder weniger erfolgreich) dran versucht.Ein Besuch der einschlägigen Reverse Engineering Foren wird dir das schnell zeigen.
-
Das ist mir schon klar
Ich möchte es dem Reverser trotzdem nicht so ganz einfach machen. Über Antworten, die auf meine Fragen bezogen sind würde ich mich freuen!MfG, 0x2A
-
Code auf nem Server ausführen, client nur zur anzeige ist relativ sicher
-
Bezüglich Anti-Debugging: Wie würde das Programm erkennen, ob es in einer "Software-Umgebung" läuft, z.B. unter bochs? Gar nicht, oder? Nützt auch der beste Anti-Debugging Schrott nichts!
-
0x2A_ schrieb:
Zur 2. Frage: Ich habe mir überlegt meinen Anti-Debugging Assembler-Code als ShellCode darzustellen und ihn in dieser Weise in meinem Programm zu verwenden: ...
Das geht nicht. Die Variable szShellCode liegt im Datensegment. Datensegmente sind nicht ausführbar.
Unter Windows gibt es dazu folgende Möglichkeit:unsigned char dein_shell_code[] = "bla-bla. bla-bla"; unsigned char *p_mem = VirtualAlloc(NULL, sizeof(dein_shell_code), MEM_COMMIT, PAGE_READWRITE); void (*p_func)() = NULL; DWORD tmp = 0; memcpy(p_mem, &dein_shell_code[0], sizeof(dein_shell_code)); VirtualProtect(p_mem, sizeof(dein_shell_code), PAGE_EXECUTE, &tmp); p_func = (void (*)())p_mem; p_func();Das ist aber auch Schrott.
-
Zu 1:
Nichts haelt den klugen Reverser davon ab, solche Sicherheitsmassnahmen einfach abzuklemmen. Ich schaetze, sowas haelt allein vielleicht einige Minuten. Als spaetere Massnahme hinter geeigneter Verschluesselung/Kompression evtl. etwas laenger - zumindest wenn es dauerhaft entfernt werden soll.Zu 2:
Wie gesagt wurde: Keine gute Idee.Um neugierige Leute zu nerven gibt es haufenweise Ideen. Eine ist zB. in C++ zu programmieren und jeden Mist in eigene kleine Klassen zu kapseln - das erzeugt sehr haeufig schoen stokeligen Asm-Code.
-
Mache es wie Ubisoft und lasse einige Programmsequenzen auf einem Server laufen ^^
-
Mit SMC kann man zumindest Unerfahrene von RE abhalten. VirtualProtect braucht man nicht mal zwingend - die section Attribute kann man während des Linkens festlegen.
-
Spar dir die Arbeit und Schütz dein Programm erst gar nicht ^^
Das wird eh gecrackt zu 99,99% ^^
Spar dir die Zeit und mach was anderes oder mache es nur aus Lern zwecken (:
-
wenn du deinen schutz eingebaut hast, dann teste es doch einfach mal gegen ollydbg phant0m :p
-
Am besten selber mit verschiedenen debugging tools testen.
aktulle Bücher:und
Es kann aber zur Übung nicht verkehrt sein, wenigstens die grundlegensten Sachen abzustellen:
siehe auch:
http://www.searchlores.org/protec/lazatips.htm
http://vx.netlux.org/lib/?index=AA&lang=en..und daran denken, das viele exotische exe-packer den Virenschutz erschweren.
Wenn du dich für Verschlüsselung interessierst, sags, es gibt auch hier das ein oder andere gute Buch oder Programm.
-
Vielen Dank erstmal für die Beiträge!
@ nachtfeuer
Bin über beide Links noch nicht gestolpert (obwohl VX heavens in meinen Fav's ist) und finde sie sehr hilfreich! Danke dafür.Im Wesentlichen bin ich auch eher ein Gegner von solchen Maßnahmen (wie bsp. Ubisoft sie anwendet), da sie eh von professionellen Teams (SKIDROW, Razor1911 etc.) umgangen werden. Meine Anwendung ist allerdings nicht kommerzieller Natur und mein einziges Bestreben ist das Erschweren der Analyse und das Verschleiern von Funktionen. Man kann Cracking nicht verhindern doch man kann den Reverser in manchen Fällen davon überzeugen, dass er sich nicht die Zeit nehmen sollte das Programm zu cracken, wenn es einen gewissen zeitlichen Aufwand erfordert. Gleichzeitig werden RE-Neulinge abgeschreckt.
An Büchern/Papers zu Verschlüsselung bin generell interessiert, wenn es in dem Werk einen Bezug zur Anwendung unter C/C++ gibt
Mein Bedarf an allgemeiner Kryptographie ist mit "Grundkurs Codierung" mehr als abgedeckt und ich habe auch schon eine Abwandlung aus LFSR (Erzeugung von Pseudo-Zufallszahlen) und OTP (One-Time Pad) programmiert.MfG, 0x2A
-
Zu 1) nix
Zu 2) mein Bruder hat schon vor ca. 25 Jahren irgendein Spiel gecrackt (Uni-Langeweile), das genau damit gearbeitet hat: "Code immer vor dir herschieben und erst zur Laufzeit entschlüsseln".
Leider kann ich ihn nicht mehr danach fragen, da er vor 1 1/2 Jahren verstorben ist.
-
Protipp: lieber etwas Geld in Themida oder VMProtect investieren, und hast vermutlich erstmal deine Ruhe. Portable Anti-Debugging-Maßnaßnahmen gibt es nicht - das einzige, was vielleicht sinnvoll ist, ist das schreiben eines eigenen Debuggers der die Programmfunktionalität ergänzt.
-
0x2A_ schrieb:
... Meine Anwendung ist allerdings nicht kommerzieller Natur und mein einziges Bestreben ist das Erschweren der Analyse und das Verschleiern von Funktionen. ...
Und wozu? Investiere die Zeit doch lieber in das Schreiben von Programmen, die einfach zu analysieren und zu "debuggen" sind.
Kein Schwein wird sich je für deine Funktionen interessieren und wenn doch und wenn es sein muss, findet er einen Weg, um sie zu analysieren, ob in Zusammenarbeit mit dir oder ohne dich...
-
@ abc.w
Wie bereits mehrfach erwähnt möchte ich es einem durchschnittlichen/unerfahrenen Reverser nicht ermöglichen Einsicht in meine Prozeduren zu erhalten, denn meiner Meinung nach sind die meisten Reverser relativ unerfahren (typischer Tutorial-User: "Hey schau mal ich kann xy cracken!"). Mir ist noch immer bewusst, dass der Schutz von erfahrenen Reversern umgangen werden kann.
Gleichzeitig ist es eine interessante Thematik und ich sehe keinen Grund mich nicht mit der Programmierung von Schutzmechanismen zu beschäftigen und diese auch zu verwenden. Ob eine solche Verwendung auch bei kommerziellen Produkten sinnvoll ist steht auf einem anderen Blatt.@ EOP
Unterschied zu der im Startpost erwähnten Variante ist, dass bei dieser zu keinem Zeitpunkt eine vollständig entschlüsselte Variante des Codes vorliegt, wie dies bei dem besagten Spiel vermutlich der Fall war. Für einen Cracker in ein Schutz á la RunPE + Runtime-Decryption ein Kinderspiel.
MfG, 0x2A
-
CRACKERS NEVER DIE !
-
nop du, nop...
-
0x2A_ schrieb:
@ abc.w
Wie bereits mehrfach erwähnt möchte ich es einem durchschnittlichen/unerfahrenen Reverser nicht ermöglichen Einsicht in meine Prozeduren zu erhalten, denn meiner Meinung nach sind die meisten Reverser relativ unerfahren (typischer Tutorial-User: "Hey schau mal ich kann xy cracken!"). Mir ist noch immer bewusst, dass der Schutz von erfahrenen Reversern umgangen werden kann.
Gleichzeitig ist es eine interessante Thematik und ich sehe keinen Grund mich nicht mit der Programmierung von Schutzmechanismen zu beschäftigen und diese auch zu verwenden. Ob eine solche Verwendung auch bei kommerziellen Produkten sinnvoll ist steht auf einem anderen Blatt.@ EOP
Unterschied zu der im Startpost erwähnten Variante ist, dass bei dieser zu keinem Zeitpunkt eine vollständig entschlüsselte Variante des Codes vorliegt, wie dies bei dem besagten Spiel vermutlich der Fall war. Für einen Cracker in ein Schutz á la RunPE + Runtime-Decryption ein Kinderspiel.
MfG, 0x2A
Doch auch in den Anfängen wurde Code nur Befehlsweise entschlüsselt und dann ausgeführt, dann wurde auch noch falscher Code eingeführt und auch Code der so nicht fehlerfrei lief dann aber durch Selbstmodifikation abgeändert wurde. Den komplett falschen Code finde ich noch am verwirrensten. Aber egal alles schon dagewesen selbst code für selbstgebaute kleine virtuelle Maschinen der dann so erstmal gar keinen Sinn ergibt. Bau davon irgendwas ein oder kombiniere es für die Noobs der Rest knackt es dir in ein paar Stunden. Durch das Internet und Foren kommste mittlerweile so schnell an Infos dass das Cracken echt zum Kinderspiel wird.
Auch in meinen Augen ist die Auslagerung auf einen anderen Rechner mit asymetrischer Verschlüsselung der Verbindung das einzig sichere, alles was allein auf deinen Rechner läuft und der Cracker starten kann ist verloren.Packe dein Prg. in ein Archiv mit Verschlüsselung und gut ist, oder verschlüssle selbst Programmteile die nur durch Eingabe des Schlüssels freigegeben werden.
Asymetrische Verschlüsselung wo der Schlüsselaustausch sicher ist knackt dir keiner so leicht.