Декомпилятор исходного кода EXE в C [дубликат]

Есть ли какой-нибудь декомпилятор, который может взять файл .exe и декомпилировать его в код C (исполняемый файл также был написан на C)? Очевидно, я не ищу результатов 1: 1 с исходным кодом, но все, что хоть как-то читается, будет удовлетворительным.


2

Как упоминалось выше, IDA является отличным симулятором, но не ожидайте хорошего источника C от скрытого нативного объекта. В целом набор утилит для управления исполняемыми файлами PE весьма ограничен по сравнению с более универсальными и открытыми исполняемыми файлами, такими как ELF. Я был бы больше заинтересован в дизассемблированной сборке, поскольку даже удаленно приемлемый C-код будет невозможен, поскольку выделенные «пользовательские» исполняемые файлы содержат запутанные символы. Я давно не использовал среду Windows, но когда я использовал функции разборки, я использовал декомпилятор Boomerang, который является открытым исходным кодом и бесплатным http://boomerang.sourceforge.net/

Улучшить этот ответ
ответил 17 января 2015, в 4:02
добавить комментарий |

Как упоминалось выше, IDA — отличный ассемблер, но не ждите хорошего источника C от скрытого нативного объекта. В целом набор утилит для управления исполняемыми файлами PE весьма ограничен по сравнению с более универсальными и открытыми исполняемыми файлами, такими как ELF. Я был бы больше заинтересован в дизассемблированной сборке, поскольку даже удаленно приемлемый код C будет невозможен, поскольку выделенные «пользовательские» исполняемые файлы имеют запутанные символы. Я давно не использовал среду Windows, но когда я использовал функции разборки, я использовал декомпилятор Boomerang, который является открытым исходным кодом и бесплатным http://boomerang.sourceforge.net/


1

Существует декомпилятор Hexrays, который представляет собой плагин для интерактивного дизассемблера (hexrays.com ). Он декомпилирует машинный код в код Pseudo-C.

Улучшите этот ответ
ответил 17 янв. в 01:54
добавить комментарий |

Существует декомпилятор Hexrays, плагин для интерактивного дизассемблера (hexrays.com). Декомпилирует машинный код в код Pseudo-C.



преобразовать исполняемый файл обратно в исходный код C

К сожалению, я потерял исходный код, и у меня есть только выходной файл, который сделал с gcc в linux, и у меня сейчас нет доступа к моему компьютеру. есть ли способ преобразовать выходной файл в исходный файл (в c под Linux)?


27

Итак, у вас была корова, но вы случайно превратили ее в гамбургер, и теперь вы хотите вернуть свою корову.

Извините, это просто не работает.

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

Ах, вы не было резервных копий. К сожалению, вселенная не дает вам для этого перерыва.

Вы можете декомпилировать двоичный файл. Это не даст вам исходный код, но даст вам некоторый исходный код с тем же поведением. Вы не получите имена переменных, если это не отладочный двоичный файл. Вы не получите точно такой же логики, если не скомпилируете без оптимизации. Очевидно, вы не получите комментариев.

Я использовал Boomerang для декомпиляции некоторых программ, и результат был более читабельным, чем машинный код. Не знаю, лучший ли это инструмент. В любом случае не ждите чудес.

Улучшите этот ответ
ответил 16 сен. ’15 в 2:07
  • 1
    Бумеранг выглядит довольно аккуратно; позор, что документация ссылается на gcc -O4, так как это абсолютно ничего не делает (кроме -O3), если память мне не изменяет. Ваше последнее предложение, конечно же, чрезвычайно актуально, как и ваши первые пять предложений. Это не значит, что остальное неверно, так как вы очень сильно подчеркиваете важность регулярного резервного копирования. +1 — Pryftan 28 янв. ’18 в 2:16
добавить комментарий |

Итак, у вас была корова, но вы случайно превратили ее в гамбургер и теперь хотите вернуть свою корову.

Извините, это просто не работает.

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

А, у вас не было резервных копий. К сожалению, вселенная не дает вам для этого перерыва.

Вы можете декомпилировать двоичный файл. Это не даст вам исходный код, но даст вам некоторый исходный код с тем же поведением. Вы не получите имена переменных, если это не отладочный двоичный файл. Вы не получите точно такой же логики, если не скомпилируете без оптимизации. Очевидно, вы не получите комментариев.

Я использовал Boomerang для декомпиляции некоторых программ, и результат был более читабельным, чем машинный код. Не знаю, лучший ли это инструмент. В любом случае не ждите чудес.


6

При обратном проектировании исполняемого файла часто используются несколько инструментов.

  1. Команда «файл», которая принимает путь к файлу в качестве первого параметра, чтобы вы могли определить (в большинстве случаев), какой тип исполняемого файла.
  2. Дизассемблеры, которые ТОЧНО показывают, что делает исполняемый файл, но их трудно читать тем, кто не пишет ассемблерный код для этой конкретной архитектуры или имеет опыт дизассемблирования.
  3. Декомпиляторы, такие как Boomerang, Hex-ray и Snowman, могут обеспечить лучшую читаемость, но они не восстанавливают фактические имена переменных или синтаксис исходной программы, и они не на 100% надежны, особенно в тех случаях, когда инженеры, создавшие исполняемый файл, протестированы с эти пакеты и попытались дополнительно скрыть безопасность.
  4. Диаграммы или таблицы потоков данных. Я не знаю бесплатного инструмента, который бы делал это автоматически, но скрипт Python или Bash поверх текстового анализатора вывода сборки (который может быть написан на sed или Perl) может быть полезным.
  5. Карандаш и бумага, хотите верьте, хотите нет, для набросков потоков и идей.

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

Улучшите этот ответ
ответил 21 февраля ’17 в 21:17
  • 2
    # 1: Верно, хотя у него тоже есть свои недостатки. # 3: Я думаю, это коммерческие? Мне просто любопытно с академической точки зрения (у меня есть резервные копии, поэтому в подобных вещах нет необходимости). # 4: на ум приходит cflow (хотя он использует исходный код, некоторые работают с двоичным кодом, конечно, с некоторыми оговорками). Есть и другие, в зависимости от того, что вам нужно. Что касается графического вывода, я не могу здесь помочь, поскольку мне не нравится или не нужен графический вывод для этого типа вещей (на самом деле я считаю, что это больше отвлекает). # 5: очень верно. Конечно, вы также можете использовать текстовый файл. — Pryftan 28 янв. ’18 в 2:06
добавить комментарий |

При обратном проектировании исполняемого файла часто используются несколько инструментов.

  1. Команда «файл» «который принимает путь к файлу в качестве первого параметра, поэтому вы можете определить (в большинстве случаев), какой тип исполняемого файла у вас.
  2. Дизассемблеры, которые ТОЧНО показывают, что делает исполняемый файл, но их трудно читать тем, кто не пишет ассемблерный код для этой конкретной архитектуры или имеет опыт дизассемблирования.
  3. Декомпиляторы, такие как Boomerang, Hex-ray и Snowman, могут обеспечить лучшую читаемость, но они не восстанавливают фактические имена переменных или синтаксис исходной программы, и они не на 100% надежны, особенно в тех случаях, когда инженеры, создавшие исполняемый файл, протестированы с эти пакеты и попытались дополнительно скрыть безопасность.
  4. Диаграммы или таблицы потоков данных. Я не знаю бесплатного инструмента, который бы делал это автоматически, но скрипт Python или Bash поверх текстового анализатора вывода сборки (который может быть написан на sed или Perl) может быть полезным.
  5. Карандаш и бумага, хотите верьте, хотите нет, для набросков потоков и идей.

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


3

То, что вы хотите сделать, называется «декомпиляцией». Существует много декомпиляторов, и описывать их здесь непрактично.

Однако в качестве общего замечания: преобразование исходного кода C в исполняемый машинный код происходит с потерями. Например:

  • Комментарии безвозвратно потеряны
  • Имена переменных пропали
  • Иногда циклы разворачиваются для повышения производительности
  • Функции могут быть переупорядочены

Код редко компилируется так, как написано. Большинство компиляторов в наши дни радикально изменят ваш код, чтобы оптимизировать его. Поэтому, когда вы декомпилируете, компилятор может только догадываться о том, как должен был выглядеть исходный код, он не имеет возможности узнать, каким был ваш код, потому что его больше нет. Если декомпилятор хорош, полученный код будет по крайней мере скомпилирован обратно в эквивалентный исполняемый файл, а затем вы можете начать медленный рефакторинг, чтобы он стал читабельным. Но, скорее всего, декомпилятор выдаст абсолютно нечитаемый спагетти-код, и расшифровать его будет огромной головной болью. Иногда может оказаться меньше работы, чтобы просто переписать программу с нуля.

Улучшите этот ответ
ответил 19 января ’18 в 23:30
  • Что касается комментариев, я недавно заметил кое-что — и я понятия не имею, позволит ли это читать комментарии декомпилятором, и я не ожидаю, что декомпиляторы даже будут искать такие вещи — это: -C Не отбрасывать комментарии. Все комментарии передаются в выходной файл, за исключением комментариев в обработанных директивах, которые удаляются вместе с директивой. Он выделяет побочные эффекты, а также параметр -CC (это для gcc, хотя, вероятно, вместо этого cpp). Не то чтобы я ожидал, что это применимо к OP, но может быть интересно для некоторых. — Pryftan 28 янв. ’18 в 2:27
добавить комментарий |

То, что вы хотите сделать, называется «декомпиляцией». Существует много декомпиляторов, и описывать их здесь непрактично.

Однако в качестве общего замечания: преобразование исходного кода C в исполняемый машинный код происходит с потерями. Например:

  • Комментарии безвозвратно потеряны
  • Имена переменных пропали
  • Иногда циклы разворачиваются для повышения производительности
  • Функции могут быть переупорядочены

Код редко компилируется так, как написано. Большинство компиляторов в наши дни радикально изменят ваш код, чтобы оптимизировать его. Поэтому, когда вы декомпилируете, компилятор может только догадываться о том, как должен был выглядеть исходный код, он не имеет возможности узнать, каким был ваш код, потому что его больше нет. Если декомпилятор хорош, полученный код будет по крайней мере скомпилирован обратно в эквивалентный исполняемый файл, а затем вы можете начать медленный рефакторинг, чтобы он стал читабельным. Но, скорее всего, декомпилятор выдаст абсолютно нечитаемый спагетти-код, и расшифровать его будет огромной головной болью. Иногда может оказаться меньше работы, чтобы просто переписать программу с нуля.

Оцените статью
logicle.ru
Добавить комментарий