Ghidra vs. ida pro

6.5.4 elf-расширение директивы COMMON

ELF позволяет задавать требования к выравниванию общих переменных. Это делается
путем помещения числа (которое должно быть степенью двойки) после имени и размера
общей переменной и отделения этого числа (как обычно) двоеточием. Например,
массив двойных слов, который должен быть выровнен по двойным словам:

          common dwordarray 128:4

Эта строка объявляет массив размером 128 байт и требует, чтобы он был выровнен
по 4-байтной границе.

6.6 aout: Объектные файлы
a.out Линукс

Формат aout генерирует объектные файлы a.out
в форме, используемой устаревшими Линукс системами. (Он отличается от других
объектных файлов a.out магическим числом в первых
четырех байтах файла. Также некоторые реализации a.out,
например NetBSD, поддерживают позиционно-независимый код, который реализация
Линукс не знает).

Формат a.out подразумевает расширение выходных
файлов по умолчанию .o.

Этот формат очень простой. Он не поддерживает специальных директив и символов,
не использует SEG или WRT
и в нем нет расширений никаких стандартных директив. Он поддерживает только
три стандартных секции с именами .text, .data и
.bss.

6.7 aoutb: Объектные файлы
a.out NetBSD/FreeBSD/OpenBSD

Формат aoutb генерирует объектные файлы a.out
в форме, используемой различными BSD-клонами UNIX: NetBSD, FreeBSD и OpenBSD.
Для большинства объектных файлов этот формат не отличается от aout
за исключением магического числа в первых четырех байтах файла. Однако формат
поддерживает (как и формат elf) позиционно-независимый
код, поэтому вы можете использовать его для написания разделяемых библиотек
BSD.

Расширение объектных файлов формата aoutb по умолчанию
.o.

Формат не поддерживает специальных директив и символов и имеет только три стандартных
секции с именами .text, .data и .bss.
Несмотря на это, для обеспечения типов перемещений в позиционно-независимом
коде он поддерживает использование WRT так же,
как это делает elf. Более подробно это описано
в .

aoutb, как и elf
поддерживает также расширение директивы GLOBAL:
см. .

6.8 as86: Объектные файлы
as86 Линукс

16-битный ассемблер Линукс as86 имеет свой собственный
нестандартный формат объектных файлов. Хотя его компаньон компоновщик ld86
выдает что-то близкое к обычным бинарникам a.out,
объектный формат, используемый для взаимодействия между as86
и ld86, все же не является a.out.

NASM на всякий случай поддерживает данный формат как as86.
Расширение выходного файла по умолчанию для данного формата .o.

Формат as86 это очень простой объектный
формат (с точки зрения NASM). Он не поддерживает специальных директив и символов,
не использует SEG и WRT,
и в нем нет никаких расширений стандартных директив. Он поддерживает только
три стандартных секции с именами .text, .data и
.bss.

6.9 rdf: Перемещаемые динамические
объектные файлы

Выходной формат rdf создает объектные файлы RDOFF.
RDOFF это «доморощенный» формат объектных файлов, разработанный вместе
с NASM и отражающий в себе внутреннюю структуру ассемблера.

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

Архив Unix NASM и архив DOS с исходниками имеют подкаталог rdoff,
содержащий набор RDOFF-утилит: RDF-компоновщик, менеджер статических библиотек,
утилита, делающая дамп RDF-файла, и программа, загружающая и выполняющая RDF-исполнимый
файл под Линукс.

Формат rdf поддерживает только стандартные секции
с именами .text, .data и .bss.

Язык. Преимущества и отличия от ЯВУ

• знание синтаксиса транслятора ассемблера, который используется (например, синтаксис MASM, FASM и GAS отличается), назначение директив языка ассемблер (операторов, обрабатываемых транслятором во время трансляции исходного текста программы);
• понимание машинных инструкций, выполняемых процессором во время работы программы;
• умение работать с сервисами, предоставляемыми операционной системой — в данном случае это означает знание функций Win32 API. При работе с языками высокого уровня очень часто к API системы программист прямо не обращается; он может даже не подозревать о его существовании, поскольку библиотека языка скрывает от программиста детали, зависящие от конкретной системы. Например, и в Linux, и в Windows, и в любой другой системе в программе на Си/Си++ можно вывести строку на консоль, используя функцию printf() или поток cout, то есть для программиста, использующего эти средства, нет разницы, под какую систему делается программа, хотя реализация этих функций будет разной в разных системах, потому что API систем очень сильно различается. Но если человек пишет на ассемблере, он уже не имеет готовых функций типа printf(), в которых за него продумано, как «общаться» с системой, и должен делать это сам.

Оптимальной

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

языков высокого уровня абстракциисредах быстрого проектирования

Литература

• Вострикова З. П. Программирование на языке ассемблера ЕС ЭВМ. М.: Наука, 1985.
• Галисеев Г. В. Ассемблер для Win 32. Самоучитель. — М.: Диалектика, 2007. — С. 368. — ISBN 978-5-8459-1197-1.
• Зубков С. В. Ассемблер для DOS, Windows и UNIX. — М.: ДМК Пресс, 2006. — С. 608. — ISBN 5-94074-259-9.
• Ирвин Кип. Язык ассемблера для процессоров Intel = Assembly Language for Intel-Based Computers. — М.: Вильямс, 2005. — С. 912. — ISBN 0-13-091013-9.
• Калашников О. А. Ассемблер? Это просто! Учимся программировать. — БХВ-Петербург, 2011. — С. 336. — ISBN 978-5-9775-0591-8.
• Магда Ю. С. Ассемблер. Разработка и оптимизация Windows-приложений. СПб.: БХВ-Петербург, 2003.
• Нортон П., Соухэ Д. Язык ассемблера для IBM PC. М.: Компьютер, 1992.
• Владислав Пирогов. Ассемблер для Windows. — СПб.: БХВ-Петербург, 2002. — 896 с. — ISBN 978-5-9775-0084-5.
• Владислав Пирогов. Ассемблер и дизассемблирование. — СПб.: БХВ-Петербург, 2006. — 464 с. — ISBN 5-94157-677-3.
• Сингер М. Мини-ЭВМ PDP-11: Программирование на языке ассемблера и организация машины. М.: Мир, 1984.
• Скэнлон Л. Персональные ЭВМ IBM PC и XT. Программирование на языке ассемблера. М.: Радио и связь, 1989.
• Юров В., Хорошенко С. Assembler: учебный курс. — СПб.: Питер, 2000. — С. 672. — ISBN 5-314-00047-4.

Как мыслит процессор

Что­бы понять, как рабо­та­ет Ассем­блер и поче­му он рабо­та­ет имен­но так, нам нуж­но немно­го разо­брать­ся с внут­рен­ним устрой­ством про­цес­со­ра.

Кро­ме того, что про­цес­сор уме­ет выпол­нять мате­ма­ти­че­ские опе­ра­ции, ему нуж­но где-то хра­нить про­ме­жу­точ­ные дан­ные и слу­жеб­ную инфор­ма­цию. Для это­го в самом про­цес­со­ре есть спе­ци­аль­ные ячей­ки памя­ти — их назы­ва­ют реги­стра­ми.

Реги­стры быва­ют раз­но­го вида и назна­че­ния: одни слу­жат, что­бы хра­нить инфор­ма­цию; дру­гие сооб­ща­ют о состо­я­нии про­цес­со­ра; тре­тьи исполь­зу­ют­ся как нави­га­то­ры, что­бы про­цес­сор знал, куда идти даль­ше, и так далее. Подроб­нее — в рас­хло­пе ↓

Какими бывают регистры

Обще­го назна­че­ния. Это 8 реги­стров, каж­дый из кото­рых может хра­нить все­го 4 бай­та инфор­ма­ции. Такой регистр мож­но раз­де­лить на 2 или 4 части и рабо­тать с ними как с отдель­ны­ми ячей­ка­ми.

