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
>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.
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.
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.
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
Binär eingelinkte Compiler-eigene Libraries sollten auch einen recht deutlichen Hinweis auf den verwendeten Compiler liefern...
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.)
Hi
>Nicht zu verachten sind auch die EXIF-Daten in den JPG-Bildern, ...
Und wo ist da ein Compiler im Spiel?
MfG Spess
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
Wenn man die Info im IHEX haben will dann kann man sie dort hinterlegen. Genause wie CRC-Checksummen nachträglich hinzugebastelt werden können.
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. --
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.