Ich habe hier den Inhalt des Flahsspeichers aus einen STM32 und ein Git-Repository mit mehreren Versionsständen des Codes. Ich soll nun herausfinden, welcher Versionsstand genau den vorhandenen Flashinhalt ergeben hat.
Beim Kompilieren erhalte ich eine Datei.elf, das Speicherabbild trägt die Erweiterung.bin. Es ist exakt zwei Megabyte groß, genau so groß wie der Flash des STM32. Ein direkter Vergleich mit der Datei.elf ist gar nicht nötig, da sie nur wenige Kilobyte groß und damit sicher verschieden ist.
Ich habe mit dem objcopy.exe aus einem Unterverzeichnis des STM32CubeIDE aus der Datei.elf eine Datei.bin gemacht um sie mit dem Flashinhalt vergleichen zu können, sie ist aber nicht zwei Megabyte groß.
Gibt es eine Möglichkeit, die kompilierte .elf so mit dem .bin zu vergleichen, dass Equivalenz festgestellt werden kann (oder .hex oder wasauchimmer mit den beiden vorhandenen Dateien möglich ist)?
Gibt es eine Möglichkeit, die kompilierte .elf so mit dem .bin zu
vergleichen, dass Equivalenz festgestellt werden kann (oder .hex oder
wasauchimmer mit den beiden vorhandenen Dateien möglich ist)?
Möglicherweise wird ein einfacher Vergleich nicht reichen:
Im bin sollte doch eine Versionsnummer zu finden sein
Das setzt voraus, daß derjenige, der die Compilate erzeugte, über soviel Selbstdisziplin verfügte, diese für jeden Durchlauf hochzusetzen.
Ich habe mir angewöhnt, im lokalen Git auch die erzeugen Binaries als Assets zu speichern. Die nehmen zwar mehr Platz weg als der reine Sourcecode, sind aber an anderer Stelle ungemein praktisch.
Auch das erfordert die nötige Disziplin, es zu tun. Wenn man eh' so arbeitet, ist das kein Problem, aber eben nicht jeder arbeitet so.
Wieviele Projekte mir schon über den Weg gelaufen sind, in denen die Versionskennung einfach ein #define mit einem String waren, in dem dann auch irgendein Datum stand ...
Die genaue Konfiguration der Toolchain ist meistens im Makefile abgebildet, aber wie schon erwähnt können unterschiedliche Versionen des Compilers unterschiedlichen Output erzeugen. Auch eine andere Version einer verwendeten C-Library erzeugt ggf. anderen Output, auch wenn dein eigener Quelltext identisch compiliert wird. Vielleicht kannst du hier anhand des Zeitraums des Builds und der verwendeten Umgebung raten, welche Versionen wahrscheinlich zum Einsatz kamen.
In der Luftfahrt haben wir bei Software zwingend einen "Software Configuration Index" (SCI), wo neben dem Quellcode und Konfigurationsparametern der Software selbst auch alle relevanten Details zur Build-Umgebung und deren Konfiguration mit abgelegt werden müssen. Ein Test ist, dass jemand nur mit den Daten des SCI einen binär identischen Output erzeugen kann.
Wir compilieren zur Sicherheit immer in einer virtuellen Maschine und archivieren die zusammen mit dem Quellcode und dem SCI. So kann auch ein älterer Code einen Bugfix bekommen, ohne große Wahrscheinlichkeit, neue Fehler einzuführen. Getestet wird natürlich trotzdem.
Gibt es eine Möglichkeit, die kompilierte .elf so mit dem .bin zu
vergleichen, dass Equivalenz festgestellt werden kann (oder .hex oder
wasauchimmer mit den beiden vorhandenen Dateien möglich ist)?
Das ginge nur, wenn schon ein paar Varianten als Referenzen zum Vergleichen da wären.
Im Hexeditor kann man so einiges machen, z.B. auch den überflüssigen Teil der Hochsprache wegknipsen.
Mit einem Emu könntest du einfach mehrere Versionen erstellen, und beide Gruppen nach z.B. nach Größe sortieren und schauen, was das hergibt.
Das vermute ich auch, man könnte schauen, ob Programme wie Peid (als Plugin) oder elfdiff, objcopy, Rust usw. noch was bringen. Je mehr man sucht und Hilfen nutzt, desto höher die Wahrscheinlichkeit, brauchbare Ansätze zu finden.
Ich habe mit dem objcopy.exe aus einem Unterverzeichnis des STM32CubeIDE
aus der Datei.elf eine Datei.bin gemacht um sie mit dem Flashinhalt
vergleichen zu können
Um objcopy sinnvoll zu nutzen, braucht es wohl noch eine gewisse Einarbeitung?
Bevor ich mir da große Gedanken über die Theorie machen würde, würde ich einfach mal die generierte bin und das Speicherabbild in Beyond Compare reinwerfen und schauen was rauskommt. Das geht schneller als hier einen Post zu verfassen.
Wenn's nix bringt, hat man zwei Minuten "verloren", kann aber immernoch in der Theorie rumstochern...
Das kommt in Klitschen und auch in renommierten Firmen immer wieder vor. Die ganz große Inventur ist wie folgt:
Hinweise im Bin
Nimm das 2MB bin und untersuche es auf Zeichenpattern, die wie ein
Datum (also sowas wie "2023" oder oder "11.23", manchmal auch mit je einem '.' dazwischen)
Pfad ("c:...")
Version (egal ob Compiler oder Programmversion)
Build-Nummer
aussehen.
Sammeln: Sammel alle .elf Files, die in Frage kommen können und schau Dir Gemeinsamkeiten/Unterschiede an (Größe, Datum, ...)
Speicherabbild: Lade das heute aktuelle Elf-File in den Prozessor. Stelle sicher, dass es richtig ist, die HW läuft. Dann lese den Prozessor zurück und vergleiche elf/bin. So gewinnst Du eine Idee, wo genau das elf im Prozessor-Abbild liegt
Toolchain: Bild den aktuellen Code und schaue, ob das aktuelle elf-File rausfällt. Falls nein, schaue wo die Unterschiede liegen. Falls ja, hast Du vielleicht die "richtige" Toolchain mit den richtigen Einstellungen.
Puzzelarbeit: Ohne jeden Hinweis bleibt Dir nur, die bisherigen Git-Stände auszuchecken, zu kompilieren, in den Prozessor einzubrennen und den Prozessor zurückzulesen. Mit ein paar Erfahrungen aus 1-4 kannst Du Dir hoffentlich einige Schritte sparen.
Das vermute ich auch, man könnte schauen, ob Programme wie Peid (als
Plugin) oder elfdiff, objcopy, Rust usw. noch was bringen.
Na ja, man sollte ja zumindest die Basics beherrschen, und zumindest einen guten Hexeditor und ebenso guten Diassembler haben und auch benutzen können.
Ansonsten wirds völlig unmöglich.
Wie gesagt, ich würde als erstes die Quellen diffen, und schauen, wo da überhaupt die Unterschiede zwischen den Versionen sind. Gibts da eindeutige Strings, wirds einfach. Wenn nicht, muß man halt nach anderen Unterschieden suchen, die sich in einem disassemblierten Kompilat identifizieren lassen.
Aber selbst wenn man die Version dann identifiziert hat, kommt beim Kompilieren vermutlich nicht 1:1 das selben Kompilat raus. Wenn das das Ziel ist, muss man halt noch mit toolchains und Optionen spielen.
Wenn nicht, muß man halt nach anderen
Unterschieden suchen, die sich in einem disassemblierten Kompilat
identifizieren lassen.
Ich hatte ganz vergessen, hinzuschreiben, dass man auch Tests oder Profiler einsetzen kann um Unterschiede zu finden, sofern solche Möglichkeiten verfügbar sind.
Das setzt voraus, daß derjenige, der die Compilate erzeugte, über soviel
Selbstdisziplin verfügte, diese für jeden Durchlauf hochzusetzen.
Das kann man automatisieren.
Ironischer weise macht genau dass eine einfache Auffindbarkeit durch Vergleichen unmöglich, da damit die einfache Reproduzierbarkeit nicht gegeben ist. Noch schlimmer wird es nur wenn die __ DATE __ oder __ TIME __ Makros verwendet wurden.
Also manuell hochgezählte Versionsinfos (in der Versionsverwaltung eingecheckt) in das Kompilat einbinden (dann ist es reproduzierbar).
Und/oder den Kompilat Durchlauf und den GIT Hash als extra Informationen hinten ans Binary anhängen. Dann lässt sich wenigstens mit wenig Aufwand ein individuelles Vergleichstool schreiben. Und das Compilieren wenn es zu einem Kunden geht nur einem Buildserver erledigen lassen, dann landen nicht versehentlich lokale Änderungen im Kompilat.
Dem TO viel Erfolg. Seine Aufgabe reicht irgendwo von leicht bis unmöglich.
Wenn in der Versionsverwaltung zehn Commits mit gleicher
Versionsinformation sind ...
Vermutlich könnte man auch mit einem Hook bei jedem Commit ein Inkrement mit einchecken, dann wäre das auch gegeben.
Ansonsten, 10 Versionen ließen sich auch durchprobieren, besser als völlig im Trüben zu stochern.
Reproduzierbarkeit ist das Wichtigste. Dazu gehört auch die Bibliotheken und den Compiler zu archivieren.
Notfalls sucht dann der Buildserver ein Wochenende lang automatisiert durch neu kompilieren und Vergleichen das richtige Kompilat.
Wenn in der Versionsverwaltung zehn Commits mit gleicher
Versionsinformation sind ...
Bei SVN wäre es üblich (weil einfach), die Revision ins Compilat einzubauen (Version oder Text) und gleichzeitig ein Zeichen, ob es lokale Modifikationen oder Mixed-Range gibt. Z.B. V12_B4711M für lokale Modifikationen und V12_B4711 ohne.
Den ausgelesenen EEPROM Dump gegen eine lokal erzeugte Datei nur simple 1:1 binär zu vergleichen schlägt idR immer Fehl, da der Programmcode idR nur ab einer bestimmten Adresse im Dump anfängt und oft hinter dem Programmcode ein Speicherblock kommt in dem das Programm persitent zu speichernde Werte ablegt wie die Konfiguration oder irgendwelche Zähler wenn das nötig ist (z.B. Betriebsstunden, Lifecyle, Abnutzungszähler für Werkzeuge/ Betriebsmittel, Fehlerzähler).
Ich hatte schonmal an meinen Flashversuchen gezweifelt, da beim verifizieren /runterladen des EEPROMS immer ein anderer HASH rauskam als beim Hochladen. Bis ich im Hex/Binärvergleich per Hand gesehen habe, dass nach dem Flashen sofort das Program beim Aufstart seine Konfig/Zähler initialisiert hatte und daher nur ein Speicherblock irgendwo hinter dem Programm abweichungen zum geflashten File hatte....