Ука­за­тель команд. В этом реги­стре хра­нит­ся толь­ко адрес сле­ду­ю­щей коман­ды, кото­рую дол­жен выпол­нить про­цес­сор. Вруч­ную его изме­нить нель­зя, но мож­но на него повли­ять раз­лич­ны­ми коман­да­ми пере­хо­дов и про­це­дур.

Регистр фла­гов. Флаг — какое-то свой­ство про­цес­со­ра. Напри­мер, если уста­нов­лен флаг пере­пол­не­ния, зна­чит про­цес­сор полу­чил в ито­ге такое чис­ло, кото­рое не поме­ща­ет­ся в нуж­ную ячей­ку памя­ти. Он туда кла­дёт то, что поме­ща­ет­ся, и ста­вит в этот флаг циф­ру 1. Она — сиг­нал про­грам­ми­сту, что что-то пошло не так.

Фла­гов в про­цес­со­ре мно­го, какие-то мож­но менять вруч­ную, и они будут вли­ять на вычис­ле­ния, а какие-то мож­но про­сто смот­реть и делать выво­ды. Фла­ги — как сиг­наль­ные лам­пы на пане­ли при­бо­ров в само­лё­те. Они что-то озна­ча­ют, но толь­ко само­лёт и пилот зна­ют, что имен­но.

Сег­мент­ные реги­стры. Нуж­ны были для того, что­бы рабо­тать с опе­ра­тив­ной памя­тью и полу­чать доступ к любой ячей­ке. Сей­час такие реги­стры име­ют по 32 бита, и это­го доста­точ­но, что­бы полу­чить 4 гига­бай­та опе­ра­тив­ки. Для про­грам­мы на Ассем­бле­ре это­го обыч­но хва­та­ет.

Так вот: всё, с чем рабо­та­ет Ассем­блер, — это коман­ды про­цес­со­ра, пере­мен­ные и реги­стры.

Здесь нет при­выч­ных типов дан­ных — у нас есть толь­ко бай­ты памя­ти, в кото­рых мож­но хра­нить что угод­но. Даже если вы поме­сти­те в ячей­ку какой-то сим­вол, а потом захо­ти­те рабо­тать с ним как с чис­лом — у вас полу­чит­ся. А вме­сто при­выч­ных цик­лов мож­но про­сто прыг­нуть в нуж­ное место кода.

Архитектура виртуальной машины ассемблера

Ассемблер fasmg (архитектура CALM-инструкций)

Является наследником ассемблера flat assembler (fasm) со схожим синтаксисом, но в отличие от fasm не привязан ни к какой архитектуре процессора. Его парадигмой является формирование посредством макросов выходных файлов любых форматов и с машинным кодом под любые архитектуры процессоров. Помимо макросов в fasmg присутствуют т. наз. CALM-инструкции (букв. «инструкции компилируемой сборки, подобные макросам») — собственные инструкции виртуальной машины ассемблера, эквивалентные макросам, которые преобразуются транслятором в байт-код. Архитектуру этих CALM-инструкций можно считать «родной» архитектурой ассемблера fasmg. В комплекте имеются наборы CALM-инструкций для эмуляции поддержки инструкций архитектур x86, x64, 8052, AVR; разработчиком могут быть описаны наборы CALM-инструкций для поддержки любой другой архитектуры, поддержки любых выходных форматов файлов. Имеются вариации транслятора для Mac OS, Linux и Windows.

Disassembler Issues[edit | edit source]

As we have alluded to before, there are a number of issues and difficulties associated with the disassembly process. The two most important difficulties are the division between code and data, and the loss of text information.

Separating Code from Dataedit | edit source

Since data and instructions are all stored in an executable as binary data, the obvious question arises: how can a disassembler tell code from data? Is any given byte a variable, or part of an instruction?

The problem wouldn’t be as difficult if data were limited to the .data section (segment) of an executable (explained in a later chapter) and if executable code were limited to the .code section of an executable, but this is often not the case. Data may be inserted directly into the code section (e.g. jump address tables, constant strings), and executable code may be stored in the data section (although new systems are working to prevent this for security reasons). AI programs, LISP or Forth compilers may not contain .text and .data sections to help decide, and have code and data interspersed in a single section that is readable, writable and executable, Boot code may even require substantial effort to identify sections. A technique that is often used is to identify the entry point of an executable, and find all code reachable from there, recursively. This is known as «code crawling».

Many interactive disassemblers will give the user the option to render segments of code as either code or data, but non-interactive disassemblers will make the separation automatically. Disassemblers often will provide the instruction AND the corresponding hex data on the same line, shifting the burden for decisions about the nature of the code to the user. Some disassemblers (e.g. ciasdis) will allow you to specify rules about whether to disassemble as data or code and invent label names, based on the content of the object under scrutiny. Scripting your own «crawler» in this way is more efficient; for large programs interactive disassembling may be impractical to the point of being unfeasible.

The general problem of separating code from data in arbitrary executable programs is equivalent to the halting problem. As a consequence, it is not possible to write a disassembler that will correctly separate code and data for all possible input programs. Reverse engineering is full of such theoretical limitations, although by Rice’s theorem all interesting questions about program properties are undecidable (so compilers and many other tools that deal with programs in any form run into such limits as well). In practice a combination of interactive and automatic analysis and perseverance can handle all but programs specifically designed to thwart reverse engineering, like using encryption and decrypting code just prior to use, and moving code around in memory.

Lost Informationedit | edit source

User defined textual identifiers, such as variable names, label names, and macros are removed by the assembly process. They may still be present in generated object files, for use by tools like debuggers and relocating linkers, but the direct connection is lost and re-establishing that connection requires more than a mere disassembler. Especially small constants may have more than one possible name. Operating system calls (like DLLs in MS-Windows, or syscalls in Unices) may be reconstructed, as their names appear in a separate segment or are known beforehand. Many disassemblers allow the user to attach a name to a label or constant based on his understanding of the code.
These identifiers, in addition to comments in the source file, help to make the code more readable to a human, and can also shed some clues on the purpose of the code. Without these comments and identifiers, it is harder to understand the purpose of the source code, and it can be difficult to determine the algorithm being used by that code. When you combine this problem with the possibility that the code you are trying to read may, in reality, be data (as outlined above), then it can be even harder to determine what is going on. Another challenge is posed by modern optimising compilers; they inline small subroutines, then combine instructions over call and return boundaries. This loses valuable information about the way the program is structured.

Начальное исследование прошивки

Кратко: на этом этапе выполняется предварительный анализ прошивки. Просмотр строк. Загрузка прошивки в IDA Pro.strings

а вы их увидели?STM32F042x4 STM32F042x6Processor TypeARM Little endianManual loadDo you want to change the processor type0x08000000 – 0x08008000Loading address = 0x08000000ARM and Thumb mode switching instructionsокно строк

Примечание для начинающих

Любая программа/прошивка представляет собой набор двоичных данных. IDA Pro может по-разному интерпретировать эти данные исходного файла (представлять данные в виде команд или данных в том или ином формате). При этом тут нет кнопки «Назад» (Ctrl+Z), чтобы отменить выбранное отображение — нужно знать, как переключаться между разными режимами отображения. (Шпаргалка по горячим клавишам IDA Pro)
Реверс-инженер из кажущегося хаоса двоичных данных восстанавливает логику, структуру и читаемость.

Строки – важная информация при реверсе! Так как, по сути, среди всего набора двоичных данных являются наиболее просто и быстро воспринимаются человеком. Строки позволяют делать выводы о назначении функций, переменных и блоков кода.

Именуй просмотренные функции! По умолчанию, IDA даёт функциям имена по их стартовым адресам. При анализе держать в голове эти адреса весьма сложно, гораздо проще пользоваться осмысленными именами

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

Именуй распознанные переменные! Для того чтобы эффективнее проводить анализ блоков кода и функций, имеет смысл именовать переменные, которые распознала IDA, в соответствии с их назначением (всё, как в лучших практиках программирования).

