Открыть список
Как стать автором
Обновить

Комментарии 44

В чём преимущество OllyDbg перед x96dbg?
Олька часто зависала на многодневных отладочных сессиях, со вторым пока ни разу не было, интерфейс почти одинаковый, кроме иконок.

У windbg, кстати, есть .dbgdbg, но она, конечно, не спасет в вашей ситуации. Статья просто супер, спасибо!

Статья просто супер, спасибо!

Спасибо. Есть ли смысл публиковать плагин Markup Dumper, обозревать его применение в контексте ведения распределённого командного реверсинга? Есть смысл публиковать статью об упомянутых ARG-файлах?

Пусть расцветают тысячи цветов! (с)
Пишите, конечно, верните торт на хабр.
Как вариант, можно реализовать в виде плагина, в нем установить свой VEH обработчик и при возникновении исключения делать дамп.
Или еще круче вариант — вызывать функцию, которая сохраняет данные в UDD файле, понятном самой OllyDbg. Не знаю как в первой версии, а во второй функция сохранения в udd принимает указатель на t_module, который можно получить вызовом Findmainmodule и флаг указывающий показывать окно выбора куда сохранять или нет.
Как вариант, можно реализовать в виде плагина, в нем установить свой VEH обработчик и при возникновении исключения делать дамп.

Непонятно, почему автор OllyDbg не обернул все обращения из хоста в плагины в __try ... __except и сам не сделал какого-нибудь аварийного автосохранения в фильтре необработанных исключений. Даже VirtualDub имеет какой-то нестандартный top-level хендер для исключений, показывающий и контекст потока, и дизасм проблемного места, хотя, казалось бы, мультимедийной утилите такой функционал не обязателен, а вот в коде отладчика уже есть многий инструментарий для реализации подобной плюшки, но самой плюшки и вообще хоть какого-то аварийного процессинга исключений внутри самого себя — нет.


Вообще, писать подобный плагин-автодампер для себя я не вижу особого смысла. У меня есть пара утилит, упомянутых в статье: memdumper.exe и extractor.exe. В случае проблемы достаточно вызвать


memdumper 12345
extractor ./ > emerg-dump.txt

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


Не знаю как в первой версии, а во второй функция сохранения в udd принимает указатель на t_module

А в первой версии такой API нет вообще. Но даже если бы была, я ведь упомянул, что есть за OllyDbg грешок тихо портить UDD при сохранении.

Человек с exelab'а несколько лет назад декомпилировал ring3 версию syser'а, но на сколько помню сорцы были утеряны.
Veliant
Это он и есть, потихоньку заного всё запилил. Ссылка на архив, так как ехелаб канул. Там к тому же видно и чем мотивируется цена, точнее его взгляды на ее формирование.
От него тут когда то на хабре даже интересная статья была.
atd ага, я тоже порадовался. Но работа там огромная проделана.
firehacker
А вот с точки зрения практической, конечно, более перспективно возраждать или поддерживать инструмент, у которго уже есть имя, репутация, комьюнити и своя экосистема, чем пробивать дорогу чему-то совершенно новому.

У Вас на самом деле поинтереснее, а syser слишком давно уже не удел, и это место давно заняли другие дебагеры.
> 3 BTC
неслабо так ))
даже по цене на 18 дек (когда он добавил эту строчку) это будет 70к баксов или 5м рублей
как мне кажется, было бы интеренеснее оживить
Честно говоря, мне интереснее было бы доделать собственный инструмент для отладки и реверс-инжиниринга, сделать «отладчик своей мечты», устранив все бесящие и нереализованные моменты Ольки, притащив туда вкусные и желанные фишки из IDA, и т.п.

Собственно говоря, это не эфемерная мечта: у меня уже давно (лет 14 как) лежит написанный классный и быстрый дизассемблирующий/ассемблирующий движок, который может удобно расширяться. Есть к дизассемблирующей половинке этого движка GUI-примочка, показывающая отдельную процедуру либо в плоском виде, как это делает OllyDbg (даже интерфейс скопирован один в один), либо в виде графа, как делает IDA. Есть самописный простенький отладчик (tinydbg), правда у него не графический, а совершенно дубовый текстовый интерфейс (не с использованием псевдографики в консольном окне, а именно сугубо текстовый «диалог» с отладчиком) — его единственное преимущество в том, что антиотладочные приёмы, которые основываются на слабых местах популярных отладчиков, на него не действуют, а так же тем, что любую нестандартную команду или функцию я в него могу добавить сразу же, как возникнет такая необходимость, и мне не надо будет искать нужный плагин или придумать, как ограниченным инструментарием скриптинга реализовать какую-нибудь пошаговую деобфускацию отлаживаемого процесса. Есть собственный вьювер DBG/PDB-файлов, собственный вьювер COFF.


