Zurück zur Zukunft: Easyrider-Reassembler

Easyrider ist ein Reassembler, mit dem Programme disassembliert und so aufbereitet werden können, daß eigene Änderungen leicht möglich sind. Der produzierte Quelltext kann von einem Assembler neu übersetzt werden. Da vielleicht nicht jeder weiß, was überhaupt ein Reassembler ist und worin er sich von einem Disassembler unterscheidet, möchte ich eine kurze Erklärung voranschicken. Gleiches tut übrigens auch der Autor im Handbuch zu Easyrider.

Ähnlich wie ein Disassembler wandelt ein Reassembler den binären Maschinencode eines Programms in ein Listing in Assemblersprache um, das durch die Verwendung von Mnemonics für die Prozessorbefehle erheblich leichter verständlich ist als ein reines “Hex-Dump”. Ein Reassembler soll dagegen noch mehr leisten. Sein Ziel ist ein vollständiger Assembler-Quelltext, der direkt von einem Assembler zurückübersetzt werden kann. Im Idealfall sollte exakt - d.h. Bit für Bit - die gleiche Binärdatei herauskommen, die man dem Reassembler vorgesetzt hatte. Ein komfortabler Reassembler sollte natürlich noch viel mehr können, nämlich das Listing durch die Verwendung von Symbolen statt Adressen und Konstanten lesbarer zu machen.

Na schön, so werden Sie fragen, aber wozu das Ganze? Damit stellt sich also die Frage nach den Anwendungsbereichen. Ein Reassembler kann dazu benutzt werden, fremde Programme (von eigenen hat man ja normalerweise den Quelltext) zu analysieren, sei es nur aus purer Neugier, weil man etwas aus ihnen lernen oder Veränderungen vornehmen möchte.

Gerade beim letzten Punkt ist die spätere Assemblierung wichtig. Da außerdem Kode eingefügt oder weggelassen werden soll, kommt es darauf an, daß alle vom Programm angesprochenen Speicheradressen über Symbole spezifiziert werden (bis auf absolute Adressen außerhalb des Programmbereichs), damit bei Änderungen der Länge einzelner Programmteile alle Speicherzugriffe bei einer erneuten Assemblierung korrekt bleiben.Da innerhalb des Programms beliebig komplexe Adreßberechnungen möglich sind, die unmöglich von einem Reassembler alle selbständig erkannt werden können, wird klar, daß der eigene Gehirnschmalz gefordert ist. Aber ein Reassembler kann Funktionen bereitstellen, die die Arbeit ziemlich stark automatisieren und vereinfachen können, so daß der Benutzer seine Zeit möglichst dem Denken (oder anderen Dingen) widmen kann.

So, genug der Vorrede, kommen wir zu unserem Testkandidaten, dem Reassembler Easyrider. Dabei handelt es sich um einen Namensvetter des Assemblers Easyrider, mit dem problemlos zusammengearbeitet wird.

Was dabei ist

Auf der Programmdiskette befindet sich neben dem Reassembler und seiner Resource-Datei nur noch ein Beispielprogramm, das in drei, in unterschiedlichen Stufen mit Easyrider bearbeiteten Formen vorliegt. Der Reassembler ist mit ca. 60 kB (einschl. Resource) angenehm kompakt. Zum Lieferumfang gehört noch das 49 Seiten starke, deutschsprachige Handbuch. Dieser Test bezieht sich auf die Version 2.0. Easyrider ist nicht kopiergeschützt, aber auf den Anwender installiert (Name und Adresse erscheinen in der Titelzeile). Anwender, die das Programm bei einem Händler erworben haben, müssen ihre Programmdisketten mit dem Kaufbeleg dem Hersteller zusenden, um am Update-Service teilzunehmen, und erhalten dafür eine auf ihren Namen installierte Version zurück.

Laden eines Programms

Nach dem Start von Easyrider erscheint zunächst eine programmeigene Dateiauswahlbox, mit der eine Datei geladen werden kann (Bild 1). Normalerweise handelt es sich dabei um eine Programmdatei, aber Easyrider erlaubt auch die Bearbeitung beliebiger Dateien sowie das “Laden” von RAM- oder ROM-Bereichen. Ferner kann auch direkt ein Boot-Sektor geladen werden. Die Bearbeitung von Objektdateien wird nicht unterstützt; hier kann es zu Fehlfunktionen kommen.

Easyrider analysiert die Datei, um herauszufinden, welche Teile als Befehle und welche als Daten zu interpretieren sind. Außerdem werden die Adressen aller offensichtlich relativen Zugriffe durch Labels, die fortlaufend ab L0000 numeriert werden, ersetzt. Als “offensichtlich relativ” zählen dabei nicht nur die PC-relativen Zugriffe, sondern auch die “absoluten”, in den Relozierdaten vermerkten, da diese stets (relativ) auf den Programmanfang bezogen sind.

Auswahl eines Programms mit Easyrider

Nun wird in einem Fenster ein Listing (des TEXT- und DATA-Segments) gezeigt, das mittels Cursortasten oder Maus sehr schnell gescrollt werden kann. Dabei gibt es die Darstellungsmodi “Disassemblieren”” und “Reassemblieren”. Bei ersterem werden noch der Kode und die aktuelle Adresse mitangezeigt, dafür finden sich im Operandenfeld keine Symbole, die aber rechts als “Kommentar” nachgestellt werden. Das Reassembling ist dagegen direkt von einem Assembler verwertbar, d.h. alle definierten Symbole sind eingesetzt. Zwischen beiden Modi kann per Menü, Tastatur oder Rechtsklick umgeschaltet werden.Ein Reassembling, wie es direkt nach dem Laden aussieht, zeigt Bild 2. Das INFO-Menü gibt einige Informationen über das Programm und das Listing.

Daten- und Befehlsbereiche

Wie schon erwähnt, entscheidet Easyrider nach dem Laden des Programms selbständig, welche Bereiche es als Befehle und welche es als Daten interpretiert. Da der nicht näher erläuterte Bewertungsalgorithmus nicht perfekt sein kann, ist er durch konstruierte Beispiele leicht zu überlisten.

Ein Kriterium für seine Qualität ergibt sich daher viel mehr aus der Erprobung an “real-existierenden Programmen”. Bei den von mir getesteten Programmen arbeitete er weitgehend fehlerfrei, eine Ausnahme bildete allerdings das TOS.

Hier identifizierte er reine Befehlsbereiche als Daten, vor allem in den LINE A-Routinen, bei denen viele Befehlswiederholungen vorkommen, und dem AES/Desktop, wohl wegen der LINE F-Befehle.

Besonders gewundert hat es mich, daß “Daten” selbst bei Zielen von Sprüngen oder nach bedingten Verzweigungen erkannt werden. Es mag zwar Programme geben, bei denen so etwas vorkommt, weil sie bedingte Sprünge benutzen, die nie oder immer ausgeführt werden, oder weil sie gar selbstmodifizierend sind, doch bilden sie wohl eher die Ausnahme. Daher sollte in diesen Fällen immer solange von Befehlen ausgegangen werden, wie dies möglich ist. meine ich. Eventuell wäre es auch sinnvoll, die Arbeitsweise des Algorithmus über einige Parameter steuern zu können. Dann müßte es auch möglich sein, die LINE A- bzw. LINE F-Befehle schon beim Einladen des Programms als Befehle anerkennen zu lassen, und nicht erst im nachhinein (s.u.). Bei compilierten Programmen hat man hier kaum Probleme, da Compiler Daten meist nur im DATA-Segment ablegen.

Um die Irrtümer bei der Bereichserkennung korrigieren zu können, bietet Easyrider zwei Funktionen zur Umwandlung eines Blocks in einen Befehls- oder Datenbereich. Im ersteren Falle wandelt Easyrider allerdings nicht blindlings alles, was disassemblierbar (d.h. vom Prozessor ausführbar) ist, sondern geht bei “unsinnigen” Befehlen davon aus, daß es sich um Daten handelt. Dies läßt sich durch Optionen teilweise aufheben, denn es kann festgelegt werden, ob LINE A-und LINE F-Befehle als solche anerkannt werden, ob der Wort/Langwortzugriff auf ungerade Adressen gestattet werden soll, und ob zwei aufeinanderfolgende Nullwörter als ORI#0,D0 interpretiert werden sollen.

So gut die Fähigkeit, Befehle als “Unsinn” anzusehen, bei der Identifizierung der Datenbereiche auch ist, so kann sie in reinen Befehlsbereichen zum Hindernis werden. Z.B. weigert sich Easyrider beharrlich, den Befehl MOVEM.L ,-(A7) (leere Registerliste!) zu disassemblieren. Dieses Beispiel stammt aus dem LINE F-Emulator des TOS, der die Registerliste in selbstmodifizierender Weise “nachbessert”. Zumindest bei der expliziten Umwandlung in Befehlsbereiche müßten alle ausführbaren Befehle auch wandelbar sein. Vermißt habe ich noch die Berücksichtigung von möglichen Erweiterungswörtern nach LINE A- und LINE F-Befehlen, die zu Fehlinterpretationen führen können.

Unbearbeitetes Reassembling und INFO-Menü

Relative Adressierung durch Symbole

Labels sind unter Easyrider immer “relativ”, d.h. ihr absoluter Wert ist von der Startadresse des Programms abhängig. Labels können auch außerhalb des Kodebereichs des Programms liegen, daher kennt Easyrider noch die Labels Begin und ZUEND, die Anfang und Ende des Kodebereichs bezeichnen (= Anfang des TEXT- und Ende des DATA-Segments). “Außerhalb” liegende Labels werden dann durch feste Offsets relativ zu diesen Spezial-Labels definiert.

Wie in der Einleitung erwähnt, gibt es neben den einfachen Fällen relativer Zugriffe, die Easyrider eindeutig erkennen kann, noch weitere “versteckte” Möglichkeiten für relative Zugriffe, die nicht automatisch erkannt werden können. Dabei kann es sich um Adreß-, Offset-Tabellen usw. handeln.

Die Funktion “Datencharakter” ermöglicht es nun, Easyrider anzuweisen, bestimmte Datenbereiche oder Befehlsoperanden (der Adressierungsart “unmittelbar”) als relative Adressen anzusehen. Neben der Angabe eines beliebigen Bezugspunktes (entweder als Adresse oder als Label) kann festgelegt werden, ob die relativen Adressen vorzeichenbehaftet oder vorzeichenlos interpretiert werden sollen, oder ob sie vom Programm irgendwohin addiert oder subtrahiert werden. Im Fall der Datenbereiche ist es möglich, die Größe der Adressen (B, W, L) sowie deren Abstände innerhalb des Datenbereichs festzulegen, d.h. Daten, die keine Adressen darstellen, zu überspringen. Nach einer Änderung des Datencharakters werden diese Offsets durch Label-Differenzen ausgedrückt, die durch die nun als Adressen interpretierten Daten dabei notwendig werdenden neuen Labels werden von Easyrider automatisch generiert. Dabei werden Labels stets fortlaufend (d.h. mit aufsteigenden Adressen) ab L0000 numeriert, so daß Label-Nummern sich ständig ändern können. Ein weiteres beliebtes Mittel, relative Zugriffe in den Kodebereich hinein zu tätigen, ist die adreßregisterindirekte Adressierung, wobei das Adreßregister meist einmal mit einer Basisadresse geladen wird und dann über große Programmbereiche unverändert bleibt. Für solche Fälle bietet Easyrider die Funktion “Adreßregister definieren” an. Der Anwender muß aus dem Programmkontext die Adresse bzw. das Label ermitteln, auf die/das das Adreßregister initialisiert wird. Dann wandelt die Funktion alle Offsets bei Zugriffen der Adressierungsarten vom Typ offset(Ax) und offset(Ax,Rx) in Label-Differenzen mit dem ermittelten Bezugspunkt um.

Eine weitere Möglichkeit, als relativ erkannte Adressen durch Labels darzustellen, hat man mit der Funktion “Adreßcharakter ändern”. Mit ihr können Operanden der Adressierungsart “absolut lang” in relative Form gebracht werden. Dies geschieht zwar normalerweise schon automatisch durch die Relozierdaten, aber z.B. beim Bearbeiten des TOS liegen diese ja nicht vor. Dazu muß ein Adreßbereich angegeben werden, in dem die zu wandelnden Adressen liegen müssen. Es gibt vier Kriterien für die nähere Auswahl der von der Funktion betroffenen Langwörter, die unabhängig voneinander anwählbar sind. Ausgewählt werden können hiermit die Befehle JMP/JSR mit “absolut lang”, alle anderen Befehle mit “absolut lang”, Langwortkonstanten in Befehlen und Langwörter in Datenbereichen. Die letzten beiden Kriterien sind mit Vorsicht anzuwenden, da die Konstanten auch als “echte” Konstanten und nicht als Adressen gemeint sein könnten, aber trotzdem ist diese Funktion ebenfalls sehr mächtig.

Die soeben beschriebenen Funktionen sind sehr leistungsfähig, da es erst mit ihnen möglich wird, die meisten relativen Zugriffe dem Reassembler auch als solche mitzuteilen, damit er alle beteiligten Adressen durch Labels bzw. Label-Differenzen ausdrücken kann. Daher erlauben es diese Funktionen, von den meisten Programmen ein Reassembling zu erzeugen, in dem beliebig Kodebereiche eingefügt oder gelöscht werden können, ohne daß irgendwelche Zugriffe ins Leere laufen.

Labels

Die Vergabe von Labels der Form Lxxxx fördert nicht gerade die Verständlichkeit des Programms, insbesondere da sich die Label-Nummern stets ändern können. Daher bietet Easyrider die Möglichkeit, den Labels bis zu 8 Zeichen lange Namen zu geben. D.h., L0008 kann in ende umbenannt werden. Dabei ändert sich aber die Numerierung der anderen Labels nicht, d.h. das Label davor bleibt L0007 und das danach L0009. Falls Easyrider später nun ein Label z.B. vor L0007 einfügt, wird L0008 zu L0009, und der neue Name ende “wandert” mit, damit er an der gleichen Stelle im Listing stehenbleibt. Die nochmalige Umbenennung ist dagegen umständlich, da dazu die Label-Nummer bekannt sein muß. Bei Labels im Kodebereich ist dies über das Disassembling leicht möglich, bei den externen Labels muß die Nummer mühsam durch “Abzählen” ermittelt werden.

Wenn das geladene Programm eine Symboltabelle hat, fragt Easyrider nach, ob alle, nur die globalen oder gar keine der Symbole als Namen für Labels benutzt werden sollen. Dabei werden nur die Namen benutzt, für die nach dem Laden schon ein Label existiert. Falls durch spätere Aktionen Labels hinzukommen, für die eine Definition in der Symboltabelle existiert, ist es nicht mehr möglich, diese von Easyrider übernehmen zu lassen. Es ist auch möglich, sich die Tabelle externer Labels anzusehen. In ihr sind alle Labels aufgeführt, die außerhalb des Kodebereichs liegen, also relativ zu Begin und ZUEND definiert sind.

Ein prinzipieller Schwachpunkt ist, daß grundsätzlich keine absoluten Symbole unterstützt werden. Es ist nicht möglich, absolute Adressen (wie System- oder Hardware-Adressen), Konstanten usw. mit Namen zu versehen, was das Verständnis eines fremden Programms beträchtlich erleichtern könnte. Konsequenterweise werden daher auch entsprechende Einträge in der Symboltabelle ignoriert. Gestört hat mich außerdem das Fehlen einer solch einfachen Funktion wie “Label erzeugen”, um an einer beliebigen Adresse ein Label zu setzen. Dazu läßt sich aber z.B. die “Datencharakter”-Funktion mißbrauchen.

Das BSS-Segment wird leider nicht über Labels und DS-Direktiven erzeugt, sondern es gibt nur ein einziges DS, und die Labels werden als externe zu Beginn über EQU und das ZUEND-Label definiert. Dies ändert zwar nichts am erzeugten Kode, stört aber die Übersichtlichkeit.

Wichtig sind auch Funktionen, die das Auffinden bestimmter Stellen im Dis-bzw. Reassembling erlauben. Zunächst gibt es ein goto, das das Anspringen von Labels (Angabe der Nummer oder des Namens möglich) oder Adressen innerhalb des Kodebereichs ermöglicht. Außerdem läßt sich ein Offset angeben, der zur Adresse addiert wird. Mit return läßt sich der letzte Sprung rückgängig machen. Laut Handbuch werden bis zu 5000 Sprünge gespeichert. In der goto-Dialogbox werden außerdem die letzten 8 selbst ausgewählten Sprünge (als Adresse) angezeigt. Diese lassen sich direkt anklicken. Bei einem return ändert sich diese Liste jedoch nicht. Für besser hielte ich es, wenn die Sprungliste die letzten 8 nicht rückgängig gemachten Sprünge zeigen würde.

Eine Suchfunktion ermöglicht das Anspringen von Zugriffen auf Labels (ebenfalls als Nummer oder Namen angebbar) im Reassembling. Ebenso läßt sich nach Byte-Folgen im Kodebereich suchen. Die Suchfolge kann dabei als Folge von Hex-Ziffern oder als ASCII-String eingegeben werden. Außerdem kann man verlangen, daß die Byte-Folge auf einer Wortgrenze beginnt (z.B. zum Suchen von Befehlen). Ebenso läßt sich nach Zeichenketten im Dis- bzw. Reassembling selbst suchen. Die Suchfunktion unterstützt auch die üblichen Quantoren ’?’ und ’*’. Die Suche ist nur textabwärts ab der aktuellen Position möglich, was aber vollkommen ausreicht. Ferner gibt es noch die Möglichkeit, an den Anfang des nächsten Datenbereichs zu springen. Damit kann schnell überprüft werden, wie zuverlässig die Aufteilung in Befehls- und Datenbereiche geklappt hat.

Ausgabe und neu assemblieren

Wenn man das Programm soweit bearbeitet hat, wie man es für nötig hält, kann man sich das Listing auch ausgeben lassen.Die Ausgabe kann in eine Datei oder auf den Drucker erfolgen. Dabei lassen sich die schon bekannten Ausgabeoptionen (Dis-/ Reassemblieren, druckbare Zeichen symbolisch oder hexadezimal) extra einstellen. Auch die Ausgabe nur eines Teilbereichs ist möglich.

Eine weitere Option verspricht eine Einsparung von bis zu 20% Speicherplatz, da Leerzeichen weggelassen werden. Dies trifft auch ungefähr zu (beim Reassembling ist es etwas weniger). Die Angaben über die Länge der Listings im INFO-Menü sind nur als grobe Richtwerte zu verstehen, ich habe Abweichungen um die 15% beobachtet.

Nicht-Harddisk-Besitzer mit nur 1 MB RAM dagegen dürften bei großen Programmen in Schwierigkeiten kommen, da Listings locker auf 1 MB anwachsen können. Hier sollte es eine Option geben, das Listing auf mehrere Dateien zu verteilen.

Beim Drucker kann zusätzlich noch das Seitenformat (Zeilen pro Seite, seitenformatiert/durchgehend) sowie eine Initialisierungs-Sequenz festgelegt werden. Easyrider meckert, wenn der Drucker anfangs nicht empfangsbereit ist. doch wenn er während des Betriebs offline geht, wird das nicht bemerkt. Hier hilft es nur, den Drucker zu reaktivieren.

Es stellt sich noch die Frage, wie problemlos das Reassembler-Listing von Assemblern verarbeitet wird. Easyrider benutzt nur gängige Assembler-Direktiven (TEXT, DATA, BSS, DC, DS, END, EQU), so daß es hier kaum Probleme geben dürfte. Ferner werden die Endungen .S und .L benutzt, um absolut-kurze bzw. -lange Adressierung zu erzwingen. Bei Verzweigungsbefehlen werden Bcc und Bcc.S verwendet, was bedeutet, daß der Assembler keine automatische (nicht abschaltbare) Verzweigungsoptimierung bieten sollte.

Einige Assembler erlauben kein DS im Textsegment oder Label-Definitionen mit noch nicht definierten Labels. Hier ist ein Editor gefragt, mit dem dies leicht angepaßt werden kann. Keine Probleme gibt es natürlich mit dem Easyrider Assembler (Testbericht im Heft), das war wohl nicht anders zu erwarten. MAD-MAC bereitet einige Probleme, da die Kodeoptimierung nicht abschaltbar ist.

Deshalb muß man sicher sein, alle relativen Zugriffe im Programm durch Symbole ausgedrückt zu haben. Auch muß die spezielle Bedeutung des Backslashes in Strings berücksichtigt werden. Beim AS68 liegt das Problem darin, daß er keine “absolut kurz”-Adressierung erlaubt. Hier müssen die ‘.S’- und ‘.L’-Suffixe bei Adressen entfernt werden.

Zuverlässigkeit und Geschwindigkeit

Die Betriebssicherheit von Easyrider läßt leider stark zu wünschen übrig, wenn der Speicher knapp ist. Beim Laden eines zu großen Programms gibt es manchmal eine Fehlermeldung, meist jedoch einen Absturz (zwei “Typen” sind bei mir aufgetreten). Auch wenn bei der Bearbeitung eines Programms der Speicher ausgehen sollte, kommt es zu Fehlfunktionen. Darauf wird zwar in der Anleitung mehrmals ausdrücklich hingewiesen, doch ist das kein Ersatz für eine vernünftige Fehlerabfrage im Programm.

Fehlerkorrekturen werden dagegen unterstützt. Es gibt zwar keine UNDO-Funktion, doch lassen sich alle beschriebenen Funktionen auch in “umgekehrter Richtung” benutzen, d.h. relative Referenzen können in absolute verwandelt werden usw. Dabei muß man darauf achten, alle Parameter und Optionen korrekt einzustellen. Aus diesem Grund gibt es auch eine spezielle Funktion zum Sichern der “Parameter”, womit alle von Easyrider gespeicherten Zusatzinformationen, die nicht in der Programmdatei enthalten sind, gemeint sind. Es läßt sich sogar einstellen, welche “Parameter”-Gruppen gespeichert werden sollen (Datenbereiche, Relozierdaten, Adreßdistanzen, Symbole). Wenn eine umfangreiche Funktion nicht das gewünschte Ergebnis zeigt, läßt sich durch “Parameter laden” leicht und schnell der Ausgangszustand wieder herstellen. Das Laden einer falschen Parameterdatei wird jedoch mit Fehlfunktionen und Bomben bestraft.

Disassembling nach Bearbeitung

Easyrider ist sehr schnell, die Bildschirmausgabe ist zwar nicht so schnell wie bei TEMPUS, aber trotzdem ganz flott. Um Ihnen eine Vorstellung zu geben, hier ein paar Zahlen, bezogen auf ein 192 kB großes Programm (TOS). Das “Laden” des TOS aus dem ROM, das wie gesagt die Aufteilung in Befehls- und Datenbereiche, die Vergabe aller benötigten Labels und einiges mehr beinhaltet, benötigt 95 s. Bei kurzen Programmen dementsprechend nur wenige Sekunden. Die “goto”-Funktion und das Suchen von Labels und Byte-Folgen über 192 kB benötigt unter 1 bzw. 2 Sekunden. Das Suchen von Zeichenketten im Listing ist mit 62 s langsam, aber dafür muß ja auch das komplette Listing intern generiert werden. Die Arbeitsgeschwindigkeit der Funktionen hängt hauptsächlich von der Länge des Programms, weniger vom Umfang der durchgeführten Änderungen, ab. So erfolgt die Funktion “Adreßcharakter ändern” mit allen vier Kriterien über das ganze TOS in 38 s, das Wandeln von 2 Bytes Daten in 1 Befehl braucht immerhin auch 36 s. Bei kleinen Programmen sind dies wiederum nur wenige Sekunden.

Wenn man also viele kleine Änderungen macht, können die Wartezeiten doch lästig werden (natürlich nur bei solch riesigen Programmen), daher sollte man hier möglichst viel in einen Arbeitsschritt zusammenfassen. Das Speichern auf Diskette ist mäßig schnell, hier ist eine RAM- oder Harddisk von Vorteil.

Einsatzmöglichkeiten

Welche der eingangs genannten Anwendungsmöglichkeiten wird Easyrider nun gerecht? Es können sehr leicht beliebige, auch große. Programme reassembliert und mit kleinen Änderungen versehen neu assembliert werden, so daß sie noch funktionieren. Dies wird durch die Vielzahl an Möglichkeiten unterstützt, Adressen bei relativen Zugriffen durch Symbole zu ersetzen.

Ferner sollte ein vernünftiger Assembler in der Lage sein, das unveränderte Reassembling in ein dem Original (fast) gleichendes Programm zu übersetzen. Nur “fast” deshalb, weil beim Reassemblieren Information, die nicht für die Programmfunktion, wohl aber für die Kodierung wesentlich ist, verlorengehen kann. So wird move.b #-2,d0 je nach Assembler zu move.b #$00fe,d0 oder move.b #$fffe,d0 übersetzt (ersteres kann auch mit move.b #$fe,d0 erzeugt werden), Easyrider reassembliert beides aber als move.b #$fe,d0. Den ebenfalls legalen Befehl move.b #$12fe,d0, der aber wohl von keinem Assembler erzeugt wird, lehnt Easyrider als Unsinn ab und stellt ihn stets als Daten dar.

Auch die Programmlänge eines neu assemblierten Programms muß nicht unbedingt exakt die gleiche sein. Das liegt nach meiner Beobachtung daran, daß die verschiedenen Linker sich nicht darauf einigen können, mit wievielen Null-Bytes die Relozierdaten enden (eins bzw. vier, wenn keine Relozierdaten da sind, wäre korrekt), auch die Symboltabellen können leicht unterschiedlich sein. GEM-DOS ist da beim Laden eines Programms recht großzügig, so daß solche Linkerfehler normalerweise nicht auffallen.

Diese “Inkompatibilitäten” sollten natürlich auf die Programmfunktion keinen Einfluß haben und sind bei “normalen” Programmen völlig bedeutungslos. Aber sie führen dazu, daß Easyrider nur bedingt dazu geeignet ist, etwa einen Kopierschutz zu “knacken”, da hier die Verwendung von Prüfsummen eine bitweise Gleichheit verlangt, die Easyrider nicht garantieren kann. Auch die Untersuchung des neuesten Bootsektorvirus' gestaltet sich mit Easyrider recht einfach.

