//Всем привет, я тут давненько не заглядывал…
А давайте поговорим об отладчиках. Ниже средних размеров простыня, приглашаю к дискуссии
(Disclaimer: ко всему ниже написанному следует приписывать "ИМХО")
<intro, to skip>
Я в последнее время стал реже подходить к компьютеру по поводу поковыряться в каком-нибудь коде, да и поводов стало меньше, зато они теперь несколько разнообразнее. Раньше основным поводом было получить кряк/серийник к какой-нибудь очень внезапно нужной программе, и, обитая на своём милом windows xp на компе с celeron-ом, в далёком детстве я запускал win32dasm и более или менее работавший в те времена softice да, в общем-то, особо и не жаловался. Потом связка поменялась на ida + olly, и она для поставленной задачи и до сих пор подходит вполне. Топик я хочу посвятить современным проблемам отладчиков. Вот, об упомянутом olly в (относительно) последнее время я не раз видел не очень хорошие слова вроде: "Это неудобная штука, но лучше нету, поэтому и юзаем", холиварить не хочу, но, тем не менее, факт остаётся фактом: олли вполне себе прижился и, не побоюсь этого слова, полюбился. Он выигрывал из-за всяких мелких удобных деталей, которые фиг, в общем-то, опишешь, плюс он обладал возможностью допиливания нужных фич плагинами. Но времена и задачи менялись…
</intro>
И пришло время ещё подумать об отладчиках, ну и о процессе в целом. В качестве дизассемблера альтернатив иде вроде (поправьте?) нету, так что в основном меня интересуют отладчики. Итак, что мы имеем (о чём я, человек, не очень следящий за прогрессом, знаю):


Сетап 1. Windows x32, usermode. (без исходников)
Связка первая: ollydbg (отладчик) + ida (дизасм) + (с некоторых пор) hexrays.
Ну, классический набор. Уютно и привычно, кругом баги и костыли, хотя в общем-то, сносно и, как показывает опыт, юзабельно. Какие-то комментарии давать излишне, не думаю, что есть много людей, работающих по-другому (поправьте?)

Связка первая ver2: ollydbg 2 (отладчик) + ida (дизасм) + (с некоторых пор) hexrays.
Я как-то привык к первой оле, но тут вроде есть плюсы в виде багфиксов и минусы в виде до сих пор не большого количества плагинов (и, на мой взгляд, очень зря внесены мелкие изменения в интерфейс). Кажется, принципиальных отличий нету, и тут уже вопрос лишь в том, задолбался ли я фиксить проблемы с использованием подстроенного под себя olly 1. Не суть. А, мелочь, а приятно: есть debug child process.

Связка вторая: windbg + ida.
Но зачем??

Связка третья: ida + ida.
Ну, можно… представить себе, что такое иногда надо, но olly почти всегда предпочтительнее.

Связка четвёртая: immunity + ida.
Ну питончик там, пара няшек… Тот же олли, немножко подточенный под эксплоитинг.


Вердикт: в общем, такой сетап живёт давно и разрешается.


(пока не забыл, но основной мой интерес не тут) Сетап 2. Windows, .NET. (без исходников)
Связка первая: Reflector + Visual Studio
+: ну чё, сразу исходники, backtrace, все дела
-: замена jne на je — уже костыли через плагины; всякие стронгнеймы, которые надо снимать вручную, обфускаторы.

Связка вторая: ? + ildasm
+: дизасмит всё
-: и что дальше?

Связка третья: windbg + ildasm/reflector
+: позволяет трейсить всё, что угодно
-: минусы windbg (см. ниже), работа не с пи-кодом (или как там оно называется, простите, склероз), а с уже jit-скомпиленным, невозможно вносить осмысленные изменения и сохранять отладочные изменения даже между перезапусками, костыли при загрузке.

Связка четвёртая: ollydbg + ILLY
+: ?
-: я как-то пытался запустить, не получилось


Вердикт: куча костылей, если код обфусцирован и не декомпилится. Да и если декомпилится, то пересобирать из-за небольших правок — слишком муторно.


Сетап 3. Windows, kernelmode. (без исходников / с исходниками)
Связка первая: windbg/kd (+ ida)
+: клёво, стандартный виндовый интерфейс, всё работает; куча powerful консольных команд
-: всё-таки хочется гуишку. Я вот почти никогда в жизни не читал мануалы, а консольные команды сами по себе не придумываются Если использовать не очень часто, то команды вылетают из головы, и каждый раз надо снова их искать. Помимо этого нет всяких удобных фич оли вроде "внести правку в файл", "потыкать в команды", ну и прочих прелестей гуишек. В общем, годится для отладки драйверов для поиска в них ошибок, но имхо не очень удобно для задач, где требуется вносить много мелких правок в код/память. Ну и для эксплоитинга.
.: Кажется, если добавить гуй по типу оли, оставив консольные возможности, то было бы идеально, вот.

