Открыть EXE-файл и увидеть его код можно, но результат зависит от того, на чём программа написана: приложения на .NET декомпилируются почти до исходного текста на C#, а нативные программы на C/C++ удаётся восстановить только до уровня ассемблера или приблизительного псевдокода. Поэтому первое действие — определить тип исполняемого файла, и уже потом выбирать инструмент.
В этой статье разберём, как устроен исполняемый файл Windows (формат PE — Portable Executable), какие программы подходят для его разбора, как извлечь ресурсы и строки, и какие ограничения есть у декомпиляции. Отдельно обозначим юридические и безопасные границы: анализ чужого ПО может нарушать лицензионное соглашение, а запуск неизвестного файла — заразить систему.
Что находится внутри EXE-файла
Файл .exe в Windows — это контейнер формата PE, внутри которого лежат заголовки, секции с машинным кодом, данные, таблицы импорта и ресурсы. Исходный код в том виде, в каком его писал программист, в файле не хранится — компилятор уже превратил его в машинные инструкции процессора.
Основные части исполняемого файла:
- 🔹 Заголовки DOS и PE — служебная информация: точка входа, разрядность, список секций.
- 📦 Секция кода (.text) — машинные инструкции, которые выполняет процессор.
- 🗂 Ресурсы (.rsrc) — иконки, диалоги, строки интерфейса, картинки, манифест.
- 🔗 Таблица импорта — список системных библиотек (DLL) и функций, которые программа вызывает.
- 🧩 Метаданные .NET — если программа написана на C# или VB.NET, здесь хранится промежуточный код IL и описание классов.
Шаг 1. Определяем тип файла
Прежде чем запускать дизассемблер, посмотрите, что перед вами. Утилиты вроде Detect It Easy (DIE) или Exeinfo PE показывают компилятор, упаковщик и разрядность файла без его запуска. Это безопасный статический анализ: файл просто читается, но не исполняется.
От результата зависит вся дальнейшая стратегия. Если определился .NET Framework — вам крупно повезло, код восстановится почти полностью. Если указан упаковщик (UPX, Themida, VMProtect) — сначала придётся снимать защитную оболочку, иначе внутри будут бессмысленные данные. Нативный C/C++ без упаковки — средний по сложности вариант.
⚠️ Внимание: никогда не запускайте неизвестный EXE-файл на основной системе «чтобы посмотреть, что он делает». Для динамического анализа используйте виртуальную машину без доступа к личным данным и с отключённой общей сетевой папкой.
Шаг 2. Извлекаем строки и ресурсы
Самый быстрый способ понять назначение программы — посмотреть её строки. Утилита Strings из набора Sysinternals вытаскивает из файла читаемые текстовые фрагменты: пути, сообщения об ошибках, URL, ключи реестра. Часто этого достаточно, чтобы понять логику работы без глубокого анализа кода.
strings.exe program.exe > strings.txtРесурсы — иконки, диалоговые окна, встроенные файлы — удобно открывать через Resource Hacker. Программа показывает дерево ресурсов и позволяет извлечь их по одному. Если EXE — это на самом деле установщик Inno Setup или NSIS, его содержимое распаковывается утилитами innounp или 7-Zip: внутри часто лежат обычные файлы и скрипт установки, который читается как текст.
Шаг 3. Декомпиляция .NET-приложений
Если файл написан на C#, VB.NET или F#, внутри лежит не машинный код, а промежуточный язык IL, из которого исходник восстанавливается с высокой точностью. Откройте файл в dnSpy, ILSpy или dotPeek — вы увидите дерево классов, методов и свойств, а код будет почти идентичен оригиналу, за исключением комментариев и локальных имён переменных.
Через dnSpy можно не только читать, но и редактировать код, а затем сохранять изменённую сборку. Единственное препятствие — обфускация: защитные инструменты переименовывают классы в бессмысленные наборы символов и запутывают логику. В таком случае читать код становится труднее, хотя сам он остаётся доступным.
☑️ Разбор .NET-приложения в dnSpy
Шаг 4. Дизассемблирование нативного кода
С программами на C/C++, Delphi, Rust или Go всё сложнее: компилятор превратил исходник в инструкции процессора, и обратного однозначного преобразования не существует. Дизассемблер переводит байты в ассемблерный листинг, а декомпилятор строит по нему приблизительный псевдокод на C-подобном языке.
Основные инструменты:
| Инструмент | Тип | Что даёт |
|---|---|---|
| Ghidra | Дизассемблер + декомпилятор | Ассемблер и псевдокод C, бесплатный, от NSA |
| IDA Free / IDA Pro | Дизассемблер | Эталонный инструмент анализа, в Pro — декомпилятор Hex-Rays |
| x64dbg | Отладчик | Пошаговое выполнение, просмотр памяти и регистров |
| Cutter / Rizin | Дизассемблер с GUI | Граф вызовов, псевдокод, открытый код |
| PE-bear | PE-анализатор | Структура заголовков, импорты, секции |
Практический порядок работы в Ghidra такой: создайте проект, импортируйте файл, запустите автоанализ с настройками по умолчанию, затем найдите точку входа и двигайтесь по графу вызовов. Окно декомпилятора покажет псевдокод выбранной функции. Имена функций и переменных будут условными (FUN_00401a30), их приходится переименовывать вручную по мере понимания логики — это нормальная часть процесса.
Почему псевдокод не совпадает с оригинальным исходником
Компилятор при сборке выполняет оптимизации: встраивает функции, удаляет неиспользуемый код, меняет порядок вычислений, заменяет умножение сдвигами. Информация об именах переменных и структуре исходных файлов теряется безвозвратно. Декомпилятор восстанавливает логику, а не текст — результат функционально эквивалентен оригиналу, но выглядит иначе.
Шаг 5. Динамический анализ через отладчик
Статический разбор не всегда отвечает на вопрос «что программа делает прямо сейчас». Отладчик x64dbg позволяет запустить файл под контролем: поставить точку останова на нужной функции, посмотреть аргументы, изменить значение регистра или флага условного перехода. Так проверяют, например, логику проверки лицензионного ключа или расшифровку строк во время выполнения.
Для наблюдения за системными вызовами без погружения в код подойдут Process Monitor (файлы, реестр, сеть) и API Monitor. Это более безопасный уровень анализа: вы видите поведение программы целиком, не разбирая каждую инструкцию.
⚠️ Внимание: динамический анализ означает реальный запуск файла. Выполняйте его только в изолированной виртуальной машине со снимком состояния (snapshot), чтобы откатить систему после сеанса.
Юридические ограничения и этика
Декомпиляция чужого ПО регулируется лицензионным соглашением и законодательством конкретной страны. В ряде юрисдикций анализ допускается для обеспечения совместимости или в исследовательских целях, но распространение восстановленного кода, снятие защиты от копирования и использование чужих алгоритмов в коммерческих продуктах — почти всегда нарушение. Перед анализом чужой программы изучите её лицензию.
Безоговорочно легальные сценарии — разбор собственных программ (например, при утере исходников), анализ вредоносного ПО в исследовательских целях, учебная практика на специально созданных crackme-задачах и файлы с открытой лицензией.
⚠️ Внимание: если цель — восстановить исходник собственной утраченной программы, сначала проверьте резервные копии, систему контроля версий и кэш IDE. Восстановление из декомпилированного кода — трудоёмкий последний вариант, а не первый шаг.
Частые вопросы
Можно ли получить исходный код EXE-файла один в один?
Полностью — только для .NET-приложений без обфускации: там код восстанавливается почти дословно, кроме комментариев. Для нативных программ на C/C++ возможен лишь приблизительный псевдокод: имена переменных, структура проекта и комментарии теряются при компиляции безвозвратно.
Чем открыть EXE-файл как архив?
Многие установщики (Inno Setup, NSIS, самораспаковывающиеся архивы) открываются через 7-Zip — правый клик по файлу и пункт «Открыть архив». Для Inno Setup точнее работает утилита innounp, которая извлекает и скрипт установки. Обычная программа архивом не является, и 7-Zip покажет только её ресурсы.
Файл упакован UPX — что делать?
UPX — открытый упаковщик, и оригинальная утилита снимает упаковку командой upx -d file.exe. После распаковки файл анализируется обычными средствами. Коммерческие протекторы (Themida, VMProtect) так просто не снимаются — их снятие требует глубоких навыков и часто нарушает лицензионное соглашение.
Это безопасно — открывать чужой EXE в дизассемблере?
Статический анализ (Ghidra, IDA, dnSpy, просмотр строк) не исполняет файл и безопасен. Опасен только запуск: отладчик, «посмотреть, что делает», двойной клик. Любое исполнение неизвестного файла проводите в виртуальной машине без доступа к личным данным.
Какой инструмент выбрать новичку?
Начните с цепочки: Detect It Easy для определения типа файла, Strings для просмотра текста, Resource Hacker для ресурсов. Затем, в зависимости от результата, — ILSpy для .NET или Ghidra для нативного кода. Эта последовательность не требует запуска файла и покрывает большинство учебных задач.