Easyrider ist sicherlich auch dazu zu gebrauchen, Einblick in fremde Programme zu bekommen und diese weitgehend zu analysieren. Für diesen Zweck könnte aber Easyrider noch einige zusätzliche Funktionen gebrauchen, um die Darstellung (nicht die Funktionalität!) des Reassemblings zu verbessern. Unübersichtlich ist z.B., daß Datenbereiche im allgemeinen nur durch dc.b, also als Bytes, repräsentiert werden (ausgenommen sind nur Adreßtabellen und LINE A/F-Befehle). Hier müßte noch zwischen Byte-, Wort- und Langwortbereichen unterschieden werden. Außerdem sollte der Anwender festlegen können, wann eine neue de-Zeile begonnen wird.

Bei Bytes, die druckbare Zeichen bezeichnen, sollte es möglich sein, individuell zu entscheiden, ob sie als Hex-, Dezimalzahlen oder als Zeichen dargestellt werden. Easyrider erlaubt nur, global festzulegen, ob Hex- oder Zeichendarstellung gewünscht ist, und das auch nur in ‘dc’-Zeilen’, was wenig brauchbar ist. Genauso sollte bei Zahlenkonstanten in Befehlen verfahren werden. Easyrider benutzt zwar je nach Zusammenhang automatisch Hex- oder Dezimalzahlen, aber dies ist nicht immer das Gewünschte. Weiterhin wäre es nützlich, wenn Konstanten oder absolute Adressen durch Symbole benannt werden könnten. Ferner ist die Darstellung eines einzelnen Null-Wortes durch DS.W 1,0 unschön: besser wäre hier einfach DC.W 0.

Easyrider erlaubt zwar das Benennen von Labels, doch muß dazu deren Bedeutung erkannt sein, was bei umfangreichen und verzahnten Programmen oft nicht auf Anhieb gelingt. Hilfreich wäre daher die Möglichkeit, jeder Zeile einen Kommentar anzufügen, der auch im Reassembling erscheint (vielleicht wahlweise wegen der Ausgabegeschwindigkeit). Ohne diese Erweiterungen kann mit Easyrider kein dokumentiertes und übersichtliches Programm-Listing erzeugt werden; umfangreiche Nachbesserungen mit einem Editor sind unumgänglich. Das soll jetzt aber nicht den Eindruck erwecken, das Reassembler-Listing sei chaotisch. Für den häufigen Anwendungsfall, einen groben Überblick von einem Programm zu erhalten und Veränderungen vornehmen zu können, reicht es völlig aus.

Handhabung und Gestaltung

Die Bedienung von Easyrider gestaltet sich im großen und ganzen recht angenehm, doch gibt es hier auch die meisten Kritikpunkte.

Für äußerst gelungen halte ich die Auswahl der Bereichs, auf dem die Funktionen wie Bereichswandlung, “Datencharakter” usw. arbeiten sollen. Im Kodebereich des Disassembler-Listings läßt sich der Bereich mit der Maus selektieren. Dabei wird der Text automatisch gescrollt, wenn das obere oder untere Ende des Fensters erreicht wird. Wenn kein Bereich selektiert wird, erscheinen in der Dialogbox zusätzliche Eingabefelder, durch die direkt Adressen oder Textanfang und -ende als Bereichsgrenzen festgelegt werden können.

Reassembling nach Bearbeitung

Dieses Konzept wurde aber leider nicht ganz durchgehalten, da bei “Datencharakter" nur mit der Maus ausgewählt werden kann, bei “Drucken" nur die Angabe der Adressen vorgesehen ist und bei “Wandlung Daten nach Befehl" die Optionen nur geändert werden können, wenn keine Selektion mit der Maus erfolgte. Positiv zu vermerken ist, daß alle Funktionen der Menüleiste auch über die Tastatur zu erreichen und die Shortcuts in der üblichen Weise im Menü vermerkt sind.

Während sich über die Verteilung der einzelnen Funktionen auf die Menütitel noch streiten läßt, ist die Gestaltung des Menüs ansonsten gründlich mißglückt. So wurde die GEM-Konvention, daß links jedes Menüeintrags zwei Leerzeichen stehen sollen, nicht eingehalten, ja es stehen meist noch nicht einmal alle Einträge eines Titels untereinander! Weiter herrscht eine merkwürdige Mischung englischer und deutscher Bezeichnungen vor (“laden" und “drucken", aber “save" und “new"), Teile des (riesigen) INFO-Menüs lassen sich einzeln selektieren, ohne daß Funktionen damit ausgelöst würden, und noch einiges mehr. Stattdessen ist die Resource-Datei “handoptimiert", um einiges der üblichen Redundanz einzusparen. Hier wurden, so glaube ich, die Prioritäten falsch gesetzt.

Überflüssig ist der Menüpunkt NEW, der nach Sicherheitsabfrage das bearbeitete Programm löscht und automatisch die Funktion “laden" aufruft. Dazu würden auch die Menüpunkte zum Laden reichen. Dagegen wird bei QUIT das Programm ohne vorherige Warnung verlassen, mit

einem Hinweis darauf in der Anleitung. Was soll das, hier mit einer Sicherheitsabfrage zu sparen?

Fehl am Platze ist meiner Meinung nach der integrierte Bildschirmschoner. Nichts gegen einen Bildschirmschoner (ich benutze selbst einen), aber was hat er in einem Reassembler zu suchen? Glücklicherweise ist er abschaltbar, wenn diese Einstellung auch nicht dauerhaft in einer Konfigurationsdatei gesichert werden kann.

Unzweckmäßig arbeitet auch die Anzeige der externen Labels, die statt des Programmlistings im Fenster präsentiert werden und, falls die Fensterhöhe nicht ausreicht, mit den Cursor-Tasten oder den vertikalen Pfeilen auch verschoben werden können. Wenn dabei aber der Anfang oder das Ende der Tabelle überschritten wird, verschwindet die Label-Tabelle ohne Vorwarnung und macht dem Pro-gramm-Listing Platz. Beim Scrollen heißt es also aufgepaßt und ja keinen Tastendruck zu viel machen. Wenn man einige Sekunden lang gar nichts unternimmt, erscheint plötzlich eine Dialogbox, die einen fragt, ob man nicht lieber zurück ins Menü möchte! Mit dem Abschalten des Bildschirmschoners wird man auch von diesem “Feature" verschont. Wozu gibt es eigentlich das Schließfeld bei Fenstern? Auch der “Slider" des Fensters ist nicht korrekt programmiert und zeigt nicht immer das an, was er soll.

Die Anleitung von Easyrider beginnt mit einer ausführlichen Einführung, was ein Reassembler überhaupt ist und wozu er verwendet werden kann. Außerdem wird auf das mitgelieferte Beispielprogramm eingegangen, an dem die vielfältigen Funktionen ausprobiert werden können.

Über das Handbuch verteilt finden sich auch theoretische Grundlagen über das GEMDOS-Programmformat, die Base-Page usw. Die Erklärung der einzelnen Funktionen ist ausführlich und geht auch auf besondere Probleme und Sonderfälle ein. Abbildungen der Menüs und Dialogboxen unterstützen den Text. An einigen Stellen ist mir die Ausdrucksweise zu programmtechnisch, z.B. werden Dialogboxen und Auswahlknöpfe (Buttons) oft nur als “Objekte" bezeichnet, was bei einem Nicht-GEM-Programmierer zu Verwirrung führen kann. Am Ende wird der von Easyrider verwendete Befehlssatz aufgeführt, und es werden Hinweise zur Assemblierung des Listings gegeben. Hier wäre vielleicht eine genaue Zusammenstellung aller notwendigen Änderungen des Listings für die verbreitetsten Assembler interessant. Im Anhang findet sich unter anderem eine Übersicht der Tastenbelegung. Das Handbuch erfüllt seinen Zweck jedenfalls ganz gut.

Urteil

Der Reassembler verfügt über beachtliche Funktionen, die Konkurrenzprodukte (soweit ich sie kenne) nicht bieten, hat dafür aber einige Macken in der Bedienung. Innerhalb kurzer Zeit lassen sich Programme in einen Zustand versetzen, in dem sie leicht geändert und neu assembliert werden können, vorausgesetzt man hat den richtigen Assembler. Gerade der Assembler-Anfänger kann beim Studium fremder Programme sicherlich einiges lernen; Gutes, aber auch Schlechtes, denn viele Assembler-Programme kann man nicht gerade als vorbildlich bezeichnen. Auch zur Analyse und Dokumentation fremder Programme einschließlich des TOS läßt sich Easyrider gebrauchen, wenn hier auch einige Mängel offenbar werden. Hoffen wir, daß zukünftige Versionen hier Abhilfe schaffen. Viele Beanstandungen sind ja - programmtechnisch gesehen - nur Kleinigkeiten.

Jedem, der sich von den Anwendungsmöglichkeiten angesprochen fühlt, und dem der Preis von DM 149,- angemessen erscheint, kann ich Easyrider daher nur empfehlen.

Bezugsadresse:
Andreas Borchert Wiesenbachstr. 2a 4500 Osnabrück


Alex Esser
Aus: ST-Computer 09 / 1989, Seite 153

Links

Copyright-Bestimmungen: siehe Über diese Seite