Остаётся только объединить кучу собственных разрозненных и сырых утилит в мощный и доделанный конгломерат.




И конечно, я говорю сейчас о собственном интересе. Так сказать, с точки зрения научного интереса было бы интереснее написать собственный инструмент. Список мастхев фич сформирован уже давно.


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

Вся эта задача документирования бинарника делается в IDA Pro у которой с сохранением данных вроде бы получше ;-) А отладчик — эт чтобы посмотреть как же там все на самом деле. За 13 лет использования Olly, кстати, не могу припомнить прямо-таки падений-зависаний в ней. Но я ничего и не аннотирую, да
А отладчик — эт чтобы посмотреть как же там все на самом деле.

Но ведь IDA Pro умеет присоединяться к существующему процессу и выступать отладчиком. Зачем тогда нужна Olly?


Дело в привычке. Я тоже пользуюсь Олей лет 15, и все действия в ней делаю уже как пулемёт. А IDA Pro всегда отталкивала нездоровой атмосферой вокруг Ильфака и его отношением к поддержке и пиратству. Окей, у вас платный продукт, а я воспользуюсь бесплатным инструментом, а для того, что он не умеет, сделаю собственные инструменты — вот так я примерно всегда размышлял.


За 13 лет использования Olly, кстати, не могу припомнить прямо-таки падений-зависаний в ней. Но я ничего и не аннотирую, да

Аннотации не влияют на вероятность зависания и вылета. Правда, длинные аннотации, создаваемые плагинами в нарушение спецификации, могут провоцировать вылеты, об этом я написал.


Просто если не аннотировать, вылеты не так критичны и не воспринимаются, как маленькие трагедии.


А зависания, как я уже писал, происходят по вине win32k.sys, в основном. Например, жмёшь в Olly Ctrl+C и она зависает намертво. Смотришь Process Explorer-ом бэктрейс основного потока — там вызов SetClipboardData из OllyDbg, из неё идёт вызов user32!_NtUserSetClipboardData@12, а это лишь переходничок, делающий SYSENTER. Дальше код уже продолжается в режиме ядра. И где-нибудь там оно висит. Аннотации тут явно не причём. Тут виноваты какие-то system-wide объекты синхронизации. Тот же буфер обмена — если один процесс открыл его с помощью OpenClipboard() и завис, другие процессы сессии не могут работать с буфером обмена.


В подобных случаях не не переключался на отладку ядерной части системы — а то это могло зайти далеко. Был у меня случай, когда я реверсил «железный» музыкальный синтезатор фирмы Roland, и использовал цифровой осциллограф, управляемый с компьютера через SCPI (GPIB), чтобы программировать его на отлов нужных событий, автоматизированно захватывать их анализировать. В реализации SCPI осциллографа была найдена дыра, позволяющая получаь доступ к прошивке осциллографа. Реверс-инжиниринг синтезатора плавно перетёк в реверс-инжиниринг осциллографа. В итоге ни то, ни другое не было доведено до конца.

Ну Ильфак да, товарищ «интересный». Касательно Иды как отладчика, ну… Имею печальный опыт, правда не с x86. Такое ощущение что когда писали отладчик для работы с gdbserver, они просто оператор if не использовали :-D

А вот для отладки драйверов IDA хороша
Тут виноваты какие-то system-wide объекты синхронизации. Тот же буфер обмена — если один процесс открыл его с помощью OpenClipboard() и завис, другие процессы сессии не могут работать с буфером обмена.

Хм, кажется, теперь я понимаю, почему иногда при копировании в буфер на удаленной системы через RDP Firefox вдруг может зависнуть и не отвисает, пока не закроешь RDP сессию.

Статья прекрасна. Да, Olly сейчас это, скажем деликатно, "винтажненько", но пусть это будет возрастом вина, а не заплесневевшего варенья.

Статья огонь! Хотя на мой непритязательный взгляд сразу видны некоторые прямо таки детские ошибки, так сказать, за автора обидно.


Вот вы, вроде умеете не только реверсить, но и код писать, даже определили проблему с сохранением — что нет периодического сохранения. Даже свой плагин по сохранению написали. Умеете создавать поток в чужом процессе. Ну напрашивается же все это объединить и заставить ваш плагин сохранять данные периодически, а если еще чуть поднатужится, то перехватить Insertname-ы и сохранять сразу после вставки. Причем, как мне кажется, все это вы могли бы написать прям сразу вместе с плагином. В итоге вся статья из-за вашей лени :)




Странная проблема с недоступностью отладчика, который на отвалившемся диске, что аж пришлось свою утилиту-дампер писать… Не проще ли было установить Olly на тот диск, который у вас был живой?

видны некоторые прямо таки детские ошибки, так сказать, за автора обидно.

Огласите весь список, пожалуйста :) Если вы пишите «ошибки», значит их много? Отсутствие автосохранения — одна из них?


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

Замысел хороший, но сразу после появления плагина стал очевиден способ спасения данных, описанный в первой половине статьи (перенаправление выполнения на код процедуры MudDoSave из плагина), автосохранение не рассматривалось как нужная фича, без которой нельзя жить и на которую не жалко тратить время. Ну разве что против внезапного отключения электричества или BSOD-а, но таких случаев может и не было вообще.


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


Странная проблема с недоступностью отладчика, который на отвалившемся диске, что аж пришлось свою утилиту-дампер писать… Не проще ли было установить Olly на тот диск, который у вас был живой?

Странный комментарий. Имеется в виду установить OllyDbg на живой диск заведомо, подозревая диск (на котором живёт том H:\) в нездоровости заранее? Или установить OllyDbg на другой диск уже после того, как диск с томом H:\ отвалился? Я надеюсь, что вы имели в виду второй вариант.


Если так, то вы невнимательно читали статью.


Во-первых, как я по вашему реверсил Insertname() после аппаратного сбоя, если не установил OllyDbg на другой диск? Конечно же OllyDbg был сразу же установлен на другой том другого диска из резервного хранилища, чтобы начать работы по разрешению ситуации.


Во-вторых, утилиту-дампер пришлось писать не потому, что OllyDbg стал недоступным для использования из-за отвала, а потому что был риск, что OllyDbg при подключении к полумёртвому процессу (коим был тоже OllyDbg) запнётся и завершится. А когда отладчик завершается, не вызвав перед этим DebugActiveProcessStop(), отлаживаемый процесс уничтожается вместе с процессом-отладчиком. Тогда бы я окончательно потерял спасаемые данные.


Т.е. утилита-дампер писалась ровно из тех соображений, чтобы воздействие на «коматозный» процесс было минимально инвазивным. Четыре аккуратных и точных вызова ReadProcessMemory должно было стать меньшим из возможных зол. Я даже не был уверен, что ReadProcessMemory() вообще сработает в отношении этого процесса и сможет прочесть хоть что-нибудь. Это сейчас примерно понятно, что произошло, а в тот момент не было уверенности, что адресное пространство сохранилось хотя бы частично (в Windows объект-процесс может существовать, а адресное пространство как совокупность структур PDE+PTE с одной стороны, и MMVAD с другой стороны — могут не существовать; на каких-то этапах жизненного цикла объекта-процесса это так). Кто мог в первые минуты гарантировать, что всё произошло именно из-за аппаратного сбоя, а не потому, что какие-то ядерные структуры были повреждены каким-то глючным драйвером?


Если вы внимательно читали, то видели, что сначала я собирался сдампить все закоммиченные страницы умирающего процесса, разобраться со сбоями, перезагрузиться, а потом уже в дампе находить нужное, не боясь, что вот-вот случится BSOD. Но Process Explorer не мог создать дамп, падал с ошибкой.


Причём было не удивительно, что он падал: если страница нечитаема, потому что механизм подкачки не может её подгрузить, то и ReadProcessMemory, которым пользуется любой дампер, её контент прочитать откуда-то волшебным образом не сможет. Был бы дампер, который читал не все подряд страницы. а только нужные — он бы не падал. Но нужно было знать, какие именно страницы читать, для чего и был начат реверсинг. А если знать, что читать нужно два больших блока плюс маленький кусочек с метаданными, зачем мне было искать подходящий дампер, если быстрее было написать его самому?

Если что-то в этом механизме перехвата ломается, зависают все GUI-приложения. Формально они не зависают, а лишь перестают реагировать на оконные сообщения, что для обычного пользователя эквивалентно зависанию. Консольные приложения при этом единственные остаются на плаву.

Вот интересно, у меня на одной из систем бывает иногда подобный сбой. Весь GUI практически висит (ну очень медленно реагирует), зато просто замечательно работает Фар в консоли. Стоит выйти из консоли и все проблемы исчезают. В чем проблема, так и не понял, но возможно Spу бывает в этот момент запущен.
кто-то до сих пор дебажит 32-битный софт?
А что, абсолютно весь софт сейчас 64 бита? «А мужики-то и не знали!» © Лично я из софта, который сейчас мне попадается, вижу процентов 80 32 бита и лишь 20 процентов чистый 64 бита (речь не об OS, а о прикладных программах).
мне почему то столько 32-битных не попадается — очевидно по файлопомойкам не шастаю ;)
Я тоже не шастаю. Говорю только про то, что используется в продакшене, официально.
унылый какой-то продакшн — в моём продакшене уже лет 6 ничего 32-битного
Ну если свои pet-проекты называть «продакшн» то верю, вполне такое может быть. А если это именно продакшн, в котором надо поддерживать уже существующие версии — тогда не верю, это не «продакшн», а так, фигня какая-то.
Ладно, оставим без комментариев ваше показное пренебрежение к 32-битному софту и 32-битной архитектуре как таковой.

Вам не приходило в голову, что и 16-битный софт под DOS кому-то может быть интересно или нужно реверсить хотя бы потому, что люди хотят функциональность перенести на более современные рельсы? Вот есть софт под DOS, который управляет станком, а хочется, чтобы был подо что-то современное. Но ни документации, ни исходников, ничего.

Понимаете мысль?
когда нет исходников, то декомпилируют софт в ИДА, а не мучают в окочурившейся ольке
Не всегда по декомпилированному в IDA/Ghidra коду можно понять логику «с лёту», иногда требуется и пошаговая трассировка. Пример — подключение какого-нибудь внешнего устройства USB. При пошаговой трассировке прекрасно видно что происходит, какие пакеты приходят, какие уходят. В IDA/Ghidra это тоже можно посмотреть, но там получается куча веток для других возможных устройств, а нужно посмотреть только для конкретного. Упреешь в IDA/Ghidra искать именно нужную ветвь. В этом случае OllyDbg даёт фору IDA/Ghidra на сто шагов вперёд.
нифига эта олька не дает — т.к. без декомпиля и не узнаешь в каком месте нужно пошагово посмотреть. А для посмотреть уже давно есть более продвинутые x64dbg|x32dbg
1) Слабо декомпилировать в IDA какой-нибудь .exe, закрытый сверху Themida? Вообще без OllyDbg? Если ответ утвердительный, тогда прилюдно съем свою шляпу после того как мне это покажут (хотя я шляпы не ношу, но специально куплю по такому случаю и съем её).

2) Не зная куда в каком месте ответвится программа упреешь смотреть на результат декомпиляции какого-нибудь .exe весом, скажем, 10 мегов и он подгружает ещё custom dll в общей сложности мегов на 15-17 (это реальный размер того, чего я в данный момент смотрю в OllyDbg) — жизни не хватит понять что там да как.
Темидой накрыт 64-битный файл и ольку можешь засунуть куда сам придумаешь.
Не надо уходить от ответа, хотя понимаю: прижали к стенке и крыть нечем, поэтому и начали выдумывать всяких сферических коней в вакууме. Но всё же повторю вопрос: если Themida поверх 32-битного приложения (а таких пока что большинство)?
сам придумал, что их большинство? — мне уже лет 6 или более никто не заказывал 32-битный софт
Я не придумал, я вижу что вокруг. А вот ALF_Zetas явно придумывает какие-то ему одному ведомые вещи. 32-битных приложений, именно приложений, а не OS, сейчас пока что большинство. Так что хватит уже откровенную чушь молоть, надоело, ей-богу.
выкручиваешься прямо как червяк на сковородке — я не представляю в какой дыре ты существуешь, что вокруг тебя 32-битные приложения. А в моем мире 32-битными остались только несколько серверов лицензий — прикладной софт весь 64-битный (Adobe, Avid, Steinberg, Blackmagic Design, Colorfront, The Foundry, Quantel, Fraunhofer, In2Core, MTI etc)
Ты автор Adobe, Avid, Steinberg, Blackmagic Design, Colorfront, The Foundry, Quantel, Fraunhofer, In2Core, MTI? Или компания в которой ты работаешь автор Adobe, Avid, Steinberg, Blackmagic Design, Colorfront, The Foundry, Quantel, Fraunhofer, In2Core, MTI? Нет? Тогда какого рожна?..

Говорю последний раз: я существую в продакшене, в котором надо поддерживать уже существующие версии, которые, сюрприз, 32-битные! И речи о том чтобы перевести их на 64 бита не идёт — это слишком затратно, долго по времени и просто невыгодно, понимаешь, НЕВЫГОДНО для бизнеса. Свои pet-проекты можешь делать какие угодно, это твоё право. Но в бизнесе, который уже давно выпускает своё ПО, так же давно сложилась своя ниша, которую менять только из-за прихоти какого-то ALF_Zetas никто не будет. Ты не поверишь может быть, но существуют годами работающие программы, которые требуют, понимаешь, требуют для своей работы Windows XP и не выше. Или вообще голый DOS.

Так что я живу не в дыре, а в реальном мире, а ты в каком-то выдуманном мирке, который существует только у тебя в голове и с реальным миром не имеет ничего общего. И это ты выкручиваешься, а не я, это ты всё пытаешься натянуть сову на глобус, оправдывая всеми возможными, а в принципе уже невозможными способами глупость, которую ты сказал несколько дней ранее.
у тебя слишком узколобое представление о продакшене — напр. производство кино-фильмов это внезапно также продакшн. А ты застрял в своем отсталом мирке и талдычишь, что вокруг только 32-битный софт
Это у тебя слишком узколобое представление. Моя сфера деятельности не использовать готовые программы, а писать программы. И заказывают почему-то 32-битные. Потому что клиентам надо именно такие. И деньги мне платят именно за 32-битные программы. И ни разу никто не хотел 64-битную версию.

Всё, разговор на эту тему заканчиваю, ты непробиваем.
и почему ты упорото экстраполируешь свою узенькую направленность на всё человечество?
Отвечу так: «и почему ты упорото экстраполируешь свою узенькую направленность на всё человечество?»

Если тебе, лично тебе так прельстивы и любовны именно 64-битные приложения, то не надо говорить за всех. Я говорю не конкретно за себя, я говорю про огромную базу тех, кто пользуется и продолжает пользоваться именно 32=битными программами. Ты же говоришь только за себя и пытаешься свои хотелки выдать за хотелки всех.
вся планета работает на 64-битном софте и только кучка лузеров всё еще торчит на 32-битном ;)
По пункту 1. Если не сильно наворотили с флагами в themida, то просто запускается приложение. Потом дампится любым способом. Полученный бинарник можно декомпилировать в IDA или еще в чем-то.

Если с флагами в themida сильно наворотили, то распаковать можно при помощи известного скрипта для OllyDbg (здесь он выступает просто запускатором). Полученный бинарник также можно декомпилировать IDA или еще чем-то.
Кстати, x64dbg и x32dbg в принципе хорошее развитие, только они пока ещё не дошли до стабильности того же OllyDbg первой версии, полностью 32-битного ещё. Я слежу за развитием x64dbg и x32dbg, но пока что нет. Близко уже, но пока что нет.

Сразу же одна весьма изматывающая особенность: если в OllyDbg первой версии нажать F12 для останова внутри отлаживаемой программы то OllyDbg первой версии останавливается именно внутри отлаживаемой программы, а x32dbg терминирует отлаживаемую программу полностью без возможности дальнейшего продолжения. Не всегда, но в 50% случаев. И это не есть хорошо. Поэтому как бы ни были хороши x64dbg и x32dbg, но пока они не дойдут в стабильности до OllyDbg первой версии они только красивые внешние подобия OllyDbg первой версии, не пригодные для реального использования на программах сложнее «Hello, world!» (образно говорю).
Читаю статью и понимаю, что вроде как стиль знакомый. Неплохие познания в кишках винды, отладка в Ольке под XP. Дочитываю: ну точно, старый друг пришёл на Хабр :)
Обязательно пиши ещё, я думаю у тебя немало интересных тем накопилось
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.