чем декомпилировать exe файл
Что значит декомпилировать файл и как декомпилируются файлы exe
Декомпиляция — это процесс восстановления исходного кода программы из машинного кода. Декомпилятор — это программа, которая может совершить процесс декомпиляции. Декомпилятор может быть разным:
Декомпиляция — это любимый процесс хакеров, хотя в некоторых случаях этот процесс помогает и с хорошими намерениями. Пока звучит как непонятная «каша», но давайте разбираться во всем по порядку.
Компиляция и декомпиляция — это противоположные процессы
Декомпиляция — это обратный процесс компиляции, также его называют «обратная разработка» или «реверс-инженерия». Суть ее сводится к простому — восстановить исходный код программы. Причем «хорошего» в этом процессе мало. Очень редко декомпиляцию применяют в добрых целях, например, чтобы восстановить исходники. Декомпи ля ция не восстанавливает исходники, а лишь предоставляет общую и запутанную структуру, в которой бывает очень трудно разобраться. Причем при декомпиляции прослеживается важная зависимость — чем сложнее и больше программа, тем менее точным будет конечный результат. Плю с и ногда разработчики применя ю т метод обфу ск аци и ( запутывания) исходного кода, тогда после декомпиляции такой программы исходный код практически не читаем.
Так для чего тогда нужна декомпиляция? Получить двоичный код программы может любой, а получить ее исходники — это уже проблема. Но бывают случаи, когда без исходников невозможно осуществить какое-либо действие с программой, например:
полностью скопировать программу или какой-то отдельный ее функционал;
взломать программ у б ез понимания ее структуры и архитектуры;
внедрить вирус в программ у б ез понимания того, как построена программа;
чтобы «обойти» лицензию или вообще отключить проверку лицензии;
В основном декомпиляция нужна для «серых» целей, поэтому реверс-инженерия в некоторых странах наказуема законом. А декомпиляция — это важная часть реверс-инженерии, хотя очень часто эти два понятия считают идентичными.
Декомпилятор ехе
VB Decompiler. Это самый популярны й декомпилятор ехе. Он ориентирован на декомпиляцию ехе-файлов, которые были разработаны при помощи языка программирования Visual Basic. Полностью бесплатный декомпилятор ехе.
EMS Source Rescuer. Это тоже бесплатная программа, но она ориентирована на ехе-файлы, которые были созданы при помощи языков программирования Delphi или С++.
ReFox. На нем отлично проходит декомпиляция ехе, если декомпилируемый файл был создан при помощи Visual FoxPro или FoxBase. Условно-бесплатная программ а с небольшим бесплатным периодом, далее придется платить.
DeDe. Отличный декомпилятор ехе, но работает только с языком программирования Delphi.
IDA Pro. Это профессиональный комплекс инструментов для полноценной реверс-инженерии. Среди прочих инструментов легко найти декомпилятор ехе. Однако у этой программы есть один минус — она очень дорогая с неадекватно завышенными ценами. Поэтому выхода два: на официальном сайте попробовать бесплатную демо-версию и решить свою проблему или тщательно поискать слитую в свободный доступ нужную версию программы — такие тоже имеются. Есть и третий выход — купить лицензию, но тогда будьте готовы заплатить за нее от 900 и до 4000$.
Заключение
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Декомпиляция EXE-файлов
Процесс декомпиляции отвечает за воссоздание исходного кода программы на языке или языках, на которых та была написана. В случае с большими программами, они имеют несколько файлов, в каждом из которых может использоваться несколько языков программирования. Чтобы они корректно взаимодействовали друг с другом и не вводили пользователя в тупик, их помещают в EXE-файл. Как раз этот процесс и называется компиляцией. Мы же рассмотрим, как разобрать EXE-файл на отдельные составляющие.
Как декомпилировать EXE-файл
К сожалению, Windows не предусматривает в своем инструментарии встроенных инструментов, позволяющих выполнить декомпиляцию, поэтому придется пользоваться только сторонним ПО. Такое ПО может быть полезно как пользователям, которые просто желают получше изучить исходный код той или иной программы, так и разработчикам.
Вариант 1: VB Decompiler
Корректно способен провести декомпиляцию EXE-файлов, написанных и скомпилированных через Visual Basic 5.0 и 6.0. Это самая популярная среда разработки программ для Windows. Сама программа полностью бесплатна и занимает на диске всего несколько мегабайт.
Вариант 2: EMS Source Rescuer
Данный декомпилятор корректно работает с файлами, скомпилированными с помощью Delphi и C++ Builder. Работа с другими компиляторами возможна, но официально не поддерживается, поэтому есть риски. Программа распространяется полностью бесплатно.
Вариант 3: ReFox
ReFox отлично зарекомендовал себя в декомпиляции проектов, созданных через Visual FoxPro и FoxBASE+. Сама программа носит условно-бесплатный характер использования. Есть демонстрационная версия, использование которой бесплатно, но только определенный период времени.
Инструкция по использованию данной программы выглядит так:
Вариант 4: DeDe
Эта программа для декомпиляции не так функциональна и поддерживает только одни язык – Delphi.
Представленные декомпиляторы способы выполнить обратное преобразование большинства EXE-файлов, написанных на разных языках программирования. Как видите, в самом процессе, вне зависимости от выбранной программы, нет ничего сложного.
Обзор декомпиляторов
Статья первоначально писалась для журнала СПЕЦ Xakep. И вышла в апрельском номере прошлого года, потому заранее извиняюсь за немного устаревшие данные. К примеру P32Dasm на данный момент уже довольно стабилен, а в VB Decompiler уже добавлено с того времени столько возможностей, что он является самым продвинутым средством для декомпиляции программ, написанных на Visual Basic.
Методика восстановления исходного кода
Как часто у Вы бывало такое, когда теряются исходники одной из разработок без возможности восстановления? Вот бы перевести EXE файл обратно в исходный код, да? Но знакомые либо не могут ничем помочь, либо называют данную идею полнейшим бредом. Конечно, того что Вы написал в своей программе с точностью до байта уже не восстановить, но частично восстановить исходный код из EXE все же можно. Об этом и пойдет речь в данной статье.
Взять данный декомпилятор можно отсюда: www.ems-hitech.com
REC by Giampiero Caprino
Это нормально. И поверте, лучше уж исследовать это, чем:
Хотя кому как. Некоторые знают ассемблер даже лучше чем ненормативную лексику.
Смею еще Вас предупредить, что программа пока работает не очень стабильно, по крайней мере версия 1.4. Потому остается только пожелать проекту его дальнейшее развитие, так как программа нужная и думаю пригодится не только исследователям, но и разработчикам.
.NET Reflector by Lutz Roeder
За программой и ее обновлениями не забудьте зайти на сайт www.aisto.com/roeder/dotnet
DJ Java Decompiler
А это уже декомпилятор Java классов. Довольно удобен и прост в использовании. открываешь в нем класс и уже созерцаешь исходник. Имеется довольно мощная подсветка синтаксиса, поиск и настройки. Также есть браузер классов и объектов. В общем довольно мощный и интересный декомпилятор. Жаль только EXE файлы написанные на Java не декомпилирует.
Программу можно скачать отсюда: members.fortunecity.com/neshkov/dj.html
ReFox by Jan Brebera
Декомпиляторы Visual Basic’а
Саму программу можно найти тут: www.vbrezq.com
VB Editor by HEXMAN
Саму программу можно найти тут: www.multimania.com/hexman
VBReFormer by Sylvain Bruyere
Если Программа приглянулась, то Trial версию можешь взять здесь: www.decompiler-vb.tk
Скачать можно с www.raceco.us
Скачать можно отсюда: progress-tools.x10.mx/p32dasm.html
Semi VB Decompiler by vbgamer45
Актуальная версия находится тут: github.com/VBGAMER45/Semi-VB-Decompiler
VB Decompiler by DotFix Software
HexRaysPyTools: декомпилируй с удовольствием
В этой статье я собираюсь рассказать о плагине для IDA Pro, который написал прошлым летом, еще находясь на стажировке в нашей компании. В итоге, плагин был представлен на ZeroNights 2016 (Слайды), и с тех пор в нём было исправлено несколько багов и добавлены новые фичи. Хотя на GitHub я постарался описать его как можно подробнее, обычно коллеги и знакомые начинают пользоваться им только после проведения небольшого воркшопа. Кроме того, опущены некоторые детали внутренней работы, которые позволили бы лучше понять и использовать возможности плагина. Поэтому хотелось бы попытаться на примере объяснить, как с ним работать, а также рассказать о некоторых проблемах и тонкостях.
HexRaysPyTools, как можно догадаться из названия, предназначен для улучшения работы декомпилятора Hex-Rays Decompiler. Декомпилятор, создавая псевдо-С код, существенно облегчает работу ревёрсера. Основым его достоинством, выделяющим инструмент на фоне других, является возможность трансформировать код, приводя его к удобному и понятному виду, в отличие от ассемблерного кода, который, даже при самом лучшем сопровождении, требует некоторой доли внимания и сосредоточенности для понимания его работы. У Hex-Rays Decompiler, как и самой IDA Pro, есть API, позволяющий писать расширения и выходить за рамки стандартного функционала. И хотя API очень широк, и в теории позволяет удовлетворить самые изысканные потребности разработчика дополнений, у него есть несколько существенных недостатков, а именно:
Чтобы разобраться во всем этом, помогали рабочие примеры, собранные в Интернете (что-то интересное нашлось даже в китайском сегменте). Так что теперь, если кто-то захочет создать что-то своё для декомпилятора, можно обратиться еще и к исходным кодам моего плагина.
Перейдем к описанию плагина. В HexRaysPyTools можно выделить две отдельные категории — это помощь по трансформации дефолтного вывода Hex-Rays Decompiler к удобному виду и реконструкция структур и классов.
Работа с кодом
Изначально, после запуска декомпилятора клавишей F5, IDA Pro выдаёт не очень понятый код, состоящий преимущественно из стандартных типов и имён переменных. И несмотря на то, что местами пытается угадать типы, создать массивы или назвать эти переменные (которым повезло оказаться аргументами у стандартных функций), получается это не очень хорошо. В целом, задача ревёрсера — привести в адекватный вид декомпилированный код. К сожалению, есть вещи, которые невозможно сделать, не прибегая к IDA SDK. Например, отрицательные обращения к полям структур, которые всегда выглядят безобразно (порой превращаясь в массивы с отрицательными индексами), а также длинные условные вложения, тянущиеся из левого верхнего угла в правый нижний. Кроме этого, очень не хватает горячих клавиш и опций для более быстрой трансформации кода. По мере получения информации в процессе анализа программы приходится изменять сигнатуры функций, переименовывать переменные и изменять типы. Всё это требует большого количества манипуляций мышкой и копирований-вставок. Перейдем к описанию того, что предлагает плагин для решения этих проблем.
Отрицательные смещения
Очень часто встречаются при реверсинге драйверов или ядра Windows или модулей ядра Linux. Например, несколько разных структур может быть расположено в двусвязном списке с использованием структуры LIST_ENTRY. При этом у каждой структуры обращение к двусвязному списку может производиться из произвольного поля.
В результате, когда мы смотрим на то, что получается в IDA Pro, видим следующую картину:
Такой вывод будет всякий раз, когда в исходных кодах программ используются макросы CONTIAINING_RECORD (windows) и container_of (linux). Эти макросы возвращают указатель на начало структуры по её типу, адресу и названию поля. И именно их плагин позволяет вставлять в дизассемблер. Вот как выглядит пример после его применения:
Еще с отрицательными смещениями можно встретиться при множественном наследовании, но это довольно изысканный пример, он редко встречается на практике.
Для того, чтобы вставить макрос в дизассемблер, нужно, чтобы подходящая в данном контексте структура существовала в Local Types или в одной из библиотек в Types Library (их может быть несколько). Мы кликаем по вложенной структуре правой кнопкой и выбираем Select Containing Structure. Далее определяем, где искать структуру, — либо в Local Types, либо в Types Library, и плагин составляет список подходящих структур. Для этого он анализирует, как указанная переменная используется в коде и определяет минимальную и максимальную границы, в которых может находиться поле типа этой переменной. Затем, используя эти сведения, проходит по всем структурам, содержащим поле, у которых все в порядке с границей. При поиске плагин смотрит вложенные структуры и объединения на любую глубину.
В примере выше у exe-файла есть символы, поэтому список подходящих структур получился довольно большой:
Помимо этого, существует ситуация, когда плагин автоматически может вставить макрос. Дело в том, что если есть явное присвоение указателя, IDA Pro догадывается (иногда неправильно) его вставить, но не распространяет его дальше в коде.
HexRays – декомпилятор нового поколения: превращаем любой бинарник в C-код
Содержание статьи
Начинающие реверсеры, еще не познавшие все прелести чистого ассемблера, постоянно спрашивают на хакерских форумах, где бы им раздобыть
декомпилятор для Си или Паскаля. Декомпиляторов-то много, но вот результат. без дизассемблера все равно ну никак не обойтись. И вот, наконец, свершилось!
Ильфак (автор легендарного дизассемблера IDA Pro) выпустил декомпилятор нового поколения
HexRays, делающий то, что другим не под силу. Мир вздрогнул от восторга (реклама вообще обещала чудо), порождая сейсмические волны впечатлений: от оргазма до полного отвращения. Истина же, как водится, где-то посередине, и стоит обозначить эту середину, рассмотрев слабые и сильные стороны
декомпилятора, а также
области его применения.
Почему у Ильфака получилось то, что упорно не желало получаться у других? Начнем с того, что
HexRay представляет собой всего лишь плагин к IDA Pro — интерактивному дизассемблеру более чем с десятилетней историей, первая версия которой увидела свет 6 мая 1991 года. Спустя некоторое время к работе над ней подключился удивительный человек, гениальный программист и необычайно креативный кодер Юрий Харон. Вместе с Ильфаком (не без помощи других талантливых парней, конечно) они начали работать в том направлении, куда еще никто не вкладывал деньги. До этого дизассемблеры писались исключительно на пионерском энтузиазме параллельно с изучением ассемблера и довольно быстро забрасывались. Ильфак и
Юрий Харон решили рискнуть. В итоге IDA Pro стал не только основным, но и, пожалуй, единственным продуктом фирмы
DataRescue (мелкие утилиты и прочие ответвления не в счет). Стоит ли удивляться, что парням удалось решить практически все фундаментальные проблемы дизассемблирования, над которыми просто не хотели работать остальные разработчики, зная, что быстрой отдачи не будет и проект потребует десятилетий упорного труда. Самое время выяснить, что же это за проблемы такие, откуда они берутся и как решаются.
Фундаментальные проблемы декомпиляции
Компиляция — процесс однонаправленный и необратимый, в ходе которого теряется огромное количество лишней информации, совершенно ненужной процессору. Это не шутка! Исходный текст, написанный на языке высокого уровня, чрезвычайно избыточен, что с одной стороны упрощает его понимание, а с другой — страхует программиста от ошибок. Взять хотя бы информацию о типах. На низком уровне процессор оперирует базовыми типами: байт, слово, двойное слово. Строки превращаются в последовательности байтов, и, чтобы догадаться, что это строка, приходится прибегать к эвристическим алгоритмам.
Структуры и классы также «расщепляются» в ходе компиляции, и, за исключением некоторых виртуальных функций, все остальные члены класса теряют свою кастовую принадлежность, становясь глобальными процедурами. Восстановить иерархию классов в общем случае невозможно, а в принципе не сильно и нужно.
Никто из здравомыслящих людей не требует от декомпилятора получения даже приближенной копии исходного кода, но мы вправе рассчитывать на удобочитаемость листинга, а также на то, что повторная компиляция не развалит программу, а создаст вполне работоспособный модуль — тогда мы сможем вносить любые изменения в
декомпилированный текст, развивая его в нужном нам направлении. В противном случае такому
декомпилятору место на свалке, и фиксить баги декомпиляции ничуть не проще, чем переписывать подопытную программу с нуля.
Декомпиляции препятствует ряд серьезных проблем, важнейшие из которых перечислены ниже.
Что в имени твоем
Комментарии, имена функций и переменных в процессе компиляции теряются безвозвратно (исключение составляют динамические типы, имена которых в двоичном модуле хранятся как есть, а потому и тормозят, словно динозавры). Ну, комментариев в большинстве исходных текстов и так негусто, так что их отсутствие еще можно пережить, но вот без имен переменных и функций логика работы даже простейших программ становится совершенно непонятной.
К счастью, современные программы наполовину (а то и более) состоят из библиотечных и API-функций, которые распознаются классическим сигнатурным поиском. Главное — собрать обширную базу библиотек всех популярных (и непопулярных) компиляторов с учетом многообразия их версий.
IDA Pro уже давно поддерживает технологию FLIRT (Fast Library Identification and Recognition Technology), не только распознающую библиотечные функции, но также восстанавливающую их прототипы вместе с прототипами API-функций, которые, кстати говоря, могут импортироваться не только по имени, но еще и по ординалу, то есть по номеру. Чтобы превратить бессловесный номер в имя, понятное человеку, опять-таки требуется база.
Почему реконструкция прототипов так важна для декомпилятора? А потому, что она позволяет восстанавливать типы передаваемых функциями переменных, назначая им хоть и обезличенные, но все же осмысленные имена в стиле: hWnd, hModule, X, Y, nWidth, nHeight, hCursor, hMenu, hDlg. Согласись, это намного лучше, чем dword_1008030, dword_1008269, dword_1006933, что характерно для подавляющего большинства остальных
декомпиляторов.
Даже если часть переменных распознана, то это уже упрощает анализ программы и реконструкцию оставшихся переменных.
Константа или смещения
В силу архитектурных особенностей x86-процессоров константы и смещения (они же в терминах языков высокого уровня указатели) синтаксически абсолютно неразличимы, и
декомпилятору (равно как и дизассемблеру) приходится задействовать мощные эвристические алгоритмы, чтобы не попасть впросак.
А какая между этими двумя сущностями разница? Очень большая! Вот, например, в регистр EAX загружается число 106996h. Если это указатель на ячейку памяти или массив данных, то дизассемблер должен воткнуть по этому адресу метку (label) и написать MOV EAX, _offset_ lab_106996 (естественно, имя метки дано условно, и совпадение с ее численным значением абсолютно случайно — при повторной компиляции она может оказаться расположенной по совершенно другому адресу). А вот если 106996h — это константа, выражающая, например, среднюю плотность тушканчиков на один квадратный метр лесополосы или количество полигонов на морде монстра, то ставить offset ни в коем случае нельзя, поскольку это введет нас в
заблуждение при анализе, а еще, как уже говорилось, при повторной компиляции смещение может уплыть, превращая число 106996h черт знает во что. Программа либо будет работать неправильно, либо сразу рухнет (особенно, если путаница между константами и смещениями происходит не единожды, а совершается на протяжении всего листинга).
Так как же все-таки определить, кто есть кто? На первый взгляд, все достаточно просто. Если данная сущность используется как указатель (то есть через нее происходит обращение к памяти по заданному адресу: mov eax, 106996h/mov ebx,[eax]), тут и
дизассемблеру ясно, что это смещение. Но стоит лишь немного усложнить пример, скажем, передать 106996h какой-нибудь функции или начать производить с ней сложные манипуляции, то дизассемблеру потребуется высадиться на полную реконструкцию всей цепочки преобразований. Но даже тогда его решение может оказаться неверным, поскольку в языке Си индексы (то есть константы) и указатели (то есть смещения) полностью взаимозаменяемы и конструкция buf[69] не
только равносильна 69[buf], но и транслируется в идентичный машинный код, при реконструкции которого возникает очевидная проблема.
У нас есть два числа A и B, сумма которых представляет указатель (то есть существует возможность определить, что это указатель, да и то если попыхтеть), но вот что из них индекс? Увы. Формальная математика не дает ответа на этот вопрос, и дизассемблеру приходится полагаться лишь на свою интуицию да эвристику. Указатели в win32, как правило, велики, поскольку минимальный базовый адрес загрузки файла равен 100000h. Индексы же, как правило (опять! как правило!), малы и много меньше указателей, однако если у нас имеется массив, расположенный по адресу 200000h и состоящий из 3 145 728 (300000h) элементов (а почему бы, собственно, и нет?!), то тут индексы старших элементов становятся больше
базового указателя на массив, что вводит дизассемблер в заблуждение.
Полный перечень эвристических методик, используемых IDA для распознавания смещений, можно найти в книге «Образ мышления — IDA» (электронная копия которой находится на сервере http://nezumi.org.ru/ida.full.zip). Нам же достаточно сказать, что IDA действительно преуспела в этом направлении и ошибается крайне редко. И тем не менее все-таки ошибается, а с ростом размеров дизассемблируемой программы количество ошибок резко нарастает.
Код или данные
Вот так проблема! Наверное, даже самый тупой дизассемблер разберется, что ему подсунули: код или данные, тем более что в PE-файлах (основной формат исполняемых файлов под Windows) они разнесены по разным секциям. Ну, это в теории они разнесены, а на практике компиляторы очень любят пихать данные в секцию кода (особенно этим славиться продукция фирмы Borland).
С другой стороны, практически все компиляторы (особенно на Си++) сплошь и рядом используют вызовы функций типа CALL EBX. Чтобы понять, куда ведет такой вызов, необходимо установить значение регистра EBX, что требует наличия более или менее полного эмулятора процессора, отслеживающего всю историю содержимого EBX с момента его инициализации и до непосредственного вызова.
Наличие эмулятора процессора и памяти позволяет также отслеживать положение регистра ESP, используемого для адресации локальных переменных и аргументов, передаваемых функциям. Если же эмулятора нет (а в IDA он есть), дизассемблер способен распознавать лишь простейшие формы адресации/передачи аргументов. Механизм, ответственный за распознание и отслеживание аргументов, носит красивое название PIT, но эта аббревиатура отнюдь не расшифровывается как «Пивоваренный [завод] Ивана Таранова», а происходит от
Parameter Identification and Tracking — идентификация и отслеживание параметров, то есть аргументов. Тех, что бывают у функций. А еще бывают функции без аргументов, но это уже другая история.
Реконструкция потока управления
Языки высокого уровня оперируют такими конструкциями, как циклы, операторы выбора, ветвления и т.д., что делает программу простой и наглядной. Собственно говоря, именно отсюда и пошло структурное программирование. А ведь когда-то, давным-давно, в Бейсике (и других языках того времени), кроме примитивного GOTO, ничего не было и программа, насчитывающая больше сотни строк, превращалась в сплошные «спагетти», лишенные всякой логики, внутренней организации и следов цивилизации.
На низком же, машинном, уровне ситуация осталась той же, что и лет 50 тому назад. И хотя x86-процессоры формально поддерживают инструкцию цикла LOOP, компиляторы ее не используют, довольствуясь одними лишь условными и безусловными переходами, а потому первоочередная задача реверсера — реконструировать циклы, ветвления и другие высокоуровневые сооружения. Подробнее о том, как это делается руками, читай в «Фундаментальных основах хакерства» (бесплатная электронная копия лежит на http://nezumi.org.ru/phck2.full.zip).
Начиная с пятой версии в IDA Pro появился механизм графов, позволяющий автоматически реконструировать циклы, ветвления и прочие «кирпичи» языков высокого уровня. Впрочем, польза от графов была небольшой, и в реальности они только замедляли анализ, поскольку подобрать адекватный механизм визуализации и навигации Ильфаку так и не удалось… Но ведь не пропадать же труду?!
У истоков HexRays
К пятой версии IDA Pro имела в своем арсенале все необходимое для автоматической декомпиляции, причем не просто декомпиляции, а очень
качественной декомпиляции, декомпиляции принципиально нового уровня, до которого не дотягивает ни один другой существующих
декомпилятор.
Вот так и родилась идея дописать к IDA еще небольшую (на самом деле очень большую) порцию кода, переводящую китайскую ассемблерную грамоту в доступный и понятный листинг на языке Си. Закипела напряженная работа, по ходу которой выявлялись все новые и новые подводные камни, обход которых требовал времени, усилий и мозговой активности. А всякая (или практически всякая) работа упирается в деньги, тем более что у Ильфака фирма!
Боевое крещение
Сначала на экране появляется логотип HexRays с предложением провериться на обновления и после нажатия на OK
HexRays думает некоторое время, а когда он закончит заниматься магической деятельностью, на диске образуется файл notepad.c.
Ура! Свершилось! Пробуем откомпилировать его компилятором MS VC 6.0, предварительно скопировав в текущий каталог файл defs.h из каталога HexRays и заменив в строке #include угловые скобки двойными кавычками, иначе компилятор будет искать defs.h в системном каталоге с включаемыми файлами, где, естественно, его не обнаружит. Но это мелочи… А вот уже проблема посерьезнее. Компилятор, выдав более сотни ошибок, просто прерывает компиляцию, поскольку продолжать ее дальше нет никакого смысла.
Может, мы не тот компилятор выбрали для тестирования? Вообще-то, по идее, декомпилятор должен выдавать листинг на ANSI C, поддерживаемый любым ANSI-совместимым C-компилятором, но… все мы хорошо знаем любовь Ильфака к продукции фирмы Borland. На нем написана сама IDA, на нем же вышло первое SDK… Хорошо, берем последнюю версию
Borland C++ (благо она бесплатна) и что же?! Вновь простыня ошибок и ругательств, приводящих к преждевременному прерыванию компиляции. Оказывается,
чтобы откомпилировать декомпилированный файл, над ним еще предстоит основательно поработать. Вот тебе и раз…
Другими словами, HexRays не позволяет компилировать декомпилированные программы без дополнительной ручной работы и реально пригоден лишь для анализа. Возникает резонный вопрос: и насколько же он упрощает анализ? Чтобы не быть голословным, приведу два фрагмента кода:
Просто? Красиво? Понятно? Элегантно? Еще как! А вот как выглядел тот же самый код в чистом дизассемблере:
.text:0100318F push ebp
.text:01003190 mov ebp, esp
.text:01003192 push ecx
.text:01003193 push ecx
.text:01003194 lea eax, [ebp+hKey]
.text:01003197 push esi
.text:01003198 xor esi, esi
.text:0100319A push eax ; phkResult
.text:0100319B push 20019h ; samDesired
.text:010031A0 push esi ; ulOptions
.text:010031A1 push offset SubKey ; lpSubKey
.text:010031A6 push 80000000h ; hKey
.text:010031AB call ds:RegOpenKeyExA
.text:010031B1 test eax, eax
.text:010031B3 jnz short loc_10031E7
.text:010031B5 lea eax, [ebp+cbData]
.text:010031B8 mov [ebp+cbData], 104h
.text:010031BF push eax ; lpcbData
.text:010031C0 push [ebp+lpData] ; lpData
.text:010031C3 push esi ; lpType
.text:010031C4 push esi ; lpReserved
.text:010031C5 push offset ValueName ; lpValueName
.text:010031CA push [ebp+hKey] ; hKey
.text:010031CD call ds:RegQueryValueExA
.text:010031D3 test eax, eax
.text:010031D5 jnz short loc_10031DA
.text:010031D7 push 1
.text:010031D9 pop esi
.text:010031DA
.text:010031DA loc_10031DA: ; CODE XREF: sub_100318F+46?j
.text:010031DA push [ebp+hKey] ; hKey
.text:010031DD call ds:RegCloseKey
.text:010031E3 mov eax, esi
.text:010031E5 jmp short loc_10031E9
.text:010031E7
.text:010031E7 loc_10031E7: ; CODE XREF: sub_100318F+24?j
.text:010031E7 xor eax, eax
.text:010031E9
.text:010031E9 loc_10031E9: ; CODE XREF: sub_100318F+56?j
.text:010031E9 pop esi
.text:010031EA leave
.text:010031EB retn 4
Согласись, что сравнение отнюдь не в пользу дизассемблера, но не спеши радоваться. Рассмотрим еще один пример:
Что делает этот код? Совершенно непонятно. То есть не то чтобы совсем непонятно, но смысл как-то ускользает. Тут требуется проанализировать, что это за переменные такие, кто еще (помимо этой функции) их модифицирует и зачем? В дизассемблере листинг выглядит схожим образом, но мощная система навигации по коду вкупе с перекрестными ссылками и подсветкой одноименных переменных/функций сокращает время анализа на несколько порядков, причем ни в одном текстовом редакторе, ни в одной среде программирования подобной системы навигации по коду нет!
А это вид в дизассемблере:
.text:01002306 loc_1002306: ; CODE XREF: sub_1002239+C4?j
.text:01002306 mov eax, dword_1008028
.text:0100230B push ebx
.text:0100230C push edi
.text:0100230D mov dword_1008BCC, eax
.text:01002312 push dword_10087D0
.text:01002318 call sub_10059A3
.text:0100231D test eax, eax
.text:0100231F jz short loc_1002328
Наш вердикт
HexRays – это, безусловно, большой шаг вперед и неплохое подспорье для начинающих, но… он не стоит тех денег, которые за него просят, к тому же (это касается начинающих), однажды потратив время на изучение ассемблера, мы обретаем возможность реверсировать что угодно и в чем угодно (на худой конец с помощью утилиты DUMPBIN.EXE, входящей в состав SDK), а обольщенные возможностями автоматической декомпиляции, мы становимся заложниками
HeyRays со всеми вытекающими отсюда последствиями.
Полную версию статьи
читай в февральском номере Хакера! Демонстрационную версию IDA ты найдешь на нашем диске. К сожалению, мы не можем выложить HexRays по правовым соображениям. На нашем диске будет видеоролик, демонстрирующий возможности HexRays.