Finde den Code zum Kompilat

[Lukas S. (lukker)]

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)?

[Nemopuk (nemopuk)]

Vermutlich wurde das bin File nicht erzeugt, sonder aus gelesen. Es ist 
größer, als das Programm. Ein direkter 1:1 Vergleich wird nicht gehen.

Ich würde versuchen, nur die ersten n Bytes zu vergleichen, entsprechend 
der kleineren bin Datei.

[Rüdiger B. (rbruns)]

Im bin sollte doch eine Versionsnummer zu finden sein, wird doch als 
Info im Programm angezigt oder ?

[G. K. (zumsel)]

Lukas S. schrieb:

> 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:

https://www.google.com/search?q=reproducible+builds

[Oliver S. (oliverso)]

Du brauchst die toolchain-Version, die für die Erzeugung des 
Flashinhalts benutzt wurde, dazu die verwendeten Optionen. Das kann 
kompliziert werden.

Wie schon gesagt wurde, wenns da irgendwelche Strings gibt, die die 
Version identifizieren, kanst du mit einem hex-Editor danach suchen.

Oliver

[Harald K. (kirnbichler)]

Rüdiger B. schrieb:
> 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.

[G. K. (zumsel)]

Harald K. schrieb:

> Das setzt voraus, daß derjenige, der die Compilate erzeugte, über soviel
> Selbstdisziplin verfügte, diese für jeden Durchlauf hochzusetzen.

Das kann man automatisieren.

[Alexander (alecxs)]

Man könnte es durch Ghidra jagen und anschließend durch eine KI.

Lukas S. schrieb:
> Ich habe hier den Inhalt des Flahsspeichers aus einen STM32 und ein
> Git-Repository mit mehreren Versionsständen des Codes.

Wieviele Kandidaten kommen in Frage?

Lukas S. schrieb:
> Ich soll nun herausfinden, welcher Versionsstand genau den vorhandenen
> Flashinhalt ergeben hat.

Wie wichtig ist das, wirst Du extra dafür bezahlt, hast Du ein paar 
Wochen Zeit?

[Harald K. (kirnbichler)]

G. K. schrieb:
> Das kann man automatisieren.

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 ...

Strukturiert arbeiten geht anders.