[HaBo]

marcotesoalli

Anzeige

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

Angehängte Dateien

1stOne.rar (4,7 KB, 114x aufgerufen)

xrayn

marcotesoalli

Danke^^

Würde es dann helfen, wenn ich die Strings ein paarmal verschlüssle vorm Vergleich?

mfg
marco

lightsaver

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.

xrayn

Wenn dein Code ordentlich obfuscated ist, wirds schwierig

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.

xrayn

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

Lesco

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.

unix256

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.

LaNdRiX

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".

__________________
mfg landrix