Kann mein eigenes CrackMe nicht lösen

Hi
Ich lerne gerade den Umgang mit OllyDbg. Hab schon paar CrackMe Turorials
"durchgearbeitet". Jetzt hab ich ein kleines Passwort Überprüfungs
Programm geschrieben, schaff das aber selbst nicht ^^.
Ich finde einfach keine Anhaltspunkte. Keine referenced text strings, keine
messagebox Aufrufe, nicht mal user32 (wegen msgbox) Aufrufe find ich.

Kann das jemand lösen... und dann ein Tipp geben ^^
Und sagen ob es zu schwer ist zum anfangen.

mfg
Vampir

EDIT: Natürlich ohne decompilen mit reflector oder ähnlichem. NUR OllyDbg oder vergl. Debugger
 
Natürlich ohne decompilen mit reflector oder ähnlichem. NUR OllyDbg oder vergl. Debugger
Gibt es dafür einen Grund? Es gilt eben "the right tool for the right job" ;)
Begründung:
NET wird im Prinzip interpretiert.
D.h im OllyDbg bekommst Du
1) den NET-Bytecode zu sehen (irgendwelche Stringreferenzen kann Olly da nicht rausziehen, weil der Bytecode eben NET-"Befehle" darstellt und Olly damit erstmal absolut nichts anfangen kann). Aus dem gleichen Grund gibt es auch keine direkten MessageBox Aufrufe - im Bytecode ist es als "Zeige Nachricht" kodiert - die eigentliche, konkrete Funktionsumsetzung übernimmt aber erst das Framework.

2) Einsicht in die Arbeit des Interpreters - nicht etwa der Exe selbst. Viel wird man dabei nicht erkennen. Zwar kann man trotzdem einige Details über Funktionsweise der Exe herausziehen (in dem man z.B direkt API Aufrufe in den jeweiligen DLLs loggt und sich anschaut - NET Frameworkt kocht auch nur mit Wasser - sprich, ruft für Funktionen WinAPIs auf), aber es ist fummelig und aufwendig.

Um es verständlich darzustellen: stell Dir vor, du hast ein altes Mac-Programm (noch für die Motorolla CPU) oder meinertwegen ein Handyprogramm.
Du kannst diese Programme also nicht direkt auf Deinem PC ausführen. Aber Du hast einen Handy/Mac Emulator. Nun willst Du die Programme verstehen, in dem Du den Emulator bei der Ausführung mit OllyDbg betrachtest? Prinzipiell geht das (und wenn es keine anderen Werkzeuge gibt, ist es auch der einzige Weg) - hat aber einen gewissen Touch von Masochismus ;)

PS: "vergleichbarer" Debugger wäre z.B IDA (leider ziemlich teuer). Die aktuelle Version sollte einen NET Disassembler und eventuell Debugger integriert haben.
 
Gibt es dafür einen Grund? Es gilt eben "the right tool for the right job" ;)

Ja, kein normaler Mensch würde ein Passwort Schutz in .Net programmieren
und den Code nicht durch einen guter Obfuscator schleudern :wink: (geh ich
jedenfalls mal davon aus).

Jedenfalls hab ich den relevanten Teil in IDA ausgemacht (s. Anhang).
Da seh ich das PW und die Strings der Msgbox.
Ich möchte jetzt nicht einfach das PW kopieren und das CrackMe als
abgeschlossen sehen, sondern irgendwie will ich das ganze jetzt manipulieren,
dass der ganze überprüf-Teil umgangen wird.
Also z.B den loc_1A8C "jump" noppen.
Aber ich habs noch nicht fertig gebracht überhaupt was in IDA zu manipulieren.
Geht das überhaupt oder ist es nur zum analysieren?
 
Ja, kein normaler Mensch würde ein Passwort Schutz in .Net programmieren
und den Code nicht durch einen guter Obfuscator schleudern :wink: (geh ich
jedenfalls mal davon aus).
Deobfuscatoren gibt es auch. Zudem sollten schon erste Net-Debugger verfügbar sein ;).

Aber ich habs noch nicht fertig gebracht überhaupt was in IDA zu manipulieren.
kommt auf Deine IDA Version an. Ich würde da speziell die Tutorials von tuts4you.com in "NET-Reversing" empfehlen.
IDA zeigt zumindest die zugehörigen Fileoffsets (unten in der Statusleiste)
damit lässt sich dann das ganze mehr oder weniger gut im Hexeditor patchen - wenn man die Liste der Opcodes hat:
http://en.wikipedia.org/wiki/List_of_CIL_instructions
http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes_members.aspx
http://fandigunawan.googlepages.com/CIL-Opcode-fin.pdf
(oder "IL opcode reference" bei google eingeben ;) )
 
Zurück
Oben