Kurze Frage: vor mir liegt eine Control-Box mit einem STM8. Aus dem nicht geschützten Prozessor habe ich Flash und Eeprom ausgelesen und den Flash Inhalt durch einen STM8 Disassembler geschickt. Im Eeprom sind nur 2 Byte geschrieben. Jetzt hab ich zwar aus 8kB Flash 300kb Assembler Text gemacht, komme aber nicht richtig weiter. Das Programm bedient u.a. eine serielle Schnittstelle und sendet Daten aus. Das klappt auch prima. Ich müsste aber wissen, ob und welche Daten und Kommandos empfangen werden könnten. Gibt es da eine gute Idee, wie ich das Programm besser lesen und verstehen könnte? VG Ralf
:
Bearbeitet durch User
Um aus einem Binary Informationen herauszuholen braucht man geeignete Tools wie z.B. Ghidra oder IDA Pro. Ein einfacher Disassembler eignet sich dafür nur in trivialen Fällen. Damit kann man dann versuchen das Binary zu verstehen und im Tool so zu bearbeiten dass etwas verständliches dabei herauskommt.
:
Bearbeitet durch User
Erstmal müsste man sich mit dem Prozessor selbst mal richtig auskennen (lernen). Z. B. den Bereich ab 0x008000 als int_s zu interpretieren, macht wenig Sinn, das sind halt die Interrupt-Vektoren, also Adressen! Die "neg (0x00,SP)" danach sind Unfug, der Bereich ist einfach leer, aber das kann ein Disassembler ja nicht wissen. Außerdem: Irgendwelche Tabellen oder Strings durch den Disassembler zu schicken, produziert viele kByte Müll. Man muss schon beim Reset-Vektor anfangen und sich dann durchhangeln, um halbwegs erkennen zu können, was Code und was eventuell Daten sein könnten.
Ich habe nur mal auf die Schnelle reingeschaut, das eigentliche Hauptprogramm liegt bei 0x9B27. Allerdings ist das Ganze ziemlich unschön weil der Compiler für den STM8 einiges an Code produziert der nicht gerade die Lesbarkeit fördert (z.B. ist 0x8B18 die Runtime für einen "switch" und es gibt viel Code nur um die Parameter auf dem Stack zu verwalten).
Ralf G. schrieb: > Gibt es da eine gute Idee, wie ich das Programm besser lesen und > verstehen könnte? Schaue es dir auch im Hexeditor an.
Ich danke herzlich, die Herren! Ich hab gerade mal Ghidra und die Extension für STM8 installiert, aber ich befürchte ich muss da noch etwas Zeit für das Ghidra Manual einplanen. Keine Ahnung wie ich das anfangen kann. Das Binary hab ich importiert, aber irgendwie bekomme ich nichts informatives angezeigt.
:
Bearbeitet durch User
Ralf G. schrieb: > > Keine Ahnung wie ich das anfangen kann. Das Binary hab ich importiert, > aber irgendwie bekomme ich nichts informatives angezeigt. Die Tools machen das nicht von alleine, man muss ihnen z.B. mitteilen was Code oder Daten sind. Und um zu erkennen was der Code dann macht braucht es in erster Linie Erfahrung damit man schnell an Ziel kommt. Was etwas helfen könnte: wenn man den verwendeten Compiler und dessen Libraries kennt kann man das Erkennen der Runtime und Funktionen aus den Libraries teilweise automatisieren. Aber auch damit sollte man sich auskennen damit es nicht zu viel Zeit kostet. Welcher STM8 ist es denn genau, dann kann man zumindest die IO Adressen zuordnen?
Danke für deine Zeit und Aufmerksamkeit, Dieter! Euch allen natürlich! Es ist ein STM8S003F3P Es ist die mehr oder weniger simple Steuerung einer Espressomaschine. Es werden zwei Temperatursensoren (A/D) überwacht, 2 Pumpen und eine Heizung gesteuert. Die Komplexizität des Codes kommt möglicherweise daher, das irgendwo ein PID Regler integriert ist, der die Heizung steuert. Und eben das Serielle Interface (9600 8N1) Das Ganze kommt aus Italien, aber meine Anfrage beim Hersteller ist bislang unbeantwortet. Ich habe deswegen keine Info zum verwendeten Compiler. Aber ich lerne gerne! Daher danke für deinen Input!
:
Bearbeitet durch User
Das hier ist vielleicht auch einen Blick wert: https://github.com/Prehistoricman/STM8-IDA (die Seite hier fand ich ebenfalls gar nicht so übel: http://aquarel-electronic.de/STM8/ASM8/ASM8_Page.html)
Vielleicht etwas zum Nachvollziehen, das ist zwar nur die Initialisierung der Hardware, hilft aber eventuell für den Einstieg:
1 | 0x962F call clock_init |
2 | |
3 | 0x9632 ld a, #1 |
4 | 0x9634 call port_init |
5 | |
6 | 0x9637 call ADC_init |
7 | |
8 | 0x963A call TIM1_init |
9 | |
10 | 0x963D ldw x, #9600 ; baud |
11 | 0x9640 call UART1_init |
12 | |
13 | 0x9643 call flash_enable_write |
14 | |
15 | 0x9646 jp IWDG_init |
:
Bearbeitet durch User
Hallo Dieter, das sieht grossartig aus! Darf ich fragen, wie du die Funktionen gefunden hast? VG Ralf Die Free Version von IDA bringt mich leider nicht weiter. Und nur für dieses eine Projekt die Pro Version kaufen, lohnt sich wahrscheinlich nicht.
:
Bearbeitet durch User
Ralf G. schrieb: > Die Free Version von IDA bringt mich leider nicht weiter. Und nur für > dieses eine Projekt die Pro Version kaufen, lohnt sich wahrscheinlich > nicht. Eventuell genügt die Demo-Version von IDA Pro https://www.heise.de/download/product/ida-pro-57580 edit: ach so, ist wohl auch die Free-Version. Naja, schade eigentlich.
:
Bearbeitet durch User
Angehängte Dateien:
-
Tabelle_0x8080.PNG
4,1 KB
Ralf G. schrieb: > > das sieht grossartig aus! Darf ich fragen, wie du die Funktionen > gefunden hast? In diesem Fall ist es einfach, man schaut wo die paar IO Adressen, die die Firmware anspricht, im Code verwendet werden. Das ist hier sehr überschaubar, als Beispiel die Funktion IWDG_init:
1 | IWDG_init: |
2 | mov IWDG_KR, #$CC |
3 | mov IWDG_KR, #$55 |
4 | mov IWDG_RLR, #$FF |
5 | mov IWDG_PR, #6 |
6 | mov IWDG_KR, #$AA |
7 | ret |
Ob man dafür Ghidra oder IDA Pro verwendet ist egal, das kann man mit beiden Tools so machen. Noch ein bischen mehr, es gibt drei Interrupt-Funktionen: UART Rx (0x9D2A), Timer 1 (0x9E26) und ADC (0x9CFD). An Adresse 0x8080 liegt eine Tabelle mit 921 Werten, diese wird in der Funktion Adresse 0x9746 verwendet. Als Kurve sieht die Tabelle so wie im Anhang aus. Und die UART wird in der Funktion Adresse 0x9300 behandelt. Mir ist allerdings momentan noch nicht klar ob die Firmware überhaupt etwas mit den per UART empfangenen Zeichen macht.
:
Bearbeitet durch User
...du würdest mich jetzt gerade schwer beeindruckt sehen !! Woher hast du denn die Namen der Funktionen? Sind das Namen aus dem Datenblatt des Proz mit den jeweiligen Adressen? Aber so grundsätzlich sind wir genau da wo ich hin wollte: Die Steuerung kann in zwei Modi betrieben werden: Im Power Save Mode geht sie nach 30min schlafen; im Normal Mode läuft sie durch. Das kann man umstellen mit so einer speziellen Einschalt-Prozedur, und ich vermute das wird im EEprom gespeichert, weil da stehen nur ein oder zwei Byte. Einerseits ist der Power Save Mode super, aber die Aufheiz-Zeit ist mit 20min recht lang. Ich hab die über den seriellen Port ausgegebenen Informationen an einen ESP8266 gegeben, der das an einen MQTT Server im Keller sendet. Damit kann ich immer sehen, was dier Maschine macht. Ich will eigentlich nur wissen, ob es ein Kommando gibt, mit der man die Maschine aus dem Power Save Mode wecken kann. Dafür versuch ich das Ganze.
Ralf G. schrieb: > > Woher hast du denn die Namen der Funktionen? Sind das Namen aus dem > Datenblatt des Proz mit den jeweiligen Adressen? Einfach anhand der verwendeten IO Adressen, in diesem Fall sind die Funktionen klein und übersichtlich und es wird immer nur ein bestimmter Teil der Peripherie initialisiert. Ob es diese Funktionen eventuell in einer Library von ST gibt hab ich nicht geschaut, das ist aber eigentlich egal weil man hier sehr deutlich sieht dass es um die Initialisierung geht (der Code wird einmal am Anfang des Hauptprogramms aufgerufen). Die Namen der IO Adressen entsprechen der Bezeichnung von ST, die stehen so im Datenblatt oder auch in diversen Header Dateien. > Dafür versuch ich das Ganze. Bisher sehe ich noch nicht dass die Firmware irgendetwas mit den empfangenen Zeichen macht. Mit dem weiter oben vermuteten "switch" lag ich daneben, der Code scheint Bestandteil der Floatingpoint Library des Compilers zu sein.
:
Bearbeitet durch User
...wenn die SW keine emfangenen Zeichen auswertet, wäre das schon das Ende der Reise. Dann geht das eben so nicht. Ich bezweifle, das die Italiener den SourceCode raus rücken, daher gäbe es dann nur den Weg die Bedienung der Maschine zu simulieren. Ist zwar bei weitem nicht so elegant, aber der ESP hat nicht viel zu tun. Ich werd mir morgen aber erst mal die Register Map des Proz ansehen. Mit deinen großartigen Tipps, sollte ich das ein oder andere nachvollziehen und verstehen können. Nochmals vielen Dank dafür! Zumindest glaub ich gefunden zu haben, wo die UART Baud Rate gesetzt wird:
1 | ld A, 0x03 ;0x009C06, B6 03 |
2 | and A, #0x0F ;0x009C08, A4 0F |
3 | or A, 0x00 ;0x009C0A, BA 00 |
4 | ld 0x5233, A ;0x009C0C, C7 52 33 |
5 | ldw X, 0x02 ;0x009C0F, BE 02 |
6 | call 0x9CC3 ;0x009C11, CD 9C C3 |
7 | ld A, XL ;0x009C14, 9F |
8 | ld 0x5232, A ;0x009C15, C7 52 32 |
:
Bearbeitet durch User
Ralf G. schrieb: > ...wenn die SW keine emfangenen Zeichen auswertet, wäre das schon das > Ende der Reise. Dann geht das eben so nicht. Ich werde mir das morgen weiter ansehen nicht dass ich etwas übersehen habe. Was man prinzipiell machen könnte ist die Firmware zu patchen und die gewünschte Funktion zu implementieren. In diesem Fall ist aber der freie Platz im Flash sehr begrenzt, da sind nur noch ein paar Bytes frei. Vielleicht findet man ja nicht benutzen Library Code, den man rausschmeißen kann.
....das der Speicher recht voll ist, war mir auch schon aufgefallen. Ich hab das auf die bregrenzten 8K geschoben, und den erwähnten PID Regler. Obwohl ich keine echte Vorstellung hab, wie viel Code das erfordert. Aber ein PID ist nun mal ein Klotz. Das Patchen der Firmware würde meine aktuellen Fähigkeiten auf absehbare Zeit überfordern. Aber ich möchte dich nicht um deine Freizeit bringen!
Könntest Du eventuell noch den Dump des EEPROM Bereichs hier hochladen, das macht es einfacher zu verstehen was genau damit gemacht wird. Danke.
Dieter S. schrieb: > Ralf G. schrieb: >> ...wenn die SW keine emfangenen Zeichen auswertet, wäre das schon das >> Ende der Reise. Dann geht das eben so nicht. > > Ich werde mir das morgen weiter ansehen nicht dass ich etwas übersehen > habe. > > Was man prinzipiell machen könnte ist die Firmware zu patchen und die > gewünschte Funktion zu implementieren. In diesem Fall ist aber der freie > Platz im Flash sehr begrenzt, da sind nur noch ein paar Bytes frei. Du koenntest ganz einfach einen groesseren STM8 nehmen.
....grössere STM8 ... muss schauen ob es den Pinkompatibel im gleichen Gehäuse gibt. Ne neue Platine wollte ich nicht machen. :-) Anbei auch noch der Schaltplan des Ganzen soweit ich ihn abgezeichnet habe.... Zwei Scheiberegister hintereinander als Treiber für die ganzen Ausgänge und eine Handvoll Eingänge.
Danke, der EEPROM Dump bestätigt das was ich bisher im Code dazu gesehen habe. Im RAM liegt ein Flag dass 0 oder 1 ist, je nach dem was im EEPROM steht, das Byte 0x55 im EEPROM ist dabei nur ein Magic-Wert der anzeigt dass der Wert im EEPROM gültig ist. Ich sehe aber immer noch nicht dass irgendetwas mit den per UART empfangenen Daten gemacht wird. Ich denke ein einfacher Patch wäre machbar, irgendetwas in die Richtung dass nur ein Zeichen ausgewertet wird und dieses dann das obige Flag im RAM auf 0 oder 1 setzt. Die Frage ist ob das alleine ausreicht um den Power-Mode zu wechseln. Hast Du einen Debugger (SWIM) für den STM8? Dann könnte man das vorab ausprobieren indem man das Flag per Debugger ändert und schaut was passiert. Ansonsten müsste ich schaue ob die Firmware auch in einem STM8 Eval-Board läuft, ich sollte irgendwo ein passendes hier haben.
Ja, einen einfachen ST Link V2 hab ich hier, der SWIM kann. Damit hab ich den Prozessor ausgelesen. Damit ich nicht am Live-System experimentieren muss, hatte ich mir dazu extra eine identische Steuerung als Ersatzteil in Italien bestellt. Von der ist die Firmware. Wenn ich damit testen sollte, müsste ich mir ein Rig bauen, mit dem ich zumindest so viel Hardware simuliere, das die Steuerung läuft. Um die Maschine aus dem StandBy zu holen, wird normalerweise der Hebel für den Kaffeebezug kurz betätigt. Dabei wird PD1 (SWIM) kurz auf Low gelegt. Vielleicht wäre das einfacher im Code zu realisieren? Hätte auch den Vorteil, das die Maschine dann wieder in StandBy geht, sonst bräuchte es wieder ein anderes Flag im EEprom. Wenn ich das Datenblatt recht in Erinnerung habe, mag diese Version des STM8 nicht gern so viele Schreibzugriffe auf das EEprom.
:
Bearbeitet durch User
Ralf G. schrieb: > > Um die Maschine aus dem StandBy zu holen, wird normalerweise der Hebel > für den Kaffeebezug kurz betätigt. Dabei wird PD1 (SWIM) kurz auf Low > gelegt. Vielleicht wäre das einfacher im Code zu realisieren? Das ist nicht so einfach da für das Auswerten der Eingänge diverse Zähler für das Entprellen mitlaufen, man hat also nicht einfach nur ein Flag dass man setzen muss. > Wenn ich das Datenblatt recht in Erinnerung habe, mag diese Version des > STM8 nicht gern so viele Schreibzugriffe auf das EEprom. 100.000 Zyklen für den Datenspeicher (EEPROM) wenn ich das richtig interpretiere, nur die Firmware sollte man nicht öfters als 100 mal neu programmieren. Ist denn die RS232 auch aktiv wenn die Maschine im Standby ist, werden also auch in diesem Fall Daten ausgegeben? Die CPU geht nach meinem bisherigen Verständnis nicht in den Halt, die sollte immer laufen. Was anderes, ich sehe bei der Ausgabe über die UART einen Wert der entweder ein "C" oder ein "+" ist, weißt Du eventuell was das ist? Das steht vermutlich im Zusammenhang mit dem Eingang PC3. Nachtrag: Ein paar Beispiele der UART Ausgabe in den beiden Betriebsarten wären interessant.
:
Bearbeitet durch User
Egal ob Aktiv oder Standby, der UART läuft da permanent und ohne Änderung durch. Etwa 3 mal pro Sekunde kommt so ein String: C1.22,116,124,093,0840,1,0\n Das erste ist Betriebsart und Versionsnummer (1.22) Dann Dampftemperatur ist, Dampftemperatur target, Wassertemperatur, Zähler für irgend einen Boost mode (bei mir immer 0000), Flag für Heizung an oder aus, Flag für Pumpe an oder aus
Ralf G. schrieb: > > Das erste ist Betriebsart und Versionsnummer (1.22) Ist die Betriebsart (da sollte das "C" bzw. "+" kommen) der Standby Modus oder etwas anderes? Nachtrag: Welche Funktion haben b1, b2 und b3 an CN6? Wie schon geschrieben, PC3 hat etwas mit der Betriebsart ("C" bzw. "+") zu tun. Ausserdem geht in Deinem Schaltplan die Verbindung zu PC4 vermutlich zu PC5.
:
Bearbeitet durch User
Ralf G. schrieb: > Keine Ahnung wie ich das anfangen kann Zuerst mal musst du dich mit dem Mikrocontroller vertraut machen. Dazu gehört in deinem Fall auch dessen serielle Schnittstelle. Du musst ihn selbst in Assembler programmieren können, sonst wirst du den Code nie verstehen. Ralf G. schrieb: > Die Komplexizität des Codes kommt möglicherweise daher, das irgendwo ein > PID Regler integriert ist, der die Heizung steuert. Ich glaube du schätzt das falsch ein. Ein PID Regler braucht nur wenige Zeilen Code.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Ich glaube du schätzt das falsch ein. Ein PID Regler braucht nur wenige > Zeilen Code. Nunja, wenige Zeilen Code in welcher Sprache? In C z.B. können diese wenigen Zeilen Code schon einen ziemlich fetten Blob erzeugen. Wenn z.B. float als Datentyp genutzt wird...
Ob S. schrieb: > In C z.B. können diese > wenigen Zeilen Code schon einen ziemlich fetten Blob erzeugen. Wenn z.B. > float als Datentyp genutzt wird... Ja, aufblähen kann man alles beliebig. Aber man muss nicht. Eine Aussage wie "wahrscheinlich ist es der PID" zu schieben, ohne den Code verstanden zu haben, ist jedenfalls abwegig. Genau so Wahrscheinlich kann es 100 andere Ursachen haben. Es kann auch sein, dass 80% davon gar kein Programmcode ist, sondern z.B. statische Texte oder Keys für Verschlüsselung. In 8kB hatte man früher mal ganze Videospiele untergebracht. Beispiele: http://homecomputerworld.com/8kb-roms-vc20.html http://homecomputerworld.com/4kb-roms-vc20.html
:
Bearbeitet durch User
Steve van de Grens schrieb: > Eine Aussage wie "wahrscheinlich ist es der PID" zu schieben, ohne den > Code verstanden zu haben, ist jedenfalls abwegig. Das würde ich ohne jede Bedenken unterschreiben. Da hast du einfach mal Recht. Du hast es nur halt nur etwas fadenscheinig begründet. > Genau so > Wahrscheinlich kann es 100 andere Ursachen haben. Es kann auch sein, > dass 90% davon gar kein Programmcode ist, sondern z.B. statische Texte > oder Keys für Verschlüsselung. Natürlich. Bei sehr vielen Programmen (insbesondere bei welchen mit einen "GUI") gibt es mehr Daten als Code. Eine Sache tauchte ja im Thread-Verlauf bereits auf: eine Tabelle. Auch Daten, kein Code.
Man hat glaube ich auf der reinen Hardwareseite bessere Karten. Damit kann man ein Steuerungsmuster "auspiepen". Ein paar brauchbare Steuerungsroutinen im gesuchten Zusammenhang zur Hand wäre auch nicht verkehrt.
Ralf G. schrieb: > Ich hab gerade mal Ghidra und die Extension für STM8 installiert, aber > ich befürchte ich muss da noch etwas Zeit für das Ghidra Manual > einplanen. > > Keine Ahnung wie ich das anfangen kann. Das Binary hab ich importiert, > aber irgendwie bekomme ich nichts informatives angezeigt. Hab mir jetzt auch mal Eimer und Kelle gekauft. Aber das Haus steht noch nicht.
Dieter S. schrieb: > Ralf G. schrieb: >> >> Das erste ist Betriebsart und Versionsnummer (1.22) > > Ist die Betriebsart (da sollte das "C" bzw. "+" kommen) der Standby > Modus oder etwas anderes? > > Nachtrag: Welche Funktion haben b1, b2 und b3 an CN6? Wie schon > geschrieben, PC3 hat etwas mit der Betriebsart ("C" bzw. "+") zu tun. > > Ausserdem geht in Deinem Schaltplan die Verbindung zu PC4 vermutlich zu > PC5. Das mit C und + ist korrekt. Es gibt einen Schalter, der je nach Position im "C = Coffee-Priority" oder "+ = Dampf-Priority" Mode fährt. Ist ein anderes Temperaturprofil. Dann gibt es noch einen 3 Positionen Schalter um die bevorzugte Wassertemperatur in 3 zwei-Grad Schritten wählen zu können (meine 92 /94 /96) Und es gibt noch 3 LEDs Wassermangel, Maschine Heizt auf und der Power Switch. Rest muss ich morgen raus suchen... und kann sein, das ich da noch einen Fehler im Plan habe
:
Bearbeitet durch User
Danke, dann gehen b1, b2 und b3 an CN6 vermutlich an die Schalter, es sieht auch so aus als ob die beiden anderen Eingänge unterschiedliche Temperaturen auswählen. Noch etwas, Du schreibst weiter oben dass es ausreicht den Pegel an PD1 zu ändern um die Maschine aus dem Standby zu holen. Wenn Du sowieso schon mit einem ESP8266 an der Maschine bist wäre es dann nicht am einfachsten damit den Pegelwechsel zu erzeugen? Dann braucht man gar nichts an der Firmware patchen.
Das war ja auch meine Idee weiter oben. Software ändern hätte ich ohne deine Hilfe eh nicht realisieren können, also ging es mir um eventuell vorhandene undocumented Features, wie eben eine Möglichkeit via Rx. Aber mit dem ESP und einem BSS138 sollte das doch auch gehen. Eine Routine mit einer subscription am MQTT Server hatte ich schon dafür angelegt.
:
Bearbeitet durch User
Ralf G. schrieb: > > Aber mit dem ESP und einem BSS138 sollte das doch auch gehen. Das wird die sauberste Lösung sein. Ich gehe inzwischen ziemlich stark davon aus dass die per UART empfangenen Daten ignoriert werden. Ein einfacher Patch der das entsprechende Flag für den Standby ändert wäre zwar vermutlich machbar, würde aber wohl ein paar Iterationen brauchen bis er auch funktioniert.
:
Bearbeitet durch User
…das ist doch das gewünschte Ergebnis! Ich kann nicht angemessen ausdrücken, wie dankbar ich für dein Interesse und Anteilnahme bin! Das ist in Foren heutzutage eher selten! Ich hab jetzt viele Einstiegspunkte, wo ich weiter lernen kann, so wie es die Zeit zulässt. Aber wie heisst es? Der Ingenieur treibt den Grad der Perfektion nicht weiter, als es der Sache dienlich ist! 😄 Ich werde das mit dem Transistor und ESP probieren und berichten! Nochmals meinen aufrichtigen Dank! VG Ralf
Der Vollständigkeit halber nochmal zu dem Binary: Der Compiler ist EWSTM8 von IAR. Die oben erwähnte Tabelle (die steht im Zusammenhang mit der Temperatur, eventuell ist das die Kalibrierung der Temperatursensoren) belegt schon fast 2 KByte, zusammen mit der Runtime des Compilers (insbesondere für Floatingpoint Arithmetik) wird schon fast die Hälfte des 8 KByte großen Flash belegt. Damit bleiben noch ca. 4 KByte für die eigentliche Funktionalität der Software.
Darf ich noch fragen, womit du die Namen der jeweiligen Routinen bekommen hast? Mein Disassembler liefert ja leider nur die ASM Befehle
Die Frage wurde doch schon beantwortet: Dieter S. schrieb: > Ralf G. schrieb: >> >> Woher hast du denn die Namen der Funktionen? Sind das Namen aus dem >> Datenblatt des Proz mit den jeweiligen Adressen? > > Einfach anhand der verwendeten IO Adressen, in diesem Fall sind die > Funktionen klein und übersichtlich und es wird immer nur ein bestimmter > Teil der Peripherie initialisiert. Die I/O-Adressen der Peripherie stehen im Datenblatt.
Ralf G. schrieb: > Darf ich noch fragen, womit du die Namen der jeweiligen Routinen > bekommen hast? Das Beispiel mit den Namen für die Hardware-Initialisierung ist ja relativ einfach: Wenn z.B. eine Funktion einmalig beim Programmstart aufgerufen wird und den ADC initialisiert dann ist ein Name wie "ADC_init" naheliegend. Man kann das natürlich beliebig benennen, es sollte halt einigermaßen zu dem passen was die Funktion macht. Wenn man jetzt z.B. die Compiler Runtime anschaut dann kann man u.a. die Funktionen für die Floatingpoint Arithmetik benennen (etwa fadd32, fsub32, fmul32 und fdiv32 bei IAR). Wie lange es dauert bis man erkennt was eine Funktion macht hängt u.a. von der eigenen Erfahrung ab, die Tools können aber teilweise bei dem Erkennen von Runtime Funktionen helfen.
... ich hab das jetzt in Ghidra zumindest so weit, das ich das bin-file disassembled habe und er mir etliche Funktionen anzeigt. Leider aber mit vielen Fehlern. Ich hab bislang nur einiges in Atmel AVR Assembler für Tiny und Mega-8 geschrieben. Hier ist für mich jetzt sowohl der Prozesser & Code als auch das Tool neu ... das dauert dann eben etwas, bis man sich zurecht findet.
:
Bearbeitet durch User
Das Binary hat folgenden Aufteilung in Code bzw. Daten:
1 | 0x8000-0x807F: Interrupt Vektoren |
2 | 0x8080-0x87B1: die weiter oben bereits mehrfach erwähnte Tabelle |
3 | 0x87B2-0x9E13: Code |
4 | 0x9E14-0x9E25: Daten für die Initialisierung des RAM |
5 | 0x9E26-0x9FE3: Code |
6 | 0x9FE4-0x9FED: Daten für die Initialisierung des RAM |
Im Code kommen allerdings auch vereinzelt Daten vor (.z.B. Floatingpoint Konstanten), die werden dann von der davor stehenden Funktion geladen und es geht nach den Daten mit dem Code weiter. Das sind aber maximal vier Bytes am Stück, meistens ist es nur ein Byte.
:
Bearbeitet durch User
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.