Aufwand zum Disassemblieren?

"Nikolaus Riehm" schrieb im Newsbeitrag news:490eda55$0$32663$ snipped-for-privacy@newsspool2.arcor-online.net...

Es gibt reihenweise 6502 Disassembler, die besseren machen pseudo- codedurchlaeufe um Programm und Daten zu trennen, aber praktisch keine Decompiler. Du siehst also Assembercode ohne Kommentare und aussagekraeftige Namen, und keinesfalls C-Programmcode, falls es jemals aus einem C-Programm entstanden sein sollte. Sicher kann man daraus die Funktion des Programm zurueckermitteln, ob sich der Aufwand lohnt, sei aber dahingestellt. Rechne ohne Uebung mit 1 Woche fuer 1k Code, ein sinnvolles Werkezug welches Setzen von aussagekraeftigen Namen erlaubt waehrend man den Code versteht, ist hilfreich, ich verwende

--
Manfred Winterhoff

Nikolaus Riehmschrieb: "

So einfach ist das leider nicht. Für das Verständnis des Programms mußt du dir klar machen, wo RAM-, EPROM- und IO-Port-Bereiche liegen, damit Du die Datenbereiche zuordnen kannst. Das ergibt sich meist schon aus der Hardware Beschaltung Dann fängst Du an die ganzen calls und returns zu suchen, um Unterprogramme zu finden. Auch die Interruptroutinen lassen sich recht einfach finden, da sie auf festen Adressen liegen.

Und dann kann man nur hoffen, dass der Entwickler keinen Spaghetti-Code entwickelt hat.

Dabei kann auch ein Simulator (besser Emulator) recht hilfreich sein.

Dirk

Hi,

Im Prinzip schon. Nur sind (natürlich) all die schönen "sprechenden" Variablennamen oder Labelnamen dann durch schnöde durchnummerierte Bezeichnungen ersetzt. Da es natürlich auch keine Kommentare gibt, macht es das nicht unbedingt leichter, einen Code zu verstehen.

Man muss sich natürlich im klaren drüber sein, was die 6502-Befehle so tun. Insbesondere im Hinblick auf die Adressierung kann das "interessant" sein. Es kann durch Sprungbefehle im Code dazu kommen, dass der Disassembler aus dem Tritt kommt und dann reine Datenblöcke versucht als Programm zu dekodieren und (schlimmer) umgekehrt auch mal nicht merkt, wo das Programm weitergeht. Da braucht es dann ein bisschen Handarbeit.

Sowas hatte ich für den C-64. Hat tadellos funktioniert und ich konnte damit das BIOS der externen Floppystation analysieren und ein bißchen tunen... aber das ist längst alles entsorgt. Ob es da was aktuelles gibt, was auf aktueller Technik läuft, weiß ich nicht, aber nach c-64 und disassembler zu googeln könnte ja vielleicht schon was bringen.

Gruß Michael Kutscher

...

..

Im Prinzip ja. Wobei "fertig" relativ ist. Ein Disassembler kann zwar Markennamen für verwendete Adressen vergeben, es läuft aber meist darauf hinaus die Adresse in HEX zu verwenden. M.a.W. ist der Code zwar syntaktisch korrekt, aber i.d.R. immer noch schwierig zu lessen.

Es ist u.U. nichttrivial, ausführbaren Code von Konstanten (Strings, Adreßtabellen etc.) zu unterscheiden.

Ich mag den d65 von Marko Mäkelä. Findest du z.B. hier: ftp://ftp.zimmers.net/pub/cbm/programming/unix/

Das Programm compiliert mit aktuellen C-Compilern nicht mehr weil es eine Kollision der C-Funktion abs() mit dem Opcode ABS gibt. Der folgende Patch umgeht das Problem:

--- dump.c.orig 1994-06-18 10:28:47.000000000 +0200

+++ dump.c 2008-11-03 12:45:08.000000000 +0100 @@ -31,7 +31,12 @@

#define _DUMP_C_ #include

+ +#if 0 #include +#else +void *malloc(size_t size); +#endif

#include "proto.h" #include "options.h"

--- label.c.orig 2008-11-03 12:45:38.000000000 +0100

+++ label.c 2008-11-03 12:46:07.000000000 +0100 @@ -33,6 +33,7 @@

#include #include

+#include

#include "proto.h" #include "options.h"

--- main.c.orig 2008-11-03 12:46:28.000000000 +0100

+++ main.c 2008-11-03 12:47:33.000000000 +0100 @@ -31,7 +31,14 @@

#define _MAIN_C_ #include

+#include + +#if 0 #include +#else +int atoi(const char *nptr); +#endif

• #ifdef __GNUC__ #include #endif /* __GNUC__ */

HTH, XL

Wenn Du weißt, * was* nicht funktioniert, bist Du da nicht mit einem Logik-Analysator schneller?

Grüße, H.

Wenn man alles in der Elektronik abgegrast hat was nicht ewig hält ( Kältespray und Heisluft manchmal nützlich ) kann man eventuell noch auf absaufendes EPROM testen. D.h. bei variabler Versorgungsspannung auslesen und prüfen ob sich dann der Inhalt ändert. Eventuell langsamer auslesen. Beides kann man manchmal in der Originalleiterplatte machen ( Manipulation an Quarz, Spannungsregler ).

MfG JRD

Rafael Deliano schrieb:

Wer weiß, vieleicht sind ja ein paar bits gekippt. Bei dem Alter durchaus denkbar. Dann wird das dissasemblieren sinlos....

Andreas

Michael Kutscher schrieb:

Hihi, das war vor fast 25 Jahren, als wir den 6502/6510 in Apple][ und C64 unsicher gemacht haben, sowie die VC1541, unsere Spezilität, bewusst den Code so zu verunstalten, dass ein Disassembler regelmäßig auf die Nase fiel.

Zum 6502 kommt noch hinzu, dass er zwar nur wenige Befehle kannte, diese einfach zu erlernen waren, aber er unterscheidet nicht zwischen Speicher- und I/O-Adressen. Somit muss erst einmal Klarheit geschaffen werden, wo was überhaupt liegt. Nur wenige Adressen sind beim 6502 sicher: Ab $FFF0 sollte ein wenig ROM liegen, und von $00 bis $01FF RAM. Im ersten liegen die Vektroren für Reset, NMI und INT, die man evtl auch verbiegen kann, die unteren 256 Bytes sind die Zero-Page, die u.a. für Indexierungen benötigt wird, und die zweiten 256 Bytes bilden den Stack. Alles dazwischen ist reine Willkühr des Entwicklers.

Disclaimer: Das ich meine Nase in Rodnay(?) Zarks "Programmierung des

6502" gesteckt habe, ist mehr als 20 Jahre her.

Ohne nachgeschaut zu haben, sollte es mit dem Teufel zugehen, wenn zum

6502 kein Crossassembler mit Simulator und Disassembler verfügbar wäre. Der Prozessor war neben dem Z80 die Referenz für das Erlernen der Programmierung in Assembler.

--
  Mit freundlichen Grüßen   | /"\  ASCII RIBBON CAMPAIGN  |
    Andreas Bockelmann      | \ /   KEIN HTML IN E-MAIL   |
   F/V +49-3221-1143516     |  X    UND  USENET-GRUPPEN   |
                            | / \                         |

Hier sollte sich finden lassen, was das Herz begehrt:

Und die 6502 Architektur ist noch lange nicht tot. Ich entwickle ja selbst mit analogen Bauteilen, die seit ueber 30 Jahren am Markt sind, aber in Sachen uC war ich bei Kunden schonmal verbluefft, wie selten man ganz neue Archtekturen sieht. Teilweise liegt es daran, dass man an jeder Ecke Programmierer fuer Sachen wie 8051 findet, teilweise liegt es am fehlenden 2nd Source bei modernen uC.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

IDA Pro ist wirklich gut, habe damit schon MIPS-Code annotiert während meiner PSP Reverse-Engineering Spielchen. Die c64 intern Buchautoren hätten sowas wohl auch recht gut gebrauchen können, falls die das Listing nicht schon von den Entwicklern bekommen haben.

Vielleicht kann der OP ja mit der Evaluierungsversion von IDA Pro was anfangen, denn nur für einmal ein ROM zu disassemblieren ist es etwas teuer (aber lohnt sich, wenn man sowas öfters braucht).

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Ich habe früher Programmierer erlebt, die konnten sich den Hexcode ansehen und das Programm darin sehen. Da bringen dann verwirrende Bytes nach unbedingten BNEs auch nichts :-)

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

"Frank Buss" schrieb im Newsbeitrag news: snipped-for-privacy@40tude.net...

IDA ohne Pro (also DOS Programm) ist glaube ich kostenlos, zumindest fuer 8086, weiss aber nicht ob 6502. Fuer den hatte ich eh was anderes verwendet, Sourcerer, andere Zeiten, und fuer Z80 den REZ.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

hen

(JNE oder JNZ bitte: es ist erstaunlich wie viele verschiedene Assembler-Sprachen es gibt, die exakt das gleiche beschreiben)

Das mit den sehen aus dem Hexcode geht aber nur solange feste Befehlsl=E4nge und Parameterl=E4ngen und ohne Pr=E4fix und Postfix gearbeitet wird. Die moderneren Intelmaschienchen verstehen ja jeden M=FCll egal ob up-down oder down-up gespeichert wurde oder mit wahlweise 2 oder 3 Parametern gearbeitet wird. Die Verarbeitung h=E4ngt dann noch von verschiedenen Registern ab (CR0 ...). Jedenfalls haben verschiedene Pseudokopierschutzmechnismen dies bis zum Excess betrieben und so den Code wirklich nicht mehr disassamblierungsf=E4hig gemacht. Zu den leichtesten =DCbungen geh=F6rt noch, dass in Pascal die Int()-Funktion mit selbst=FCberschreibenden Code arbeitet. Dann gibt es noch die JMP +1 Befehle, die eigentlich nur den Cache leeren sollen.

Bei RISC's ist es etwas schwieriger als ASCI's, da ich weniger Befehle zur Auswahl habe. Aber mit ein bischen Kreativit=E4t l=E4sst sich auch hier jeder Befehl in einen Funktions- oder Unterroutinenaufruf verpacken.

Im allgemeinen l=E4sst sich Assembler-Code besser Disassemblieren als ein Hochsprachencode. Bei Hochsprachencode sa=DF ich schon mal mit einem Disassembler da, um zu sehen was ich in der Hochsprache (C) eigentlich angestellt habe und warum das timing nicht stimmt. Ist nat=FCrlich etwas einfacher, wenn ich das Quellprogram in C habe.

Das kommt von ganz alleine wenn du in Maschinensprache programmiert aber noch keinen Assembler hattest und das Programm auch noch immer in eine REM-Zeile poken musstest. Relative Spruenge waren aber nervig...

Olaf

Also ich kenne nur BNE. Google meint auch, daß 6502 bne mehr als doppelt so häufig wie 6502 jne vorkommt.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

In article , Stefan Engler writes: |> |> JNE oder JNZ bitte

Aber doch nicht bei 6502...

Rainer

Hatte ich ganz zu Anfang auch mal gemacht, aber über eine kleine Verzögerungsschleife mit Bildschirm füllen bin ich da nicht herausgekommen. Bin dann schnell zu einem guten Macro Assembler gewechselt (Hypra Ass). Ich glaube den hatte ich sogar aus einem Magazin als Basic-Programm, mit unzähligen data-Zeilen abgetippt.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Noe..ZX Spektrum.

Olaf

Frank Buss schrieb:

Ich kann Dir zeigen, wie das z.B. beim Z80 läuft:

- push hl

- irgendwas umschaufeln und rechnen

- ex hl,(sp)

- ret Das wird natürlich nicht wegen des Begreifschutzes gemacht, sondern um eine Sprungtabelle einzubauen. Aber wenn das Programm diese dann noch dynamisch im RAM verwaltet, dann war's das.

MfG hjs