

          ۰                                                ۰
         ۰ ۰۰                                             
        ۰   ۰   ۰
       ۰         ۰  ۰    ۰  ۰     ۰    ۰   ۰۰  ۰
       ۰          ۰ ۰  ۰  ۰ ۰  ۰ ۰ ۰  ۰  ۰  ۰  ۰  ۰  ۰
        ۰        ۰ ۰    ۰۰     ۰      ۰۰    ۰۰    ۰ ۰  ۰۰
         ۰      ۰   ۰  ۰  ۰  ۰    ۰  ۰  ۰  ۰  ۰۰  ۰
                                                            

                             prsentiert voller Stolz:

                 Den ausfhrlichen Cracktutor ber SmartDraw 4.0


                        Tutorial #1 vom 27. Mai 1999, 22:00


---[ Wissenswertes ]------------------------------------------------------------

Das Tool SmartDraw ermglicht das Zeichnen von FlowCharts, Netzwerkdiagrammen
und hnlichem. Es ist als Shareware unter
   
   http://www.smartdraw.com

als kostenlose 30 Tage Testversion zu beziehen. Es handelt sich dabei um eine
richtige Demoversion, die nicht ber eine Seriennummer oder ein Keyfile frei-
geschaltet werden kann. Das heit, da fr den Crack alle Einschrnkungen der
Demoversion beseitigt werden. Folgende Einschrnkungen sind in der Demoversion
enthalten:

   * Das Programm ist nur 30 Tage lauffhig
   * anschlieend kann man es noch starten und nur mehr laden
   * Lstige NAG-Screens beim starten.

---[ Information ]--------------------------------------------------------------

Bentigte Tools:

  * W32Dasm 8.9.x, HexWorkshop 2.54 oder anderer

Bentigtes Wissen:

  * Grundwissen ber Bedienung von W32Dasm 8.9.x und eines HexEditors
  
---[ Das Tutorial ]-------------------------------------------------------------

Laden der SmartDraw.EXE im W32Dasm. Wir stellen die Uhr nach vorne und starten
das Programm (nicht im Debugger) um zu sehen, was passiert. Aha - ein kleines
Dialogfeld ffnet sich und teilt uns mit, da unsere Zeit abgelaufen ist. Nach
dem Besttigen kommt unser normaler Titel-Screen und anschlieend noch mal die
Meldung, da das Proggi abgelaufen ist.

Machen wir uns daran, dieses Zeitlimit zu vernichten:

Als erstes Sehen wir mal im W32 Dasm nach, ob unsere Meldung "This Trial..."
in der Stringliste vorkommt. Einige Referenzen haben wir gefunden. Um zu sehen,
welche am Anfang angesprungen wird, starten wir das ganze mal im Debugger und
setzen an jede Referenz einen Breakpoint. Wie wir sehen, wird an der Adresse

    004BE98F 6A29               push 00000029

in den Debugger abgebrochen. Wir drcken nochmal auf Run um zu sehen, ob
noch woanders am Anfang auf den Nag referenziert wird. Keine weitere Referenz
auf unseren Dialog - Gut! Etwas weiter oben sehen wir folgenden Code:


   :004BE978 E97603000          jmp 004BECF3

   * Referenced by a (U)nconditional or (C)onditional Jump at Adress:
   |:004BE95F (U)
   |
   :004BE97D E8AF080000         call 004BF231
    004BE982 85C0               test eax, eax
    004BE984 0F8423000000       je 004BE9AD

Sehr verdchtig! Wir starten das Proggi im Debugger, setzen einen Breakpoint
an diese Funktion und sehen, was passiert. Aha, die Funktion gibt EAX=1 zurck,
somit wird nicht gesprungen. Der Gegentest mit zurckgestelltem Datum ergibt,
da normalerweise 0 zurckgegeben wird. Sehen wir uns mal die Funktion genauer
an: Eine Menge Code, aber im Endeffekt wird nur abgecheckt, ob unser Proggi 
schon zu lange luft oder nicht. Also Versuchen wir mal das ganze im Memory
zu Patchen. Breakpoint gesetzt und so umgeschrieben, da EAX immer auf 0 gesetzt
und dann wieder zurckgekehrt wird.

Knnte ungefhr so aussehen:

   Vor Modifikation:

   * Referenced by a CALL at Adress:
   |:004BE97D
   |
   :004BF231 55                push ebp
   :004BF232 8BEC              mov ebp, esp
   :004BF234 83EC2C            sup esp, 0000002C
   : .
   : .

   Nach Modifikation:

   * Referenced by a CALL at Adress:
   |:004BE97D
   |
   :004BF231 33C0              xor eax, eax
   :004BF233 C3                ret
   : .
   : .

Probieren wirs mal und siehe da: Es funktioniert. Der Expired-Nag am Anfang ist
weg, der zweite wie gewohnt da und der dritte (leider) auch noch. Also, ein 
zweiter Patch mu her, der ihm diesen dritten aushngt und auch noch das Save-
problem beseitigt. Wir sehen in der Dialogreferenz nach und suchen nach unserem
Dialogfeld, doch wir finden es nicht! Fast keine Dialog sind eingetragen - was 
tun? Wir starten das Programm und sehen uns die Nags mal genau an. Wir suchen
in der Stringreferenz, ob wir einen aus dem Nag-Screen bekannten Text finden - 
und siehe da der String "WELCOME" kommt uns sehr verdchtig vor. Wir setzen 
einen Breakpoint auf die "WELCOME" Referenzen und starten das Proggi im 
Debugger. Wir sehen uns in der Gegend um und entdecken ein Stck weiter oben
einen CALL mit anschlieendem CMP und JE und JMP -> verdchtig. Wiederum setzen
wir vor dem CALL einen Breakpoint und starten das Proggi neu. Aha, es wird vor
unserem dritten Nag in den Debugger gebrochen. Wir patchen das ganze um, damit
der CALL nicht ausgefhrt wird aber trotzdem gesprungen wird (am besten Packen
wir das ganze an der Wurzel und Patchen die Funktion um).

   Vor Modifikation:

   * Referenced by a CALL at Adresses:
   |:0040282B, :0045D555, :0045D746
   |
   :0045D1A0 55                push ebp
   :0045D1A1 8BEC              mov ebp, esp

   Nach Modifikation:

   * Referenced by a CALL at Adresses:
   |:0040282B, :0045D555, :0045D746
   |
   :0045D1A0 33C0              xor eax, eax
   :0045D1A2 C3                ret

Und auch der dritte Nag ist weg. Doch leider ist unsere Savemglichkeit noch
immer ausgeschaltet. Aber auch dieses Problem beseitigen wir...

Aber auch dieser Dialog ist nicht in unserer Dialogliste und so mssen wir uns
anderer Mittel bedienen um diesen Dialog rauszubekommen. Suchen wir mal im
disassemblierten Text selbst nach unserem Dialog mit dem Namen "CANTSAVE". Uups...
Na wen haben wir denn da.. Wir setzen mal einen Breakpoint auf die zwei
gefundenen Referenzen. Und siehe da, jedesmal wenn man auf "SAVE" oder "SAVE" as
geht, wird in den Debugger gebrochen. Wenn wir ein paar Zeilen Code weiter rauf
gehen, sehen wir da ein Vergleich zwischen einer Speicherstelle und 0 gemacht
wird. Wenn wir diesen Vergleich aushngen und immer springen, dann gibt es keine
Probleme beim Saven mehr. Eleganter wre es natrlich, wenn man das Problem von
unten her anpacken wrde und gleich die Speicherstelle patchen wrde, was wir
auch machen werden:

Wir sehen, da ein Vergleich folgender Form gemacht wird:

   cmp dwort ptr [00568A88], 00000000

Wenn der Inhalt der Speicheradresse 00568A88 gleich 0 ist, dann wird 
gespeichert ansonsten nicht. Wir machen nun folgendes:

Wir starten das Programm im Debugger und setzen an alle Stellen an denen diese
Speicherstelle in Verbindung mit einem MOV und 1 vorkommt einen Breakpoint. An
folgenden Stellen wird dann in den Debugger gebrochen:

   004BE9A3: C705888A560001000000     mov dword ptr [00568A88], 00000001
   004C70F7: C705888A560001000000     mov dword ptr [00568A88], 00000001
   004C71F6: C705888A560001000000     mov dword ptr [00568A88], 00000001

Wenn wir nun all diese Befehle so verndern, da anstatt von 1 eine 0 an die
Speicerstelle geschrieben wird, so kann man immer speichern.


So, das wars auch schon frs erste. Ich hoffe, da Ihr vielleicht ein paar
Kleinigkeiten aus diesem Tutorial gelernt habt und freue mich schon, wenn ich
euch den nchsten Prsentieren darf. Wenn Ihr irgendwelche Anregungen, Kritiken
oder hnliches in Bezug auf dieses Tut habt, dann knnt Ihr mir gerne schreiben.

                            mnemonix@gmx.de
                  http://mnemonix.cjb.net (ab 1. Juni 1999)

---[ Ende des Tuts ]------------------------------------------------------------