Erstes Crackme [solved]

M

marcotesoalli

0
Hi ihr^^... Also ich hab mal mein erstes Crackme geschrieben (bin noch nicht so gut im Programmieren)

Bitte versucht mal es zu lösen und sagt mir dann wie die Schwierigkeit in etwa ist (ich schätze 0 =P) und was ich von meinem Kenntnisstand aus besser machen könnte.

mfg
marco

//edit: habe das File angehängt.// root
 
Man muss nur eine Eingabe machen, bei der die dezimalen Werte folgenden String ergeben: 8284551155110790. Das ist nicht weiter schwer, wenn man so etwas zur Verfuegung hat. Ich hab mich mal fuer folgende Eingabe entschieden:
82 84 55 11 55 110 7 90
R T 7 [strg-k] 7 n [strg-g] Z
schaut in der Konsole dann so aus: RT7^K7n^GZ
 
Tips gibt es in so einigen Threads hier.
Die Verschlüsselung kann man im Regelfall erstmal nachvollziehen. Des Weiteren kommt es darauf an, ob du Patchen erlaubst oder nicht. Du kannst vor dem Vergleich noch so gut verschlüsseln, wenn es letztendlich auf einen normalen Vergleich, also z.B. if ("verschlüsselter Text" == "gespeicherter Key") hinausläuft, dann kann man den vergleich einfach patchen. Genauso sollte ein Key nicht komplett gespeichert sein (weiß jetzt nicht, ob das bei dir der Fall ist).

Suche mal ein wenig im Forum, da wirst du auf einige Tips stoßen, die dir sicher weiterhelfen.
 
Ja das ist wahr, aber ein gutes Konzept bringt auch nichts, wenn man es weg-nop-pen kann. Schonmal von lena151 ein unpackme/crackme gesehn, da sieht man was Obfuscation anrichten kann :)
 
Original von lightsaver
Security by obscurity ist keine gute Idee. Wenn das Konzept unsicher ist, bringt ein Verschleiern nicht viel und man sollte sich nicht darauf verlassen.
Zum Vergrößern anklicken....

Es gibt keine völlig sichere Softwarelösung, wenn man etwas ausführen kann, kann man es cracken(von entsprechenden Hardwarelösungen abgesehen, wobei dort auch eine entsprechende Analyse zumindest in der Theorie möglich ist), daher ist security by obscurity in diesem Bereich ein durchaus sinnvolles Konzept, da es darum geht den Aufwand für den Reverser soweit zu steigern, dass sich ein Angriff darauf nicht mehr lohnt und er demotiviert aufgibt. Dies kann sehr gut durch obfuscation erfolgen, bereits eine Übertragung der wichtigen Codestellen in eine Art VM-Zwischencode der erst wieder interpretiert werden muss, macht es dem Cracker bereits wesentlich schwerer, auch wenn es sich dabei letztlich um security by obscurity handelt.

Allerdings war dieser Absatz jetzt nur auf kommerzielle Anwendungen bezogen und nicht auf CrackMes, bei welchen die Demotivierung des Angreifers nicht das Ziel sein sollte, genausowenig wie die Verwendung von fremden Packern. Dabei sollten m.E. eher interessante Konzepte, Probleme oder Ideen im Mittelpunkt stehen und nicht das bloße Zermürben des Reversers damit möglichst lange "unsolved" am CrackMe steht, schließlich würde sich niemand der noch bei Trost ist, ellenlangen, uninteressanten, fremden Assemblycode antun, bloß um ein CrackMe zu lösen.
 
Hallo,
ich arbeite mich gerade in das Thema ein und habe mich daher auch mal versucht.
Im Dateianhang meine Lösung.

Was mich aber nun mehr interessieren würde, ist ob ich eine "gute" Lösung gefunden habe oder ob es bessere gibt.
Ich habe einfach das JNZ durch JZ ersetzt. Daduch erhalte ich immer (wobei ich aber glaube, dass ich die Falschmeldung erhalte, wenn ich nun eine richtige Nummer eingeben würde?) die Richtigmeldung.
 
Der Thread ist zwar schon uralt, aber egal.

Ja, wenn du nun den Richtigen Key eingeben würdest, bekämst du die Falschmeldung.

Das einfachste wäre hier (und da keine Regeln angegeben sind ist dies wohl auch erlaubt) den von die editieren JNZ-Befehl einfach weg zu "nopen".
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben