Сколько информации об источнике хранится в исполняемых файлах c ++

Несколько дней назад я случайно открыл исполняемый файл C ++ коммерческого приложения в Notepad ++ и обнаружил, что в исходном файле хранится довольно много информации об исходном исходном коде.

Внутри исполняемого файла я мог найти имена файлов (app.c, dlgstat.c, …), имена функций (GetTickCount, DispatchMessageA, …) и небольшие кусочки исходного кода, в основном условия (szChar != TEXT('\0'), iRow < XTGetRows( hwndList )). После этого я проверил другой исполняемый файл QT и: да, снова имена исходных файлов и сигнатуры методов.

В связи с этим мне интересно, сколько информации об исходном коде действительно хранится в исполняемом файле C / C ++ (например, скомпилированном с использованием QT или MinGW). Возможно, это какая-то отладочная сборка, все еще содержащая исходный код? Эта информация используется для размышлений? Есть ли причина, по которой издатели не удаляют этот материал?

3

Решение

Сколько информации об исходном коде действительно хранится в исполняемом файле C / C ++?

На практике не сильно. Исходный код не требуется во время выполнения. Строки, которые вы называете, происходят из двух вещей:

  • Имена функций (например, GetTickCount) являются названиями функций, импортированных из других модулей. Имена требуются во время выполнения, потому что функции разрешаются динамически (путем вызова GetProcAddress с именем функции).

  • Условия, скорее всего, утверждения: assert макрос структурирует свой аргумент, чтобы при запуске вы знали, какое условие не было выполнено.

Если вы создаете DLL, она также будет содержать имена всех экспортируемых функций, поэтому они могут быть разрешены во время выполнения (то же самое, вероятно, верно для других форматов общих объектов).

Символы отладки могут также содержать некоторый исходный исходный код, хотя это зависит от формата, используемого символами отладки. Эти символы могут содержаться либо в самом двоичном файле, либо во вспомогательном файле (например, в файлах .pdb, используемых в Windows).

11

Другие решения

Имена функций Windows: они, вероятно, существуют только потому, что к ним обращаются динамически — где-то в вашей программе есть GetProcAddress чтобы получить их адрес. Тем не менее, нет причин для беспокойства, каждое приложение использует WinAPI, поэтому по этой информации не так уж много можно узнать о вашем исполняемом файле.

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

Имена исходных файлов и сигнатуры методов: вероятно, из-за некоторого использования __FILE__ а также __func__ макросы; вероятно, опять же из assert,

Другими источниками информации о внутренней структуре вашей программы является RTTI, который должен обеспечивать некоторое представление для каждого типа, который typeid может работать над Если вам не нужна его функциональность, вы можете отключить ее (но я не знаю, возможно ли это в проектах Qt).

2

Смешанный с двоичным файлом приложения C ++, вы найдете имена большинства глобальных символов (и символы отладки, если они включены в компиляторе), но с дополнительным «текстом оформления», который кодирует вызывающую подпись символа, если это функция или метод. , Аналогично, литералы символьных строк встраиваются в открытый текст. Но там, где вы не найдете ничего похожего на настоящий исходный код, который компилятор использовал для создания двоичного исполняемого файла. Эта информация теряется во время процесса компиляции, и особенно трудно провести обратный инжиниринг, если в сборке используются шаблоны C ++.

0
По вопросам рекламы ammmcru@yandex.ru
Adblock
detector