Определить исходный язык из двоичного файла?

Question

я ответил На другой вопрос о разработке для iPhone на языках, отличных от Objective-C, я заявил, что использование, скажем, C# для написания для iPhone могло бы неправильно ударить рецензента Apple.Я говорил в основном об элементах пользовательского интерфейса, различающихся в рассматриваемых библиотеках ObjC и C#, но один комментатор высказал интересную мысль, которая привела меня к следующему вопросу:

Можно ли определить язык, на котором написана программа, только по ее двоичному файлу? Если существуют такие методы, то какие они?

Предположим для целей вопроса:

• Что с точки зрения взаимодействия (поведение консоли, внешний вид графического интерфейса и т. д.) они идентичны.
• Эта производительность не является надежным индикатором языка (нельзя сравнивать, скажем, Java с C).
• Что между вами и языком нет интерпретатора или чего-то еще — только необработанный исполняемый двоичный файл.

Бонусные баллы, если вы, насколько это возможно, не зависите от языка.

Answer 1

Я не хакер компиляторов (надеюсь, когда-нибудь), но я полагаю, что вы сможете найти в двоичном файле характерные признаки, указывающие, какой компилятор его сгенерировал, а также некоторые использованные параметры компилятора, например уровень указана оптимизация.

Однако, строго говоря, то, о чем вы просите, невозможно.Возможно, кто-то сел с ручкой и бумагой и разработал двоичные коды, соответствующие программе, которую он хотел написать, а затем напечатал это в шестнадцатеричном редакторе.По сути, они будут программировать на ассемблере без инструмента ассемблера.Точно так же вы никогда не сможете с уверенностью сказать, был ли собственный двоичный файл написан на прямом ассемблере или на C с использованием встроенного ассемблера.

Что касается сред виртуальных машин, таких как JVM и .NET, я ожидаю, что вы сможете идентифицировать виртуальную машину по байт-кодам в двоичном исполняемом файле.Однако вы, возможно, не сможете определить, какой был исходный язык, например C# или Visual Basic, если только нет особых особенностей компилятора, которые вас подскажут.

Answer 2

Короткий ответ: ДА

Длинный ответ:

Если вы посмотрите на двоичный файл, вы сможете найти имена библиотек, которые были связаны с ним.Открыв cmd.exe в TextPad, вы легко обнаружите следующее по шестнадцатеричному смещению 0x270:msvcrt.dll, KERNEL32.dll, NTDLL.DLL, USER32.dll и т. д.msvcrt — это функции поддержки среды выполнения Microsoft C.KERNEL32, NTDLL и USER32.dll — это библиотеки, специфичные для ОС, которые сообщают вам либо целевую платформу, либо платформу, на которой она была создана, в зависимости от того, насколько хорошо кроссплатформенная среда разработки разделяет их.

Если оставить в стороне эти подсказки, то большинству любого компилятора c/c++ придется вставлять имена функций в двоичный файл: в таблице хранится список всех функций (или точек входа).C++ «искажает» имена функций для кодирования аргументов и их типов для поддержки перегруженных методов.Имена функций можно запутать, но они все равно будут существовать.Сигнатуры функций будут включать количество и типы аргументов, которые можно использовать для отслеживания системных или внутренних вызовов, используемых в программе.По смещению 0x4190 находится «SetThreadUILanguage», по которому можно найти много информации о среда разработки.Я нашел таблицу точек входа по смещению 0x1ED8A.Я легко мог видеть такие имена, как printf, exit и scanf;вместе с __p__fmode, __p__commode и __initenv

Любой исполняемый файл для процессора x86 будет иметь сегмент данных, который будет содержать любой статический текст, включенный в программу.Обратно к cmd.exe (смещение 0x42C8) находится текст «S.o.f.t.w.a.re..P.o.l.i.c.ie.s..M.i.c.r.o.s.o.f.t..W.in.d.o.w.s..S.y.s.t.e.m.».Строка занимает вдвое больше символов, чем обычно необходимо, поскольку она хранилась с использованием символов двойной ширины, вероятно, для интернационализации.Коды ошибок или сообщения являются здесь основным источником.

По смещению B1B0 — это «p.u.s.h.d», за которым следуют mkdir, rmdir, chdir, md, rd и cd;Я исключил непечатаемые символы для удобства чтения.Это все аргументы команды cmd.exe.

Что касается других программ, мне иногда удавалось найти путь, по которому программа была скомпилирована.

Так, да, можно определить исходный язык из бинарного файла.

Answer 3

Я ожидаю, что вы могли бы это сделать, если бы дизассемблировали исходный код или, по крайней мере, знали компилятор, поскольку не все компиляторы будут использовать один и тот же код для printf например, поэтому Objective-C и gnu C здесь должны отличаться.

Вы исключили все языки байт-кода, поэтому эта проблема будет менее распространенной, чем ожидалось.

Answer 4

Первый забег what на некоторых двоичных файлах и посмотрите результат.Идентификаторы CVS (и SVN) разбросаны по всему двоичному изображению.И большинство из них из библиотек.

Кроме того, часто существует «карта» различных библиотечных функций.Это тоже большой намек.

Когда библиотеки связываются с исполняемым файлом, в двоичный файл часто включается карта с именами и смещениями.Это часть создания «позиционно-независимого кода».Вы не можете просто «жестко связать» различные объектные файлы вместе.Вам нужна карта, и вам придется выполнить некоторые поиски при загрузке двоичного файла в память.

Наконец, стартовый модуль для C, C++ (и, я полагаю, C#) уникален для набора библиотек по умолчанию этого компилятора.

Answer 5

а как насчет этих инструментов:

ЧП детектив

ПЭИД

оба являются идентификаторами PE.ок, они оба для окон, но именно так было, когда я сюда приземлился

Answer 6

Ну, C изначально преобразуется в ASM, поэтому вы можете писать весь код C в ASM.

Answer 7

Нет, байт-код не зависит от языка.Разные компиляторы могут даже использовать один и тот же исходный код и генерировать разные двоичные файлы.Вот почему вы не видите декомпиляторов общего назначения, которые будут работать с двоичными файлами.

Answer 8

Команду «строки» можно использовать, чтобы получить некоторые подсказки относительно того, какой язык использовался (например, я только что запустил ее в вырезанном двоичном файле написанного мной приложения C, и первые найденные записи — это библиотеки, связанные с исполняемым файлом). .