Комментарии 46
В чём преимущество OllyDbg перед x96dbg?
Олька часто зависала на многодневных отладочных сессиях, со вторым пока ни разу не было, интерфейс почти одинаковый, кроме иконок.
У windbg, кстати, есть .dbgdbg, но она, конечно, не спасет в вашей ситуации. Статья просто супер, спасибо!
Или еще круче вариант — вызывать функцию, которая сохраняет данные в 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 при сохранении.
Это он и есть, потихоньку заного всё запилил. Ссылка на архив, так как ехелаб канул. Там к тому же видно и чем мотивируется цена, точнее его взгляды на ее формирование.
От него тут когда то на хабре даже интересная статья была.
atd ага, я тоже порадовался. Но работа там огромная проделана.
firehacker
А вот с точки зрения практической, конечно, более перспективно возраждать или поддерживать инструмент, у которго уже есть имя, репутация, комьюнити и своя экосистема, чем пробивать дорогу чему-то совершенно новому.
У Вас на самом деле поинтереснее, а syser слишком давно уже не удел, и это место давно заняли другие дебагеры.
неслабо так ))
даже по цене на 18 дек (когда он добавил эту строчку) это будет 70к баксов или 5м рублей
как мне кажется, было бы интеренеснее оживить
Честно говоря, мне интереснее было бы доделать собственный инструмент для отладки и реверс-инжиниринга, сделать «отладчик своей мечты», устранив все бесящие и нереализованные моменты Ольки, притащив туда вкусные и желанные фишки из IDA, и т.п.
Собственно говоря, это не эфемерная мечта: у меня уже давно (лет 14 как) лежит написанный классный и быстрый дизассемблирующий/ассемблирующий движок, который может удобно расширяться. Есть к дизассемблирующей половинке этого движка GUI-примочка, показывающая отдельную процедуру либо в плоском виде, как это делает OllyDbg (даже интерфейс скопирован один в один), либо в виде графа, как делает IDA. Есть самописный простенький отладчик (tinydbg), правда у него не графический, а совершенно дубовый текстовый интерфейс (не с использованием псевдографики в консольном окне, а именно сугубо текстовый «диалог» с отладчиком) — его единственное преимущество в том, что антиотладочные приёмы, которые основываются на слабых местах популярных отладчиков, на него не действуют, а так же тем, что любую нестандартную команду или функцию я в него могу добавить сразу же, как возникнет такая необходимость, и мне не надо будет искать нужный плагин или придумать, как ограниченным инструментарием скриптинга реализовать какую-нибудь пошаговую деобфускацию отлаживаемого процесса. Есть собственный вьювер DBG/PDB-файлов, собственный вьювер COFF.
Остаётся только объединить кучу собственных разрозненных и сырых утилит в мощный и доделанный конгломерат.
И конечно, я говорю сейчас о собственном интересе. Так сказать, с точки зрения научного интереса было бы интереснее написать собственный инструмент. Список мастхев фич сформирован уже давно.
А вот с точки зрения практической, конечно, более перспективно возраждать или поддерживать инструмент, у которго уже есть имя, репутация, комьюнити и своя экосистема, чем пробивать дорогу чему-то совершенно новому.
Что то повторно наткнулся на данную статью. Год назад исходники syser'а были открыты (задонатил все же кто то или просто так — не видел сообщений по данному поводу)
Вот так вот, вспомнил что исходники отреверсенной копии открыли, а тут неожиданно объявились, те у кого есть исходники оригинального, и так же выложили его в открытый доступ.
А отладчик — эт чтобы посмотреть как же там все на самом деле.
Но ведь 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 осциллографа была найдена дыра, позволяющая получаь доступ к прошивке осциллографа. Реверс-инжиниринг синтезатора плавно перетёк в реверс-инжиниринг осциллографа. В итоге ни то, ни другое не было доведено до конца.
А вот для отладки драйверов 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у бывает в этот момент запущен.
Вам не приходило в голову, что и 16-битный софт под DOS кому-то может быть интересно или нужно реверсить хотя бы потому, что люди хотят функциональность перенести на более современные рельсы? Вот есть софт под DOS, который управляет станком, а хочется, чтобы был подо что-то современное. Но ни документации, ни исходников, ничего.
Понимаете мысль?
2) Не зная куда в каком месте ответвится программа упреешь смотреть на результат декомпиляции какого-нибудь .exe весом, скажем, 10 мегов и он подгружает ещё custom dll в общей сложности мегов на 15-17 (это реальный размер того, чего я в данный момент смотрю в OllyDbg) — жизни не хватит понять что там да как.
Говорю последний раз: я существую в продакшене, в котором надо поддерживать уже существующие версии, которые, сюрприз, 32-битные! И речи о том чтобы перевести их на 64 бита не идёт — это слишком затратно, долго по времени и просто невыгодно, понимаешь, НЕВЫГОДНО для бизнеса. Свои pet-проекты можешь делать какие угодно, это твоё право. Но в бизнесе, который уже давно выпускает своё ПО, так же давно сложилась своя ниша, которую менять только из-за прихоти какого-то ALF_Zetas никто не будет. Ты не поверишь может быть, но существуют годами работающие программы, которые требуют, понимаешь, требуют для своей работы Windows XP и не выше. Или вообще голый DOS.
Так что я живу не в дыре, а в реальном мире, а ты в каком-то выдуманном мирке, который существует только у тебя в голове и с реальным миром не имеет ничего общего. И это ты выкручиваешься, а не я, это ты всё пытаешься натянуть сову на глобус, оправдывая всеми возможными, а в принципе уже невозможными способами глупость, которую ты сказал несколько дней ранее.
Всё, разговор на эту тему заканчиваю, ты непробиваем.
Если тебе, лично тебе так прельстивы и любовны именно 64-битные приложения, то не надо говорить за всех. Я говорю не конкретно за себя, я говорю про огромную базу тех, кто пользуется и продолжает пользоваться именно 32=битными программами. Ты же говоришь только за себя и пытаешься свои хотелки выдать за хотелки всех.
Если с флагами в themida сильно наворотили, то распаковать можно при помощи известного скрипта для OllyDbg (здесь он выступает просто запускатором). Полученный бинарник также можно декомпилировать IDA или еще чем-то.
Сразу же одна весьма изматывающая особенность: если в OllyDbg первой версии нажать F12 для останова внутри отлаживаемой программы то OllyDbg первой версии останавливается именно внутри отлаживаемой программы, а x32dbg терминирует отлаживаемую программу полностью без возможности дальнейшего продолжения. Не всегда, но в 50% случаев. И это не есть хорошо. Поэтому как бы ни были хороши x64dbg и x32dbg, но пока они не дойдут в стабильности до OllyDbg первой версии они только красивые внешние подобия OllyDbg первой версии, не пригодные для реального использования на программах сложнее «Hello, world!» (образно говорю).
Обязательно пиши ещё, я думаю у тебя немало интересных тем накопилось
OllyDbg при смерти — спасение наработок отладочной сессии