Einen wunderschönen Abend meine Kerle,
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"
Tim H. schrieb:> jedoch wüsste ich> gerne was auf welchen Ports angeklemmt ist usw
Das wird nicht im Assembler Code stehen. Du wirst dort nicht mal die
Namen von Variablen sehen.
Stefan F. schrieb:> Du wirst dort nicht mal die> Namen von Variablen sehen.
Das kommt auf den Decompiler/Disassembler an - der "denkt" sich manchmal
wirklich schöne Variablennamen aus :-)
Wenn man mit "dickem Eisen" drauf losgehen will, so wie es aussieht,
unterstützt auch Ghidra die 8-Bit-AVRs von Atmel.
https://en.wikipedia.org/wiki/Ghidra
Hugo H. schrieb:> Stefan F. schrieb:>> Du wirst dort nicht mal die>> Namen von Variablen sehen.>> Das kommt auf den Decompiler/Disassembler an - der "denkt" sich manchmal> wirklich schöne Variablennamen aus :-)
Ja, aber es sind eben nicht DIE Namen.
Jens G. schrieb:> Ja, aber es sind eben nicht DIE Namen.
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.
Harald K. schrieb:> erkennen, welche Peripherie überhaupt genutzt wird> Bei UARTs beispielsweise lässt sich die Baudrate bestimmen.
Das kriege ich einfacher mit einem Logic Analyzer hin.
Rahul D. schrieb:> 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.
Stefan F. schrieb:> Das kriege ich einfacher mit einem Logic Analyzer hin.
Mit dem siehst Du die Baudrate, mit der eine passiv auf Empfang
lauschende UART arbeitet?
Hut ab.
(Sowas hat man beispielsweise bei Modbus-Geräten. Von sich aus senden
die gar nichts)
Ob S. schrieb:> 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.
Harald K. schrieb:> Mit dem siehst Du die Baudrate, mit der eine passiv auf Empfang> lauschende UART arbeitet?
Ja, da ich das Gerät in Aktion ausmessen würde.
Rüdiger B. schrieb:> Was steht den in der .INO Datei als Baudrate und Ports drin ?
DU bist ein Scherzkeks! Wenn er den Quelltext hätte, bräuchte er nicht
das Binary zu disassemblieren.
Rahul D. schrieb:> Das ist keine INO, sondern eine HEX.
Nicht wirklich:
Tim H. schrieb:> Ich habe eine alte Version der Software als ino Datei in einer Discord> Gruppe gefunden.
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.
Rahul D. schrieb:> nicht dem Dateinamen nach.
Lies exakt, was ich zitiert habe. Nochmal etwas umfangreicher:
Tim H. schrieb:> 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.
(Hervorhebung von mir)
Harald K. schrieb:>> 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.
Rahul D. schrieb:> 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.
Tim H. schrieb:> ... 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.
Sebastian S. schrieb:> 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.
Tim H. schrieb:> Einen wunderschönen Abend meine Kerle
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.
https://github.com/NationalSecurityAgency/ghidrahttps://www.makeuseof.com/how-to-install-ghidra-linux/
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.
Christoph db1uq K. schrieb:> 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.
Hier die benutzten Interuptvektoren:
Reset code:0000 0c 94 7c 01 jmp FUN_code_017c
INT0 code:0000 02 0c 94 16 09 jmp FUN_code_000916
INT1 code:0002 0c 94 16 09 jmp FUN_code_0916
TIMER2_OVFcode:0004 0c 94 ea 08 jmp FUN_code_08ea
TIMER1_COMPAcode:0006 0c 94 be 08 jmp FUN_code_08be
TIMER1_OVF code:0008 0c 94 92 08 jmp FUN_code_0892
SPI_STC code:000a 0c 94 66 08 jmp FUN_code_0866
USART_UDRE code:000c 0c 94 3a 08 jmp FUN_code_083a
Christoph db1uq K. schrieb:> Es gibt noch einen avr_256, der dürfte für den Atmega2560 genauer> passen.
Und wenn du den Atmega2560 einfach auswählen würdest?
Der ist in der Liste enthalten.
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.
Kilo S. schrieb:> Und wenn du den Atmega2560 einfach auswählen würdest?>> Der ist in der Liste enthalten.
Dein "Screenshot" zeigt das nicht, da steht nur "atmega256".
Harald K. schrieb:> Dein "Screenshot" zeigt das nicht, da steht nur "atmega256".
Ich benutze aktuell genau diese Einstellungen zum lernen und zwar mit
einem 2560.
Da kommt nachvollziehbarer "code" bei raus wenn die Analyse fertig ist.
Christoph db1uq K. schrieb:> 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.
Tim H. schrieb:> Einen wunderschönen Abend meine Kerle,
Hallo,
> 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.
In diesem X-Plane-Treiber sind alle Kommandos für das G1000 eingetragen:
https://github.com/hamarituc/realsimgear/.
Die Mappings für weitere Geräte kann man aus dem macOS-Treiber für
X-Plane unter
https://help.realsimgear.com/en/articles/7971491-downloads-for-x-plane
ableiten. Dort ist eine Datei CommandMapping.ini enthalten, die alles
enthält, was du brauchen solltest.
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.
Harald K. schrieb:> 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?
öffne die .hex einfach mit dem AVR Studio V4.xx das wirft dir direkt ein
Assemblerlisting aus. Weiß nicht ob das bei V5 oder V6 noch
funktioniert.
Zusammen mit den Adressen aus der passenden .include Datei bekommst du
auch raus welche Register usw. benutzt werden.
Wf88 schrieb:> Harald K. schrieb:>> 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.
Le X. schrieb:> Dann betreib es in einer VM ohne Netzwerkzugang, wenn du dich so> fürchtest.
Ich fürchte mich nicht davor. Aber die Herkunft abtun mit "ist ja open
source, alles sauber" ist sehr kurzsichtig.
Wf88 schrieb:> 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.
Thread beobachten
Seitenaufteilung abschalten