About
Stuff
Contact

File: cracking_everest.txt (5904 bytes, Date: January 29 2017, Views: ?)



Hallo Allerseits!

Das hier sind ein paar Notizen zum cracken des Editors "Everest" V3.3E für den
Atari ST. Everest ist Shareware und ein relativ leichtgewichtiger
Editor, von daher gut als Target bei einem ersten cracking Versuch
geeignet! :) Und warum? Nun, ich nutze meinen Atari gerne und finde
das man was lernt wenn man Programme crackt. Und da ich auch Programme
für den Atari entwickeln möchte, kann mir das Wissen das ich mir beim
cracken erarbeite gut dienen. Also los jetzt!



1. TOOLS und ENVIRONMENT

- "calc.cpx" V. 1.01
- "PureDebug"
- "Filemon"

Zunächst ein paar Worte zu den genutzten Tools. Das cracken auf dem
Atari gestalltet sich natürlich längst nicht so komfortabel wie auf
einem PC mit ollydbg und IDA, das war ja auch zu erwarten. Zunächst
musste ich festellen das mir die Disassembler EasyRider oder TTDigger
keine große hilfe waren, hauptsächlich weil ich nicht interaktiv durch
den C0de steppen kann. TTDigger Bietet zwar eine Sprung-vorhersage
(man kann also bei einem Sprung (BRA anweisung) doppelt klicken und
gelangt dann zum errechneten Ziel). Ein weiteres Manko sehe ich darin
das ich es nicht geschafft habe Labels zu benennen oder Kommentare zum
Code hinzuzufügen. Da ziehe ich dann den Interaktiven Debugger vor!

Ich habe für alles den PureDebugger von PureC genutzt. Ich gehe aber
davon aus das der debugger aus dem DevPac oder PeaceDebug die Aufgabe
besser lösen könnten.

Debuggt habe ich auf einem Atari ST 68000 mit normalem TOS - Vorteil:
Das Programm wird immer an die selbe Base geladen und man muss nach
einem Neustart die recherchierten Adressen nicht neu berechnen
(Vorausgesetzt man startet vorher keine anderen Programme).

Zum patchen benutze ich das Tool Filemon, ein Hexeditor für Dateien
und Disk-Sektoren.

2. LOS GEHTS!

Wenn man das Programm mit PD geladen hat stellen sich zunächst
Orientierungsprobleme ein. Man muss zumindest einen Anhaltspunkt haben
an dem man "zupacken" kann. Für mich ist das eigentlich das main
Programm. Ich konnte aber bisher keinen zuverlässigen Weg finden um die Main
routine zu finden, dafür aber etwas besseres. Durch suchen nach Byte-
folgen kann man diverse Libraryfunktionen von PureC finden, als
nutzbar erwies sich eine Suche nach der Bytefolge die die AES Aufrufe
einleitet, und auch eine Bytefolge die appl_init einleitet.
Bei beiden calls können wir main ermitteln und wir wissen das das
Programm gerade initialisiert wird. Wenn man einen Breakpoint bei den
AES aufrufen setzt, also nicht nur bei appl_init - dann muss man natürlichen
filtern welcher call nun relevant ist.

Bytefolgen:

appl_init: 0x22,0x3c,0x0a,0x00
aes: 0x30,0x3c,0x00,0xc8
form_alert: 0x22,0x3c,0x34,0x01

Wobei es bei mir reichte nach den ersten 2-3 bytes zu suchen - manchmal
muss man dann halt schauen ob es wirklich die PureC Funktionen sind
und wenn man das verifiziert hat, setzt man dort einen Breakpoint.

Die Bytefolgen kann man ermitteln in dem man mit PureC ein kleines
Programm schreibt das die gesuchten Funktionen aufruft und in PDebug
kann man sich dann im Dump anschauen was für Opcodes daraus entstehen.

Zum Notizen machen habe ich 1. ein Schmierpapier für Temporäre
Adressen u. berechnungen und 2. eine Tabelle für Notizen, Beispiel:

LOCATION | INFO
---------------------------------
$xADDR - $xBASE Hier wird das Register-Formular angezeigt.
$CF24E - $BF368 A0 = Username

Nun kann man sich mit dem Debugger weiter vorarbeiten, und sobald etwas
passiert das Notiz-Wert ist, wird es in die Tabelle eingetragen. Dann
ist es eigentlich nur noch eine Frage der Zeit bis man die interes-
santen Stellen gefunden hat. Ich benutze hier das Wort cracking ganz
Bewusst. Ich habe nicht das Ziel eine Software im Gehirn so abzubilden
wie es ein Entwickler getan hat. Ich versuche nur die relevante Stelle
(en) zu identifizieren und dann so umzuschreiben das "wir" eine schein-
bar registrierte Software haben.

3. DER CRACK

Ich kann hierzu nichts sagen, wie ich die Stelle gefunden habe...
Dafür sollte man auch einfach ein bisschen seinen Instinkt benutzen ;)
Ansonsten breakpoints bei form_alert aufrufen - meist wird ja eine
alert box nach der Serien-Nr. Eingabe angezeigt, so bahnt man sich
dann in die Bereiche vor, in denen der Key-Check zu finden ist.
Ok, wir haben also die Stelle gefunden an der der Key überprüft wird.
Es ist die Routine an Offset 0x15988 (d.h base+0x15988).

Ich kenne auf dem Atari leider kein Programm mit dem man Shellcode
entwickeln kann. Von daher muss ich mir mit dem Code behelfen der schon
vorhanden ist. Eleganter wäre es eigenen Code zu
schreiben - vielleicht hilft das Dokument "Motorola 68000 CPU Opcodes"
von GoldenCrystal.

Hier ein paar Zeilen der Routine:

0xd4cf0 movem.l d3-d5/a2-a4,-(a7) ; register sichern
0xd4cf4 lea.l -$20(a7), a7 ; platz fuer lokale variabeln
; schaffen
0xd4cf8 moveq.l #$01, d0 ; das ist das resultat das ich brauche
0xd4cfa clr.w d2 ; ab hier kann gepatcht werden

...

0xd4dd6 lea.l $20(a7), a7 ; lokale variablen freigeben
0xd4dda movem.l (a7)+,d3-d5/a2-a4 ; register wiederherstellen
0xd4dde rts ; rücksprung


Ich kopiere nun einfach die Bytes von 0xd4dd6 bis 0xd4dde+2
an die Adresse 0xd4cfa. Damit ziehen wir das Ende der Routine vor,
Und gibt immer einen positiven Wert zurück.
Zum patchen nutze ich das Tool Filemon. Hierbei werden physikalische
Adressen gepatcht, das heisst ich muss erstmal die logische RAM
Adresse in einen offset innerhalb der Datei auf Disk umwandeln. Das
geht beim GEMDOS aber zum Glück ganz einfach :).

Angenommen das Programm liegt an Adresse 0xbf368, die Patch Adr.
liegt an 0xd4cfa. Dann rechnen wir einfach:

0xd4cfa - 0xbf368 + 0x1c

0x1c wird addiert um den GEMDOS header der Programmdatei zu
überspringen. Das ist alles!

Voila, das Programm ist gepatch. Wer will kann nun unter Info die
Anwendung auf einen beliebigen Besitzer anmelden.

Cheers,
m0n0





monochrom.net