ich würde gerne wissen, welche Schnittstellen und Befehle eine gekaufte Hardware benutzt. In dem Gerät ist ein Arduino Mega 2560 verbaut. Ich habe die Updatefiles vom Hersteller erhalten, diese sind jedoch schon kompliliert.
Das Updateprogramm überträgt die Hex Datei via AVR Dude.
Ich habe eine alte Version der Software als ino Datei in einer Discord Gruppe gefunden. Wenn ich diese mit der Arduino IDE auf einen blanken Arduino Pro mini spiele, wird er auch von diesem Updatetool als original Hardware erkannt und auf die neue Version geupdated.
Gibt es eine Möglichkeit das File zurück zu übersetzen? Dass da der original Code nicht bei herauskommt ist mir klar, jedoch wüsste ich gerne was auf welchen Ports angeklemmt ist usw.
Das Gerät kann ich leider nicht öffnen, da es 1. noch auf dem Weg aus der USA zu mir ist und 2. auf den Produktfotos ein Garantiesiegel erkennbar ist.
Hier ist noch das Logfile von AVRdude:
1
2
avrdude.exe: Version 6.3, compiled on Feb 17 2016 at 09:25:53
3
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
4
Copyright (c) 2007-2014 Joerg Wunsch
5
6
System wide configuration file is "C:\Program Files (x86)\RealSimGear Firmware Utility\Data\Loader\avrdude.conf"
Natürlich nicht. Aber man kann anhand von Peripherizugriffen (deren Namen sollten eindeutig sein) erkennen, /welche/ Peripherie überhaupt genutzt wird (Timer, SPI, I2C etc.) und dann analysieren können, /wie/ diese Peripherie genutzt wird. Bei UARTs beispielsweise lässt sich die Baudrate bestimmen.
Natürlich, Variablennamen, Funktionsnamen oder gar Quelltextkommentare kann so ein Tool nicht wieder herstellen.
Die Methode nennt sich "disassemblieren".
Und wieder Name schon sagt, bekommt man ein Assemblerlisting heraus.
Und oft ist nichtmal das wieder direkt assemblierbar (also in dem Sinne, das wieder das originale Binary dabei herauskommt), sondern bedarf meistens noch einiger Nacharbeit, bevor wenigstens das geht.
Und oft ist nichtmal das wieder direkt assemblierbar (also in dem Sinne,
das wieder das originale Binary dabei herauskommt), sondern bedarf
meistens noch einiger Nacharbeit, bevor wenigstens das geht.
Nur so yur Info: Ursprünglich hatte der TO "dekompilieren" im Threadtitel verwendet; darunter wird man im Netz eher weniger Informationen finden.
Wie weit das Resultat verwendbar ist, war nicht teil meiner Antwort.
Damit habe ich keinerlei Erfahrungen.
HEX heisst hier Intel-HEX-Format:
https://de.wikipedia.org/wiki/Intel_HEX
Darin steht immerhin, wohin die einzelnen Bytes geladen werden. Man kann auch mehrere unzusammenhängende Speicherbereiche damit füllen, das geht mit reinem BIN nicht. Prüfsummen stecken auch noch drin.
Ich habe die Updatefiles vom Hersteller erhalten, diese sind
jedoch schon kompliliert.
Das Updateprogramm überträgt die Hex Datei via AVR Dude.
Ich habe eine alte Version der Software als ino Datei in einer Discord
Gruppe gefunden. Wenn ich diese mit der Arduino IDE auf einen blanken
Arduino Pro mini spiele, wird er auch von diesem Updatetool als original
Hardware erkannt und auf die neue Version geupdated.
Ich habe eine alte Version der Software als ino Datei in einer Discord
Gruppe gefunden. Wenn ich diese mit der Arduino IDE auf einen blanken
Arduino Pro mini spiele, wird er auch von diesem Updatetool als original
Hardware erkannt und auf die neue Version geupdated.
Schön. Bezieht sich aber auf den alten Kram.
Die Frage war, die aktuelle Datei zu disassemblieren.
Es könnte ja (mit Sicherheit) Änderungen zur alten Version geben.
Es könnte ja (mit Sicherheit) Änderungen zur alten Version geben.
Klar, aber gefragt wurde nach der Baudrate der seriellen Schnittstelle. Und die wird sich ja wohl nicht einfach so bei einem bestehenden Produkt ändern.
Wenn Du ein direkter Nachfahre vom alten Sisyphos bist,
extrem Fit in der Programmierung auf Assemblerebene und
echt Ahnung davon hast, wie üblicherweise Programmiert wird,
dann könnte es klappen.
Ansonsten spar Dir die Zeit und kümmere Dich ein bisschen um deine Nächsten.
... Dass da der original Code nicht bei herauskommt ist mir klar,
jedoch wüsste ich gerne was auf welchen Ports angeklemmt ist usw.
Woran willst du das erkennen?
Der disassemblierte Code sagt dir nur, wo im Programm auf die Ports zugegriffen wird, kann dir aber nicht verraten, was an dem Port angeklemmt ist - es sei denn, du kannst die Zugriffe auf Grund des Programmablaufes zuordnen. Das kann dir des Disassembler aber nicht abnehmen.
Wenn Du ein direkter Nachfahre vom alten Sisyphos bist,
extrem Fit in der Programmierung auf Assemblerebene und
echt Ahnung davon hast, wie üblicherweise Programmiert wird,
dann könnte es klappen.
Ist er aber wahrscheinlich nicht, sonst hätte er die Eingangsfrage nicht gestellt.
Ja Kerl, dann lade Dir doch mal GHIRA runter (kostenlos, Open Source) und schau Dir an, was mit Ausführung herauskommt. Das kannst Du dann mit dem "alten Code" vergleichen (oder auch nicht) und Deine Schlüsse ziehen.
IDA pro ist aus meiner Sicht besser (kostet aber auch €) - aber auch damit wirst Du keinen tollen C-/ C++-Code mit sprechenden Variablen-Namen herausbekommen.
Ich bin auch Haralds Tipp nachgegangen. Es gibt zwar kein Ubuntu Rundumsorglospaket für Ghidra, aber man muss anscheinend nur vorher noch Open-JDK installieren und kann den Rest von Github runterladen.
Gleich mit Reklame für die NSA:
"If you are a U.S. citizen ... consider applying for a career with us."
Früher habe ich öfters Disassembler benutzt, erst für den 6502, um die Programme aus Funkschau und mc zu studieren. Die musste man damals noch als Hex-Code abtippen. Später auch mal Atari ST (68k) und ein DOS-Programm
Und den 6809-Code meines Musiksynthesizers, der war aber etwas groß.
Erst dieses Jahr habe ich jemanden auf Github entdeckt, der den 6809 genauer untersucht hat und sogar einen Programmfehler beseitigt hat, ein echter Künstler: https://github.com/ijsf/wersi-mk1-ex20-rehttps://wer.si/ "fixing firmware bugs from 1987 in 2017"
https://bitlog.it/20170102_fixing_firmware_bugs_from_1987_in_2017.html
Den Fehler hatte ich damals auch gesehen, aber nicht untersucht. Auf der MIDI-Schnittstelle fehlte ein end-of-transmission Zeichen, damit funktionierte die SysEx-Übertragung nicht.
Das einzige DOS-Programm, das ich mir damals näher angeschaut habe steht noch hier zum Download bereit:
https://www.mobimail.de/afu.htm#prmon
Der Quelltext war damals natürlich nicht erhältlich. Soweit ich noch weiß ein TSR-Programm "terminate-and-stay-resident", eine Art Multitasking unter DOS.
Ich vermisse den "Kopierschutz", er fragte sein Rufzeichen ab, das im Programm irgendwo stand. Das lief eine Weile am Arbeitsplatz, wir waren in der Abteilung von 11 Kollegen insgesamt acht Funkamateure. Irgendwann sprach der Entwicklungsleiter ein Machtwort "das verschwindet vom Rechner", als er in der Pause uns beim "Lemminge" spielen ertappt hatte.
Das einzige DOS-Programm, das ich mir damals näher angeschaut habe steht
noch hier zum Download bereit:
https://www.mobimail.de/afu.htm#prmon
Der Quelltext war damals natürlich nicht erhältlich. Soweit ich noch
weiß ein TSR-Programm "terminate-and-stay-resident", eine Art
Multitasking unter DOS.
Naja, nicht gleich "Multitasking". So ein DOS-TSR hat sich einfach nur in die Vektoren bestimmter Systemaufrufe (alle die es benötigte, um seinen Job zu machen) "eingehängt".
Also mitnichten Multitasking. Es hat einfach entweder vor oder nach dem Nutzcode der laufenden Anwendung irgendwas tun können. Ob vorher oder nachher, konnte es selber bestimmen (durch die Art des Einhängens in den Vektor).
Naja, das TSR konnte sich darüber hinaus auch noch in Vektoren einhängen, die in der aktuellen DOS-Anwendung überhaupt nicht benutzt wurden. Also doch irgendwie ein wenig "echtes" Multitasking.
Ghidra startet jetzt schon mal. Ich hatte zunächst das Problem, Ghidra das eigentlich schon installierte Java zu zeigen. Es muss jedenfalls ein gültiges ausführbares javac finden, dann ist es zufrieden. AVR-Code ist möglich und ein Intel-HEX File kann man importieren.
Der erste Anlauf ergab ein Postscript-File mit 900 Seiten. Die ersten 86 hier als PDF, noch nicht sehr lesbar. Der Rest scheint eher Unsinn zu sein. Bis Seite 9 Interrupt-Vektoren, die letzten Seiten 77-86 sind Texte. Das dazwischen sieht nach echtem Code aus.
Das war mein erster Versuch mit Ghidra, als Mikrocontroller ein "avr_8/gcc" eingestellt, der war wohl etwas zu allgemein. Es gibt noch einen avr_256, der dürfte für den Atmega2560 genauer passen. Das Postscript-File hat jetzt sagenhafte 3220 Seiten, aber wieder ab S. 87 nur Müll. Hier Seiten 1-86 als PDF gedruckt.
Jetzt sehen schon die Interrupt-Vektoren besser aus. Man sieht dass nicht sehr viele benutzt sind. Die meisten enden wie es Atmel schon vorschlägt mit einem jmp RESET.
Unfein, dass mitten im Programmcode auch Texte untergebracht sind, wenn ich recht sehe. Das macht man nicht.
Unterprogramme erkennt man am push zu Beginn und pop ret (bzw. reti für Interrupts) am Ende, davon gibt es einige.
Hab ich ja gemacht, hier die fünf Auswahlmöglichkeiten.
Die breiten jmp-Befehle gibt es bei den "default" AVR8 nicht, daher schon in der Interrupttabelle die Fehler.
In der Interruptliste habe ich ein paar vergessen, im PDF stehen sie alle auf den ersten Seiten. Also Pin-Interrupts INT, USART und Timer sind benutzt.
Ja da gibt es aber nur zwei, den 2560 und 2561 (und ein paar x-Mega256, aber für die gibt es eine eigene Auswahlmöglichkeit):
https://www.microchip.com/en-us/parametric-search.html/716
Das hätte ich vorher sehen sollen, dann hätte ich gleich den "atmega256" gewählt. Man sieht den Unterschied auch am "Size", "default" ist 16, die beiden anderen 24.
Egal. Um z.B. die Baudrate zu finden, muss man schon ziemlich tief im Text wühlen. Die USART-Register sind im Hauptprogramm nicht speziell bezeichnet.
Unfein, dass mitten im Programmcode auch Texte untergebracht sind, wenn
ich recht sehe. Das macht man nicht.
Sieht aber nicht nach Text (0x20..0x7E) aus. Könnten Daten (16Bit) sein oder der Dissassembler ist aus dem Tritt geraten.
Daten inmitten Code habe ich beim AVR-GCC noch nicht gesehen. Der AVR-GCC versucht, konstante Daten in den ersten 64kB zusammen zu fassen, nach der Vektortabelle.
Wie kommt man eigentlich auf die verrückte Idee, plain Text als PDF auszugeben?
Wenn ich Ghidra zum Drucken auffordere habe ich nur die Möglichkeit auf meinen Laserdrucker zu drucken, kann aber auch "in Datei drucken". Da wird als einzige Möglichkeit ein .ps vorgeschlagen, und das wird riesig.
Das kann ich sicher alles irgendwo konfigurieren. Bisher habe ich es einfach so gemacht wie es ohne Nachlesen klappte, das ist sicher nicht optimal. Mit Okular noch in ein PDF gedruckt, und nur die ersten 86 Seiten. Ich finde 300 kByte sind noch recht klein.
Die Daten sind ja nebendran noch als ASCII gezeigt, wo es geht. Dazwischen auch gelegentlich der Dateiname als ASCII-Text. Ich hatte auch einen Fehler in Ghidra vermutet, vielleicht auch mein Konfigurationsproblem.
ich würde gerne wissen, welche Schnittstellen und Befehle eine gekaufte
Hardware benutzt. In dem Gerät ist ein Arduino Mega 2560 verbaut. Ich
habe die Updatefiles vom Hersteller erhalten, diese sind jedoch schon
kompliliert.
um die Ursprungsfrage aufzugreifen ... Das Gerät ist relativ simpel konstruiert. Es stellt per USB eine serielle Schnittstelle bereit und schickt dort bei Betätigung der Eingabetasten eine Textzeile, welche Taste gedrückt wurde.
Drehst du den HDG-Knopf nach rechts, kommt z.B. ENC_HDG_UP, drehst du ihn nach links, dann ENC_HDG_DN. Drückst du den HDG-Knopf, kommt BTN_HDG_SYNC=1 und lässt du ihn los, dann BTN_HDG_SYNC=0.
In regelmäßigen Zeitabständen schickt das Gerät noch Leerzeilen als Heartbeat und ab und zu noch einen Info-Banner. Mit einem seriellen Terminal kann man sich das alles anschauen, ganz ohne die Firmware reverse engineeren zu müssen.
Wie die Ansteuerung von Ausgaben funktioniert, weiß ich leider (noch) nicht. Dazu fehlt mir die Hardware. Für das G1000 sind Ausgaben nicht relevant.
Ich habe mir die Firmware und den Treiber in Ghidra angeschaut. Ich vermute, dass man mit <0, <1, <2 ... LEDs an- und ausschalten kann (z.B. an einer GMA340-Aufschaltanlage. Mit {Z0 bis {Z1.0 kann man jeweils "Analogausgänge" (z.B. Helligkeit der Anzeigen, etc.) ansteuert. A bis Z wären die entsprechenden Kennbuchstaben für den Kanal. Mit | dürfte sich der Status der Kanäle abfragen lassen. Zudem gibt es noch die Kommandos !c, !o0 und !o1, auf die ich mir aber keinen Reim machen kann.
Ja, aber Open Source. Als Anwender davon muss man also keine Ängste
verspüren.
Aha, nur weil der Code mit rausgerotzt wurde, ist es also frei von
Verdacht?
Gabs da schon ein grosses Code-Checken von einer Gruppe aus einigen
Erfahrenen Programmiereren?
Dann betreib es in einer VM ohne Netzwerkzugang, wenn du dich so fürchtest.
Aber wahrscheinlich sind da gleich ein paar Breakout-Exploits drin um deine Geheimnisse trotzdem heimfunken zu können.
Gabs da schon ein grosses Code-Checken von einer Gruppe aus einigen
Erfahrenen Programmiereren?
Wo gibt es denn so etwas? In der Phantasiewelt?
Open Source ist schnell entwickelte Bastelsoftware ohne Ziel. Da wirken evolutionäre Mechanismen und was heraus kommt ist Zufall.
