Forum: Mikrocontroller und Digitale Elektronik Info zum verwendeten Compiler im HEX-File?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ulrich E. (sudu)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

folgende Frage habe ich:

Kann man aus dem vorliegenden HEX-File für einen µC auch Rückschlüsse 
ziehen auf den verwendeten Compiler (oder sogar dessen Version)?

Der Compiler-Hersteller könnte doch einfach nach jeder Codegenerierung 
ein paar Byte als eigene Kennung hinten anhängen, oder alternativ auch 
vorn am Codebeginn an einer definierten Stelle ablegen und über diese 
Zeichen dann hinwegspringen.

Gibt es dazu noch igendwo weitere Infos oder Erfahrungen?

Vielen Dank schon mal und beste Grüße

von holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Kann man aus dem vorliegenden HEX-File für einen µC auch Rückschlüsse
>ziehen auf den verwendeten Compiler (oder sogar dessen Version)?

Nein.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ulrich E. schrieb:
> Kann man aus dem vorliegenden HEX-File für einen µC auch Rückschlüsse
> ziehen auf den verwendeten Compiler (oder sogar dessen Version)?

Der HEX-File ist eine Schreibweise für dein in Maschinencode übersetztes 
Programm. Du würdest dich schön beschweren, wenn da was anderes drin 
stände, als du mit deinem Quellcode erreichen wolltest.

Wenn du das nicht glaubst, nimm einfach deinen LST-File und vergleiche 
selber den generierten Code mit dem Inhalt vom HEX-File.

von Ulrich E. (sudu)


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Der HEX-File ist eine Schreibweise für dein in Maschinencode übersetztes
> Programm. Du würdest dich schön beschweren, wenn da was anderes drin
> stände, als du mit deinem Quellcode erreichen wolltest.

Das ist schon klar. Wahr ist aber auch:

Wenn der Compiler den Assemblercode erzeugt, genau wie im Quelltext als 
Aufgabe vorgegeben, und anschließend daran, dort wo nie OP-Code 
ausgeführt wird, noch einige Byte anfügt, würde das wohl niemand in der 
Praxis bemerken.

von holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Wenn der Compiler den Assemblercode erzeugt, genau wie im Quelltext als
>Aufgabe vorgegeben, und anschließend daran, dort wo nie OP-Code
>ausgeführt wird, noch einige Byte anfügt, würde das wohl niemand in der
>Praxis bemerken.

Das ist in HEX-Files aber nicht vorgesehen. Und du würdest dich 
wahrscheinlich wundern wieviele Programmer ein HEX-File mit
"Zusatzinformationen" möglicherweise komplett ablehnen.

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
Du kannst beim GCC vordefinierte Macros als Konstante im Flash ablegen.
1
#define GCC_VERSION (__GNUC__ * 10000 \
2
                     + __GNUC_MINOR__ * 100 \
3
                     + __GNUC_PATCHLEVEL__)

Das mußt Du aber selber in den Code reinschreiben.

von nfet (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Grundsätzlich denke ich schon, dass es möglich ist.
Jeder Compiler optimiert den Code ein bisschen anders und bei einen 
ausreichend großen Programm, denke ich, kann man da schon ziemlich 
sichere Rückschlüsse auf den verwendeten Compiler ziehen.
Ob sich da schon mal wer die Mühe gemacht hat, da statistisch irgendwas 
zu zeigen: keine Ahnung.
Aber interessant finde ich das Thema auch, auch wenn mir kein 
praktischer Nutzen einfällt.

von Ulrich E. (sudu)


Bewertung
2 lesenswert
nicht lesenswert
holger schrieb:
> wieviele Programmer ein HEX-File mit
> "Zusatzinformationen" möglicherweise komplett ablehnen.

Ich bezweifele, das ein Programmer so etwas überhaupt bemerken könnte.

Der Compilerbauer fügt zum Beispiel vor dem eigentlichen, zu 
generierenden Assembler-Code einen zusätzlichen Sprungbefehl über eine 
eigene Kennung (bestehend natürlich aus irgendeinem gültigem OP-Code) 
ein.

Das dürfte jeder Programmer problemlos verarbeiten und der Anwender 
bekommt sein gewünschtes Programm geliefert

von holger (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>Der Compilerbauer fügt zum Beispiel vor dem eigentlichen, zu
>generierenden Assembler-Code einen zusätzlichen Sprungbefehl über eine
>eigene Kennung (bestehend natürlich aus irgendeinem gültigem OP-Code)
>ein.

Dem würde ich die Hammelbeine langziehen wenn er meinen Speicher mit
Informationen belegt die ich nicht im Speicher haben möchte.
Vieleicht passt mein Programm aufgrund dieser Informationen nicht
mehr ins Flash. Es ist auch völlig Banane mit welchem Compiler
die HEX Datei erstellt wurde. Aus einer HEX Datei bekommt man
seinen Sourcecode ja nicht wieder decompiliert.

Deine allgemeine Ursprungsfrage kann man aber immer noch mit NEIN 
beantworten weil das wohl kaum jemand tut. Wenn DU selbst diese
Informationen in DEINEM Programm hinterlegst geht das natürlich.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Die .elf könnte dagegen Informationen enthalten.
https://stackoverflow.com/questions/2387040/how-to-retrieve-the-gcc-version-used-to-compile-a-given-elf-executable

Ein kurzer Test mit einer .elf die ich ohne Einstellungen gemacht zu 
haben erzeugt habe:

avr-readelf -p .comment FT8xx_Test.elf

String dump of section '.comment':
  [     0]  GCC: (AVR_8_bit_GNU_Toolchain_3.6.0_1734) 5.4.0

arm-none-eabi-readelf -p .comment FT8xx_Test.elf

String dump of section '.comment':
  [     0]  GCC: (AVR_8_bit_GNU_Toolchain_3.6.0_1734) 5.4.0

Also was man gerade so an "readelf.exe" rumliegen hat sollte die 
Informationen rauswerfen können falls vorhanden.

Falls der verwendete Compiler überhaupt eine .elf erzeugt natürlich.

Die nächste Frage wäre, was einem die Information überhaupt bringt.

von Ulrich E. (sudu)


Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> würde ich die Hammelbeine langziehen wenn er meinen Speicher mit
> Informationen belegt...

Volle Zustimmung!

Bei Open-Source-Compilern würde das wohl auch schnell bekannt werden.

In kommerziellen Produkten ist sicher nur ganz schwer zu überprüfen, ob 
irgendwo nicht doch noch ergänzende Code-Schnipsel eingefügt werden.

von Patrick J. (ho-bit-hun-ter)


Bewertung
0 lesenswert
nicht lesenswert
Hi

Das LST-File und das HEX-File sollten aber einen identischen Aufbau 
besitzen.
Das sollte man mit einem zusammen geschusterten Script vergleichen 
können.
Ob das LST-File noch andere Informationen enthält, als mein Programm, 
muß ich aber dort selber prüfen.
Denke aber auch, sobald ein Compiler/Assembeler so was macht, wird es 
keine 2 Tage dauern, dann ist Dieser 'unten durch' und weltweit 
gebrandmarkt.

Denke weiter: Das wird sich kein Software-Entwickler leisten wollen, 
ggf. auch nicht leisten können.

MfG

von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

>> würde ich die Hammelbeine langziehen wenn er meinen Speicher mit
> Informationen belegt...

Anscheinend weißt du gar nicht was z.B. alles in exe-Dateien drin steht. 
Oder in den Hex-Files von ARM-Compiler. Da freut sich die NSA.

MfG Spess

von Andreas K. (andreasmc)


Bewertung
2 lesenswert
nicht lesenswert
Binär eingelinkte Compiler-eigene Libraries sollten auch einen recht 
deutlichen Hinweis auf den verwendeten Compiler liefern...

von Ulrich E. (sudu)


Bewertung
1 lesenswert
nicht lesenswert
spess53 schrieb:
> was z.B. alles in exe-Dateien drin steht...

Nicht zu verachten sind auch die EXIF-Daten in den JPG-Bildern, die oft 
so arglos in diversen Foren mit hochgeladen werden. (z.B. Angaben zur 
Kamera, Rechner, Nutzer, Verzeichnis, Ort!!!, Datum, u.v.m.)

von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

>Nicht zu verachten sind auch die EXIF-Daten in den JPG-Bildern, ...

Und wo ist da ein Compiler im Spiel?

MfG Spess

von Felix U. (ubfx)


Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:

> Deine allgemeine Ursprungsfrage kann man aber immer noch mit *NEIN*
> beantworten weil das wohl kaum jemand tut.
Die allgemeine Ursprungsfrage war, ob man aus dem Hex-File 
Rückschlüsse ziehen kann, nicht ob es da im Klartext drinsteht. Und da 
lautet die Antwort mit Sicherheit JA. Die library-Funktionen die man 
relativ einfach per Signatur matchen kann, wurden bereits erwähnt. Auf 
vielen Plattformen reicht aber auch schon ein Blick in die IDA Graph 
View um typische Strukturen zu erkennen. Die Version wird man daraus 
nicht unbedingt ableiten können, aber ob ein Binary mit gcc oder iar 
kompiliert wurde, lässt sich schon ermitteln.

von holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Die Version wird man daraus
>nicht unbedingt ableiten können, aber ob ein Binary mit gcc oder iar
>kompiliert wurde, lässt sich schon ermitteln.

Und was bringt einem das?

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Ulrich E. schrieb:
> In kommerziellen Produkten ist sicher nur ganz schwer zu überprüfen, ob
> irgendwo nicht doch noch ergänzende Code-Schnipsel eingefügt werden.

Du nimmst irgendwie an, dass ein Programm 100kByte oder mehr hat und 
sich die keiner anguckt.

Das ist falsch.

Es gibt genügend Freaks, die Minimalprogramme von wenigen Bytes (z.B. 
LED endlos toggeln) auf deren Umsetzung prüfen.

Und so Dinge wie Lizenznummer und Co dürfen da auch nicht drin sein, 
denn auch bei 100kByte sollte ein Quelltext mit gleicher Compilerversion 
auch gleichen Output liefern (von _DATE__ und __TIME_ abgesehen). Ein 
Bereich von 13 Bit, der da unterschiedlich ist, bliebe nicht unentdeckt.

von Felix U. (ubfx)


Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Und was bringt einem das?

Es könnte beispielsweise der allererste Schritt in einem 
Reverse-Engineering Vorgang sein. Standardfunktionen erkennen kann da 
sehr nützlich sein. Zugegeben, dass man dabei noch rausfindet, welcher 
Compiler dahintersteckt ist eher ein Nebeneffekt. Aber was der 
Fragesteller vor hat, weiß ich ja auch nicht.

von Kaj (Gast)


Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
>>Die Version wird man daraus
>>nicht unbedingt ableiten können, aber ob ein Binary mit gcc oder iar
>>kompiliert wurde, lässt sich schon ermitteln.
>
> Und was bringt einem das?
Think big:
Wenn du weisst mit welchem Compiler (und der Version) etwas gebaut 
wurde, kannst du moeglicherweise auf Fehler/Sicherheitsluecken 
hoffen/schliessen, ohne dass du dir den Code/das HEX-File (what ever) 
angeschaut haben musst. Entsprechende Eintraege in den Bug-Listen der 
Compiler helfen dabei.

Ein Beispiel fuer so einen compilerspezifieschen Fehler:
Beitrag "[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading"

Das Problem tritt nur auf, wenn die OCaml-Runtime mit dem gcc und ganz 
bestimmten optimierungs Optionen gebaut wurde.
https://caml.inria.fr/mantis/view.php?id=7452#c17108

von Ulrich E. (sudu)


Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal soweit für eure Antworten.

Achim S. schrieb:
> Und so Dinge wie Lizenznummer und Co dürfen da auch nicht drin sein,....

Warum eigentlich nicht, wenn das Programm perfekt läuft?

Achim S. schrieb:
> denn auch bei 100kByte sollte ein Quelltext mit gleicher Compilerversion
> auch gleichen Output liefern (von DATE__ und __TIME abgesehen). Ein
> Bereich von 13 Bit, der da unterschiedlich ist, bliebe nicht unentdeckt.

In diese Richtung zielte auch grundsätzlich meine Frage.
Ich erziele mit meinem lizensierten Compiler vom gleichen Quellcode 
stets den gleichen Output (...von DATE__ und __TIME abgesehen...).

Ich würde es eigentlich für völlig legitim halten, wenn der Compiler 
stets selbständig noch eine Art _COMP+VERS_ (oder sogar LIZENZNR) als 
eigene kurze Signatur mit einfügt, so das letztendlich der gleiche 
Quellcode auf einem anderen zum Compilieren benutzten Rechner um diese 
Signatur differieren würde.

Achim S. schrieb:
> Es gibt genügend Freaks, die ..... auf deren Umsetzung prüfen.

Solange die das immer mit Open-Source-SW compilieren oder immer nur den 
gleichen Compiler am selben Rechner verwenden, ist das kaum 
feststellbar.

von Ulrich E. (sudu)


Bewertung
0 lesenswert
nicht lesenswert
Ulrich E. schrieb:
> so das letztendlich der gleiche
> Quellcode auf einem anderen zum Compilieren benutzten Rechner um diese
> Signatur differieren würde.

Korrektur, es sollte heissen:

 so das letztendlich der Output vom gleichen
 Quellcode auf einem anderen zum Compilieren benutzten Rechner um diese
 Signatur differieren würde.

von Dergute W. (derguteweka)


Bewertung
1 lesenswert
nicht lesenswert
Moin,

Aus dem Compiler faellt ja aber nicht direkt das hex-file raus, sondern 
ueblicherweise ein file im elf (oder coff) -format. Das besteht dann aus 
verschiedenen Sections, in denen durchaus so Zeugs drinnenstehen kann, 
wie gcc- und alle moeglichen anderen Versionen, debug infos, etc.
Wenn man dann aber hergeht und mittels objcopy oder aehnlichem aus dem 
elf-file ein hex-file erzeugt, dann wird da automatisch alles, was nicht 
ins .hex gehoert, nicht mitkopiert. Wozu auch. Platz ist da evtl. 
kostbar.

Gruss
WK

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wenn man die Info im IHEX haben will dann kann man sie dort hinterlegen. 
Genause wie CRC-Checksummen nachträglich hinzugebastelt werden können.

von Jobst M. (jobstens-de)


Bewertung
0 lesenswert
nicht lesenswert
Ulrich E. schrieb:
> Warum eigentlich nicht, wenn das Programm perfekt läuft?

Datenschutz?


Ulrich E. schrieb:
> Ich würde es eigentlich für völlig legitim halten, wenn der Compiler
> stets selbständig noch eine Art _COMP+VERS_ (oder sogar LIZENZNR) als
> eigene kurze Signatur mit einfügt, so das letztendlich der gleiche
> Quellcode auf einem anderen zum Compilieren benutzten Rechner um diese
> Signatur differieren würde.

Die Frage ist aber viel mehr: Warum möchtest Du das tun? Welchen Zweck 
erfüllt es? Wen möchtest Du verfolgen?
Möchtest Du die Verbreitung von compilierten Code eindämmen?


Ulrich E. schrieb:
> Solange die das immer mit Open-Source-SW compilieren oder immer nur den
> gleichen Compiler am selben Rechner verwenden, ist das kaum
> feststellbar.

Tun sie deshalb ja nicht.


Gruß
Jobst

von Adib (Gast)


Bewertung
0 lesenswert
nicht lesenswert
zur Ausgangsfrage zurück,

konvertier das Ganze mal als bin und schau es dir in einem .binär oder 
.hex Editor an.

Manchmal muss der Compiler Sachen reinlinken, die etwas gesprächiger 
sind als ursprünglich gedacht. Konstante Strings der stdlib und sowas.

Einfach mal probieren.

Kannst du das hex posten?

Danke und Grüße,

Adib.
--

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.