Come 'n crackme

[SOLVED] Come 'n crackme

Hallo,

anbei ein kleines (unter 30 Codezeilen) Crackme von mir. Das ist in diesem Forum fast schon ein Muss. :wink:

Schwierigkeitsgrad:
Mittel.

Dateiformat:
ELF (32 Bit)

Ablauf:
Man wird nach einem Passwort gefragt. Gibt man das richtige Passwort ein, dann zeigt das Crackme eine geheime Zahl auf dem Bildschirm an.

Ziel:
Einziges Ziel ist es mir die geheime Zahl zu nennen. Das Passwort muss hingegen nicht genannt werden.

Erlaubte Mittel:
Alle, inkl. Patching.

Sonstige Hinweise:
Den Sourcecode des Crackmes stelle ich hier online, sobald die erste, richtige Lösung vorliegt.

Happy cracking.

Greetz
Hackse
 
Zuletzt bearbeitet:
kann da dran leider nicht abreiten -.- kein Linus debugger auf dem PC.
Grade auch mal gegoogelt leider nichts gefunden um mit IDA+win laufen zu lassen -.-

mfg
schade

in IDA sah das programm jedoch nicht sehr komplex aus ^^
 
Die sinnvollste Software für Windows ist Cygwin um Linux laufen zu lassen. Da kann dann der GNU Debugger (gdb) verwendet werden.

Das Crackme hat unter 30 Zeilen Source und ist nicht so komplex. Anyway, ein paar Fallen sind einprogrammiert, keine Sorge. :-)


Greetz
Hackse
 
Sorry bin neu hier und wollte mal fragen wie ich die gecodete crackme starten muss ?! hab mir cygwin heruntergeladen und installiert..wie gehts jetzt weiter? hab mit cygwin leider noch nie gearbeitet :S
 
Wenn ich das eingebe kommt folgender Fehler:

Code:
$ ./crackme
./crackme: ./crackme: cannot execute binary file

Könnte es daran liegen das ich zusätzliche Pakete für Cygwin benötige, oder liegt der Fehler in der crackme? Wenn es an Cygwin liegt welche Pakete benötige ich dann alle?
 
Nun, die beste Lösung wäre Windows endlich in den Müll zu werfen und ein Linux zu installieren. :)

Das crackme ist in Ordnung.

Versuche mal vor dem Execute ein
Code:
chmod 750 crackme


Greetz
Hackse
 
Hi,

wäre nett wenn jemand seine Vorgehensweise posten würde, wenn er es geschafft hat :)

Habe es mir unter Windows mal mit IDA angeschaut. Allzu kompliziert scheint das Programm an sich wirklich nicht so sein.

Wie ich jedoch unter Linux mit dem gdb an die Sache herangehen soll, weiß ich noch nicht so genau. Ich lese erstmal das Tutorial dazu weiter.


zeal
 
Dateiformat: ELF.....:rolleyes:

Ist Dir klar, dass ELF das Standardbinärformat unter Linux ist?

Ein unter Linux entwickeltes Crackme, das auf linuxartige shared libraries zugreift, verwendet nun mal auch ein linuxartiges Binärformat (ELF). Das sollte Dir nicht so abwegig erscheinen.

- Bist Du ohne PE-EXE-Format und Windows aufgeschmissen?
- Bist Du nicht in der Lage einen Linux-Debugger zu verwenden?
- Weisst Du nicht wie man unter Linux ein Programm ausführt?

Bitte beschreibe Dein Problem ein bisschen präziser. Dann kann ich Dich beim Cracken unterstützen.

Greetz
Hackse
 
Es ist nunmal so das die meisten unter Win Systemem reversen. Kannst ja mal fragen wer hier ohne Olly RE betreibt. Du hast gefragt warum es noch keine Lösungen gibt und ich habe dir eine Antwort darauf gegeben, woran es meiner Meinung nach liegt.

Willst du eine breite Masse hier ansprechen so wäre es vorteilhaft auf PE +compilierte Sprachen zu setzen.
 
Denjenigen die einen OllyDbg ähnlichen Debugger für Linux suchen, kann ich EDB wärmstens empfehlen:
http://www.codef00.com/projects.php#debugger

@Hackse
Wenn ich das richtig sehe bringt patchen hier wenig und es muss zur Lösung ein eigenes BruteForce-Programm geschrieben werden?!
Falls dem so ist, könntest du bitte die Länge des Passworts und ein relativ kurzes dazu passendes Charset angeben? Möchte meinen Rechner ungern länger mit BruteForce beschäftigen.

PS: Ich finds gut, dass gelegentlich auch mal Linux Crackmes gestellt werden.
 
@ivegotmail

Sehr gut, auf so eine Antwort habe ich gewartet.

Richtig, dieses Crackme kann durch Patchen nicht gelöst werden. Manipulierst Du die Hauptverzweigung, dann ist die Geheimzahl immer Null und somit falsch.

Du liegst ebenfalls richtig mit der Einschätzung, dass ein Bruteorce-Algorithmus zur Lösung des Problems unerlässlich ist.

Anbei die von Dir geforderte Info:
Passwort-Charset: {1234abcdestvTU.}, (Achtung, letztes Zeichen ist ein Punkt: "."), 8-stellig.
Mit o.g. Infos wirst Du im worst case ca. 3 Milliarden Permutationen berechnen müssen. Das sollte schnell gehen


Greetz
Hackse
 
in IDA sah das programm jedoch nicht sehr komplex aus ^^
Das ist korrekt, doch wie Du siehst hängt das Lösen eines simplen Crackmes nicht ausschließlich vom Komplexitätsgrad des Sourcecodes ab, sonst gäbe es längst eine Lösung. Ich möchte den Schwierigkeitsgrad dieses < 30-Zeilen Crackmes ungern von „mittel“ auf „unlösbar“ stellen, nur weil hier scheinbar die Meisten ohne Windowsdebugger ratlos sind.

Ich kenne keine Universität, deren Informatikstudenten sich nicht ausgiebig mit Unix/Linux auskennen, daher kann ich nicht nachvollziehen, wieso dieses Crackme noch fröhlich atmet.

Anbei ein Ratschlag zum allgemeinen Vorgehen:
Bevor man ohne zu überlegen den Debugger anwirft (sorry), sollte man erst mal deterministisch analysieren was das Programm so tut, d.h. welche Funktionen es mit welchen Parametern wie oft aufruft, welche shared libraries es verwendet, welche Strings im Programm vorhanden sind, etc. Dies alles lässt sich de facto mit Linux Standardmitteln herausfinden, und die resultierenden Informationen sind derart aussagekräftig, dass jeder Blick in den Debugger Zeitverschwendung ist. Man benötigt somit für dieses Crackme keinen Debugger und auch sonst abgesehen vom Bruteforce-Algorithmus, der in 15 Min. entwickelt werden kann, keine Non-Standardsoftware. Das Crackme ist somit sogar von einer Linux-Live-CD lösbar ohne irgend etwas zusätzlich zu installieren.

Sorry, wenn ich ab und an etwas gemein klinge. Informatik ist u.a. ein Synonym für das Bestreben permanent und kontinuierlich dazuzulernen, daher sollten vor allem die Windows-Leute mal versuchen sich mit den schönen Dingen um Windows herum zu befassen.

Einfach Fragen stellen. Ich gebe Euch alle Antworten, die Ihr benötigt um dieses Crackme zu lösen.


Greetz
Hackse
 
Zuletzt bearbeitet:
Ich habe nur kurz drübergeschaut, da ich auch kein Linux zum Testen da habe. Kann es sein, dass der Check so aussieht?
Code:
crypt(pw, pw[0:1]) = "CCAD.x3WG4xno"
secretNumber := pw[4]
Dazu gibt es folgendes Wissen:
Code:
Alphabet: "1234abcdestvTU."
Länge: 8 Zeichen
crypt ist natürlich eine relativ langsame Hashing-Funktion, deshalb läuft eine Brute-Force-Attacke trotzdem lange. Liege ich bis dahin richtig?

Edit: Das würde natürlich bedeuten, dass der Salt "CC" ist, genauso wie die ersten beiden Zeichen des Passworts. Das wiederum würde dem von dir angegebenen Alphabet widersprechen. Hast du vielleicht 'nen kleinen Tipp?
 
Zuletzt bearbeitet:
Code:
crypt(pw, pw[0:1]) = "CCAD.x3WG4xno"
Edit: Das würde natürlich bedeuten, dass der Salt "CC" ist, genauso wie die ersten beiden Zeichen des Passworts.
O.g. Annahmen sind falsch. Ich komme später noch zum Salt.
Code:
secretNumber := pw[4]
Alphabet: "1234abcdestvTU."
Länge: 8 Zeichen
Korrekt. Die SecretNumber entspricht der Integer-Repräsentation der vierten Stelle des korrekten Passwortes. O.g. Annahme setzt somit voraus, dass Deine Indizierung bei "1" anstatt bei "0" beginnt.
Das wiederum würde dem von dir angegebenen Alphabet widersprechen.
Das Alphabet bezieht sich nicht auf den Salt, sondern auf das Passwort.
Hast du vielleicht 'nen kleinen Tipp?
O.k., folgende Infos zum Salt.

- Der Salt hat keinen konstanten Wert,
- sondern er durchläuft im Programm eine Iteration über einen (wohl definierten) Definitionsbereich.
- Der Definitionsbereich des Saltes ist im Klartext im Binärcode hinterlegt.
- Der Salt, den Du suchst, ist einstellig
 
Zuletzt bearbeitet:
Dann verstehe ich gerade mehr nicht, als ich dachte. Soweit ich weiß hängt die crypt-Funktion den Salt vorne an der Hash an. Der kürzest-mögliche Hash (für DES-Crypt) ist zweistellig. In diesem Fall müsste das demnach "CC" sein.

Das ist (zum Teil) der Code, den IDA mir ausgibt:
Code:
loc_8048653:
movzx   eax, byte ptr [ebx]
mov     esi, s2
mov     [esp], edi      ; key (8-stellige Benutzereingabe)
mov     [esp+2Dh], al
lea     eax, [esp+2Dh]
mov     [esp+4], eax    ; salt (??)
call    _crypt
mov     [esp+4], esi    ; s2 ("CCAD.x3WG4xno")
mov     [esp], eax      ; s1 (generierter Hash)
call    _strcmp         ; (strings müssen gleich sein)
test    eax, eax
jz      short loc_80486B0
Ungünstig ist, dass ich in statischer Code-Analyse gar nicht gut bin. Mit einer Mac-Version wäre ich wahrscheinlich schon weiter.
Meine Vermutung ist momentan, dass zumindest diese Annahme richtig ist:
Code:
crypt(pw, salt) = "CCAD.x3WG4xno"
Was mir auf jeden Fall weiterhelfen würde, wäre, wenn du zumindest eine Stelle (besser zwei) des richtigen Passworts verraten könntest. Alle acht Zeichen zu Brute-Forcen dauert einfach zu lange.
 
Zurück
Oben