Оставляй комментарии, чтобы не забыть важное. По аналогии с программированием, комментарии при реверсе позволяют дополнительно пояснять логику работы программы или отдельных её участков.
По возможности создавай структуры! IDA в своём арсенале имеет средство работы со структурами, имеет смысл освоить это средство и применять его при необходимости

При наличии структур исследуемый код станет еще проще для восприятия.

Архитектуры RISC

MCS-51

MCS-51 (Intel 8051) — классическая архитектура микроконтроллера. Для неё существует кросс-ассемблер ASM51, выпущенный корпорацией MetaLink.

Кроме того, многие фирмы-разработчики программного обеспечения, такие, как IAR или Keil, представили свои варианты ассемблеров. В ряде случаев применение этих ассемблеров оказывается более эффективным благодаря удобному набору директив и наличию среды программирования, объединяющей в себе профессиональный ассемблер и язык программирования Си, отладчик и менеджер программных проектов.

AVR

На данный момент для AVR существуют 4 компилятора производства Atmel (AVRStudio 3, AVRStudio 4, AVRStudio 5 и AVRStudio 6, AVRStudio 7).

В рамках проекта AVR-GCC (он же WinAVR) существует компилятор avr-as (это портированный под AVR ассемблер GNU as из GCC).

Также существует свободный минималистический компилятор avra.

Платные компиляторы: IAR (EWAVR), CodeVisionAVR, Imagecraft. Данные компиляторы поддерживают языки Assembler и C, а IAR ещё и C++.

Существует компилятор с языка BASIC — BASCOM, также платный.

ARM

PIC

Средой разработки, выпускаемой компанией Microchip Technology для создания, редактирования и отладки программ для микроконтроллеров семейства PIC, является MPLAB. Среда включает в себя трансляторы с языка ассемблер MPASM и ASM30 для различных семейств микроконтроллеров PIC. Современные версии среды «MPLAB X IDE» являются мультиплатформенными и работают под различными операционными системами для ЭВМ. Среда распространяется бесплатно.

Parameters

The following options are available for .exe, .dll, .obj, .lib, and .winmd files.

The following additional options are available for .exe, .dll, and .winmd files.

The following options are valid for .exe, .dll, and .winmd files for file or console output only.

The following options are valid for .exe, .dll, .obj, .lib, and .winmd files for file or console output only.

The following options are valid for .lib files for file or console output only.

Note

All options for Ildasm.exe are case-insensitive and recognized by the first three letters. For example, /quo is equivalent to /quoteallnames. Options that specify arguments accept either a colon (:) or an equal sign (=) as the separator between the option and the argument. For example, /output: filename is equivalent to /output= filename.

Примеры дизассемблеров

Дизассемблер может быть автономным или интерактивным. Автономный дизассемблер при запуске генерирует файл на ассемблере, который можно исследовать; интерактивный показывает эффект любого изменения, которое пользователь делает немедленно. Например, дизассемблер может изначально не знать, что часть программы на самом деле является кодом, и рассматривать его как данные; если пользователь указывает, что это код, получившийся дизассемблированный код отображается немедленно, что позволяет пользователю изучить его и предпринять дальнейшие действия во время того же запуска.

Любой интерактивный отладчик будет включать некоторый способ просмотра дизассемблера отлаживаемой программы. Часто один и тот же инструмент дизассемблирования будет упакован как автономный дизассемблер, распространяемый вместе с отладчиком. Например, objdump, часть GNU Binutils, относится к интерактивному отладчику GDB.

• Бинарный ниндзя
• ОТЛАЖИВАТЬ
• Интерактивный дизассемблер (ИДА)
• Гидра
• Hiew
• Дизассемблер бункера
• Netwide Disassembler (Ndisasm), спутник Сетевой ассемблер (НАСМ).
• ОЛИВЕР (CICS интерактивный тест / отладка) включает дизассемблеры для Ассемблера, КОБОЛ, и PL / 1
• OllyDbg это 32-битный отладчик, анализирующий уровень ассемблера
• Radare2
• SIMON (пакетное интерактивное тестирование / отладка) включает дизассемблеры для Assembler, COBOL и PL / 1.
• Sourcer, комментирующий 16-битный / 32-битный дизассемблер для ДОС, OS / 2 и Windows к V Связь в 1990-е годы

Анализ строк

Кратко: Анализ строк может помочь составить примерный план исследования двоичного файла.

• Операционная система – FreeRTOS;
• Наличие форматных строк – скорее всего используются printf-подобные функции, можно будет установить назначение регистров/переменных;
• Названия задач (тасков) – можно предположить назначение этих самых тасков и связанных с ними функций;
• Использование AT-команд – предположительно так строится взаимодействие микроконтроллера и Bluetooth-модуля.

Далеко не всегда всё так радужно при анализе прошивок – строк и debug-информации может не быть совсем или они малоинформативны, но при создании прошивки мы намеренно не стали усложнять процесс обратной разработки.

Подытожим…

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

1. Создание загрузчиков, прошивок устройств (комплектующих ПК, встраиваемых систем), элементов ядра ОС.

2. Низкоуровневая работа с железом, в т.ч. с процессором, памятью.

3. Внедрение кода в процессы (injection), как с вредоносной целью, так и с целью защиты или добавления функционала. Системный софт.

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

5. Оптимизация кода по скорости, в т.ч. векторизация (SSE, AVX, FMA), математические вычисления, обработка мультимедиа, копирование памяти.

6. Оптимизация кода по размеру, где нужно контролировать каждый байт. Например, в демосцене.

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

8. При создании компиляторов и трансляторов исходного кода с какого-либо языка на язык ассемблера (например, многие компиляторы C/C++ позволяют выполнять такую трансляцию). При создании отладчиков, дизассемблеров.

9. Собственно, отладка, дизассемблирование, исследование программ (reverse engineering).

10. Создание файлов данных с помощью макросов и директив генерации данных.

11. Вы не поверите, но ассемблер можно использовать и для написания обычного прикладного ПО (консольного или с графическим интерфейсом – GUI), игр, драйверов и библиотек 🙂

Decompilers[edit | edit source]

Akin to Disassembly, Decompilers take the process a step further and actually try to reproduce the code in a high level language. Frequently, this high level language is C, because C is simple and primitive enough to facilitate the decompilation process. Decompilation does have its drawbacks, because lots of data and readability constructs are lost during the original compilation process, and they cannot be reproduced. Since the science of decompilation is still young, and results are «good» but not «great», this page will limit itself to a listing of decompilers, and a general (but brief) discussion of the possibilities of decompilation.

Decompilation: Is It Possible?edit | edit source

In the face of optimizing compilers, it is not uncommon to be asked «Is decompilation even possible?» To some degree, it usually is. Make no mistake, however: an optimizing compiler results in the irretrievable loss of information. An example is in-lining, as explained above, where code called is combined with its surroundings, such that the places where the original subroutine is called cannot even be identified. An optimizer that reverses that process is comparable to an artificial intelligence program that recreates a poem in a different language. So perfectly operational decompilers are a long way off. At most, current Decompilers can be used as simply an aid for the reverse engineering process leaving lots of arduous work.

Common Decompilersedit | edit source

Hex-Rays Decompiler

Hex-Rays is a commercial decompiler. It is made as an extension to popular IDA-Pro disassembler. It is currently the only viable commercially available decompiler which produces usable results. It supports both x86 and ARM architecture.

ILSpy

ILSpy is an open source .NET assembly browser and decompiler.

DCC

RetDec

The Retargetable Decompiler is a freeware web decompiler that takes in ELF/PE/COFF binaries in Intel x86, ARM, MIPS, PIC32, and PowerPC architectures and outputs C or Python-like code, plus flow charts and control flow graphs. It puts a running time limit on each decompilation. It produces nice results in most cases.

Reko

a modular open-source decompiler supporting both an interactive GUI and a command-line interface. Its pluggable design supports decompilation of a variety of executable formats and processor architectures (8- , 16- , 32- and 64-bit architectures as of 2015). It also supports running unpacking scripts before actual decompilation. It performs global data and type analyses of the binary and yields its results in a subset of C++.

C4Decompiler

C4Decompiler is an interactive, static decompiler under development (Alpha in 2013). It performs global analysis of the binary and presents the resulting C source in a Windows GUI. Context menus support navigation, properties, cross references, C/Asm mixed view and manipulation of the decompile context (function ABI).

Boomerang Decompiler Project

Boomerang Decompiler is an attempt to make a powerful, retargetable decompiler. So far, it only decompiles into C with moderate success.

Reverse Engineering Compiler (REC)

REC is a powerful «decompiler» that decompiles native assembly code into a C-like code representation. The code is half-way between assembly and C, but it is much more readable than the pure assembly is. Unfortunately the program appears to be rather unstable.

ExeToC

ExeToC decompiler is an interactive decompiler that boasted pretty good results in the past.

snowman

Snowman is an open source native code to C/C++ decompiler. Supports ARM, x86, and x86-64 architectures. Reads ELF, Mach-O, and PE file formats. Reconstructs functions, their names and arguments, local and global variables, expressions, integer, pointer and structural types, all types of control-flow structures, including switch. Has a nice graphical user interface with one-click navigation between the assembler code and the reconstructed program. Has a command-line interface for batch processing.

Ghidra

Ghidra is a reverse engineering package that includes a decompiler. It was written by the NSA for internal work, and apparently released because they didn’t want to have to re-train every new person they hired. It is written in Java.

Оговорочки

Хочу сразу оговориться, что правильно говорить не «ассемблер» (assembler), а «язык ассемблера» (assembly language), потому как ассемблер – это транслятор кода на языке ассемблера (т.е. по сути, программа MASM, TASM, fasm, NASM, UASM, GAS и пр., которая компилирует исходный текст на языке ассемблера в объектный или исполняемый файл). Тем не менее, из соображения краткости многие, говоря «ассемблер» (асм, asm), подразумевают именно «язык ассемблера».

Синтаксис директив, стандартных макросов и пр. структурных элементов различных диалектов (к примеру, MASM, fasm, NASM, GAS), могут отличаться довольно существенно. Мнемоники (имена) инструкций (команд) и регистров, а также синтаксис их написания для одного и того же процессора примерно одинаковы почти во всех диалектах (заметным исключением среди популярных ассемблеров является разве что GAS (GNU Assembler) в режиме синтаксиса AT&T для x86, где к именам инструкций могут добавляться суффиксы, обозначающие размер обрабатываемых ими данных, что бывает довольно удобно, но там есть и другие нюансы, сбивающие с толку программиста, привыкшего к классическому ассемблеру, к примеру, иной порядок указания операндов, хотя всё это лечится специальной директивой переключения в режим классического синтаксиса Intel).

Поскольку ассемблер – самый низкоуровневый язык программирования, довольно проблематично написать код, который корректно компилировался бы для разных архитектур процессоров (например, x86 и ARM), для разных режимов одного и того же процессора (16-битный реальный режим, 32-битный защищённый режим, 64-битный long mode; а ещё код может быть написан как с использованием различных технологий вроде SSE, AVX, FMA, BMI и AES-NI, так и без них) и для разных операционных систем (Windows, Linux, MS-DOS). Хоть иногда и можно встретить «универсальный» код (например, отдельные библиотеки), скажем, для 32- и 64-битного кода ОС Windows (или даже для Windows и Linux), но это бывает нечасто. Ведь каждая строка кода на ассемблере (не считая управляющих директив, макросов и тому подобного) – это отдельная инструкция, которая пишется для конкретного процессора и ОС, и сделать кроссплатформенный вариант можно только с помощью макросов и условных директив препроцессора, получая в итоге порой весьма нетривиальные конструкции, сложные для понимания.