Crackme from nooby of the year :D

Huggy · Apr 27, 2007

Hi!

Hab heute seit langem wieder paar crackmes probiert und - zu meinem erstauenen -ein paar geschafft! :-D

Nunja, jetzt würd ich gern wissen wie "schwer" (<-- muhaha) es für euch ist, meins (falls man es überhaupt crackme nennen kann^^) zu brechen.

Schreibt ruhig eure schärfsten Kritiken
Bewerft mich mit Schande
Verletzt meine Ehre!

Nunja, hier is das "berüchtigete" crackme :-D

Viel "Spaß"

mucki · Apr 27, 2007

Also das sind so die Crackmes die überhaupt keinen Spaß machen. Alleine wenn ich die Dateigröße (für einen einfachen Dialog) sehe, dann fehlt mir grad die Motivation. Krypto Analyzer sagt da sei MD5 drin, habs mir aber noch nicht näher angeschaut. Was soll das sein - eine Bruteme? Vielleicht kann man das mit einem Inlinebruter versuchen.

+++ATH0 · Apr 28, 2007

Das Passwort setzt sich zusammen aus:
Benutzername, Uhrzeit ohne ":" dazwischen, ein "@" und die Local Lan IP

Bei mir war es:
neotracer0046@192.168.0.4

Einfach einen BP auf lstrcmpiA setzen oder das AutoIt Script finden und anschauen.

CDW · Apr 28, 2007

Da komm ich wohl 5 Minuten zu spät

, aber trotzdem:

Vielleicht kann man das mit einem Inlinebruter versuchen.

der Source ist ja beigelegt

Bei AutoIt hat sich anscheinend seit 2006 immer noch nichts geändert - der alte Decompiler funktioniert immer noch zuverlässig.

+++ATH0 · Apr 28, 2007

Bei AutoIt hat sich anscheinend seit 2006 immer noch nichts geändert - der alte Decompiler funktioniert immer noch zuverlässig.

Naja, ich denke AutoIt ist auch nicht dafür ausgelegt Schutz für Software zu bieten.
Oder meinst du, dass AutoIt seitdem generell nicht weiterentwickelt wurde?

CDW · Apr 28, 2007

Oder meinst du, dass AutoIt seitdem generell nicht weiterentwickelt wurde?

Zumindest das Format ist scheinbar gleich geblieben, was z.B bei AHK nicht der Fall ist.
War aber eigentlich nur ein Hint zu einem im Board bereits vorhandenen Decompiler

Huggy · Apr 28, 2007

Hallo!

1) Danke für euren Zeitaufwand!
2) WIE findet ihr herraus, dass es sich um AutoIt handelt? :-D

3) Einfach einen BP auf lstrcmpiA setzen versteh ich nur halb, werds mir mal anschauen!
Danke!

So, hab n neues gemacht.sollte schwerer sein , hoff ich

Auch mit Autoit =D

cw2k · Jul 28, 2007

Na wer weiss die richtige Frage zu dieser Antwort

PHP:

MsgBox(0x20,"Crackmes [für 100]",@UserName & @HOUR  & @Min & "@" & @IPAddress1)

Kandidat: "Was ist ein P... ~hmmpf~ ;( ?"
QuizMaster: "Leider falsch. Was ist ein Passwort währe die richtige Frage zu dieser Antwort gewesen."

Auch schade, dass der VBS - MD5 Algorithmus erst gar nicht zum Einsatz gekommen ist.

Und wie ich finde, kann man auch mal erwähnen bzw. als Kommentar drin stehen lassen, dass dieser von 'Phil Fresle' stammt. Siehe:
http://www.frez.co.uk

Passwortchecks al la

Code:

If EingebenesPassword="DasSupergeheime Passwort" Then

sind ehr nicht so gut - weil da immer "DasSupergeheime Passwort" im Klartext im Quellcode und deren Kompilat bzw. Konfigurationsdatei steht.

Besser ist da mit Hashwerten zu arbeiten. Beispielsweise bildet man den MD5 Hash von "DasSupergeheime Passwort" (hier 7ce9b47a21fc662d68bf5b5c998e896b)
und verwendet diesen um das Passwort zu überprüfen. Also so

PHP:

If md5HashCreate(EingebensPassword)="7ce9b47a21fc662d68bf5b5c998e896b" Then

Als Crackme wäre so ein langes Passwort allerdings ziemlich unfair.
Bei Verwendung eines solchen Schemas sollte das Passwort maximal 4 Zeichen lang sein, damit man es mit einem MD5-Bruteforcer in vertretbare Zeit ermitteln kann.
Bei einem Crackme's geht es darum, die Passwortabfrage ausfindige zu machen, zu verstehen und zu entdecken wie diese funktioniert.
Einen MD5-Hash ausbrüten, mit nichts außer brutaler Rechenpower - geht ziemlich daran vorbei.
Wenn einem so was in der 'Praxis' begegnet, wird das gegepächt - oder wenn mit dem nachfolgend noch Daten entschlüsselt werden, diese für 'ohne Passwort leider nicht benutzbar' gestempelt.

Vergleichbar mit einem Rar-Archive wo man das Passwort nicht hat. Praktisch gesehen kann man da nicht viel machen, außer von irgendwo das Passwort her zu bekommen.

+++ATH0 · Jul 28, 2007

Hashes sind Schwachsinn.
Tauscht man aus oder man manipuliert den Execution Flow.

EDIT: Hmm. Merkwürdig. Zuerst argumentierst du für Hashes und am Ende sagst du, dass es Quatsch sei.

cw2k · Jul 29, 2007

Original von +++ATH0
Hashes sind Schwachsinn.
Tauscht man aus oder man manipuliert den Execution Flow.

Guter Punkt, da habe ich in dem Moment gar nicht dran gedacht. Aber sogenommen ist würde ich Hashaustauschen auch zum Patchen zählen.

Das Hashes Schwachsinn sind kann ich nicht nachvollziehen.
Auf alle Fälle find ich eine Passwortabfrage die mit Hashs arbeitet sicherer, als eine mit 'Klartext-Passwörtern' .

Original von +++ATH0
EDIT: Hmm. Merkwürdig. Zuerst argumentierst du für Hashes und am Ende sagst du, dass es Quatsch sei.

Ich habe mal meine Post nochmal gelesen und einige Rechtschreibt und 'Wortfehler' behoben, aber trotzdem so unverständlich -auch mit Fehlern- is das meiner Meinung nach wirklich nicht. Wogegen ich mich ausgesprochen habe, sind crackme's bei denen der Schwerpunkt das 'Ausbrüten' eines MD5-Hashpasswords ist.

+++ATH0 · Jul 29, 2007

Auf alle Fälle find ich eine Passwortabfrage die mit Hashs arbeitet sicherer, als eine mit 'Klartext-Passwörtern' .

Eine "Passwortabfrage" mit Hash ist ein völlig unsinniger Ansatz für Sofwareprotection.
Da sind sehr gute obfuscated durch VMs gemangelte Serial-Validation Routines der bessere Weg.

cw2k · Jul 29, 2007

Original von +++ATH0

Auf alle Fälle find ich eine Passwortabfrage die mit Hashs arbeitet sicherer, als eine mit 'Klartext-Passwörtern' .

Zum Vergrößern anklicken....

Eine "Passwortabfrage" mit Hash ist ein völlig unsinniger Ansatz für Sofwareprotection.
Da sind sehr gute obfuscated durch VMs gemangelte Serial-Validation Routines der bessere Weg.

Ohne Frage besser geht immer - nur schätze ich den Aufwand eine virtual Maschine zu entwerfen als recht hoch ein.
Aber allen 'verstecken & vernebeln' Tricks - das Hauptproblem bei lokalen serial protections ist nun mal das Server(exe) und Client(User) auf einer Maschine laufen und der Server(exe) (An)greifbar ist.
Zurück zur Praxis: Und da ist mir auch noch nicht eine VM-basieren serial-validation vor den Klicker/Debugger gekommen.
... aber Ansätze in dieser Art:
Bei DAEMON Tools (CD-Emulator) habe ich das erste mal gesehen, dass dort das gesamte Program von einer Art SoftwareCPU ausgeführt wird.
War keine Serialabfrage oder sonst was zu beanstanden - es war nur so das da die Exe im ACCII-Viewer verdächtig aussah und ich desswegen mit Ollydebug mal nachgeguckt habe, ob da nicht vielleicht der Wurm drin ist.

Hast du schon mal sowas realisiert bzw. wo gesehen?

+++ATH0 · Jul 29, 2007

Produkte wie VMProtect, Oreans CodeVirtualizer und ASProtect beispielsweise haben das und erfreuen sich immer größerer Beliebtheit.

Inliferty · Jul 29, 2007

Original von +++ATH0
Hashes sind Schwachsinn.
Tauscht man aus oder man manipuliert den Execution Flow.

EDIT: Hmm. Merkwürdig. Zuerst argumentierst du für Hashes und am Ende sagst du, dass es Quatsch sei.

Hehe ich find die Idee mit den Hashes nicht schlecht.
Ja als Crackme eher schlecht, aber als normale Protection?
Klar könnte man einfach den Hash austauschen oder nen JE zu einem JMP patchen, aber was wäre wenn das Passwort (Klartext) als Key verwendet wird um den Programmcode zu dekodieren.
Dann gibt es nur die Möglichkeit den Hash zu bruten.
Ja durch Analyse wäre es natürlich auch möglich ihn knacken.

cw2k · Jul 29, 2007

Original von Iarumas
Hehe ich find die Idee mit den Hashes nicht schlecht.
Ja als Crackme eher schlecht, aber als normale Protection?

Bei Winhex ist das z.B. so. Da brauch man zumindest eine gültige Serialnummer, damit mit dem darin enthaltene Passwort die Teile/Funktionen des Programms erfolgreich entschlüsselt werden können (Read/WriteProcessmemory...), die zum Speichern grössere Dateien, RAMInhalte,... nötig ist.
Natürlich biete auch ASProtect & Co. so'ne Features, ich wollte das hier nur mal erwähnen, weil bei Winhex die Protection noch pure, simple & 'Hausgemacht' ist.

+++ATH0 · Jul 29, 2007

aber was wäre wenn das Passwort (Klartext) als Key verwendet wird um den Programmcode zu dekodieren.

Dann kauft sich der Cracker einmal das Produkt und verrät allen das eindeutige PW für diesen Hash?

Keine langwierige RE-Arbeit mehr, so lobe ich mir das.

cw2k · Jul 29, 2007

Original von +++ATH0Dann kauft sich der Cracker einmal das Produkt ...

X( Ja was aber wenn Cracker kein Geld hat oder sich das Produkt vielleicht gar nicht kaufen will.
(Oder hat sich hier jemand ernsthaft Windows kaufen gewollt.

)

Klar ich sehe ganz klar deinen Punkt der Kritik. Und natürlich ist das nicht von der Hand zu weisen. Aber aus 'eigener Erfahrung' kann ich sagen, das obiger Grund doch schon ziemlich behindern/nerven, rauszögern kann.

Natürlich habe ich das damals nur zu 'wissenschafts- und Lehrzwecken' gemacht. :]
...das nur, das hier kein keiner falsche Schlüsse zieht.

+++ATH0 · Jul 29, 2007

Was ich eigentlich damit sagen wollte ist, dass man doch ganz einfach, bevor man einen Hash nimmt, das Produkt OHNE diese zusätzlichen käuflichen Features als Demo anbietet.

Dann muss man sich das Produkt auch erst einmal kaufen und kann danach noch schwieriger verteilt (Mehr Daten) werden als das PW vom Hash, dass man nach dem Kauf bei der ersten Veriante schon weiss.

Wenn man jedoch das ganze mit SerialValidation realisiert, welches auf der Hardware-ID basiert, genau dann muss sich der Cracker, auch wenn er das Produkt kauft, mindestens einmal damit richtig beschäftigt haben um es zu knacken.

cw2k · Jul 29, 2007

Richtig beschäftigen muss man sich schon damit, sonst wirds nur eine habe halbseidene Sache. Aber man macht das ja gern.
Bei den 'private Release' muss man zusätzlich noch aufpassen, das diese nicht mit seinem Kundennummer/ Name 'getaggt' sind wie das z.B. bei IDA realsiert wurde. Also um auf Nummer sicher zu gehen ist es gut zwei 'private Releases' zu haben und diese dann mal zu vergleichen (auch auf Kleinigkeiten wie z.B. Dateidatums achten).

Gern oder Gar nicht. Wenn man 'reingucken' kann und sich drauf einlässt - bedeutet Hardware-ID nur noch mehr Spass. Solche HardwarewareincompatiblitätsBug behebt man natürlich - mit dem Debugger <- man kennt sich ja schiesslich damit aus.
Entschlüsslungs-Passwörter werden - sofern sie nicht mit persönlichen Daten 'verunreinigt' sind im Programm 'festverdrahtet'.
Oder wenn möglich ganz entfernt und entsprechend verschüsselte Daten mit unverschlüsselten ersetzt. Für mehr Offenheit, Transperanz ...und besser Packraten.