![[HaBo]](/styles/default/logoklein.png)
Arthis KeygenmeA0.3FINAL -unsolved
- Themenstarter sartre
- Beginndatum
Also irgendwie ist das fast dasselbe wie das andere (IMHO sehen die Zahlen im Stack usw genauso aus).
Drei Sachen sind neu - das Crackme startet wesentlich schneller (der Dump ist nur noch 2.7 MB groß), die Maus ist ans Crackme gebunden (kann nur Leute nerven, die Ollys Tastaturkürzel nicht kennen
) und eine "FalscheVBDLL Prüfung".
Das blöde an dieser Prüfung ist allerdings, dass der ACProtect die DLL vorher lädt, also bevor er das Crackme startet und das Crackme auch noch auf die DLL Funktionen zugreift, um herauszufinden ob es eine fake DLL ist *wer erkennt hier ein Dilemma?*.
Jedenfalls kann man dann in dem von der DLL erstellten Dump nachlesen, welche Funktionen zuletzt aufgerufen wurden (bevor sich das Crackme beendete) - ein Byte muss dann gepatch werden (was die DLL auch direkt beim Laden übernimmt 8) ). Ansonsten mussten zwei oder 3 Adressen angepasst werden.
Das Passwort lässt sich auf dieselbe Weise auslesen wie in der anderen Crackme. Z.B für
sartre ist 14F6ED346 gültig. Ich poste mal keine Lösung, vielleicht interessiert sich ja ein oder anderer dafür. Man braucht auch keine DLL, ein Loader mit Codeinjection sollte mehr als ausreichend sein - zuerst die richtige Routine finden und dann einen "Callback" oder ähnliches injezieren bzw. diese Routine auf den eigenen Code umleiten, der das Passwort ausließt. Habe neulich im Netz auch was vernünftiges zu den Loadern gefunden:
http://cracking.accessroot.com/
EDIT: was ich mit Loader meine: euer eigenes Programm startet das Crackme, patcht bestimmte adesse - schon ist ein Patch fertig. Um das Passwort auszulesen, muss man sich nur eine Methode überlegen das Passwort "sichtbar" zu machen - z.B in dem man eine eigene DLL (wo eine Messageboxroutine oder ein Dialog) drin ist "injeziert" (alle Funktionen dazu sind ja eher schon in der Crackme vorhanden). Und dann könnte man z.B einen Aufruf so patchen, dass die eigene Prozedur angesprungen wird, die dann das Passwort dumpt/ausliest.
Drei Sachen sind neu - das Crackme startet wesentlich schneller (der Dump ist nur noch 2.7 MB groß), die Maus ist ans Crackme gebunden (kann nur Leute nerven, die Ollys Tastaturkürzel nicht kennen
) und eine "FalscheVBDLL Prüfung". Das blöde an dieser Prüfung ist allerdings, dass der ACProtect die DLL vorher lädt, also bevor er das Crackme startet und das Crackme auch noch auf die DLL Funktionen zugreift, um herauszufinden ob es eine fake DLL ist
*wer erkennt hier ein Dilemma?*. Jedenfalls kann man dann in dem von der DLL erstellten Dump nachlesen, welche Funktionen zuletzt aufgerufen wurden (bevor sich das Crackme beendete) - ein Byte muss dann gepatch werden (was die DLL auch direkt beim Laden übernimmt 8) ). Ansonsten mussten zwei oder 3 Adressen angepasst werden.
Das Passwort lässt sich auf dieselbe Weise auslesen wie in der anderen Crackme. Z.B für
sartre ist 14F6ED346 gültig. Ich poste mal keine Lösung, vielleicht interessiert sich ja ein oder anderer dafür. Man braucht auch keine DLL, ein Loader mit Codeinjection sollte mehr als ausreichend sein - zuerst die richtige Routine finden und dann einen "Callback" oder ähnliches injezieren bzw. diese Routine auf den eigenen Code umleiten, der das Passwort ausließt. Habe neulich im Netz auch was vernünftiges zu den Loadern gefunden:
http://cracking.accessroot.com/
EDIT: was ich mit Loader meine: euer eigenes Programm startet das Crackme, patcht bestimmte adesse - schon ist ein Patch fertig. Um das Passwort auszulesen, muss man sich nur eine Methode überlegen das Passwort "sichtbar" zu machen - z.B in dem man eine eigene DLL (wo eine Messageboxroutine oder ein Dialog) drin ist "injeziert" (alle Funktionen dazu sind ja eher schon in der Crackme vorhanden). Und dann könnte man z.B einen Aufruf so patchen, dass die eigene Prozedur angesprungen wird, die dann das Passwort dumpt/ausliest.
hm, ja, es ging schon
. Wobei die wesentliche Schwiergkeit bei VB Crackmes normalerweise die ganze Auslagerung in die VB-DLL ist, sprich: für jeglichen Kleinkram wird die DLL-Funktion aufgrufen. Und dann noch das das Umständliche rechnen mit Zahlen : bevor z.B mit 605 oder 21.xyz gerechnet wird, wird sie 3-4 mal hin und her umgewandelt. Anderseits hat man den Vorteil (z.B MFC gegenüber) dass viele VB Funktionen so aussagekräftige Namen haben wie vbaStrCmp. IMHO besteht jetzt bei einer "normalen" VB Crackme der Aufwand darin, die Keyroutine zu finden, weil bei VB eben keine Windowsnachrichtenschleife gibt (diese ist AFAIK in der VB-DLL drin).
Und ACProtect "verschleiert" im Prinzip die ganzen DLL Aufrufe, so dass man nicht auf Anhieb erkennen kann, was jetzt gemacht wird. Aber entweder hat die Demo die "besten" Funktionen nicht, oder sie hält nicht das was sie verspricht - Memorypatch und solche Späße funktionieren ganz gut. Ok, ich könnte mir vorstellen, dass das MUPen hier kein Spass ist.
Das wäre ja so das Grundsatzproblem - wenn DLLs statisch eingebunden werden, werden sie vom PE-Loader automatisch vor dem start schon geladen. Beim dynamischen Laden könnte man ja noch paar Checks machen, bei VB fällt das leider ins Wasser, weil ohne die DLL es erstmal gar nicht läuft. Anderseits könnten ja die "Protect-Firmen" drauf kommen und ein paar Checks einbauen, ob das jetzt Original-DLLs sind (msvbvm60.dll oder eben msvcrt/MFC für viele VC++ Programme) oder nicht. 2 DLL || !2DLL
EDIT: hab noch was auf meiner Platte entdeckt, da sich anscheinend niemand mehr dafür interessiert:
Wobei für die Anleitung keine Garantie, dass es nicht die von dem anderen (ähnlichem ) Crackme ist.
Anleitung für den "Keysniff":
Dll in den Crackmeornder platzieren, Crackme starten und sich aussuchen, was man haben will
Damit kann man auch das Crackme relativ schnell lösuen:
mit der Dll im Ordner starten, Dump aktivieren, bis zur eingabe warten, jetzt den dump öffnen, Cursor auf die letze Anweisung: jetzt kann man im Olly den entsprechenden Adressen nachgehen.