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
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.
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.
>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.
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.
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
>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.
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.
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.
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
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
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.)
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.
>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?
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.
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.
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
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.
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.
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
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
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.
--
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
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten