Ich antwortete zu einer anderen Frage über die Entwicklung für das iPhone in Nicht-Objective-C-Sprachen, und ich machte die Behauptung, dass die Verwendung, sagen wir C # für das iPhone zu schreiben würde einen Apple-Rezensenten falsch schlagen. Ich sprach hauptsächlich über UI-Elemente, die sich zwischen den ObjC- und C # -Bibliotheken unterschieden, aber ein Kommentator machte einen interessanten Punkt, der mich zu dieser Frage führte:
Ist es möglich, die Sprache, in der ein Programm geschrieben ist, allein anhand seiner Binärdatei zu bestimmen? Wenn es solche Methoden gibt, welche?
Nehmen wir für die Zwecke der Frage an:
Bonuspunkte, wenn Sie möglichst sprachunabhängig sind.
Ich bin kein Compiler-Hacker (hoffentlich irgendwann), aber ich denke, Sie könnten in einer Binärdatei verräterische Zeichen finden, die anzeigen würden, was der Compiler und einige der verwendeten Compileroptionen, wie z die Ebene der Optimierung angegeben.
Streng genommen ist jedoch das, was Sie fragen, unmöglich. Es könnte sein, dass jemand sich mit Stift und Papier hingesetzt hat und die Binärcodes ausgearbeitet hat, die dem Programm entsprechen, das sie schreiben wollten, und dann dieses Zeug in einem Hex-Editor eingegeben hat. Im Grunde würden sie in Assembly ohne das Assembler-Tool programmieren. In ähnlicher Weise können Sie möglicherweise nie mit Sicherheit sagen, ob eine native Binärdatei in einem geraden Assembler oder in C mit einer Inline-Assembly geschrieben wurde.
Wie bei VM-Umgebungen wie JVM und .NET sollten Sie in der Lage sein, die VM anhand der Bytecodes in der binären ausführbaren Datei zu identifizieren, was ich erwarten würde. Sie können jedoch möglicherweise nicht sagen, was die Ausgangssprache war, wie C # im Vergleich zu Visual Basic, es sei denn, es gibt bestimmte Compiler-Eigenarten, die Sie als Tipp ausgeben.
Kurze Antwort: YES
Lange Antwort:
Wenn Sie sich eine Binärdatei ansehen, können Sie die Namen der Bibliotheken finden, die verlinkt wurden. Beim Öffnen von cmd.exe in TextPad finden Sie leicht die folgenden Hexadezimalwerte 0x270: msvcrt.dll, KERNEL32.dll, NTDLL.DLL , USER32.dll usw. msvcrt ist die Laufzeitunterstützung von Microsoft 'C'. KERNEL32, NTDLL und USER32.dll sind OS-spezifische Bibliotheken, die Ihnen entweder die Zielplattform oder die Plattform, auf der sie erstellt wurde, mitteilen, je nachdem, wie gut die plattformübergreifende Entwicklungsumgebung die beiden segmentiert.
Wenn man diese Hinweise beiseite legt, muss fast jeder c / c ++ - Compiler die Namen der Funktionen in die Binärdatei einfügen, es gibt eine Liste aller Funktionen (oder Einstiegspunkte), die in einer Tabelle gespeichert sind. C ++ "manipuliert" die Funktionsnamen, um die Argumente und ihre Typen zu codieren, um überladene Methoden zu unterstützen. Es ist möglich, die Funktionsnamen zu verschleiern, aber sie würden immer noch existieren. Die Funktionssignaturen würden die Anzahl und Typen der Argumente enthalten, die verwendet werden können, um in das System oder interne Aufrufe, die in dem Programm verwendet werden, zu verfolgen. Bei Offset 0x4190 ist "SetThreadUILanguage", nach dem gesucht werden kann, um viel über die herauszufinden Entwicklungsumgebung . Ich habe die Eingangspunkttabelle am Offset 0x1ED8A gefunden. Ich könnte leicht Namen wie printf, exit und scanf sehen; zusammen mit __p__fmode, __p__commode und __initenv
Jede ausführbare Datei für den x86-Prozessor enthält ein Datensegment, das jeglichen statischen Text enthält, der im Programm enthalten war. Zurück zu cmd.exe (Offset 0x42C8) ist der Text "S.o.f.tw.w.a.e.P.o.l.i.c.i.e...M.i.c.r.o.s.o.f.t.W.i.n.d.o.w.s.S.y.s.t.e.". Die Zeichenfolge benötigt doppelt so viele Zeichen wie normalerweise erforderlich, da sie für die Internationalisierung mit Zeichen mit doppelter Breite gespeichert wurde. Fehlercodes oder Nachrichten sind hier eine Hauptquelle.
Bei Offset B1B0 ist "p.u.s.h.d" gefolgt von mkdir, rmdir, chdir, md, rd und cd; Ich habe die nicht druckbaren Zeichen aus Gründen der Lesbarkeit weggelassen. Das sind alle Befehlsargumente für cmd.exe.
Bei anderen Programmen konnte ich manchmal den Pfad finden, von dem ein Programm kompiliert wurde.
Also yes ist es möglich, die Quellsprache aus der Binärdatei zu bestimmen.
Ich erwarte, dass Sie, wenn Sie die Quelle disassemblieren, zumindest den Compiler kennen, da nicht alle Compiler den gleichen Code für printf verwenden, also sollten sich Objective-C und gnu C hier unterscheiden.
Sie haben alle Bytecode-Sprachen ausgeschlossen, sodass dieses Problem seltener auftritt als erwartet.
Führen Sie zuerst what für einige Binärdateien aus und sehen Sie sich die Ausgabe an. CVS- (und SVN-) Identifikatoren sind im gesamten Binärbild verstreut. Und die meisten davon stammen aus Bibliotheken.
Außerdem gibt es oft eine "Karte" zu den verschiedenen Bibliotheksfunktionen. Das ist auch ein großer Hinweis.
Wenn die Bibliotheken in die ausführbare Datei eingebunden sind, gibt es oft eine Karte, die in der Binärdatei mit Namen und Offsets enthalten ist. Es ist Teil der Erstellung von "positionsunabhängigem Code". Sie können die verschiedenen Objektdateien nicht einfach "fest verknüpfen". Sie benötigen eine Karte und Sie müssen einige Nachschlagevorgänge durchführen, wenn Sie die Binärdatei in den Speicher laden.
Schließlich ist das Start-up-Modul für C, C ++ (und ich stelle mir C # vor) eindeutig für den Satz von Bibliotheken dieses Compilers.
Was ist mit diesen Tools:
Beide sind PE-Identifikatoren. ok, sie sind beide für Windows, aber das war es, als ich hier gelandet bin
Nun, C ist zunächst die ASM konvertiert, so dass Sie alle C-Code in ASM schreiben konnten.
Der Befehl 'strings' könnte verwendet werden, um ein paar Hinweise darüber zu bekommen, welche Sprache verwendet wurde (ich habe sie zum Beispiel für eine C-Anwendung, die ich geschrieben habe, auf der stripped binary ausgeführt und die ersten gefundenen Einträge sind die Bibliotheken, die verlinkt sind die ausführbare Datei).
Tags und Links programming-languages binary disassembly