Связка вторая: syser (+ ida) (только x32, да?)
+: есть GUI
-: unstable, работает локально, из-за чего не удаётся параллельно работать в нескольких программах; если что-то нужное не реализовано (а этого добра навалом), то оно уже не реализовано, и никак с этим не побороться


Вердикт: windbg, жить можно, но почему за столько лет никто не приделал нормальный gui — не понимаю.


Сетап 4. Windows, usermode, WOW64. (без исходников)
то же, что и x32: оля более или менее справляется, но с костылями, плюс (поправьте?) плохо дело с плагинами для скрытия отладчика. Для задач эксплоитинга не очень важно, но для крякинга уж порой. Лучше на x32 тогда уж дебажить.


А тут уже интереснее:
Сетап 5. Windows, usermode, x64. (без исходников)
Связка первая: ida + ida
+ и - все сами понимают; не очень удобно, но я живу так. Фактически просто умеем выполнять код пошагово. Для всякого ассемблинга, правок используется блокнот, hex-редактор и чуть ли не таблицы опкодов.

Связка вторая: fdbg + ida (без исходников)
+: закос под olly
-: этот закос под olly уже не первый год остаётся просто неудачным нефункциональным закосом; всякий раз скачивал fdbg, смотрел на него, а потом не юзал. Потому что это olly без всех удобств.
Интересно, кто-нибудь юзает?

Связка третья: windbg + ida
Это как windbg в kernelmode, только usermode.


Вердикт: ну всё как-то неудобно, кто-то привык уже, наверное, а я вот не могу. И, почему fdbg такая гадость уже столько времени, непонятно.
Просто поассемблить код/поиграться с опкодами (для эксплоитинга порой хочется) — и то проблема.


Сетап 6. *nix, usermode, x32/x64.
Связка 1: gdb + ida (без исходников/с исходниками)
+: отлаживает всё
-: безумная неудобная консолька: как kd, только совсем неудобно. Как в нём люди сплоиты разрабатывают — не понимаю. Это ж сколько терпения надо иметь.

Связка 2: gdbserver/linux_sever + ida + ida (без исходников)
+/-: ну, получается, как обыкновенная отладка в иде. Сносно (см. выше).
дополнительные -: linux_server бажноват (по крайней мере, из паблика), через gdbserver — медленно. Вероятно, могут быть проблемы при отладке каких-нибудь крупных многофайловых проектов, не пробовал.

Связка 3: evan's debugger + ida (только x32, вроде; без исходников)
+: закос под олю
-: прямоты моих рук не достаточно, чтобы понять, почему у меня с ним ничего не получается


Вердикт: за дохрена лет существования линукса под него не написали ни одного нормального отладчика. Ну и стоит упомянуть стандартные линуксовые проблемы отладки и запуска кодов, скомпиленных на разных дистрибутивах.


Сетап 6. *nix, kernelmode.
Кажется, тут я вообще не умею.

Сетап 7. Windows, usermode, с исходниками.
Visual Studio rulez, нет?

Сетап 8. ARM.
В природе где-то есть hex-rays, а так я вообще не знаю, что тут делать. Ну и да, про всякие джавы вообще и мобильные apple-ы и андроиды тоже интересно, но тут я умею только запускать декомпиляторы

<outro>
1. Посмотрел, там в соседнем топике лежит Nanomite, надо бы потрогать.
2. Там вроде когда-то был грандиозный проект написать лабовский дебаггер, как с ним дела, расскажите, а?
</outro>

Ну что, расскажите, кто что думает, особенно про x64 и про линуксы.

| Сообщение посчитали полезным:

edb умеет x86-64 и он с исходниками.

| Сообщение посчитали полезным:

для gdb есть мордочка именуемая ddd
и все работает

| Сообщение посчитали полезным:

Zorn, а оно нормально работает? Или это только у меня настолько кривые руки?

reversecode, а вот у меня язык не поворачивается обозвать вот это вот гордым словом "мордочка":

(упс, скриншотик с армом оказался)

| Сообщение посчитали полезным:

а вы хотели интерфейс на куте? со стразами?


не вижу ничего плохого
и edb постоянно обновляется

| Сообщение посчитали полезным:

Честно говоря, хотел бы

Да, согласен, для отладки своего кода (или кода с исходниками) в оригинальном смысле слова "отладка" ddd можно использовать. Но всё равно даже здесь на фоне Visual Studio моё желание не кажется мне слишком порочным А отлаживать без сурсов… ну не ня же

| Сообщение посчитали полезным:

народ использует ida+linux_server и не парится

для тех кому стразы, ставят idademo для линукса и тоже не парятся

а кто парится ставить с исходников --> Link <--

| Сообщение посчитали полезным:

ой, слушайте, а edb и вправду изменился в лучшую сторону

| Сообщение посчитали полезным:

непонятно только зачем он нужен
ну ладно дебагеры для винды нужны, потому что протекторов много всяких и разных,
а под линуксом протекторов практически нет,
а то что требует отладки обычно с исходниками поставляется и банального gdb с консоли хватает поуши

| Сообщение посчитали полезным:

Windows, user mode x86-x64 => ida + ida
Есть все: и плаги, и питон и сокрытие. Правки hiew32 который держит обе архитектуры без проблем.

-----
старый пень

| Сообщение посчитали полезным:

Потыкался в edb, до сих пор сырой. Даже сессии сохранять всё ещё не научился.

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

reversecode пишет:
обычно с исходниками поставляется и банального gdb с консоли хватает поуши
как вообще можно терпеть консольный gdb для отладки с исходниками после виндовой visual studio?

r_e пишет:
Правки hiew32 который держит обе архитектуры без проблем.
неужели только я один очень люблю что-нибудь in-place во время исполнения править? а то патч в хиеве, открытие нового файла в иде, снова анализ, потеря бд, перезапуск… и так для каждой правки. да и вообще, порой хочется поправить код вне модуля (те же протекторы)… или это как-то побеждается (какими-нибудь плагинами)?

(да, если что, я тут ни на кого/ни на что не наезжаю, мне действительно интересно, как так жить)

| Сообщение посчитали полезным:

vptrlx, со всеми перечисленными задачами справляется ida + linux_server. Под freebsd правда это не пашет, а связка ida + gdb отвратна. Но возможно получится собрать linux_server из sdk под freebsd.
r_e, вставка asm во время исполнения ida тоже умеет. Edit->Patch program->Assemble...

| Сообщение посчитали полезным:

vptrlx
ИДА умеет инплейс во время исполнения. Правда, только в хексе. Плаг асма не помешал бы.

-----
старый пень

| Сообщение посчитали полезным:

Oott пишет:
вставка asm во время исполнения ida тоже умеет. Edit->Patch program->Assemble...

У меня в x64 не получается: 32-битные инструкции ассемблит, а 64-битные не хочет
//кстати, как потом патч в базе отменить?

| Сообщение посчитали полезным:

vptrlx пишет:
У меня в x64 не получается
Это да, ида не может ассемблировать 64 битные регистры. В некоторых случаях можно писать инструкции с 32битными регистрами, опкод для них будет аналогичен н.р. push eax: 50h , push rax: 50h. В остальных случаях добавлять перед опкодом \x48 или юзать такие https://defuse.ca/online-x86-assembler.htm#disassembly штуки. Как отменить изменения - хз.

| Сообщение посчитали полезным:

Отменить изменения можно попробовать через GetOriginalByte или как-то так. Ограничений не помню на нее правда.

-----
старый пень

| Сообщение посчитали полезным:

Вы так пишете, будто бы вам никогда это нужно не было

| Сообщение посчитали полезным:

vptrlx пишет:
захочется мне написать какой-нибудь эксплоит, там нужно и оффсетики поподбирать, и шеллкод подебажить
да бросте)
когда последний раз хотелось то? думаю давно)) и врядли захочется

vptrlx пишет:
как вообще можно терпеть консольный gdb для отладки с исходниками после виндовой visual studio?
строго говоря я уже давно ничего не отлаживаю
код пишется на глаз, а потом только первичные баги убираются
так что бы отладка... да еще по F7/F8 брр, забыл уже что это такое
тем более VS как таковой уже и не пользуюсь сто лет,
одного компилера хватает, и компиляции с командной строки под far

vptrlx пишет:
неужели только я один очень люблю что-нибудь in-place во время исполнения править?
а зачем это вообще надо? расскажите, а то может и мне надо а я и не знаю

| Сообщение посчитали полезным:

reversecode пишет:
думаю давно))
неделю назад

reversecode пишет:
а зачем это вообще надо? расскажите, а то может и мне надо а я и не знаю
например, иногда хочется направить код по другой ветке без перезапуска, а для этого надо что-нибудь подготовить.
А вот пример поживее:

подправить encrypt, чтобы он делал декрипт, и вызвать decrypt(secret). При этом, так как нужно выполнить один раз, можно жёстко закодить динамические офсеты. Часто это проще, чем рипать код, из-за всяких инициализаций.

Oott пишет:
Но возможно получится собрать linux_server из sdk под freebsd.
Во-во, правильно, ещё и фряха не линукс, и с ней вообще до сих пор ничего не понятно


reversecode пишет:
код пишется на глаз, а потом только первичные баги убираются
ну это зависит. в далёком детстве я один раз писал acm-овский контест с человеком, который говорил: "нет, не будем дебажить, давай внимательно читать код!", но это явно не мой стиль. мне по роду деятельности порой приходится писать, например, математический код, который проще отладить. ну свой код под никсы я и не пишу, собственно)
От студии на far я тоже когда-то перешёл, но потом вернулся, а теперь с быстрым компом в ней действительно удобнее.

| Сообщение посчитали полезным: