Как дизассемблировать dll файл
Обновлено: 04.07.2024
У каждого из команды ][ — свои предпочтения по части софта и утилит для
пентеста. Посовещавшись, выяснилось, что выбор так разнится, что можно составить
настоящий джентльменский набор из проверенных программ. На том и решили. Чтобы
не делать сборную солянку, весь список мы разбили на темы. Сегодня мы разберем
отладчики и дизасемблеры - все, что понадобится для реверсинга приложений.
OllyDbg
Если ты хоть раз читал статьи о крякинге или, например, смотрел видеоуроки от
нашего реверсера Cr@wler'а, то имя "Ольки" тебе должны быть знакомо. Это
32-битный отладчик работающий на ring-3 с продуманным интерфейсом и полезными
функциями, которые существенным образом облегчают процесс отладки. В OllyDBG
встроен специальный анализатор, которые распознает и визуально обозначает
процедуры, циклы, константы и строки, внедренные в код, обращение к функциям API,
параметры этих функции и т.п. Для новичка (и не только) - это именно то, что
надо! В ходу до сих пор находится версия 1.10, а бета-версия второй ветки еще с
марта не претерпела изменений, однако уже сейчас можно оценить многочисленные
нововведения дебаггера. Работа ведется уже давно, и поэтому разработчику уже
есть что показать (прежде всего новый движок). Бету едва ли можно рассматривать
как основной инструмент для серьезных дел, поэтому спешу предупредить: о
стабильности нового движка пока приходится только мечтать, поэтому используй "бетку"
на свой страх и риск.
Тут надо сказать, что стал OllyDbg стандартным user-land отладчиком, взятым
на вооружение хакерами и они тут же захотели его улучшить. Появилось множество
нестандартных сборок: одни фиксят ошибки Ольги, другие расширяют функционал,
третьи – скрывают ее от протекторов. Недостаток — "движок" отладчика работает
через MS Debugging API, страдающий кучей врожденных ограничений, оставляющий за
собой множество трудноудаляемых следов и представляющий легкую мишень для
антиотладочных технологий.
Immunity Debugger
Известный мод одноименной фирмы, специализирующейся на безопасности и
скрестившей Ольгу 1.10 с Питоном – интерпретируемым языком, на котором очень
легко и быстро писать скрипты. Конечно, писать их можно прямо в Ольге, но это не
слишком удобно, все приходится делать вручную и решать типовые задачи (типа
поиска в памяти), которые уже давно решены.
В Immunity Debugger входит множество библиотек, написанных на Питоне и
заточенных под хакерские нужды. Библиотеки вызываются из Питоновых программ,
среди которых значится и searchcrypt.py – отличное средство идентификации
следующих криптографических алгоритмов: AES, BLOWFISH, CAMELLIA, CAST, MD5, RC2,
RC5, RIPEMD160, SHA1, SHA256, SHA512.
Immunity Debugger используют многие специалисты по безопасности,
выкладывающие proof-of-concept expolit'ы, написанные на Питоне и предназначенные
для работы исключительно в среде данного отладчика. И хотя хакер с головой
разберется в алгоритме работы exploit'а и без Immunity Debugger'а, портируя
exploit на любой другой язык, рано или поздно отладчик оказывается на
компьютере, зачастую становясь основным инструментом, вытесняющим Ольгу.
Популярный и очень мощный мод, основанный на Ольге 1.10 и собравший в своем
дистрибутиве огромное количество плагинов, скриптов, а также кучу других
полезных инструментов. В отличие от Immunity Debugger'а, ориентированного на
специалистов по безопасности, YDbg писался хакерами и для хакеров, ломающих
защиты с протекторами (те активно сопротивляются такому положению дел и
напичканы анти-отладочными приемами, распознающими присутствие Ольги по главному
окну с ее именем и пунктам меню). Поэтому первое, что бросается в глаза при
запуске YDbg (исполняемый файл которого переименован из OLLYDBG.EXE в SND.exe),
это "покореженные" пункты меню. В частности, "Memory" превратилось в "M3m0ry", "SEH
chain" в "S3H chain", "Breakpoints" в "Br3akp01nts" и т. д. Словом, все
"хакерские" пункты изменены – попробуй их найти (естественно, в новых версиях
протекторов наверняка появится детекция YDbg, но пока он успешно скрывается от
кучи защит, палящих Ольгу). В состав дистрибутива YDbg входит 36 популярных
плагинов (и не нужно теперь рыскать по Сети в их поисках). Среди них затесался
настоящий бриллиант – IDA Sigs, название которого говорит само за себя. Да-да!
Это плагин, поддерживающий IDA-сигнатуры и отображающий их в виде комментариев к
вызываемым функциям в Ольге или в YDbg. Другой полезный плагин – red-hawk
("красный ястреб") представляет собой панельку инструментов, позволяющую, в
частности, одним движением мыши установить точки останова на нужные функции
(например, в Visual Basic'е это что-то типа __vbaStrCmp или __vbaStrCopy,
используемые для сравнения и копирования строк, соответственно). Начинающие
хакеры просто визжат от восторга, поскольку красный ястреб фактически является
учебником по взлому, а так попробуй догадаться, что нужно делать! Каталог \SCRIPT
содержит 637 скриптов, главным образом предназначенных для снятия различных
протекторов/упаковщиков исполняемых файлов и автоматизации всяких рутинных дел.
SoftICE
Всем известный (даже тем, кто к крякингу даже близко не подходил) отладчик
для Windows, работающий дна уровне ядра. В отличие от прикладного отладчика, как
например OllyDbg, SoftICE способен приостановить все операции в Windows, что
очень важно для отладки драйверов. Работает в обход MS Debugging API, что
значительно усложняет антиотладку, однако, учитывая, что для разработчиков защит
soft-ice – враг номер один, практически все протекторы легко распознают его
присутствие в системе. Поэтому никак не обойтись без специальных расширений
(которые упомянем дальше). SoftICE был первоначально разработан компанией NuMega,
которая включала его в пакет программ для быстрой разработки
высокопроизводительных драйверов под названием Driver Studio, который
впоследствии был приобретён Compuware. Помнишь, сколько всевозможных мануалов
было по поводу установки Soft-Ice'а под Windows XP? Увы, начиная с висты,
отладчик не работает. Разработчики приостановили разработку в апреле 2006 года.
На официальном сайте его не найти и доступен только на торрентах.
Microsoft Debugger
Microsoft Debugger может работать как на прикладном уровне (ring-3), так и на
уровне ядра. Вплоть до XP ядерная отладка требовала, как минимум, двух машин,
соединенных COM-шнурком, но теперь достаточно и одной.
Поставляется в двух редакциях: windbg.exe – графический интерфейс и cdb.exe —
интерфейс командой строки. И та и другая являются лишь тонкими обертками вокруг
dbgeng.dll, в которой, собственно, и реализован основной отладочный "движок",
документированный протокол обмена. Поэтому, чтобы в очередной раз не писать
трассер с нуля, dbgeng.dll можно использовать в качестве "фундамента" при
написании универсальных распаковщиков исполняемых файлов.
Syser Kernel Debugger
Достойных отладчиков ядра всего три: SoftICE, Syser и Microsoft Kernel
Debugger, но SoftICE не работает на Висте и Server 2008, а Microsoft Kernel
Debugger – для хакерских целей не самый лучший вариант. Остается Syser, который
хакеры взяли на вооружение и весьма активно используют. Написан он двумя
предприимчивыми китайскими реверсерами Wu YanFeng и Chen JunHao. По сути, Syser
- отладчик уровня ядра с графическим оконным интерфейсом. Позволяет отлаживать
как приложения, так и драйвера. Сочетает в себе функции IDA Pro, Softice и
Ollydbg. Поддерживает подсветку листинга дизассеблера, динамическую загрузку и
выгрузку, все команды отладчика SoftICE, полноценную работу с юникодом и
многопроцессорными системами. Проработаны многие мелочи: например корректно
работает буфер обмена, позволяющий копировать данные из уровня Ring 3 в уровень
Ring 0. Многие из операций можно автоматизировать с помощью скриптов. Надо
сказать, что Syser - преемник SoftICE, из которого, как говорят, были дернуты
целые модули. У него масса преимуществ, как, впрочем, масса недостатков, поэтому
реально его приходится юзать совместно с Microsoft Kernel Debugger.
GNU Debugger – основной отладчик под UNIX, ориентированный на совершенно иной
тип мышления, чем все вышеперечисленные отладчики. Это не просто интерактивный
отладчик, скорее это станок с программным управлением, гибким и мощным
интерфейсом. Отлаживать с его помощью "честные" программы — одно удовольствие,
но в плане антиотладки дела обстоят плохо. GDB даже не пытается сопротивляться и
работает через библиотеку ptrace (которая на самом деле никакая не библиотека, а
системный вызов). GDB принципиально неспособен отлаживать программы, которые не
хотят, чтобы их отлаживали. А такие программы мало-помалу начинают появляться.
Естественно, помимо GDB существуют и другие отладчики для никсов, например,
Lin-Ice, но поскольку антиотладочные технологии под UNIX только-только начинают
развиваться, в большинстве случаев вполне сгодиться и GDB.
IDA Pro
IDA Pro - это одновременно интерактивный дизассемблер и отладчик. Она
позволяет превратить бинарный код программы в ассемблерный текст, который может
быть применен для анализа работы программы. Правда, стоит сказать, что
встроенный ring-3 отладчик довольно примитивен. Он работает через MS Debugging
API (в NT) и через библиотеку ptrace (в UNIX), что делает его легкой добычей для
защитных механизмов. Но зато IDA Pro — интерактивный дизассемблер более чем с
десятилетней историей, первая версия которой увидела свет 6 мая 1991 года. Юрий
Харон вместе с Ильфаком начали работать в том направлении, куда еще никто не
вкладывал деньги. До этого дизассемблеры писались исключительно на пионерском
энтузиазме параллельно с изучением ассемблера и довольно быстро забрасывались.
Стоит ли удивляться, что парням удалось решить практически все фундаментальные
проблемы дизассемблирования, над которыми просто не хотели работать остальные
разработчики, зная, что быстрой отдачи не будет и проект потребует десятилетий
упорного труда. К пятой версии IDA Pro имела в своем арсенале все необходимое
для автоматической декомпиляции, причем не просто декомпиляции, а очень
качественной декомпиляции. На текущй момент последний резиз 5.5 от 12 июня.
Влюбленные в продукт пользователи генерят немало полезных плагинов, в том числе
поддерживающих разные скриптовые языки для написания сценариев в дополнение к
встроенному IDC. Например,
IdaRUB
добавляет поддержку Ruby, а
IDAPython - Python.
Тут надо сказать, что начиная с версии 5.4 IDAPython идет предустановленной в
дистрибутивы ИДЫ.
Hex-Rays
Дальше разработчики подумали и решили, что уж раз смогли получить
человеческий код на ассемблере, то неплохо дописать еще одну фичу, переводящую
китайскую ассемблерную грамоту в доступный и понятный листинг на языке Си.
Закипела напряженная работа, по ходу которой выявлялись все новые и новые
подводные камни, обход которых требовал времени, усилий и мозговой активности. В
итоге на свет появился
Hex-Rays - декомпилятор, требующий обязательно установленную на компьютеру
ИДУ. Декомпилятору подается на вход бинарник, указывается ряд параметров, после
чего Hex-Rays выплевывает исходник на чистом C - в большинстве своем понятный и
доступный. Правда, спешить компилировать его обратно в бинарник не стоит, потому
как в большинстве случаев в момент компиляции ты увидишь столько ошибок, сколько
еще не видывал. Одна из причин - отсутствие поддержки в Hex-Rays ресурсов.
W32DASM
Начинающие хакеры обычно испытывают большие трудности при взломе программ,
написанных на Delphi и Builder, поскольку классические трюки, типа бряка на
GetWindowTextA, не работают. Для декомпиляции кода, написанного на Delphi/Borland
C++ Builder, т.е программ, которые используют библиотеку VCL от Borland, нужен
специальный подход, и он реализован в утилите DeDe. По сути, это единственный
работающий декомпилятор для Delphi-программ, которые не смотря ни на что никак
не умирают. DaFixer, автор проекта, к сожалению, забросил заниматься своим
детищем, поэтому официальной страницы у проекта в настоящий момент нет.
Подробнее о том, как совладать с программами на Delphi, читай в статье "Взлом
Борландии: изящная декомпиляция Delphi".
Любой коммерческий продукт должен быть достаточно хорошо защищен.
Разработчики намеренно использует разного рода упаковщики и так называемые
протекторы, которые применяют разного рода антиотладочные средства, максимально
препятствующие взлому программы. Обойти их можно, но для этого нужно четко
представлять, что использовалось для защиты программы, какой плагин для
отладчика использовать - и от этого "крутиться". Изящно определить название и
версию упаковщик способна небольшая утилита PEiD. Собственно, для этого она и
нужна.
PE Explorer
Программа для просмотра и редактирования PE-файлов - начиная с EXE, DLL и
ActiveX контролов, и заканчивая скринсейвверами SCR (Screensavers), апплетами
панели управления CPL, SYS и бинарниками для платформы Windows Mobile. По сути,
это не одна утилита, а целый набор тулз для того, чтобы посмотреть изнутри, как
работает программа или библиотека. Включает в себя просмотрщик заголовков,
экспорт вызовов API-функций, редактор ресурсов, дизассемблер.
Дизассемблеры и декомпиляторы исполняемых файлов
В комментариях к статьям меня часто спрашивают где взять тот или иной инструмент, используемый в исследовании. По возможности я всегда указываю ссылки, но теперь настало время самых мощных инструментов, а именно дизассемблеров и декомпиляторов исполняемых файлов. Сразу уточню терминологию. Дизассемблирование - преобразование программы из двоичного кода к ее ассемблерному представлению. Декомпиляция - процесс воссоздания исходного кода программы.
Скриншот программы dnSpy
Скриншот программы IDA Pro Advanced
IDA Pro (сокращение от Interactive DisAssembler) - один из моих основных инструментов для реверс-инжиниринга и разбора файлов. Это интерактивный дизассемблер и отладчик с поддержкой множества форматов исполняемых файлов для большого числа процессоров и операционных систем. Чтобы перечислить все его возможности потребуется целая книга. Но даже тут возможности IDA не заканчиваются. Плагин Hex-Rays для IDA Pro позволяет декомплировать ассемблерный листинг в более-менее человекопонятный псевдокод, по синтаксису похожий на C. В некоторых случаях это значительно облегчает работу. Просто так приобрести IDA Pro частным лицам практически невозможно, и дело не только в непомерной цене, а в том, что автор придерживается абсолютно неадекватной политики в плане продаж. К счастью, несколько последних версий этого замечательного дизассемблера, несмотря на все трудности, были успешно слиты в свободный доступ. Это IDA Pro Advanced 6.8, последняя доступная версия, которая работает с 32-битными системами, а также IDA Pro Advanced 7.0 и IDA Pro Advanced 7.2 для 64-битных систем. Если по каким-то причинам вы не можете использовать варез, то на офсайте есть бесплатные демо-версии с урезанным функционалом.
Скриншот программы Interactive Delphi Reconstructor
IDR (Interactive Delphi Reconstructor) - бесплатный декомпилятор исполняемых файлов и динамических библиотек. В отличие от IDA Pro, этот декомпилятор создан специально для разбора файлов, написанных на языке Delphi. Сейчас проект прекратил развитие, если какие изменения и вносятся, то исключительно косметические. Исходники для доработки открыты. Лично я пользуюсь стабильным комплектом Interactive Delphi Reconstructor 2.6.0.1.
Скриншот программы VB Decompiler Pro
Еще один специализированный декомпилятор - VB Decompiler Pro. Он работает с программами (EXE, DLL, OCX), написанными на Visual Basic. В случае, если приложение собрано в p-code, декомпилятор может разобрать его практически до исходного кода. Но даже если приложение скомпилировано в native code, в этом случае VB Decompiler анализирует и восстанавливает довольно много инструкций, чтобы насколько это возможно приблизить ассемблерный код к исходному. Это сильно упростит задачу анализа алгоритмов исследуемой программы. Честные граждане могут воспользоваться бесплатной Lite-версией с офсайта, для любителей полных версий софта есть релиз VB Decompiler Pro 10.0. Антивирусы могут ругаться на активатор, но тут вы уже сами решайте что делать.
Конечно, это далеко не полный список инструментов для дизассемблирования и декомпиляции, который есть в свободном доступе. Например, та же набирающая популярность Ghidra от АНБ может составить конкуренцию IDA Pro с Hex-Rays. Но я в этой статье перечислил лишь те программы, которыми пользуюсь сам и которые упоминаются в статьях на этом сайте.
Одним из приоритетных направлений в разработке любого продукта является его отладка. Ведь мало написать удовлетворяющий требованиям исправно работающий код, так нужно ещё и протестить его в "токсических условиях", на предмет выявления всевозможных ошибок. Для этих целей, инженеры Microsoft включили в состав ОС полноценный механизм дебага в виде двух библиотек пользовательского режима: это Dbgeng.dll – основной движок отладки (Debug Engine), и Dbghelp.dll – вспомогательный процессор отладочных символов PDB (Program Database).
На моей Win-7, библиотека символов имеет размер 0.8 Мб и выдаёт на экспорт аж 205 стандартных API-функций, а вот вторая Dbgeng.dll в три раза тяжелее своего (со)брата с размером
2.5 Мб, зато экспортирует с выхлопной трубы всего 3 функции. От сюда следует, что эта либа от нас явно что-то скрывает, поскольку жалкие три процедуры никак не могут весить более двух мегабайт. В данной статье мы попытаемся заглянуть внутрь отладочного движка Engine, и в качестве примера вытащим из него полноценный дизассемблер инструкций процессоров х86.
1. Знакомство с механизмом отладки
Первые библиотеки отладки, так-же известные как файлы "Symbolic Debugger Engine", были созданы компанией Microsoft в 2001-году для операционной системы Windows-XP. Большая часть либы Dbghelp.dll содержит в себе функции с префиксом(Sym), что говорит об их принадлежности к символьному процессору. Они позволяют по указанному адресу вычислять имена функций, определять типы данных, а также номер строки и название файла, в котором эта строка находится. Поддерживаются и обратные операции, например поиск адреса функции по её имени. Это достаточно творческая единица, если знать как ею пользоваться ( см.документацию на сайте мелкософт).
В состав этой библиотеки входят и привычные нам функции, без каких-либо префиксов. Например потянув за всего одну EnumerateLoadedModules() можно получить список всех модулей DLL (вместе с виртуальной базой и размером), которые загружены в интересующее нас приложение. Поскольку вся черновая работа происходит в фоне, то в большинстве случаях это удобно. На входе, функция требует лишь дескриптор процесса (в примере ниже я передаю -1, т.е. текущий процесс), и адрес callback-процедуры, куда она в цикле будет сбрасывать информацию о модулях. Функция связана со-своей "обратной процедурой" невидимой нитью, так-что программный цикл выстраивать не нужно – обход на автомате прекращается, как только коллбэк возвращает родителю ошибку:
Всё идёт прекрасно до тех пор, пока мы не сталкиваемся с вызовом функций из основного движка-отладки Dbgeng.dll – здесь и начинается самое интересное. Эта библиотека построена по модели СОМ (Component-Object-Model), а значит и вызывать из неё функции нужно соответствующим образом. Но проблема в том, что в отличии от крестов С++ и прочих высокоуровневых языков, ни один из ассемблеров не поддерживает на данный момент технологию COM/ActiveX, и врядли уже будет поддерживать в будущем. Ассемблер – это язык низкого уровня, а прослойка СОМ находится в иерархии намного выше.
Как уже упоминалось, библиотека Dbgeng.dll выдаёт на экспорт всего 3-функции (см.в тотале по ctrl+q) – это DebugCreate() , DebugConnect() и DebugConnectWide() . Но под капотом у неё припрятаны ещё порядка 300 внутренних, неэкспортируемых обычным способом функций. Чтобы подобраться к ним, для начала нужно разобраться, что вообще такое COM-интерфейс и как его реализуют современные компиляторы – вот об этом и поговорим..
2. Component-Object-Model в ассемблере
COM – многокомпонентная, клиент-серверная модель объектов Microsoft, которая является продолжением OLE и фундаментальной основой многих других технологий, в том числе ActiveX и DCOM (Distributed COM, работа с сетью). Ключевым аспектом COM является то, что эта технология обеспечивает связь между клиентом (нашим приложением) и сервером (операционной системой) посредством "интерфейсов" . Именно интерфейс предоставляет клиенту способ узнать у сервера, какие конкретно возможности он поддерживает на текущий момент.
В терминологии языка С++ интерфейс – это абстрактный базовый класс, все методы которого являются виртуальными. То-есть вызов этих методов осуществляется через специальную таблицу-указателей, известную как vTable . Например, вызов метода QueryInterface из интерфейса IUnknown будет выглядеть так: IUnknown::QueryInterface() . На сайте rsdn имеется увесистый хаб , выделенный специально под описание всех нюансов СОМ-технологии.
Если-же посмотреть на СОМ глазами ассемблера, то интерфейс представляет собой ничто-иное, как обычную структуру в памяти. Чтобы придерживаться общих правил, мы будем называть её так-же, т.е. "vTable". В свою очередь методы – это лишь иное название уже привычных нам API-функций, а указатели на эти функции хранятся внутри интерфейса. Таким образом, интерфейс можно рассматривать как массив указателей на СОМ-функции. Влиться в эту тему поможет ветка на wasm.in , где представлены материалы по СОМ с реальными примерами на ассемблере – "допризывникам" настоятельно рекомендуется к прочтению.
В операционной системе Win имеется огромное количество СОМ-интерфейсов и это не удивительно, ведь Microsoft строит системы используя объектно-ориентированный подход программирования, а частью ООП является как-раз-таки OLE/ActiveX/СОМ. Чтобы из этого общего пула у нас была возможность выбрать и использовать в своих программах конкретный интерфейс, система назначает ему уникальный идентификатор GUID . Собрав в единую базу, Win хранит все эти идентификаторы в своём кусте реестра под названием "HKEY_CLASSES_ROOT\Interface". Если выбрать любой GUID в левом окне, то в правом получим отождествлённое с этим идентификатором, название интерфейса:
СОМ-сервер операционной системы имеет базовый интерфейс под названием "IUnknown" . Он глобален и все остальные наследуются именно от него. GUID этого интерфейса имеет значение . В своей тушке интерфейс хранит указатели на три метода (функции) и на ассемблере будет выглядеть так:
Как видим, при помощи IUnknown и его метода QueryInterface() можно найти адрес любого СОМ-интерфейса в системе, но только при условии, что мы знаем GUID искомого (нужно будет передать его в качестве аргумента этому методу). Важно запомнить, что базовый интерфейс IUnknown входит в состав буквально всех СОМ-интерфейсов, занимая первые три указателя в нём. СОМ-сервер инкапсулирует его во-все интерфейсы, чтобы вести над ними учёт.
Например, когда мы получаем от сервера ссылку (указатель) на какой-нибудь интерфейс, его метод AddRef() на автомате увеличивает внутренний счётчик-обращений к данному интерфейсу. Если-же интерфейс нам больше не нужен, мы должны вызвать его метод Release() , который соответственно уменьшит этот счётчик на 1. Сервер периодически парсит счётчики активных интерфейсов и если обнаруживает в нём нуль, то из-за ненадобности сразу выгружает его из памяти. Так реализуется "время жизни" СОМ-интерфейсов, и это стандартная схема учёта системных структур, в памяти Win.
3. Структура СОМ-библиотеки Dbgeng.dll
Будем считать, что прошлись по макушкам СОМ-технологии, и теперь рассмотрим её реализацию внутри главного героя этой статьи – библиотеки Dbgeng.dll. В каком-то смысле, эта библиотека сама является полноценным СОМ-сервером, поскольку GUID'ы её интерфейсов не прописаны в системном реестре Win, хотя библиотека и является детищем самой Microsoft. Из этических соображений, все разработчики СОМ-интерфейсов обязаны сопровождать свой продукт полной документацией, чтобы армия прикладных программистов могла использовать незнакомые интерфейсы в своих программах. Связано это с тем, что не зная GUID мы просто не сможем найти ни один интерфейс в системе, и соответственно лишимся возможности вызывать из него методы.
Движок-отладки Dbgeng.dll отлично документирован в репозитории мягких – общие сведения о нём можно почерпнуть по этому линку . Что касается описания непосредственно имеющихся в наличии методов и GUID всех интерфейсов, то они находятся в заголовочном файле Dbgeng.h , электронная версия которого лежит здесь . Судя по этому хидеру, в данную библиотеку включён не один, а целая дюжина связанных с отладкой различных интерфейсов, и в каждом из них имеются свои функции (методы). Исторически, 16-байтные GUID интерфейсов принято обозначать как IID, что подразумевает "Interface-Identifier".
Одной из примечательных особенностей СОМ-интерфейсов является их масштабируемость. Так, если мы захотим изменить уже существующий интерфейс, то достаточно написать недостающие методы, и добавить указатели на них в конец прежнего интерфейса. К примеру, каждый из представленных выше 13-ти фейсов имеет дополнительные экземпляры, к именам которых добавляется порядковый номер по типу: IDebugClient (основной интерфейс), и дальше IDebugClient2 (3,4,5,6,7). Каждый последующий экземпляр включает в себя какие-то свежие методы и ему назначается новый GUID, в результате чего интерфейс шагает в ногу со-временем.
Посмотрим на рисунок ниже, где представлена обобщённая структура библиотеки Dbgeng.dll.
Чтобы воспользоваться услугами сервера-отладки, мы должны сначала активировать его функцией CoInitialize() из библиотеки подсистемы исполнения OLE32.dll. Теперь нужно создать "клиента отладки" функцией DebugCreate() из либы Dbgeng.dll, передав ей в виде аргумента GUID интерфейса "IDebugClient::". Это основной интерфейс клиента, где собраны часто используемые им (т.е. нашим приложением) методы.
Если зайти отладчиком OllyDbg в функцию DebugCreate() по [F7], то можно обнаружить, что она проделывает массу полезной работы – например копирует из тушки движка в пространство пользователя различные структуры, находит через GetProcAddress() и подключает вспомогательные функции отладки из библиотеки Ntdll.dll типа: DbgEvent() , DbgBreakPoint() и многое другое. Именно эта функция создаёт полный контекст отладки в памяти ОЗУ, и нам остаётся лишь вызывать методы из требуемых СОМ-интерфейсов:
Значит передаём функции DebugCreate() GUID интерфейса "IDebugClient::", на что функция возвращает нам адрес этого интерфейса в памяти. Если вернуться к рис.выше, то можно обнаружить, что первые три метода в любом интерфейсе, есть копия базового интерфейса "IUnknown::", а первый метод – как-раз нужный нам QueryInterface() . Он ожидает на входе два аргумента – это GUID искомого интерфейса, и указатель на переменную, куда метод сохранит его адрес.
Особое внимание нужно обратить на способ вызова СОМ-методов в ассемблере. Дело в том, что помимо обозначенных прототипом аргументов, мы всегда должны добавлять ещё один лишний аргумент – в спецификации его назвали "This" и представляет он собой адрес интерфейса. Другими словами, перед вызовом любого метода из какого-либо интерфейса, мы должны явно указать серверу, из какого именно осуществляем вызов. Этот аргумент(This) всегда является первым аргументом метода – вот пример:
Посмотрим на результат работы программы..
Интерфейсы, у которых адресом является нуль, не реализованы в движке-отладки Dbgeng.dll и вызывать из них методы нельзя (получим исключение Access-Violation с кодом 0xC0000005, т.к. будет попытка чтения адреса нуль). Ну с интерфейсами Client::[6,7] и Control::[5,6,7] всё понятно – как видим, это обновы предыдущих и добавлены они только начиная с Win-8. Однако мне так и не удалось найти ответа, почему отсутствуют интерфейсы Breakpoint:: и Callbacks. Ради эксперимента я даже пробовал подключать не системную библиотеку Dbgeng.dll, а переименовав подсовывал программе либу ядерного отладчика WinDbg, и всё-равно получал аналогичную картину. После нескольких попыток было решено оставить этот вопрос открытым, до лучших времён.
Из остальных интерфейсов можно смело вызывать их методы. Например, лист методов интерфейса IDebugClient::[2,3,4] выглядит так.. а остальные – перечислены в созданном мной инклуде Dbgeng.inc (см.скрепку). Обратите внимание, как добавляются расширенные интерфейсы к предыдущим. Каждый из них включает в себя полный список всех/своих предков, и только в конце добавляются новые.
4. Практика – пишем дизассемблер
Теперь, на финишной прямой, собрав воедино всё/вышеизложенное напишем дизассемблер, одноимённый метод которого лежит в интерфейсе IDebugControl. Чтобы на поверхность всплыла исключительно полезная составляющая кода, я ограничился дизаcсемблированием лишь текущей программы. В идеале, нужно было дать возможность юзеру выбирать исполняемый файл, но в этом случае "пайлоад" утонул-бы в массе дополнительных функций. Здесь главное понять суть, а окружение – это уже второстепенная задача и дело вкуса. Значит алго будет такой:
Ну и собственно вот реализация этого алгоритма на ассемблере FASM.
Все строки кода прокомментированы, а если что-то непонятно, то всегда можно задать вопрос в комментариях статьи:
Здесь я добавил некоторую вспомогательную информацию в шапке, чтобы продемонстрировать расположение интерфейсов и их методов. Так, первые две строчки указывают на наше пользовательское пространство памяти, куда функция DebugCreate() любезно сбросила указатели на интерфейсы. А вот сами методы находятся уже внутри библиотеки Dbgeng.dll, о чём свидетельствует их адреса с базой 0x5D0D0000 . Если вызов метода возвращает в EAX=0 , значит он прошёл успешно (константа S_OK), иначе в EAX получим следующие коды ошибок:
5. Заключение.
Программирование СОМ-интерфейсов открывает перед нами огромные возможности, поскольку в своих/больших штанинах они прячут достаточно интересные методы, подобраться к которым можно только через указатель на интерфейс, аля GUID. По модели СОМ построена добрая половина системных библиотек – объектная модель позволяет нам работать с такими механизмами как WMI (инструментарий Windows), технологией DirectX, с библиотекой Shell32.dll и многое другое. Как упоминалось выше, любой СОМ-интерфейс обязан быть документированным, поэтому проблем не возникает – главное уловить логическую нить, а дальше уже дело техники.
главная программы pe explorer обзорный тур
Простота, ясность и удобство навигации
Дизассемблер, входящий в состав PE Explorer, разработан с целью дать разработчикам и исследователям простой и удобный инструмент для выполнения экспресс-анализа исполняемых файлов. Чтобы сделать процесс дизассемблирования быстрым и лёгким, некоторая часть функциональности, встречаемая в других дизассемблерах, была специально убрана. Таким образом, дизассемблер в PE Explorer сфокусирован на простоте, ясности и удобстве навигации, в то же время являясь ничуть не менее мощным, чем более сложные и дорогие конкурирующие продукты.
Мы попытались достичь уровня IDA Pro, при этом не требуя от пользователя специфических знаний и умений, поскольку большинство стадий процесса дизассемблирования в PE Explorer автоматизированы. Во многих случаях использование IDA Pro для быстрого анализа кода файла напоминает стрельбу из очень тяжёлой и дорогой пушки по очень маленьким воробьям. Мы же сделали просто хороший дизассемблер по очень доступной цене. И если ваша повседневная работа включает реверсинг и исследование уязвимостей программного кода, восстановление исходных кодов и поиск параметров, тестирование или изучение поведения неизвестных файлов, PE Explorer сэкономит вам немало часов и во многом упростит вашу работу.
Использование дизассемблера PE Explorer предполагает последующее редактирование полученного листинга вручную. Однако, чтобы избавить пользователя от значительного количества рутинной работы и уменьшить объём ручной правки, дизассемблер использует очень гибкий и интелектуальный алгоритм дизассемблирования, способный реконструировать ассемблерный код изучаемого исполняемого файла с высокой степенью достоверности.
Одной из причин, по которой я купил PE Explorer, был дизассемблер. Отличная вещь.
После сравнения PE Explorer с другими продуктами я полагаю, что выбрал самое лучшее предложение на рынке за свои деньги - вместо того, чтобы платить $400 за Ida Pro.
Основная проблема дизассемблирования заключается в правильности интерпретации изучаемых данных. Отделить код от данных - задача невероятно сложная, особенно когда код включает в себя специальные меры противодействия для затруднения дизассемблирования. Специально для таких случаев мы разработали особую модель алгоритма, позволяющую снизить ошибки определения типа данных.
Несмотря на то, что эта модель увеличивает время дизассемблирования, её результатом является значительное уменьшение ошибок, связанных с неверной интерпретацией кода/данных, и существеное сокращение времени, затрачиваемого на ручную корректировку полученного результата.
Процесс дизассемблирования
Дизассемблер запускается в своём отдельном окне, и вы можете переключаться из окна дизассемблера в основное окно PE Explorer. Дизассемблер поддерживает основные наборы инструкций Intel x86 и расширения MMX, 3D Now!, SSE, SSE2 и SSE3. В начале процесса окно Options предлагает выбрать следующие опции:
Нажатие кнопки Start Now запускает процесс, кнопка Start Later откладывает запуск.
Verify Offsets - При включении этой опции дизассемблер особо тщательно проверяет, является ли анализируемое значение смещением.
Reverse Offset Checking Order - По умолчанию, дизассемблер рассматривает необработанные данные как код, и только потом как смещения к данным. При включении этой опции дизассемблер будет рассматривать необработанные данные как данные.
В большинстве случаев включение этой опции либо ничего не изменит, либо сделает качество листинга хуже. Однако, в некоторых случаях (например, с программами, написанными на Visual Basic) изменение порядка определения смещений может дать лучший результат. Автоматизировать применение этой опции затруднительно, поэтому рекомендуется использовать эту опцию только в ситуациях, когда настройки по умолчанию приводят к неудовлетворительным результатам.
Find ANSI and Unicode Strings - При включении этой опции дизассемблер автоматически обнаруживает текстовые ANSI и Unicode строки длиннее 3-х символов. В отдельных случаях, если результаты анализа позволяют однозначно интерпретировать данные как строку, эта длина может быть и менее 3-х символов.
Find Alignment - Поскольку доступ к выравненным данным происходит быстрее, многие компиляторы выравнивают код, добавляя лишние команды, не влияющие не ход выполнения программы, такие как nop, mov eax,eax и т.п.
При включении этой опции дизассемблер интерпретирует подобный код/данные как выравнивание.
Forcible Find Offsets - При включении этой опции дизассемблер автоматически обнаруживает смещения к данным в коде, который остался нераспознанным после первого прохода по файлу.
Используйте эту опцию с осторожностью, так как правильно определить, являются ли найденные данные смещением или фрагментами кода/данных, довольно сложно. Не рекомендуется использовать эту опцию без особых причин.
Analyze Uprocessed Data - Во время дизассемблирования отдельные фрагменты кода по причине отсутствия явных на них ссылок могут оказаться нераспознанными. При включении данной опции дизассемблер проводит дополнительный анализ таких блоков и пытается определить, являются ли эти фрагменты кодом или данными. Включение этой опции улучшает качество листинга.
Окно Processing Info отображает информацию о ходе процесса дизассемблирования:
По окончании процесса в главном окне дизассемблера появляется дизассемблерный листинг исходного кода изучаемого файла. Этот листинг можно редактировать в окне или сохранить на диск для дальнейшей работы.
Нахождение всех текстовых строк внутри EXE файла
Дизассемблер отображает все найденные в сегменте данных текстовые строки в отдельной закладке Strings. Если вы пытаетесь найти какие-то зацепки в изучаемом файле в виде осмысленного текста, подобный список строк может дать вам подсказки о назначении тех или иных функций и процедур, вызываемых файлом, или даже какую-нибудь информацию о происхождении файла.
В отличие от существующих разнообразных утилит, занимающихся поиском и нахождением текстовых строк в исполняемых файлах, PE Explorer делает это аккуратнее и качественнее, поскольку опирается в своем поиске на результаты анализа кода кода приложения.
Нахождение VCL объектов и методов Delphi
Дизассемблер отображает список всех найденных VCL объектов и методов в отдельных закладках VCL Objects и VCL Methods:
Известные ограничения
Важно понимать, что PE Explorer не декомпилирует код. Он дизассемблирует код, т.е. преобразует машинный код в ассемблерный код. При этом он не генерирует код на С или С++ из полученного листинга. Сама по себе эта задача невероятной сложности, так еще при этом часто в исполняемом файле либо нет никаких упоминаний о том, какой язык программирования был использован для создания программы, либо оригинальный язык был совсем не С++.
Дизассемблирование файлов размером более 1 Мб может занять несколько минут. Во многом скрость зависит от возможностей вашего компьютера. В общем случае, для каждого байта дизассемблируемого файла требуется 40 байт памяти. Т.е. для файла размером в 1 Мб требуется 40 Мб памяти, для 2 Мб - 40 Мб памяти, и так далее.
Полученный дизассемблерный листинг не может быть заново скомпилирован "как есть". Мы не ставили перед собой задачи формировать листинг, который мог бы быть рекомпилирован. Это не имеет большого смысла для сколь-либо значимого размера входного файла. Нашей целью было получить продукт, способный БЫСТРО и достаточно качественно дать представление о содержимом исполняемого файла, обнаружить в нём интересующие исследователя места и проанализировать их. Получение же листинга, способного быть откомпилированным, представляется нам задачей мало применимой в реальной жизни в силу внушительных размеров современных исполняемых файлов и, как следствие, КРАЙНЕ ВЫСОКОЙ СЛОЖНОСТИ качественного анализа ВСЕХ данных, содержащихся в программе. Нам кажется, что имеет смысл вести разговор только о возможности извлечь какую-либо процедуру из листинга для использования ее в своих целях (естественно, в рамках действующего законодательства).
Есть DLL. Небольшая 12kb, написана на native C++ со вставками ассемблера (исходников не имею). Мне нужно провести дизасемблинг этой DLL, и затем создать проект который будет открываться и компилироваться в Visual Studio. Пожалуста, подскажите как и какими инструментами я могу это сделать.
Разве это законно?
Дизассемблирование незаконно, кроме случая подозрения на вирусную и вредноносную программу.
Зависит от лицензии.
А раздел все-равно не тот.
Есть случай, когда дизассемблироание вполне законно - когда программу нужно дизассемблировать её владельцу. Как правило это ситуация, когда программист для фирмы написал что-то и ушёл, а исходники не сохранились. И нужно в программу внести изменения.
Если бы не ушёл, ему проще было бы по памяти заново её написать.
Нужен дизассемблер, например IDA. Можно просмотреть в редакторе типа HIEW или QVIEW (правда последние известные мне версии смотрят только 32-разрядные PE-файлы для Win95/98, и возможно 2000/XP) в режиме дизассемблирования.
Небольшую программу можно пройти в отладчике.
Правда на дизассемблер нужна лицензия. На редакторы вроде тоже.
И надо знать, что такое дизассемблирование может оказаться по трудоёмкости сравниться с написанием программы с нуля.
Пожалуста, подскажите как и какими инструментами я могу это сделать.
Cпасибо всем за ответы, тему можно закрывать. Пожалуста, подскажите как и какими инструментами я могу это сделать.
ИМХО. Если бы ты умел это делать, то таких вопросов не задавал бы. Не получится взять и скомпилировать код из дизассемблера -- это лишь инструмент для анализа. Если логика работы понятна, то проще написать самому с 0 на известном языке. К тому же размер в 12Кб намекает, что там не слишком богатый функционал.
Добавлено 20.12.15, 16:25
Ну эпически повезло, что еще можно сказать Но я бы настоятельно рекомендовал тщательнее потестировать после этого.
Работы по сложности разные бывают.
Корректировка констант или текстовых строк полегче будет.
Человек спрашивает как сделать, а не о законности
Есть DLL. Небольшая 12kb, написана на native C++ со вставками ассемблера (исходников не имею). Мне нужно провести дизасемблинг этой DLL, и затем создать проект который будет открываться и компилироваться в Visual Studio. Пожалуста, подскажите как и какими инструментами я могу это сделать.С большой вероятностью это не получится. Тоесть ты можешь сохранить листинги дизассемблера, но скомпилировать обратно будет крайне сложно и потребует много ручной работы.
Проще говоря, нужно ли оно тебе? Если просто поиграть, то пожалуйста. Если нужно пропатчить файл чтобы работал "так как нужно", то это решается классическим бит-хаком за пару минут.
Всё просто, если знаком с темой реверса.
Алгоритм такой:
0. Качаешь IDA Pro с торрента, можно даже официальную демоверсию с сайта, её функциональности для этой задачи будет более чем достаточно. Впрочем по сети гуляют полные версии с тыреными лицензиями
1. Закидываешь в неё файлик, ждешь пока разберется, ишешь нужное тебе место
2. Патчишь (либо при помощи замены инструкции, в меню есть такая фишка, либо в окошке HEX редактора заменой байт, смотря что нужно запатчить)
3. В меню "Файл" есть пункт "применить патч" или как то так, файл записывается с внесенными изменениями
Подробней не скажу т.к. это не будет иметь ценности, если не знаком с реверсом, то придется сначала в это погрузиться.
Если есть конкретные вопросы - подскажу.
Читайте также: