Лучшие инструменты пентестера: отладчики и дизассемблеры

Содержание статьи

У каждого из команды ][ — свои предпочтения по части софта и утилит для
пентеста. Посовещавшись, выяснилось, что выбор так разнится, что можно составить
настоящий джентльменский набор из проверенных программ. На том и решили. Чтобы
не делать сборную солянку, весь список мы разбили на темы. Сегодня мы разберем
отладчики и дизасемблеры — все, что понадобится для реверсинга приложений.

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

Входит в состав WDK (Windows Driver Kit — бывший Driver Development Kit или
DDK), а также в комплект Debugging Tools. Оба они бесплатны, но WDK намного
больше по объему и требует предварительной регистрации для получения Windows
Live ID, в то время как Debugging Tools раздается без регистрации вместе с SDK,
в которую входит документация, заголовочные файлы, библиотеки и несколько
примеров, как надо писать плагины.

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

Отличный дизассемблер, удобный и понятный. Набор функций с точки зрения
профессионала довольно ограничен, да и вообще его пора отнести к инструментам из
прошлого века, но нет. W32DASM выдает хороший листинг, и для новичков является
отличным вариантом понять и разобраться, что к чему. К тому же именно на него
опираются в многочисленных мануалов для новичков, в том числе нашим манулом для
начинающих «Крякинг — это просто» (#80
номер ][).

Начинающие хакеры обычно испытывают большие трудности при взломе программ,
написанных на 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-функций, редактор ресурсов, дизассемблер.

Инструментарий для анализа и отладки .NET приложений

Заглянуть «под капот» кода или посмотреть на внутреннее устройство CLR можно с помощью множества инструментов. Этот пост родился из твита, и я должен поблагодарить всех, кто помог составить список подходящих инструментов. Если я пропустил какие-то из них, напишите в комментариях.

Во-первых, я должен упомянуть, что хороший отладчик уже присутствует в Visual Studio и VSCode. Также существует множество хороших (коммерческих) профилировщиков .NET и инструментов мониторинга приложений, на которые стоит взглянуть. Например, недавно я попробовал поработать с Codetrack и был впечатлён его возможностями.

Однако оставшийся пост посвящён инструментам для выполнения отдельных задач, которые позволят лучше понять, что происходит. Все инструменты имеют открытый исходный код.

PerfView от Вэнса Моррисона

PerfView – великолепный инструмент, который я использую уже несколько лет. Он работает на основе трассировки событий Windows (ETW) и позволяет лучше понять, что происходит внутри CLR, а также даёт возможность получить профиль использования памяти и центрального процессора. Чтобы освоить инструмент, придётся впитать много информации, например с помощью обучающих видео, но это стоит потраченного времени и усилий.

Инструмент настолько полезен, что сами инженеры Microsoft используют его, а многие из недавних улучшений производительности в MSBuild появились после анализа узких мест с помощью PerfView.
Инструмент создан на базе библиотеки Microsoft.Diagnostics.Tracing.TraceEvent library, которую можно использовать для создания собственных инструментов. Кроме того, поскольку исходный код библиотеки является открытым, в ней благодаря сообществу появилось множество полезных функций, например графики flame-graphs:

SharpLab от Андрея Щёкина

SharpLab появился как инструмент для проверки IL-кода, генерируемого компилятором Roslyn, и со временем превратился в нечто большее:

SharpLab – интерактивная среда для запуска кода .NET, в которой отображаются промежуточные шаги и результаты компиляции кода. Некоторые функции языка – всего лишь обёртки для других, например using() становится try/catch. С помощью SharpLab вы увидите код, как его видит компилятор и лучше поймёте суть языков .NET.

Инструмент поддерживает C#, Visual Basic и F#, но самыми интересными функциями в нём являются Decompilation/Disassembly:
Функции декомпиляции/дизассемблирования можно использовать для:

Вы правильно поняли: инструмент выводит код ассемблера, который .NET JIT генерирует из вашего кода C#:

Object Layout Inspector от Сергея Теплякова

С помощью этого инструмента вы сможете проанализировать структуру .NET объектов в памяти, т.е. как JITter расположил поля, принадлежащие вашему классу или структуре. Это полезно при написании высокопроизводительного кода. Кроме того, приятно иметь инструмент, который сделает сложную работу за нас.

Официальной документации, которая бы описывала структуру полей, не существует, поскольку авторы CLR оставили за собой право изменить её в будущем. Но знания о структуре могут быть полезны, если вы работаете над быстродействующим приложением.
Как можно изучить структуру? Можно посмотреть на необработанную память в Visual Studio или использовать команду !dumpobj в SOS Debugging Extension. Оба подхода требуют много усилий, поэтому мы создадим инструмент, который будет выводить структуру объекта во время выполнения.

Согласно примеру в репозитории GitHub, если вы используете TypeLayout.Print () с подобным кодом:

появится следующий вывод, который точно покажет, как CLR расположит struct в памяти на основании правил оптимизации и заполнения байтами.

The Ultimate .NET Experiment (TUNE) от Конрада Кокосы

Как сказано на странице GitHub, TUNE – многообещающий инструмент. Он поможет изучить внутреннее устройство .NET и способы повышения производительности с помощью экспериментов с кодом C#.

Подробную информацию о нём можно узнать из этого поста, но на высоком уровне он функционирует следующим образом:

• напишите работающий пример кода на C#, который содержит хотя бы один класс с публичным методом, принимающим один строковый параметр. Код запускается с помощью кнопки Run. Вы можете включить любое количество методов и классов. Но помните, что первый публичный метод из первого публичного класса будет выполнен с использованием первого параметра из окна ввода под кодом;
• нажмите кнопку Run, чтобы скомпилировать и выполнить код. Кроме того, он будет компилирован в IL-код и код ассемблера в соответствующих вкладках;
• пока Tune работает (в том числе во время выполнения кода), инструмент строит график, отображающий данные сборщика мусора. Он содержит информацию о размерах поколений и сеансах сбора мусора (представлены в виде вертикальных линий с числом внизу, которое указывает на то, в каком поколении выполняется сборка мусора).

Выглядит это следующим образом:

Инструменты на базе CLR Memory Diagnostics (ClrMD)

Наконец, давайте взглянем на определённую категорию инструментов. С момента выхода .NET разработчики всегда могли использовать WinDBG и SOS Debugging Extension, чтобы посмотреть, что происходит в среде выполнения .NET. Однако, это не самые простые инструменты для первого знакомства и, как сказано в следующем твите, не всегда самые продуктивные:

Very true. While hardcore windbg/sos skills are impressive, teaching them to novices without outlining the easier, less threatening alternatives is harmful. https://t.co/jQanX9LVtz

К счастью, Microsoft сделал доступной библиотеку ClrMD (также известную, как Microsoft.Diagnostics.Runtime), и теперь любой может создать инструмент для анализа дампов памяти программ .NET. Подробную информацию можно прочитать в официальном блоге. Я также рекомендую взглянуть на ClrMD.Extensions, которые “… обеспечивают интеграцию с LINPad и делают использование ClrMD ещё проще”.

Я хотел собрать список всех существующих инструментов и призвал на помощь твиттер. Напоминалочка самому себе: осторожнее с твитами. Менеджер, ответственный за WinDBG, может прочитать их и расстроиться!

Lazy web, I’m trying to put together a list of tools that help you debug .NET internals, specifically ones that replace the functionality you can find in WinDBG. Are there any I’ve missed out? https://t.co/sg0RY0xVUH pic.twitter.com/XBYuSLSL2y

Большинство этих инструментов работают на базе ClrMD, потому что так проще всего. Но при желании можно использовать COM-интерфейсы напрямую. Также нужно заметить, что любой инструмент на базе ClrMD не является кроссплатформенным, поскольку сама ClrMD предназначена только для Windows. Описание кроссплатформенных вариантов можно найти в Analyzing a .NET Core Core Dump on Linux.

Наконец, чтобы как-то соблюсти баланс, недавно появилась улучшенная версия WinDBG, которой сразу же попытались добавить функциональность:

После всех этих слов переходим к списку:

• SuperDump (GitHub)
  • Средство для автоматического анализа аварийного дампа (презентация)
• msos (GitHub)
  • Среда с интерфейсом командной строки типа WinDbg для выполнения SOS-команд при отсутствии SOS.
• MemoScope.Net (GitHub)
  • Инструмент для анализа памяти процесса в .NET. Можно сделать дамп памяти приложения в файл и прочитать его позже.
  • Файл содержит все данные (объекты) и информацию о тредах (состояние, стек, стек вызовов). MemoScope.Net проанализирует данные и поможет найти утечки памяти и взаимные блокировки.
• dnSpy (GitHub)
  • Отладчик и редактор сборок .NET
  • Его можно использовать для редактирования и отладки сборок, даже если у вас нет исходного кода.
• MemAnalyzer (GitHub)
  • Инструмент анализа памяти для управляемого кода. Присутствует интерфейс командной строки.
  • Подобно !DumpHeap в Windbg может определить, какие объекты занимают больше всего места в куче без необходимости устанавливать отладчик.
• DumpMiner (GitHub)
  • Инструмент с графическим интерфейсом для работы с ClrMD. Больше возможностей появится в будущем.
• Trace CLI (GitHub)
  • Инструмент для отладки и отслеживания во время эксплуатации
• Shed (GitHub)
  • Shed – приложение, которое анализирует выполнение программы в .NET. Его можно использовать для анализа вредоносного ПО, чтобы получить данные о том, какая информация сохраняется, при запуске такого ПО. Shed может:
  • извлекать все объекты, хранящиеся в управляемой куче;
  • выводить строки, хранящиеся в памяти;
  • создавать моментальный снимок кучи в формате JSON для последующей обработки;
  • делать дамп всех модулей, загруженных в память.

Вы можете найти множество других инструментов, которые используют ClrMD. Сделать её доступной было хорошей идеей Microsoft.

Другие инструменты

Стоит упомянуть и другие инструменты:

• DebugDiag
  • Инструмент DebugDiag создан для устранения таких проблем, как зависания, низкая производительность, утечки памяти или её фрагментация, а также отказы процессов, выполняющихся в пользовательском режиме (теперь с интеграцией CLRMD).
• SOSEX (возможно больше не разрабатывается)
  • … расширение для отладки управляемого кода, которое снижает моё недовольство SOS.
• VMMap от Sysinternals
  • VMMap – средство для анализа виртуальной и физической памяти процессов.
  • Я применял его, чтобы проанализировать использование памяти в CLR