Hallo, ich würde gerne zwecks Reverse-Engineering die Firmware eines MC68331-Microcontrollers (144-pin version), der in einem Gerät verbaut ist, auslesen (Manual: https://www.nxp.com/docs/en/data-sheet/MC68331UM.pdf). In der Manual finde ich zum Debuggen lediglich das BDM-Interface, oder habe ich etwas übersehen? Mit welcher Hardware (möglichst günstig) und welcher Software könnte ich damit am besten an das Programm gelangen? Ich habe leider noch keine Erfahrungen mit Mikrocontrollern gemacht und benötige etwas Input. Vielen Dank schonmal.
Der MC68331 hat weder ROM noch RAM integriert, da musst Du mal auf der Platine nach Flash-Bausteinen oder EPROMs suchen.
Hier etwas Lesestoff und eine Bauanleitung für Dich: http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html Damit habe ich es damals hinbekommen. Beide Adapter funktionieren mit BDM32. Das ist allerdings ein DOS-Programm, das für das Timing Warteschleifen verwendet. Außerdem werden beide Adapter über LPT angeschlossen. Ein alter DOS-PC ist also hilfreich. Es gibt wohl auch kommerzielle Lösungen. Zu denen kann ich aber nichts sagen.
Vielen Dank für eure Antworten! Hmmm schrieb: > Der MC68331 hat weder ROM noch RAM integriert, da musst Du mal auf der > Platine nach Flash-Bausteinen oder EPROMs suchen. Auf der Platine befinden sich SRAM-Bausteine, die angeblich das Programm enthalten sollen (Samsung K6X1008C2D-TF55). Natürlich ist das Programm weg, wenn die Spannungsversorgung unterbrochen wird. Daher möchte ich mit dem BDM-Adapter noch während der Microcontroller läuft, das Programm auslesen. Steffen Hausinger schrieb: > Hier etwas Lesestoff und eine Bauanleitung für Dich: > http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html > > Damit habe ich es damals hinbekommen. Beide Adapter funktionieren mit > BDM32. Das ist allerdings ein DOS-Programm, das für das Timing > Warteschleifen verwendet. Außerdem werden beide Adapter über LPT > angeschlossen. Ein alter DOS-PC ist also hilfreich. > > > Es gibt wohl auch kommerzielle Lösungen. Zu denen kann ich aber nichts > sagen. Ich habe das Public-Domain-Interface von dieser Seite nachgebaut und auf einem alten Linux-System den dort hochgeladenen gdb-Patch auf eine alte gdb-Version angewendet sowie den BDM-Driver kompiliert und in den Kernel geladen. Jetzt kann ich mit gdb auf den Microcontroller zugreifen und auch zum Beispiel mit
1 | set $sfc=5 |
2 | print $sfc |
3 | set $XX0000=5 |
4 | print $XX0000 |
Register oder den Initial Stack Pointer verändern, ich schätze also, dass der Adapter so funktioniert, wie er soll. Ich weiß jetzt nur nicht, wie ich auf den Addressbereich komme, in den die Speichermodule gemappt sind. In der Anleitung des MC68331 konnte ich dazu nichts finden. Hat jemand einen Hinweis dazu?
:
Bearbeitet durch User
Axel P. schrieb: > Ich weiß jetzt nur nicht, > wie ich auf den Addressbereich komme, in den die Speichermodule gemappt > sind. In der Anleitung des MC68331 konnte ich dazu nichts finden. Hat > jemand einen Hinweis dazu? Das Stichwort im Datenblatt ist Memory Map, aber im Endeffekt hängt alles von der externen Beschaltung ab. Bei 0x00000000 findest Du den SSP, bei 0x00000004 den PC beim Reset, das dürfte zumindest Anhaltspunkte liefern.
Axel P. schrieb: > Hmmm schrieb: >> Der MC68331 hat weder ROM noch RAM integriert, da musst Du mal auf der >> Platine nach Flash-Bausteinen oder EPROMs suchen. > > Auf der Platine befinden sich SRAM-Bausteine, die angeblich das Programm > enthalten sollen (Samsung K6X1008C2D-TF55). Natürlich ist das Programm > weg, wenn die Spannungsversorgung unterbrochen wird. Daher möchte ich > mit dem BDM-Adapter noch während der Microcontroller läuft, das Programm > auslesen. Diese Argumentationskette ist doch Unsinn. Eine logische Kette müsste dazu führen: Ich suche den Speicher, der bei Abschaltung der Versorgung NICHT seinen Inhalt verliert. Es muss ein solcher Speicher existieren und er muss das Programm enthalten, wenn auch nicht unbedingt vollständig im "Klartext", es könnte z.B. durchaus sein, dass der Hauptteil des Programms gepackt vorliegt. > Ich weiß jetzt nur nicht, > wie ich auf den Addressbereich komme, in den die Speichermodule gemappt > sind. Der ROM muss im Minimum den Resetvector und ein Stück Initialisierungscode ungepackt enthalten. Da die initialen Vectoren bei dem Controller am Ende des Speichers liegen, wird der ROM mit Sicherheit am Ende eingeblendet werden, zumindest erstmal beim Reset. Also dürfte die Startadresse des ROM auf Endaddresse des Controllerspeichers-Größe des ROM+1 liegen. Später kann sich das alles ändern. Es wäre z.B. nicht ungewöhnlich, dass nach Füllen des RAM der ROM komplett ausgeblendet wird und RAM an seine Stelle tritt. Was genau passiert, bekommt man heraus, indem man den Initialisierungscode im ROM analysiert.
Ich verstehe das Konzept nicht. Das Programm ist nur im SRAM. Und wenn der Strom einmal weg ist, ist das Gerät unbrauchbar, weil kein Rom vorhanden ist? Das kann ich mir nicht so recht vorstellen. Da wird wohl ein Rom vorhanden sein. Also auslesen und disassemblieren. Die CPU ist kompatibel zum 68000. Und da gab es bereits vor 30 Jahren Disassembler, mit dem man sich die Instruktionen anschauen konnte. Sowas habe ich damals schon für den Atari-ST benutzt. Ist allerdings schon Richtung Hardcore, man sollte wissen, was man tut.
BAR in der Anleitung suchen... Base Adress Register glaube gab 0 bis 7... Ist schon ne Weile her... Die auslesen und den reset vektor heraus finden
PittyJ schrieb: > Das Programm ist nur im SRAM. Und wenn der Strom einmal weg ist, ist das > Gerät unbrauchbar, weil kein Rom vorhanden ist? > Das kann ich mir nicht so recht vorstellen. Es gibt ein Haufen Geräte bei denen das der Fall ist! Für diese Geräte gibt es sogar ICs die zwischen CPU und Speicher sitzen und im Falle eines "Angriffs" auf das Gerät prozessorunabhängig den Speicher löschen. Zum Auslösen der Löschung können Ereignisse wie Lichteinfall per Fotodiode, plötzlicher Temperaturabfall per Thermoelement, Drahtbruch einer Drahtschleife usw. dienen.
c-hater schrieb: > Da die initialen Vectoren bei dem Controller am Ende des Speichers > liegen, wird der ROM mit Sicherheit am Ende eingeblendet werden, > zumindest erstmal beim Reset. Die liegen wie gesagt am Anfang. Falls Du Dich an den Atari ST erinnerst, wo das ROM weiter hinten liegt: Da wurden deshalb die ersten 8 Bytes eingespiegelt.
Kryptonix schrieb: > Es gibt ein Haufen Geräte bei denen das der Fall ist! Wie kommt ein solches Gerät vom Hersteller zum Kunden? Läuft es auf dem Transport aus einer Batterie? Wenn beim Kunden die Sicherung auslöst, weil die Kaffeemaschine defekt ist, wird das Gerät unbrauchbar? Irgendwo in der Kiste ist ein nichtflüchtiger Speicher, der das Programm enthält. Anders geht es nicht.
Georg G. schrieb: > Irgendwo in der Kiste ist ein nichtflüchtiger Speicher, der das Programm > enthält. Anders geht es nicht. Gegenbeispiel: Siemens Micromaster 4xx AOP (ADVANCED OPERATOR PANEL). In diesem befindet sich tatsächich der Programmcode in einem batteriegepufferten SRAM. Die Batterie muss explizit bei bestromten Gerät getauscht werden. Grüßle Volker
Georg G. schrieb: > Wie kommt ein solches Gerät vom Hersteller zum Kunden? Läuft es auf dem > Transport aus einer Batterie? Exakt. Vor Jahren hatte ich mal ein EC-Kartenterminal verschrottet, da war diese Batterie sogar über eine dünne Folie angeschlossen, die mit einem Leiterbahn-Mäander bedruckt war und beim Öffnen zerriss. So stellte man sicher dass der Programmspeicher beim Öffnen des Gerätes sicher gelöscht wird.
PittyJ schrieb: > Ich verstehe das Konzept nicht. > Das Programm ist nur im SRAM. Und wenn der Strom einmal weg ist, ist das > Gerät unbrauchbar, weil kein Rom vorhanden ist? > Das kann ich mir nicht so recht vorstellen. Das ist richtig. Auf der Platine sind 2 Batterien fest verlötet, die ca. 10 Jahre halten und den Speicher mit Strom versorgen, wenn das Gerät nicht am Netz hängt. Ist die Batterie einmal leer gegangen, hat man Elektroschrott. Kryptonix schrieb: > Es gibt ein Haufen Geräte bei denen das der Fall ist! Für diese Geräte > gibt es sogar ICs die zwischen CPU und Speicher sitzen und im Falle > eines "Angriffs" auf das Gerät prozessorunabhängig den Speicher löschen. > Zum Auslösen der Löschung können Ereignisse wie Lichteinfall per > Fotodiode, plötzlicher Temperaturabfall per Thermoelement, Drahtbruch > einer Drahtschleife usw. dienen. Sowas ist auch vorhanden (Fotodiode und Bohrschutz). Falle es jemanden interessiert, es geht um einen alten Spielautomaten, da sind solche Maßnahmen wohl gesetzlich vorgeschrieben. Ist natürlich in meinem Fall alles für den privaten Gebrauch. Die Frage, die sich mir nach euren Antworten stellt, ist, wie überhaupt der Microcontroller weiß, an welchen Adressen die einzelnen Speichermodule liegen. Gibt es eine interne Tabelle, in der das steht? Dafür spricht, dass in der Anleitung CSBAR0 bis CSBAR10 gibt, in denen jeweils eine Base Address und eine Block Size enthalten ist. Oder muss ich extern nach einem zweiten Microcontroller schauen, der das beim Starten konfiguriert? (So sieht es für mich in Figure 4-17 der Anleitung aus dem 1. Post aus). Und wenn es intern gespeichert wird, ob diese Information auch gelöscht wird, sobald er die Spannung verliert oder resetted wird.
Axel P. schrieb: > Die Frage, die sich mir nach euren Antworten stellt, ist, wie überhaupt > der Microcontroller weiß, an welchen Adressen die einzelnen > Speichermodule liegen. Wenn ich mich richtig erinnere, konnte man den 68332 (und somit wohl auch den '331) per "Hardware" konfigurieren, indem man gewisse Datenleitungen während des Resets auf Low-Pegel zieht. So konnt dann z.B. das Chip-Select für das Boot-ROM aktiviert werden. Grüßle Volker
Axel P. schrieb: > Sowas ist auch vorhanden (Fotodiode und Bohrschutz). Und du hast das Umgangen oder warum ist das Programm dann noch nicht gelöscht?
Von dem aktuellen Automaten an dem ich teste ist das Programm gelöscht, aber man kann Automaten (viel teurer) kaufen, bei denen diese Sicherheitsmaßnahmen ausgehebelt sind. Man darf dann natürlich nichts falsches machen, damit man den neuen Automaten nicht auch ausversehen löscht. Deshalb möchte ich soweit es geht an dem aktuellen gelöschten Automaten "üben". Dann könnte ich später das Programm von jedem Automaten herunterladen (da ich gehört habe, dass es auch von Außen über herausführende Pins ohne Öffnen des Gehäuses möglich sein soll) und könnte viel billiger Automaten sammeln, da die Automaten ohne Programm viel günstiger sind und ich das Programm auf diese wieder aufspielen könnte.
Axel P. schrieb: > Die Frage, die sich mir nach euren Antworten stellt, ist, wie überhaupt > der Microcontroller weiß, an welchen Adressen die einzelnen > Speichermodule liegen. Ein Blick ins Datenbuch zeigt, dass das Boot-ROM (oder in Deinem Fall, das batteriegepufferte SRAM) über den Pin /CSBoot (Pin 140 im 144-Pin Gehäuse) selektiert wird. Über D0 kann ausgewählt werden, ob das ROM 16- oder 8-Bit breit ist. Im letzten Fall muss D0 während des Resets auf Low gezogen werden. CSBoot kann auch über das CSPAR0-Register aktiviert und über CSBARBT sowie CSORBT konfiguriert werden. Wenn sich zwei RAMs im System befinden, würde ich vermuten, dass diese gemeinsam über CSBoot selektiert werden. Falls der byteweise Schreibzugriff gewünscht wird, müssten noch LDS und UDS mit den beiden RAMs verbunden sein . Sind mehr als zwei RAMs verbaut, musst Du entweder die CS-Leitungen durchklingeln oder aus dem intialisierten System die CS-Konfigurationsregister auslesen. Es sollte also kein Problem darstellen, CSBoot mittels BDM-Interface passend zu konfigurieren und auszulesen oder zu beschreiben. Grüßle Volker P.S.: Bin gespannt, ob dieser Beitrag ebenfalls negativ bewertet wird und wäre in diesem Fall über Hinweise, was zur Abwertung führte, dankbar.
:
Bearbeitet durch User
Angehängte Dateien:
-
20160817_120854.jpg
240 KB
Georg G. schrieb: > Irgendwo in der Kiste ist ein nichtflüchtiger Speicher, der das Programm > enthält. Anders geht es nicht. In Deiner Welt vielleicht - Spätestens wenn es sich um Software mit Geheimhaltungsstatus handelt sieht es ganz anders aus. Da wird sogar Hardware automatisch mit einem Lichtbogen zerstört. Die Jungs auf der anderen Seite des Atlantiks schreddern sogar Prozessoren und RAMs die mal geheime Daten gesehen haben
Volker B. schrieb: > Sind mehr als zwei RAMs verbaut, musst Du entweder die CS-Leitungen > durchklingeln oder aus dem intialisierten System die > CS-Konfigurationsregister auslesen. > > Es sollte also kein Problem darstellen, CSBoot mittels BDM-Interface > passend zu konfigurieren und auszulesen oder zu beschreiben. Vielen Dank für diesen Vorschlag. Nach dem Bau eines neuen BDM-Adapters scheint der Zugriff nun zu funktionieren. Es sind insgesamt 4 SRAMs (jeweils 128 kB) auf der Platine verlötet und ich möchte die CS-Konfigurationsregister auslesen. Diese sollten ja in der SIM-Tabelle sein, welche sich entweder an der Adresse 0xFFFA00 oder 0x7FFA00 befinden muss. Ich habe an beiden Stellen Daten auslesen können und mir ein Programm geschrieben, um die Startadressen und Blocksizes der CS-Register CSBARBT/CSBARx mittels entsprechender Bitshifts zu berechnen. Es kommt beispielsweise raus:
1 | SIM-Table startAddress: 0x7ffa00 |
2 | CSBOOT addr: 0xf000 blksz: 2K ratio: 30.0 |
3 | CS0 addr: 0x300000 blksz: 512K ratio: 6.0 |
4 | CS1 addr: 0xc38000 blksz: 2K ratio: 6256.0 |
5 | CS2 addr: 0xac0800 blksz: 2K ratio: 5505.0 |
6 | CS3 addr: 0xeac800 blksz: 2K ratio: 7513.0 |
7 | CS4 addr: 0x60e000 blksz: 8K ratio: 775.0 |
8 | CS5 addr: 0xec000 blksz: 8K ratio: 118.0 |
9 | CS6 addr: 0xc00000 blksz: 128K ratio: 96.0 |
10 | CS7 addr: 0x0000 blksz: 2K ratio: 0.0 |
11 | CS8 addr: 0x340000 blksz: 256K ratio: 13.0 |
12 | CS9 addr: 0xb28000 blksz: 2K ratio: 5712.0 |
13 | CS10 addr: 0x3e2000 blksz: 8K ratio: 497.0 |
(ratio ist das Verhältis von addr zu blksz, welches eine ganze Zahl sein muss) Das Problem ist jedoch, dass bei jedem Auslesen der SIM-Tabelle andere Daten herauskommen und daher auch andere Adressen und Blocksizes (auch, wenn ich die SIM bei 0xFFFA00 starten lasse). Das Gleiche gilt für einen Dump des Speichers bei 0x0. Da wo, z.B. der RESET - INITIAL PC stehen sollte, steht bei jedem Auslesen immer eine andere Adresse. Der BDM-Adapter sollte aber eigentlich ordnungsgemäß funktionieren, denn bei einem System mit gelöschten Speichern habe ich testweise mal die SIM-Tabelle geschrieben und erfolgreich wieder korrekt ausgelesen. Was könnte das Problem beim schon initialisierten System sein?
Axel P. schrieb: > CSBOOT addr: 0xf000 blksz: 2K ratio: 30.0 Das wundert mich! Das Boot-ROM, bzw. hier -RAM, sollte doch an Adresse 0 gemappt werden, damit der Resetverktor und Stack-Adresse vorhanden sind. Auch für den späteren Betrieb werden doch sicherlich die Interrupt-Vektoren benötigt, die nach meiner Erinnerung gleich nach Reset-Vektor und Stack-Adresse folgen. Oder kann der '331 die Interrupt-Tabelle verschieben? Es ist schon 20 Jahre her, dass ich mit dem '332 gearbeitet habe... Auch die Blockgröße von 2k erstaunt mich. Bei 128k RAM würde ich entweder 128k- oder 256k erwarten. Prüfe doch mal, ob das Boot-RAM 8- oder 16-Bit breit organisiert ist. > CS0 addr: 0x300000 blksz: 512K ratio: 6.0 > CS1 addr: 0xc38000 blksz: 2K ratio: 6256.0 > CS2 addr: 0xac0800 blksz: 2K ratio: 5505.0 > CS3 addr: 0xeac800 blksz: 2K ratio: 7513.0 > CS4 addr: 0x60e000 blksz: 8K ratio: 775.0 > CS5 addr: 0xec000 blksz: 8K ratio: 118.0 > CS6 addr: 0xc00000 blksz: 128K ratio: 96.0 > CS7 addr: 0x0000 blksz: 2K ratio: 0.0 > CS8 addr: 0x340000 blksz: 256K ratio: 13.0 > CS9 addr: 0xb28000 blksz: 2K ratio: 5712.0 > CS10 addr: 0x3e2000 blksz: 8K ratio: 497.0 Wäre es nicht schneller, an jedem RAM das benutzte CS auszumessen? Es sind ja nur vier ICs. > Das Problem ist jedoch, dass bei jedem Auslesen der SIM-Tabelle andere > Daten herauskommen und daher auch andere Adressen und Blocksizes (auch, > wenn ich die SIM bei 0xFFFA00 starten lasse). Das Gleiche gilt für einen > Dump des Speichers bei 0x0. Da wo, z.B. der RESET - INITIAL PC stehen > sollte, steht bei jedem Auslesen immer eine andere Adresse. Bist Du Dir sicher, dass die PLL der MCU korrekt initialisiert wurde, bevor Du mit dem BDM-Interface auf Register und Speicher zugreifst? Grüßle Volker
Volker B. schrieb: > Wäre es nicht schneller, an jedem RAM das benutzte CS auszumessen? Es > sind ja nur vier ICs. Kurzer Nachtrag: Falls die MCU auch einen Schreibzugriff auf die RAMs durchführen kann, müssen natürlich zwei CS-Signale auf jedes RAM geschaltet werden. Eines stellt ChipSelect und OutputEnable dar, das zweite WriteEnable. Vermutlich können ChipSelect bzw. OutputEnable eine ganze Bank, also die jeweiligen Low- und High-RAM gleichzeitig bedienen. Damit käme ich auf 6 (2+4) CS-Leitungen, wenn das RAM 16-Bit breit organisiert ist (alles unter der Prämisse, dass es sich um 8-Bit-RAMs handelt, wie meine Glaskugel behauptet). ...man könnte natürlich auch /UDS und /LDS mit R/W verknüpfen, um ein WriteEnable zu erzeugen, müsste dann aber die entsprechenden I/O-Pins der MCU aktivieren und zwei Oder-Gatter opfern. Leider kann ich das durch meine Glaskugel nicht erkennen... Grüßle Volker
:
Bearbeitet durch User
Das Thema klingt sehr interessant, bin durch Recherche auf dieses Thema gestoßen! Gibt es neue Erkenntnisse?
Beitrag #7644235 wurde von einem Moderator gelöscht.
Beitrag #7644310 wurde von einem Moderator gelöscht.
Beitrag #7644418 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.