TMS 7000 Decompilieren in Ghidra

Johannes M. #7887557
Lesenswert?
• ▲
▼

Hallo,

ich kenne mich ein wenig mit Ghidra aus und versuche gerade ein Programm gemacht für den TMS70C02 im Full Expansion Mode zu decompilieren.

Dazu habe ich folgendes Modul in Ghidra geladen: https://github.com/benpye/tms7000

In der Memory Map von Ghidra habe ich den ROM Speicher Bereich definiert und als Read Only markiert. Ebenso habe ich ein in der Schaltung vorhandenes externe RAM definiert und als RWX markiert.

Nun bekomme ich zwar relativ viel decompiliert, habe aber immer wieder Bereiche von Funktionen mit Daten die unbekannt sind. (Beispiel im Screenshot)

Was mache ich falsch?

Ich vermute Ghidra weiß nicht, dass der TMS im Full Expansion Mode laufen soll da ich auch Dinge sehe wie z.B. P13 = 0x12;

Letzendlich möchte ich ja nicht wissen welche einzelenen Schritt In der CPU laufen, sondern welche Adresse im RAM oder Rom gelesen wird. Ist die Frage ob das überhaupt möglich ist? Weil dafür letztendlich ja die ganzen ASM Befehle ablaufen müssen in der CPU, Ghidra müsste diese Muster nur zum decompileren in den C-Code erkennen können.

Angehängte Dateien:
Beitrag melden Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Markierten Text zitieren Antwort Antwort mit Zitat
Cartman E. #7887577
Lesenswert?
• ▲
▼

Johannes M. schrieb:

Außerdem bin ich denke ich nicht fit genug mit dem reinen Assemblercode um das rauszufinden, was ich rausfinden möchte.

/dasmxx/ ist nur ein simpler Dissassembler und kein IDA Pro. Er braucht u.U. auch /Hilfestellung/ bzgl. der Speicherbereiche.

Aus den Beispielen: ffirmware.bin q,30 c8000

p804d Reset p91a1 INT1_Handler p91c3 INT2_Handler p922e INT3_Handler p9279 INT4_Handler p9282 INT5_Handler

bf2d2

vfff4 Vector_Table effff

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Johannes M. #7891223
Lesenswert?
• ▲
▼

Es scheint so, als wenn Ghidra manchmal Daten als ausführbaren Code interpretiert. Also komme ich erstmal so weiter.

Allerdings hänge ich gerade ein wenig an der Funktion der die Checksumme des Eproms berechnet. Ich verstehe nicht wie die Checksumme genau berechnet wird.

Meine Vermutung ist, dass die Checksumme als 16 bit Wert an Adresse 0x5000 steht.

Ich versteht es so, als wenn ab Adresse 0xf800 der Inhalt der Adresse in R98 addiert wird.

Aber bis wohin? Und eigentlich macht mit der Aufbau des Eproms Adresse 0xf800 kein Sinn. 0xFFFF wäre logischer.

R88 wird in der Funktion gar nicht initalisiert. Wofür BTJO %0x1,R88,LAD_d489 geprüft wird verstehe ich gar nicht.

Zum Schluss dürfte dann der Wert aus Adresse 0x5000 mit der Checksumme aus R99 verglichen werden und JZ LAB_d4d5 entscheidedt ob die Checksumme korrekt ist oder nicht.

Kann mir jemand beim ASM Code auf die Sprünge helfen?

Angehängte Dateien:
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Thomas Z. #7891286
Lesenswert?
• ▲
▼

Johannes M. schrieb:

Kann mir jemand beim ASM Code auf die Sprünge helfen?

warum exportierst du das als jpg?. Jeder der aktive Hilfe will würde den Ausschnitt als txt zur verfügung stellen.

Übrigens: man kann Variablen auch sinnvoll umbenennen. R100 usw ist nicht so aussagekräftig. Ich bin mir sicher dass Ghitra auch erlaubt Kommentare zu vergeben.

Also in der Art

1
 
   MOVD  %0xF800, R98       ; Start_Value = 0xF800

2
 
   MOVD  %0x0000, R100      ; ChkSum = 0;

3
 
   ...
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren