Отладчики программ и какие есть

Содержание

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

Сегодня есть множество IDE, поддерживающих работу с Go и позволяющих отлаживать приложения. На текущий момент для Go представлены два отладчика: GDB (но он не поддерживает многие фичи языка, например Go-рутины) и Delve. Многие IDE используют последний как дефолтный отладчик. И в этой статье я расскажу о возможностях Delve: о том, что умеет сам отладчик, а не что нам предоставляет IDE.

Основы работы с Delve

Для того чтобы начать работу с отладчиком, нужно скомпилировать программу на Go и выполнить в командной строке команду dlv debug, находясь в директории с исполняемым файлом. После этого мы попадём в Delve. Для начала работы требуется установить первую точку останова и выполнить команду continue.

Пошаговая отладка программ с выводом переменных | О самом простом | Program DEBUG

Возьмём простую программу на Go, которая читает данные из текстового файла и обновляет его, если объём данных не превышает 12 байт. А если объём равен 12 байтам, то программа просто выводит строку hello и завершает выполнение.

package main import ( «fmt» «io/ioutil» «log» «os» ) func main() < file, err := os.Open(«test.txt») defer file.Close() data, err := ioutil.ReadAll(file) if err != nil < fmt.Errorf(» problem: %v», err) >fmt.Println(data) fmt.Println(len(data)) if len(data) == 12 < fmt.Println(«hello») return >data = append(data, byte(len(data))) err = ioutil.WriteFile(«test.txt», data, 0644) if err != nil < log.Fatal(err) >>

Так выглядит моя директория перед компиляцией:

Теперь скомпилируем программу, выполнив команду go build main.go в командной строке. В результате должно получиться вот что:

Получив бинарный файл, заходим в директорию с ним и выполняем команду dlv debug:

Далее устанавливаем в файле точку останова на строке номер 14, выполнив команду break main.go:14:

И запускаем отладку с помощью команды continue:

Онлайн отладчик программ

Исполнение программы остановилось на 14-й строке. Теперь можно посмотреть значения переменных:

Чтобы продолжить отладку, нужно в командной строке либо выполнить команду next (и тогда выполнится следующая строка кода), либо набрать continue, (и программа выполнится до следующей точки останова).

Теперь вкратце расскажу про основные команды Delve, с помощью которых вы сможете отлаживать свои приложения:

next — следующая строка;
step — вход внутрь вызываемой функции:
continue — следующая точка останова (breakpoint):
break — установка точки останова, например break m67 main.go:67;
cond — задаёт условия, при которых произойдёт останова на текущей команде отладки. Например, при выполнении команды cond m67 len(array) == 8 сработает останова на этой строке, если в массиве будет восемь элементов;
breakpoints — отображает все заданные точки останова;
print — распечатывает значение выражения или переменной;
vars— выводит значения всех загруженных переменных приложения:
locals — выводит значения локальных переменных функции:

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

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

Пишем свои команды на Starlark

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

На Starlark, например, можно написать команду для создания дампа текущего приложения и перезапуска его отладки уже с новыми дампом и данными. Такая функциональность может пригодиться, если какая-то ошибка воспроизводится только в очень «экзотических» случаях.

Структура программ-конфигураций на языке Starlark:

def command_название команды «Комментарий, который будет выведен, если набрать help имя команды» Далее пишем код.

Синтаксис языка можно посмотреть здесь.

Давайте рассмотрим пример создания команды для Delve:

def command_flaky(args): «Repeatedly runs program until a breakpoint is hit» while True: if dlv_command(«continue») == None: break dlv_command(«restart»)

Эта команда будет перезапускать отладку до тех пор, пока не будет достигнута точка останова. Чтобы выполнить её в Delve:

Сохраните команду в файл с расширением .star.
Запустите Delve.
Выполните в командной строке команду source flaky.star.
Расставьте точки останова.
Выполните команду flaky.

Для работы с flaky возьмём программу из предыдущего раздела. Пример того, что отобразится в консоли отладчика:

Как видите, программа была перезапущена семь раз, и при каждом выполнении условия срабатывала точка останова. Отлавливать такие вещи вручную в Visual Studio Code и других средах разработки не так-то просто.

Если вам интересно, что ещё можно сделать в Delve с помощью Starlark-синтаксиса, за подробностями добро пожаловать сюда. А если вы не любите использовать командную строку или не хотите разбираться в тонкостях «неродного» языка, то давайте рассмотрим, как сделать то же самое на Go.

Написание плагинов на Go

Рассмотрим этот процесс на примере удалённой отладки приложений. В Delve реализован gRPC-сервер, к которому можно обращаться по API. Для этого сначала необходимо установить Delve рядом с приложением. Если вы используете микросервисную архитектуру, то можно добавить этот инструмент в образ вашего контейнера.

Возьмём код из первого раздела и попробуем отладить его с помощью Go. Для этого нам нужно выполнить в командной строке команду:

dlv exec —continue —headless —accept-multiclient —api-version 2 —listen 0.0.0.0:50080 main

Открываем любимую IDE и пишем на Go:

package main import ( «encoding/json» «fmt» «os» «github.com/go-delve/delve/service/api» «github.com/go-delve/delve/service/rpc2» ) func main() < serverAddr := «localhost:50080» funcToTrace := «main.main» // Create a new connection to the Delve debug server. // rpc2.NewClient will log.Fatal if connection fails so there // won’t be an error to handle here. client := rpc2.NewClient(serverAddr) defer client.Disconnect(true) // Stop the program we are debugging. // The act of halting the program will return it’s current state. state, err := client.Halt() if err != nil < bail(err) >bp := FunctionName: funcToTrace, Tracepoint: true, Line: 12, >client.Restart(false) tracepoint, err := client.CreateBreakpoint(bp) if err != nil < bail(err) >defer client.ClearBreakpoint(tracepoint.ID) for _, i := range []int < fmt.Printf(«i:t %dn», i) client.Restart(false) // Continue the program. stateChan := client.Continue() // Create JSON encoder to write to stdout. enc := json.NewEncoder(os.Stdout) fmt.Println(«____________________________________________») fmt.Println(«state») for state = range stateChan < // Write state to stdout. enc.Encode(state) >fmt.Println(«____________________________________________») > > func bail(s interface<>)

Что происходит на стороне сервера, когда идёт отладка:

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

Заключение

Я только поверхностно ознакомил вас с возможностями Delve. Показал, что мы можем отлаживать код и без IDE. Можно писать анализаторы поведения программ и приложения для отладки своего приложения. Наконец, функциональность Delve можно расширять собственными командами, что делает его очень мощным инструментом.

Дополнительная литература

Удалённая отладка контейнера с помощью Delve и IDE
Удалённая отладка приложения с помощью Delve и GoLand

Источник: habr.com

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

В недавнем интервью с Джоном Скитом мы пришли к выводу, что профессиональная работа с любой технологией подразумевает умение диагностировать проблемы и понимать, как ваши приложения работают под капотом. Вдогонку к тому разговору, я узнал у Саши goldshtn Гольдштейна, одного из лучших в мире экспертов по производительности .NET, автора книги «Pro .NET Performance», на какие инструменты следует обратить внимание .NET-разработчикам.

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

Подробнее про все инструменты и про то, как с их помощью решать проблемы с производительностью ваших приложений на практике Саша расскажет 21 мая на тренинге в Петербурге.

Typeperf and Perfmon

Счетчики производительности Windows — первый шаг к получению высокоуровнего обзора того, чем занята ваша система. Мониторинг использования CPU и памяти, диска и I/O, сетевых пакетов и HTTP-запросов позволяет получить обзор работы системы с высоты «птичьего полета» с малым оверхэдом и понять, куда копать дальше.

Perfmon (Performance Monitor) является встроенным в Windows инструментом, который не только предоставляет доступ к панели счетчиков производительности в реальном времени, но и позволяет записывать данные счетчиков, чтобы посмотреть их позже на другом компьютере, и даже настроить автоматические уведомления на случай, если что-то пойдет не так. Для любителей командной строки есть Typeperf — инструмент, записывающий данные счетчиков в CSV файл, который впоследствии можно легко парсить и автоматически анализировать. Эти два инструмента позволяют быстро понять, на что следует обратить внимание в первую очередь, а также нормально ли работает ваша система. Впрочем, для глубокого исследования они, конечно, не подходят, поскольку счетчики просто показывают вам цифры, отображающие те или иные аспекты работы операционной системы.

Typeperf documentation on TechNet
Perfmon documentation on TechNet

XPerf, WPR, and WPA (Windows Performance Toolkit)

За последние 10 лет ETW (Event Tracing for Windows) стал весьма распространенным инструментов и по факту оказался стандартом де-факто среди инструментов анализа производительности под Windows. Записывая и анализируя данные ETW, можно на уровне ОС осуществлять профайлинг ЦПУ, исследовать блокировки, выяснять, какие части вашего приложения создают высокую нагрузку на диск или на сеть, и даже отслеживать сборку мусора, аллокации памяти и события загрузки сборок самого NET. XPerf — более старый консольный инструмент для записи ETW событий, имеющий несколько аналитических модулей для измерения производительности I/O, составления отчетов работы CPU и расчета «стоимости» запуска приложений. Кроме того, он умеент конвертировать записи ETW в CSV формат, который можно легко парсить другими инструментами и скриптами. WPR (Windows Performance Recorder) — графическая оболочка, позволяющая выбирать события, которые вы хотели бы записать.

Есть еще WPA (Windows Performance Analyzer), современный инструмент для просмотра записей ETW, способный строить графики, сводные таблицы с разными фильтрами и группировками, а также отдельные вьюшки для определенных событий: CPU стэков, аллокаций памяти, I/O запросов и этапов загрузки. Совсем недавно появилась поддержка flame graphs, нового метода отображения больших деревьев стека, позволяющий с легкостью их анализировать.

В общем, инструменты под ETW отлично подходят для анализа на продакшне, хотя их можно использовать и в разработке. Главным недостатком этих решений является относительное неудобство их использования по сравнению с коммерческими профайлерами.

PerfView

Основная проблема инструментов Windows Performance Toolkit заключается в том, что они не заточены под мониторинг на управляемые процессы и CLR-специфичные события, такие как сборка мусора, управляемые исключения, загрузка сборок или JIT-компиляция. PerfView представляет из себя open source инструмент от Microsoft, который может записывать, собирать и отображать события CLR, включая те собтия, которые вы инициируете сами при помощи EventSource API, доступном начиная с .NET 3.5. У PerfView есть несколько уникальных возможностей: например, отображение дампов кучи управляемых процессов в очень удобном виде (в котором очень легко обнаруживать утечки памяти); сворачивание и группировка стэков вызовов, позволяющая быстро разбираться с тысячами data points, и сбор данных по .NET событиям вроде GC и аллокаций. К сожалению, интерфейс PerfView делал перфоманс-инженер, так что он не слишком интуитивен и требует определенного периода привыкания, после которого вы сможете работать с инструментом на все 100.

Etrace and LiveStacks

На DotNext 2017 Piter Саша представит несколько собственных open source разработок, которые он сам использует для «очного» исследования производительности и которые не требуют генерации больших объемов данных и последующего их анализа. Первый из них — etrace, который генерирует живой лог интересных ETW событий и дает много возможностей по их фильтрации. Пример: вы можете попросить etrace вывести сообщение в момент использования какого-либо конкретного файла, когда в процессе происходит полная (generation 2) сборка мусора, когда загружается какая-то конкретная .NET assembly, или когда ASP.NET-приложение бросает управляемое исключение. Работа из командной строки позволяет использовать etrace в скриптах и быстро получать результаты, не копаясь в GUI.

Второй инструмент — LiveStacks, похожий на профайлер инструмент, предназначенный для захвата и объединения стеков событий в реальном времени. Если точнее, то LiveStacks собирает управляемые стеки вызовов (имена методов), исследуя память целевого процесса, в отличие от традиционного ETW подхода, требующего завершения сессии профилирования для генерирования и парсинга CLR rundown events. Как результат такого подхода — быстрый, легковесный и эффективный инструмент, способный сохранять стек в компактном виде, пригодном для формирования flame graph. Если вам нужны быстрые результаты на продакшне и вы не брезгуете поработать в консоли, надеюсь, эти инструменты будут вам полезны.

etrace GitHub repository
LiveStacks GitHub repository

Procdump and DebugDiag

Инструменты, описанные выше, прежде всего нацелены на оптимизацию производительности, хотя при помощи того же ETW я отловил множество багов и утечек памяти. Однако в некоторых случаях вам может понадобиться полный дамп памяти сломанного процесса, который можно было бы изучить на продакшен системе или потом в вашем development environment. В Windows есть несколько инструментов, предназначенных для создания дампов, мы здесь поговорим о двух из них: Procdump, очень гибкое бесплатное консольное приложение от Sysinternals, генерирующее дампы по различным триггерам (% использования CPU, объем используемой памяти, неотвечающие окна и прочие); и DebugDiag, инструмент для мониторинга, который можно очень тонко настроить для фонового отслеживания ваших процессов в ожидании неполадок. Есть очень много ошибок, найти которые можно лишь изучая дамп, или даже несколько дампов, сделанных с определенной периодичностью, поэтому создание инфраструктуры для получения таких дампов может стать задачей номер один.

WinDbg

Вообще, для анализа дампов и получения из них максимума информации можно использовать Visual Studio, однако лучше обратить внимание на WinDbg и его всевозможные расширения. WinDbg, Windows Debugger, это мощный и очень unfriendly инструмент для отладки работающих процессов и анализа дампов.

Вооружившись расширениями (такими как SOS, SOSEX, NetExt, and MEX), вы получите огромные возможности: исследование управляемой кучи, поиск неиспользуемых и неудаляемых объектов, находить задедлоченные потоки одной командой, обнаруживать ASP.NET запросы в реальном времени и делать множество других исследований. Важно отметить, что WinDbg можно управлять как внешними скриптами (запуская его из командной строки с определенными параметрами), так и внутренними (написанными на скриптовых языках или C/C++/C# DLL). Все это дает значительно более гибкие возможности для отладки в сравнении с VS или другими IDE, а его легковесность позволяет ставить его на продакшн и использовать для real-time мониторинга. Поверьте, вы оцените эту возможность не копировать к себе 50 гигабайтный дамп, когда окажется, что ваш сервер находится за 5000 километров от вас, а ширина канала не превышает 1 мегабита в секунду.

Кстати, на прошлом DotNext, Саша уже рассказывал много интересного про WinDbg.

Msos

Этот список был бы неполным, если бы не еще одно приложение (которое Саша написал сам), предназначенное для решения одной весьма неприятной проблемки с анализом дампов: у меня были файлы с Windows Phone, а для WinPhone CLR нет публичного SOS расширения, столь нужного для любого вида управляемого анализа дампов в WinDbg. Потому я написал свой open-source дебаггер на основе Windows Debugging API (DbgEng) и библиотеки Microsoft CLRMD. Msos — это open-source фреймворк, предоставляющий SOS интерфейсам управляемую оболочку. Со временем msos оброс уникальными фичами, которые отделили его от WinDbg и SOS:

Запросы выборок объектов из кучи, например «Найди все HTTP запросы, ожидающие более 2 секунд» или «найди все объекты типа CustomerData где параметр AmountDue отрицательный»;
Обнаружение дедлоков в управляемых и native механизмах синхронизации;
Поддержка индексации хипа для быстрого обхода графов;
Кастомный генератор дампов памяти, игнорирующий регионы памяти, ненужные для анализа управляемых дампов (таким образом сохраняя до 80% дискового пространства);
Режим автоматической сортировки, генерирующий лаконичный JSON отчет с минимумом данных, требуемых для более глубокого исследования. Я понимаю, что большинство из вас продолжит использовать VS для повседневной отладки, и это нормально. Однако мой инструмент позволит вам справляться с самыми неприятными ситуациями.

А если целый день отладке и производительности вы уделять не хотите, то встретиться с Сашей и еще 30 .NET-гуру со всего мира можно будет на DotNext 2017 Piter.

UPD. Мы снова делаем тренинг с Сашей, в этот раз в Москве: регистрация и условия участия есть на сайте.

Блог компании JUG Ru Group
Высокая производительность
.NET
Отладка
C#

Источник: habr.com

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

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

OllyDbg

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

YDbg

Популярный и очень мощный мод, основанный на Ольге 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.

GDB

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
номер ][).

DeDe

Начинающие хакеры обычно испытывают большие трудности при взломе программ,
написанных на Delphi и Builder, поскольку классические трюки, типа бряка на
GetWindowTextA, не работают. Для декомпиляции кода, написанного на Delphi/Borland
C++ Builder, т.е программ, которые используют библиотеку VCL от Borland, нужен
специальный подход, и он реализован в утилите DeDe. По сути, это единственный
работающий декомпилятор для Delphi-программ, которые не смотря ни на что никак
не умирают. DaFixer, автор проекта, к сожалению, забросил заниматься своим
детищем, поэтому официальной страницы у проекта в настоящий момент нет.
Подробнее о том, как совладать с программами на Delphi, читай в статье «Взлом
Борландии: изящная декомпиляция Delphi».

PEiD

Любой коммерческий продукт должен быть достаточно хорошо защищен.
Разработчики намеренно использует разного рода упаковщики и так называемые
протекторы, которые применяют разного рода антиотладочные средства, максимально
препятствующие взлому программы. Обойти их можно, но для этого нужно четко
представлять, что использовалось для защиты программы, какой плагин для
отладчика использовать — и от этого «крутиться». Изящно определить название и
версию упаковщик способна небольшая утилита PEiD. Собственно, для этого она и
нужна.

PE Explorer

Программа для просмотра и редактирования PE-файлов — начиная с EXE, DLL и
ActiveX контролов, и заканчивая скринсейвверами SCR (Screensavers), апплетами
панели управления CPL, SYS и бинарниками для платформы Windows Mobile. По сути,
это не одна утилита, а целый набор тулз для того, чтобы посмотреть изнутри, как
работает программа или библиотека. Включает в себя просмотрщик заголовков,
экспорт вызовов API-функций, редактор ресурсов, дизассемблер.

Источник: xakep.ru