[HaBo]

F: Was sind Crackmes überhaupt?

A: Crackmes sind in der Regel Programme, bei denen bestimmte Funktionen besonders geschützt sind.
z.B durch Passwortabfrage oder ähnliches.Die Aufgabe ist es, an diese Funktionen zu kommen.
Es gibt hier einige Vorgehensweisen und der Autor entscheidet i.R welche davon erlaubt sind.

F: wie macht man das bloß? Wie löst man so ein Crackme?

A: Man analysiert das Crackme und versucht zu verstehen, was die einzelnen Bereiche
für eine Aufgabe haben. Dann muss man den richtigen Bereich finden und ihn, je
nach Aufgabenstellung, entsprechend bearbeiten oder die Routine komplett verstehen, um
diese selbst in z.B einem Keygenerator, umzusetzen. Da es dabei unzählige Variationen
gibt, ist es auch unmöglich ohne Kombinationsdenken und Hintergrundwissen auszukommen.
Das ist eben die Herausforderung - manch anderer spielt stattdessen Schach oder CS.



F: Warum nehmt ihr denn keine "echten" Programme? Ist doch viel spannender!

A: Weil man in der Regel dazu Reversengineering http://de.wikipedia.org/wiki/Reverse_engineering
betreiben muss. Ist also ein heikeles Thema an sich und deshalb in vielen Boards nicht gerne gesehen.
Warum? Weil die Webspaceanbieter da manchmal zu kurzen Prozess machen und das Board samt Datenbank
vom Server löschen. Es sei allerdings erwähnt dass in Deutschland die Freiheit der Forschung
greift, siehe dazu auch den Wikipedia link.
Außerdem würdet ihr doch auch nicht gerne sehen, wenn ihr monatelang eine Software schreibt und
in einem Board wird dann ein Verfahren veröffentlicht, die Software umsonst zu benutzen ?
Bei Crackmes dagegen hat man derlei Probleme nicht, da sie extra für diesen Zweck geschrieben wurden.


F: Wie fange ich an?

A: Wie auch bei allen anderen Sachen - am Anfang.
Lerne Google richtig zu bedienen. Richtig suchen mit Google
Das heißt auch dass 20 Minuten suchen nicht als "ich hab gesucht und nichts gefunden" gelten.
Lerne lesen. Das ist ernst gemeint, denn bloß drüberfliegen reicht nicht.
Lerne Programmieren (programmiersprachen lernen -- Was meint ihr??), nimm dazu eine Sprache die Dir gefällt,
aber Du solltest zumindestens die Sprachen verstehen, in denen die Crackmes geschrieben wurden. Lerne Assembly.
Schaue Dir an, wie Programme aussehen und ablaufen. Versuche einiges über systeminterne Abläufe
herauszufinden und zumindest im Groben zu wissen, was hinter den "bunten Fenstern" steckt.
Erst wenn Du das hast, kannst Du loslegen.


F: Ich (bin Noob und) möchte möglichst schnell alles lernen, kann mir das jemand beibringen?

A: Ob jemand sich Zeit nimmt und Dir alles erklärt, ist nur seine Entscheidung. Hier ist Eigeninitiative
gefragt. Es haben sich schon viele Leute die Mühe gemacht und Einsteigertutorials geschrieben. Siehe dazu Google.
Allerdings wird es mit der Einstellung "Zwei Wochen lesen und rumprobieren und dann bin ich der
krasseste Cräcker in der Nachbarschaft" nichts. Ist ja bei den meisten Dingen so.


F: Wozu muss ich Programmieren können? Ich will doch nur "cracken"?!

A: Kannst Du ein Auto reparieren, ohne zu wissen wie es aufgebaut ist?
Die meisten gängigen Programmiersprachen übersetzen den Programmcode in maschinenlesbaren.
Das ist der, den die (Ziel)CPU versteht, die das Programm eben ausführen soll.
Die ganzen komplizierten Funktionen werden also "zerhackt" und zerlegt.
Mit nur paar verschiedenen Anweisungen (AFAIK waren es 4, so genau weiß ich das nicht mehr,
ist schon länger her )kann man also die riesigen Programme wie Photoshop &Co. umsetzen.
In Wirklichkeit sind es zwar etwas mehr, aber in sehr übersichtlicher Anzahl.

Die Analyse der Crackmes geschieht also im "Low-Level" Bereich. Dabei hat man es sehr oft
(praktisch immer) mit Assembly zu tun: http://de.wikipedia.org/wiki/Assembly
Das ist die zum Maschinencode am nächsten liegende Sprache. Sie bietet prinzipiell 1:1
Umsetzung - eine Assemblyanweisung=eine CPU Anweisung. Deshalb kann auch ein in Maschinensprache
vorliegendes Programm in diese zuverlässig konvertiert werden. Höhere Sprachen wie C/C++ oder Pascal
sind abstrakter angelegt und generieren in der Regel für ein Sprachanweisung mehrere CPU Anweisungen.
Je nach dem sogar sehr viele. Deshalb ist es auch nicht möglich, das fertige Programm wieder in diese
Sprachen zu übersetzen. Denn es werden weder Variablennamen noch sonstige Informationen gespeichert.
Das heißt auch, dass man z.B nicht erkennen kann, ob es vorher eine while,repeat until/do while
oder je nach dem for-Schleife war. Da so ein Programm mehrere Tausend Anweisungen enthält, muss man sich
im Klaren sein, welcher Bereich wofür verantwortlich ist - sonst kann man jahrelang an einem Stück
Assemblycode sitzen, welcher z.B die Hintergrundfarbe des Dialogs regelt. Und ohne selber Programmieren zu
können ist es eben sehr schwer.


F: Was brauche ich für Tools?

A: So viele sind es nicht. Das Mächtigste ist Dein Wissen um die Hintergründe.
Dann gibt es Debugger wie OllyDbg. Er übersetzt den Maschinencode zurück in Assembly und bietet die
Möglichkeit,der CPU "bei der Arbeit" zuzuschauen - das heißt, wenn ein Programm ausgeführt wird,
sieht man in OllyDbg was für Werte woher, wo und wie berechnet und wohin zurückgeschrieben werden.
Man kann damit Schritt für Schritt jede einzelne Anweisung durchgehen. Er macht aber nichts
automatisch - wird also nicht den "richtigen" Bereich anzeigen oder automatisch die
Routine herausfinden können. Und wenn man nicht weiß was man macht, wird man auch hier jahrelang
eine Routine durchgehen, die sich um die richtige Fensterpositionierung kümmert.
Ein weiterer Debugger ist SoftICE. Im Gegensatz zu Olly ist es ein kommerzieller Debugger.

Zusätzlich gibt es noch DeDe,WDASM,IDA,Reflector und VB-Decompiler.
DeDe (Deplphi Decompiler) übersetzt aber nicht, wie der Name vermuten lässt, in Object Pascal
geschriebene Programme zurück. Vielmehr "zerpflügt" er die VCL (Visual Components Library)
in ihre Bestandteile und stellt sie übersichtlich da.VCL ist eine Bibliothek vom Compilerhersteller
Borland.Diese Bibliothek soll die Entwicklung von Programmoberflächen unter den IDEs Delpi und BC++
vereinfachen und hat alles nötige an Routinen um schöne bunte Fenster darzustellen. Damit kann
der Programmierer die Oberfläche sehr schnell zusammenfügen - und zur Ausführungszeit des Programms
kümmert sich diese Bibliothek eben um die Darstellung. Somit lassen sich mit DeDe auch die mit BC++
erstellten Programme analysieren.
Zusätzlich liest DeDe die vorhandenen Information aus der ausführbaren Datei aus, die ebentuell vom
Borlands Compiler hinzugefügt wurde - wie Unit und Prozedurnamen - und zeigt deren disassemblierten
(also in Assembly umgewandelten Maschinencode) an. Auch hier also braucht man Assembly.

WDASM ist ein Disassembler. Übersetzt Maschinencode in Assembly, zeigt Referenzen an.
Kann auch zum Debuggen genutzt werden, hier ist OllyDbg allerdings um einiges besser.
Auch kommerziell.


IDA - ein schöner Disassembler,Freeware - wenn man mit einer älteren Version zufrieden ist.

Reflector: ist etwas für sich - decompiliert die für .NET Framework geschriebenen Programme.
Das ist wiederum möglich, weil die Programme in einem sogenannten MSIL-Code vorliegen.
Dieser wird dann von der Common Language Runtime in den Maschinencode übersetzt.
Dank des CTS und der Bestrebung möglichst viel und gut zu optimieren,
werden hier auch viele Zusatzinfos mitgespeichert.Das macht die Decompilierung erst möglich:
http://www.dsdt.info/grundlagen/plat.../framework.php

VB_Decompiler: frühere VB-Versionen haben "gerne" einen sogenannten P-Code generiert.
Also Anweisungen, die nicht direkt im Maschinencode vorlagen, sondern erst noch interpretiert
werden müssen. Die früher "berüchtigten" VB-Runtime DLLs. VB_Decompiler stellt diesen P-Code mehr
oder weniger lesbar dar. Heutzutage funktioniert dies öfters nicht mehr, weil die Programmierer laut google
seit VB 5.0 die Option zur Erzeugung von "Maschinencode" haben. Trotzdem werden auch heute noch
viele Funktionen in die VB Dlls ausgelagert.

Es gibt noch einige Programme die einen unterstützen können, wie z.B PE-Editor, ImpRec,verschiedene Dumper.
Es würde allerdings den Rahmen der FAQ sprengen. Außerdem setzen diese Programme schon
voraus, dass man weiß was man tut - da ist nix mit lustigen Hilfsblasen oder Assistenten, die
einem Schritt für Schritt alles erklären .


F: Jetzt habe ich OllyDbg - und wie gehts weiter?

A: Man schaut sich hier im Board, bei Google - oder nicht zuletzt in der OllyDbg Hilfe um.


F: Gehts nicht irgendwie einfacher? Ich habe keine Lust so viel zu lernen!

A: Man muss eben alles im Leben lernen - sogar das Laufen . Wenn Du keine Lust hast,
dann lass es sein. Such Dir ein anderes Hobby.

F: Warum machen die Mods kein Tutorial mit steigernder Schwierigkeitsstufe?

A: Weil es eben nicht ihere Aufgabe ist. Wenn Du hier suchst, wirst Du sehr schnell
Crackmes verschiedener Schwierigkeitsgrade finden. Und bei allen ist eine Lösung dabei.
Wenn Du diese nicht verstehst, dann fange mit Grundlagen an - siehe auch Wie fange ich an?
Es bringt nichts, ein Tutorial für jemanden zu schreiben, der keine Wissensbasis hat.


F: Wie kann ich eigene Crackmes schreiben?

A: Du must eben eine gängige Programmiersprache beherrschen, die ausführbare Dateien
für Dein Ziel OS erstellen kann. Und Du solltest die Crackmes der gleichen
Schwierigkeitsstufe selber lösen können. Wenn Du weißt wie man eine Crackme löst, wirst Du
auch eine schreiben können. Andersrum kommt meist nicht viel raus.
Bedenke - es geht nicht darum möglichst viele fremde Schutzroutinen zu benutzen und
eventuell die krassesten Packer/Crypter die man kennt. Ziel einer Crackme ist es Herausforderung
durch den Code selbst zu bieten, durch Originalität - nicht die Zeit der Teilnehmer stehlen, in
dem man möglichst viel Unnütz einbaut. Nicht jeder hat Zeit und Lust mehrere Stunden an einem Crypter zu
sitzen, denn Du in 2 Sekunden eingebaut hast.Und bei solchen Crackmes geht die oft stolz geschriebene
"status - unsolved" Meldung eben zum größtenteil an den Packer/Crypterautor, nicht an Dich.


Anregungen, Berichtigungen oder Vorschläge für weitere Fragen bitte möglichst per PM schicken,
um der FAQ-Seite nicht unnötig die Übersichtlichkeit zu nehemen.