Тип преобразования кода, используемый в исполняемых файлах Linux

Я хочу спросить, какой тип кодирования используется для создания исполняемых файлов linux, например. шестнадцатеричный, двоичный или что-то еще. как он преобразуется? Есть ли способ вернуть исходный код из этого исполняемого файла?

Вот немного кода, который у меня есть:

ELF���������>�����%|�����@�������������������@�8��@���������������������@�������@�����7<�����7<������� ������������������f�����f���������������������� ������[�UPX!L
h�h�8����������?�E�h=��ڊ̓�N�    4���9ISloB�q�w�]ȉ.��,ς��Q䝦����#e��-�N����/�b,���d<��'��-E��6E�s�/�U���ly�V�Y2]"a��S�.�hU�|�S�J�I�2���X}
�G0�;���5d�$���.)

что это означает? [!d2 ]

1
задан 9 September 2015 в 15:15

4 ответа

У меня недостаточно очков репутации для комментария, так что это ответ:

Нет, его невозможно перевести «назад». Вы упомянули упаковщик upx, вы когда-нибудь читали руководство по upx?

Если вы потеряли источник или не имеете доступа к коду кого-то еще, это не имеет значения здесь, это просто невозможно.

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

7
ответ дан 23 May 2018 в 17:38

Это, вероятно, двоичный файл (файл ELF), как описано здесь:

https://en.wikipedia.org/wiki/Executable_and_Linkable_Format

Если вы изменили он с обычным текстовым редактором и сохранил ваши изменения, это не была хорошая идея, и вы, возможно, уничтожили его.

3
ответ дан 23 May 2018 в 17:38

Как уже указывал Оли в своем ответе, вы не можете получить исходный исходный код исполняемого файла.

Во время компиляции исходного кода (компиляция, предназначенная как в типичном более широком принятии, следовательно, как весь процесс, который «преобразует» исходный код в исполняемый файл), теряется множество информации.

Препроцессор C, например, выполнит следующее (между прочим): [!d2 ] Интерпретировать, выполнить и удалить директивы препроцессора (#) Удалить комментарии Удалить ненужные пробелы

С другой стороны, то, что не потеряно во время компиляции исходного кода, технически обратимо к функциональный эквивалентный исходный код

Это происходит потому, что:

Интерпретировать, выполнить и удалить директивы препроцессора (#) Инструкции по сборке не имеют 1: 1 соответствие с инструкциями C; компиляция исходного кода C обычно представляет собой не просто преобразование инструкций C в инструкции по сборке на основе таблицы коррумпированности, на самом деле это часто противоположное; обычно инструкция C преобразуется в краткие (часто разные на основе компилятора) инструкции сборки; однако шаблоны нескольких команд сборки обычно идентифицируются и возвращаются к одной команде C;

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

Рассмотрим эту программу:

#include <stdio.h>

#define MESSAGE "Literal strings will be recovered" // This preprocessor directive won't be recovered

/*

This comment and the comment above won't be recovered

*/

int main(int argc, char* argv[]) {
    printf(MESSAGE);
    return 0;
}

. Скомпилировав ее в исполняемый файл и декомпилируя его в исходный код снова, это более или менее то, что вы обычно возвращаете (в этом конкретном случае я использовал gcc / Boomerang):

// address: 0x80483fb
int main(int argc, char **argv, char **envp) {
    printf("Literal strings will be recovered");
    return 0;
}

Как и было предсказано:

Инструкции по сборке не имеют коррумпированности 1: 1 с инструкциями C; компиляция исходного кода C обычно представляет собой не просто преобразование инструкций C в инструкции по сборке на основе таблицы коррумпированности, на самом деле это часто противоположное; обычно инструкция C преобразуется в краткие (часто разные на основе компилятора) инструкции сборки; однако, шаблоны нескольких инструкций сборки обычно идентифицируются и возвращаются к одной инструкции C. Удалить комментарии Отсутствуют ненужные пробелы (кроме новых строк и таблиц, которые были добавлены декомпилятором)

Это также довольно хороший результат; не редко встречаются встроенные инструкции сборки в код:

asm("assembly_instruction");
__asm__("assembly_instruction");

Нижняя строка (как уже указывалось в других ответах): far *. [!d27 ]

* Однако, в зависимости от исполняемого файла и вашей удачи, вы можете получить что-то с помощью декомпилятора.

3
ответ дан 23 May 2018 в 17:38

Исполняемые файлы обычно являются двоичными, если вы говорите о скомпилированных программах. Вы можете найти дополнительную информацию, используя file path/to/executable. Вы можете отображать двоичные исполняемые файлы в шестнадцатеричном формате с использованием, например, hexdump -C path/to/executable | less (независимо от того, что бы вы сделали). Если вы хотите «преобразовать его обратно в исходную форму», вам нужно будет использовать соответствующий декомпилятор, см. Это сообщение, например, хотя это даст вам совершенно нечитаемый код, а не оригинал, из которого он был скомпилирован. Если это не скомпилированный двоичный файл, это будет какой-то исполняемый скрипт, который должен быть легко читаемым в любом текстовом редакторе. То, что вы показали нам здесь, вероятно, является скомпилированным исполняемым файлом. ELF означает «Исполняемый и связанный формат», который является общим двоичным форматом в системах Linux / Unix. Существует возможность извлекать читаемые части строки из двоичных файлов с помощью strings path/to/executable, если это то, что вам нужно.

2
ответ дан 23 May 2018 в 17:38
  • 1
    Я попытался перестроить его с помощью пакета upx, но не работал, а также с сообщением, которое вы предложили. Поэтому, пожалуйста, скажите мне, есть ли другой способ. – Jaysheel Utekar 8 September 2015 в 12:25
  • 2
    Очень жаль, но я не могу сказать вам ничего больше, чем то, что написано в превосходном посте @ Оли. – Hinz 8 September 2015 в 13:03

Другие вопросы по тегам:

Похожие вопросы: