[HaBo]

sartre

Anzeige

Hi,

mal ein neues Crackme von mir !


1. Wie immer in VB6
2. Anti Loader, Debugger, Patcher etc. Subroutinen
3. Double-String Encryption? Technologie ( selbst Entwickelt )
4. Freeware EXE-Protector ( modifiziert ) --> Bei Antivir, NOD32 und evtl. Bitdefender Engines kann es zu ( FALSCHEN ) Virenmeldungen kommen !
5. Und vieles mehr...

Angehängte Dateien

Arthis_Crackme_delta7.zip (17,9 KB, 108x aufgerufen)

Voodoo

Es trägt zwar jetzt nicht wirklich etwas zum Thema bei aber darf ich trotzdem mal fragen warum du das Ganze "Arthis Crackme" nennst? Wäre "satres Crackme" nicht angebrachter?

sartre

Weil ich als "Arthi" mit den Crackmes angefangen habe. Außerdem ist "Arthi" weltweit in der Hacker, Cracker, Crackmes und Warez Szene besser bekannt als "sartre".

SUID:root

LOL.

Arthi, sonst gehts dir aber gut, ja?

CDW

wennn die Serial nicht Systemabhängig ist:
889875 nicht wahr, Peter (was VB so alles in die EXE mitspeichert)
Serial finden:
Crackme öffnen, irgendwas eintippen, in Olly attachen, BP auf 733B8E2C
F9 bis es läuft, "Registrieren". Plop - im Stack kann man die richtige Seraial auslesen.
Hatte die übrigens schon relativ früh - konnte aber nicht glauben dass es die Serial sein kann, weil die so kurz ist
Hab übrigens die Exe weder entpackt noch irgendwie sonst beeinflüsst, micht würde allerdings interessieren wozu da WriteProcessMemory,CreateToolhelp32Snapshot &Co drine sind.

Wer Die Crackme selber lösen will, muss sich ja die Lösung nicht anschauen

__________________
Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf!
Selig, wer nichts zu sagen hat und trotzdem schweigt.

sartre

Ja, der PC ist auf den Namen "Peter" registriert !


PS: Hey, ich glaube das Du uns was vormachst ! Wie komme ich denn auf 733B8E2C ?
- So weit reicht die EXE doch garnicht !
Und ohne den Crypter zu entpacken ? - Wenn ich Deinen Anweisungen folge, schließt sich mein Crackme sofort, selbst wenn ich F8 bzw. F7 zum Step Into/Over gehe !

Nein, Du arbeitest ganz sicher NICHT mit Olly. Mein Programm enthält spezielle Anti-Olly Sub´s und der Crypter sicherlich auch !

Außerdem ist mein Prog absichtlich in P-Code kompiliert worden. Wenn, dann ginge es ( NACH dem entpacken ) nur noch mit WKTVBDE. Und dagegen ist es auch geschützt !

Also da stimmt was nicht !

CDW

Oh doch. Ich sage ja nicht dass ich die Crackme im Debugger lade - dann geht es natürlich nicht, aber man kann diese auch attachen. Denn beim attachen (im Ring3, per OS API) wird der Prozess afaik "zugefroren" und die nächste Anweisung ist der BP. Wenn man deine Crackme mit dem Olly lädt, dann wird ja auch die Anti-Debuganweisung ausgeführt.

Probiers mit GOTO Adresse . Ist nämlich der Adressraum der MSVBVM60 DLL.
Um alle "Memoryadressräume" zu sehen gehe in Olly unter "View"->"memory"
Mit GOTO kommt man immer zu einer gültigen Speicherstelle.

Ich hab den P-Code mir gar nicht angeschaut und zum Entpacken bin ich zu faul - wozu auch, wenn die VB.DLL alles intern macht. Wenn man deine Crackme einfach startet und was eintippt landet es im Heap. Da muss man nur danach suchen. Ein wenig rumspielen und beobachten. F9 drücken und bestätigen bis die sich schließt und dann den Stack durchgehen.

