конвертувати виконуваний файл у вихідний код C

На жаль, я втратив свій вихідний код, і у мене просто є вихідний файл, який було зроблено з gcc в Linux, і я не маю доступу до мого ПК зараз.

c source-code reverse-engineering

— махса
джерело

Те, що ви хочете, називається декомпілятором. Ви можете знайти допомогу з цією відповіддю: stackoverflow.com/questions/193896/whats-a-good-c-decompiler

— Ерік Реноф

IDA Pro з модулем декомпілятора - єдине практичне рішення, яке фактично працює з великими виконуваними файлами.

— fpmurphy

@ fpmurphy1 У вас вийшов Hopper, який за якістю можна порівняти з IDA Pro і ліцензія - це частка ціни.

— Rui F Ribeiro

@ fpmurphy1 Я ще не встиг побачити якість коду, створеного Avast ... хто вже використовує 32-бітні платформи Intel? Крім того, я не використовував Wintel вже десятиліттями. див. unix.stackexchange.com/questions/418354/… Різниця в ціні є досить значущою, однак Hex-ray / IDA pro починаються з 1500USD для особистої ліцензії до деяких вимагаючих цінностей для комерційних ліцензій, таких як 5000USD або вище AFAIK, Hopper становить 100USD для одного користувача та 130 для одного комп’ютера.

— Rui F Ribeiro

@RuiFRibeiro. Пекло багато зловмисного програмного забезпечення, яке я перевіряю, все ще є 32-бітним.

— fpmurphy

Відповіді:

Отже, у вас була корова, але ви ненароком перетворили її на гамбургер, і тепер ви хочете, щоб ваша корова була назад.

Вибачте, це просто не працює таким чином.

Просто відновіть вихідний файл із резервних копій.

Ах, у вас не було резервних копій. На жаль, Всесвіт не дає тобі відпочити.

Ви можете декомпілювати двійкове. Це не дасть вам вихідний код, але це дасть вам деякий вихідний код з тим же поведінкою. Ви не отримаєте імен змінних, якщо це не було бінарним налагодженням. Ви точно не будете отримувати таку ж логіку, якщо не будете складені без оптимізацій. Очевидно, ви не отримаєте коментарів.

Я використовував Boomerang для декомпіляції деяких програм, і результат був більш читабельним, ніж машинний код. Я не знаю, чи це найкращий інструмент там. У всякому разі, не чекайте чудес.

— Жил "ТАК - перестань бути злим"
джерело

Бумеранг виглядає досить акуратно; ганьба посилання на документацію gcc -O4, оскільки це абсолютно нічого (крім -O3), якщо пам'ять слугує мені правильно. Ваше останнє речення, звичайно, є надзвичайно правильним, як і ваші перші п'ять речень. Це не означає, що решта не вірна настільки, оскільки ви дуже сильно вказуєте на важливість регулярного резервного копіювання. +1

— Прифтан

Кілька інструментів є загальними для зворотного проектування виконуваного файлу.

Команда "файл", яка приймає шлях до файлу як перший параметр, щоб ви могли визначити (у більшості випадків) тип вашого виконуваного файлу.
Розбиральники, які показують ТОЧНО, що робить виконуваний файл, але важко їх прочитати тим, хто не пише код складання в цій конкретній архітектурі або має досвід розбирання.
Декомпілятори, такі як Boomerang, Hex-ray та Snowman, можуть забезпечити більшу читабельність, але вони не відновлюють фактичні назви змінних чи синтаксис оригінальної програми, і вони не є на 100% надійними, особливо у випадках, коли інженери, які створили виконуваний файл, тестували ці пакети і намагалися надалі придушити безпеку.
Діаграми або таблиці потоків даних. Я не знаю жодного безкоштовного інструменту, щоб зробити це автоматично, але сценарій Python або Bash над вершиною текстового аналізатора виводу збірки (який може бути записаний у sed або Perl) може бути корисним.
Олівець і папір, вірите чи ні, для викладення потоків та ідей.

У більшості випадків, які я бачив, код потрібно було переписати з нуля, підтримувати як програму мовної збірки або відновити шляхом повторного застосування запитів на зміни до старій версії.

— Дуглас Дазееко
джерело

№1: Правда, хоча і в цьому є свої помилки. №3: Я думаю, це комерційні? Мені просто цікаво академічно (у мене є зайві резервні копії, тому немає потреби в такому типі). # 4: cflow (хоча для використання джерела є деякі, які працюють над бінарними - з деякими застереженнями, звичайно). Там є інші, залежно від того, що ви хочете. Щодо графічного виводу, я не можу допомогти там, оскільки мені не подобається або не потрібен графічний вихід для такого типу речей (я вважаю, що це більше відволікає насправді). № 5: дуже правда. Тут, звичайно, можна також використовувати текстовий файл.

— Прифтан

Те, що ви хочете зробити, називається "декомпілюванням". Там є багато декомпіляторів, і тут не практично їх висвітлювати.

Однак, як загальне зауваження: Перетворення з джерела C у виконуваний машинний код є втратним. Наприклад:

Коментарі незворотно втрачені
Імен змінних немає
Іноді петлі розкручуються для виконання
Функції можуть бути переставлені

Рідко зустрічається код, як писати. Більшість компіляторів сьогодні різко змінить ваш код, щоб оптимізувати його. Отже, коли ви декомпілюєте, компілятор може лише здогадуватися, як повинен був виглядати вихідний код, він не може знати, яким був ваш код, тому що цього немає. Якщо декомпілятор хороший, отриманий код, принаймні, можна буде скласти назад в еквівалентний виконуваний файл, і тоді ви можете почати повільно переробляти його для читання. Але, швидше за все, декомпілятор видасть абсолютно нечитабельний код спагетті, і розшифрувати його буде величезний головний біль. Іноді це може призвести до меншої роботи, щоб просто переписати програму з нуля.

— Багалов
джерело

Що стосується коментарів, те, що я нещодавно помітив, - і я не маю уявлення, чи це дозволить декомпілятору читати коментарі, чи не очікую, що декомпілятори навіть шукають такий тип речей - це: -C Не відкидайте коментарі. Усі коментарі передаються у вихідний файл, за винятком коментарів до оброблених директив, які видаляються разом із директивою. Він підкреслює побічні ефекти, а також параметр -CC (це стосується gcc, хоча, мабуть, замість цього cpp). Не те, що я очікую, що це стосуватиметься ОП, але, можливо, цікавить когось.

— Прифтан