Genauere Anletung: Crackme öffnen, was eintippen, in Olly attachen. Jetzt landet man bei 77F62838 6A 08 PUSH 8
(Hab in Olly unter Einstellungen "Break on new thread/DLL" an und BP bei WinMain)
das ist wohl die Nachrichtenschleife oder ähnliches.
Jetzt kannst Du unter "View"-> "Memory" viele schöne speicherbereiche auswählen.
Aber man kann auch ein goto 401000 machen (deine EXE). Hier findet man recht schnell die Import Table (binary string suche nach FF 25 was ein far Jump ist).
ein Rechtklick darauf und Follow in the Dump:
das sind die Adressen die angesprungen werden. Aus der letzen Crackme weiß ich dass es sehr wahrscheinlihc die VBDlll ist. Aber zurück zur dieser JMP Tabelle:
auf alle ein F2 (BP setzen). Und F9 zum ausführen. Nach ein paar F9s kann man "Registriern" betätigen und landet auf einem BP.
Jetzt mit F9 einfach immer weiter bis man eine Exception reingewürgt kriegt. Hier siehe man ins Stackfenster:
das hab ich ehrlich gesagt zuerst für den Key gehalten. Aber weitergehts:
noch mal SHIFT F9 und man darf den laufzeitfehler "0" wegklicken, danach beendet sich die Crackme. Nochmal öffen, pass rein und diesesmal im Dumpfenster ein GOTO 001a738C
machen. Hier großzügig einen Speicherbereich markieren(ist eben der heap und die aderessen müssen nicht zwangsläufig immer dieselben sein) und einen BP "Memory on access" setzen. F9 und "registrieren". Nach einiger Zeit stellt man fest dass die Nummer nichts damit zu tun haben, aber man kommt mal auf die Idee nach dem usernamen zu suchen. Der wird übrigens schon bei der Eingabe eingelesen. Naja, jetzt F9 und auf die Exeption warten. Jetzt STRG+B und nach dem Benutzernahmen in UNICODE suchen:
nochmal alles neustarten, diesesmal aber einen Memory BP eben großzügighierhin setzen. Jetzt auf Registrierung klicken und man landet eben auf diesem Speicherpunkt, wo noch kein Name steht - aber man darf mittels F9 zusehen wie er reingeschrieben wird. Noch ein F9 und in den Stackfenster sehen:
noch ein F9 (falls man nicht schon hier ist):
blick auf die Register. Blick auf REPE CMPS WORD
Und jetzt die Preisfrage wie ich auf 733b8e2c komme:
Stackfenster etwas runterscrollen:
Und 733xyz ist die Adressspace von der VBDLL.
Für die Wissbegieriegen: wir gehen mal auf die 733B8E46 im CPU-Fenser und scrollen hoch bis:
jetzt schaut man mit irgendeinem Tool (Olly?- Olly: in Olly die msvbvm60 laden)
ein goto:733B8E46
was steht da?

So, jetzt hab ich mich wieder rausgeredet, damit ich mein Super_Hypertool nicht preisgeben muss, welches eigentlich solche Crackmes automatisch anlysiert

WKTVBDE kannte ich gar nicht, leider ist auch die offizielle Seite nicht mehr da (war das kostenlos? wenn ja kennt jemand einen Link drauf?) . Das Ding wäre ganz nützlich. Der P-Code muss übrigens trotzdem ausgeführt werden - von der VB Virtual Machine. Einer Referenz dafür und man könnte den auch so lesen.

Aber ich dachte der Crackmeersteller muss immer seine Crackmes auch selber cracken können, oder irre ich mich ? Gilt es jetzt möglichst viele Schutzmechanismen draufzuknallen deren Arbeitsweise man gar nicht versteht und dann zu behaupten es wäre unknackbar (man verzeihe mir die Bissigkeit, aber das musste auch mal sein). Soll ich mal eine Crackme schreiben welche auch niemand knacken kann? Ganz ohne Packer. Ich lasse nur die eingegebene Serial per MD5 haschen und die restlichen Jumps im Programm sind Serialabhängig - wer die nicht kennt, der kennt die nicht

PS: in der letzen Woche habe ich wahrscheinlich mehr Crackmes gemacht als in den letzen 2 Jahren. Die sind zwar eine Art Hobby, vertieft habe ich es nie. Etwas Systemkenntniss und grobe Kenntnisse der Funktionsweise von Windows-executables reichen für die meisten Crackmes gut aus *auf andere Crackmes in diesem Unterforum schiel*. Für manche muss man eben etwas tiefer in die Trickkiste greifen (wie mit der DLL). Der Witz an der Sache ist dass ich durch Crackmes erst zum Programmieren gekommen bin - und mich auch für Assembly interessiert hab.

__________________
Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf!
Selig, wer nichts zu sagen hat und trotzdem schweigt.

+++ATH0

Hehe. Bei diesen Worten fällt mir doch gleich ein Crackme ein, dass von einem Profi namens Hagen gemacht worden ist. Er stellte sein Crackme auf der www.delphipraxis.net vor. Und DAS ist wirklich unknackbar. Er hat die Technik patentieren lassen.

Kannst es ja mal probieren:
http://home.arcor.de/neotracer/Serial.rar

Damit du dir nicht die Zähne daran ausbeisst hier die Begründung, warum es unknackbar ist:

Ok, ich gebe zu meine Demo ist echt hinterhältig.

1.) sollte sie nur EINE Serial zulassen, was demzufolge einem Verschlüsselungsalgorithmus mit einem Passwort entspricht. D.h. nicht das ich dies nicht ändern könnte. Es wären also auch mehrere Serials als Passwörter möglich ohne die jetzige Sicherheit zu reduzieren.

2.) für jedes System das nur softwarebasiert arbeitet kann man sagen das es 100%'tig knackbar sein muß.

3.) jedes System das einbruchssichere Hardware benutzt, und korrekt konzipiert wurde, kann man beweisen das es 100%'tig sicher sein muß.

4.) die Demo entschlüsselt ihren ausführbaren Code mit dem Serialkey. Dieser Code lädt die verschlüsselte Resource des TForm2 und erzeugt es. Der dafür nötige Schlüssel ist 256 Byte groß und absolut Zufällig. Er steht im Codesegment an erster Stelle des verschlüsselten Codes zur Erzeugung des TForm2. D.h. 256Bytes = 2048Bits = 2^2048 verschiedene Schlüssel und somit ist eine Bruteforce Attacke auf die DFM von TForm2 absolt ausgeschlossen. Gleichzeitig dienen diese 256 Bytes als Zufallsmuster um den eigentlichen TForm2-Erzeugungscode zu schützen. Da ja dieser Key + dem TForm2 Code ebenfalls durch die Serial verschlüsselt wurde.

Wird eine Serial eingegeben so wird nun dieser DFM Key + der Code zur Erzeugung des TForm2 entschlüsselt. Danach wird, egal ob der Key korrekt war oder nicht, dieser entschlüsselte Code aufgerufen. Asserbad, ich nehme mal an das dein Debugger/EXE des öfteren abgekackt ist. Tja, ohne richtige Serial ?! Soll heissen, mit falscher Serial wird inkorrekter Code erzeugt der natürlich zum Absturz führen kann. Ok, an eurem System wird nichts kaputt gehen, dazu habe ich einen harten SEH reingebaut.

5.) der Verschlüsselungsalgorithmus selber ist mein PMC = Polymorph Cipher. Er erzeugt sich ständig veränderlichen Maschinencode der als Verschlüsselungsalgorithmus dient. Der Key und die Message bestimmen also mit welchem Code verschlüsselt wird. Jeder 32 Bytes Message Block wird durch einen anderen 8Kb-128kb Maschinencode ent/verschlüsselt. Die DFM Resource von TForm2 ist 16Kb / 32 * (8Kb + 256 *4) ~4.5Mb Verschlüsselungscode. Wird also die 16Kb DFM Resource entschlüsselt so produziert der PMC 4.5 Mb Maschinencode um diesen zu entschlüsseln. Deswegen meinte ich "happy-tracing".

6.) ich erzähle es euch hiermit, so daß ich nicht dafür verantwortlich bin wenn ihr später die verlorene Zeit bereut.

7.) gebe ich euch einmal diese Serial dann ist der komplette Schutz hinüber. Soll ein Softwarebasierter Schutz 100%'tig sicher sein, dann dürft ihr niemals eine Serial rausrücken. Ansonsten wird der Cracker die Serial nehmen, das Program starten, den entschlüsselten Codeteil übertragen und dort die Abfragen deaktivieren. Er baut also eine Kopie der Software die ohne Serial und Veerschlüsselung arbeitet.

8.) das Passwort ist "DP Test 1 für Anti-Cracking by negaH" ohne Hochkommata.

Gruß Hagen

Alles nachzulesen in diesem Thread:

http://www.delphipraxis.net/topic814...ackme&start=61

CDW

Warum sollte ich das probieren wollen ? Man kann hier nicht mal den Bruteforce ansetzen, weil man keinen Anhaltspunkt für die Richtigkeit des Codes hat. Allerdings hatte Hagen auch selber geschrieben dass man die Serial auf keinen Fall rausrücken darf - somit ist das Verfahren für Sharewareautoren leider unbrauchbar.
Bei meiner Crackme wäre zwar nicht bewiesen dass sie unknackbar wäre, aber mal ehrlich: wer würde sich in der Praxis schon sowas antun? Aus der Serial wird eine Nummer gehasht und als Basis für weitere Sprünge/Calls genutzt - landet der Sprung nicht da wo vorgesehen, ist sowieso alle im Eimer (z.B der Stackframe).

Worauf ich noch eingehen wollte:Die wären sehr wahscheinlich die Exception, IsDebuggerPresent und das komische Gerüst mit CreateToolhelp32Snapshot. Die Exceptions kann man in Olly weiterleiten lassen. Für IsDebuggerPresent kann man Plugin runterladen oder selber was machen, und gegen CreateToolhelp32Snapshot Olly umbenennen. Nichts von dem habe ich gemacht. Ok, jetzt schon, zum ausprobieren - Olly umbenannt, die Exeptions alle weiterleiten lassen und IsDebuggerPresent Plugin heruntergeladen und benutzt - schon glaubt die Crackme sie wäre gaaanz alleine.

__________________
Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf!
Selig, wer nichts zu sagen hat und trotzdem schweigt.

sartre

@ CDW

Danke für die ausführliche Beschreibung/Belehrung !

Dann würde ich den MD5-Hash einfach auf "d41d8cd98f00b204e9800998ecf8427e" ändern !

Per Hex-Editor --> Es gibt nichts Leichteres !!!


@+++ATH0

Kein Programm der Welt ( solange es ausgeführt werden muss ) ist unknackbar !
Es gibt viele, die noch vor ein paar Monaten behauptet haben, dass Starforce unknackbar wäre !

Seit SH3 wissen wir es besser.

+++ATH0

Dieses Beispiel ist insofern etwas anderes, da man quasi gezwungen ist zu Bruteforcen. Ähnlich wie bei Hahes. Und Patchen geht auch nicht, da der auszuführende Code der ist, der verschlüsselt wurde. Und zwar deftig.

Also bleibt einem nichts anderes übrig als das Crypto-Verfahren zu knacken. (Knack erstmal MD5). Oder mit immenser Rechenleistung zu Bruteforcen. In dem Thread hat Hagen dargelegt wie sinnlos das sein wird.

Also meine ich "unknackbar" für Hobbycracker wie uns. Ich meine damit nicht die NSA. Obwohl die sehhhrrr lange dran zu beissen hätten, wenn sie es überhaupt schaffen.

sartre

Ja, aber sie Hashes an sich kann ich mit nem Hex-Editor ändern !

Sonst würde ich Dir aber recht geben.

sheepd

Du kannst die Hashes bei dieser Methode ändern wie du willst, es bringt dir nichts.
Lies dir das nochmal durch:

CDW

Nene, nix da mit ändern . Sonst könnte man auch die CMP patchen.
Wenn ich die Crackme erstelle lege ich eine Serial fest. An dieser mache ich den Programmablauf nach der Eingabe der Serial fest: z.B Zeichen 1,4,7,9,14,6 liefern die Adresse für die nächste Anweisung, zeichen 2,1,6,3,17 für die übernächste usw. Das ist zwar nicht so wirksam wie die Verschlüsselung, aber ohne die Kenntniss des richtigen Hashes und bei genug Codemenge wird man den Programmablauf nicht mehr (in annehmbarer Zeit ) rekonstruieren können. Es wird also gar keine VergleichsMD5 im Crackme geben - die Eingabe wird zu einer solchen gemacht und wenn die Eingabe falsch ist, kommt natürlich eine komplett andere Hash raus - und dadurch stimmen die JMP-Adressen (oder was man auch immer da nehmen würde) nicht mehr - die nächste Anweisung landet einfach im "wilden" Speicher. Ganz einfaches Beispiel:
'

Hier könnte man noch relativ schnell was sinnvolles finden, aber schon bei genug Code wird das schnell langweilig und langwierig.

Jetzt zu dem Hagens verfahren: er geht noch einen Schritt weiter und verschlüsselt den Code nach der Eingabe mit dem Schlüssel. Das heißt dieser Teil des Codes wird mit dem Schlüssel entschlüsselt und ausgeführt. Ohne den richtigen Schlüssel bekommt man den Code "nie" zu sehen (wie z.B mit der PGP Mail). Allerdings ist es wie erwähnt nicht Sharewaretauglich (bzw. für jeden Kunden eigene Version).

__________________
Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf!
Selig, wer nichts zu sagen hat und trotzdem schweigt.

+++ATH0

Wenn man jedoch ansatzweise weiss was rauskommen soll, kann man sich den Jmp zurechtpatchen. Nur muss man sich mit viel Mühe durchreversen. Früher oder später entdeckt man schon was richtig sein könnte. Bei einem Crackme ist das eigentlich meistens sinnfrei. Dann baut man sich halt seine eigene richtig-Meldung und jumpt dahin.

Die Methode lässt zudem nur eine richtige Serial zu. Ausser man kopiert den richtig-Code zigmal oder jumpt von da aus wiederum zur einzig richtigen Adresse. Zu der findet man aber leider auffällig viele Referenzen.