Kris Kaspersky напиши отладчик уровня ядра, а не опиши его

kd* функции имхо не очень полезны. нехилаая часть кода служит для взаимодействия с kd по своему протоколу.

 

Great
Kd* функции самого ядра. имхо их потенциал велик и могуч, кроме того они системно-независимы (то есть, зависимы, конечно), но у меня вообще идея фикс - модульный отладчик. типа есть набор модулей: один (движок) занимается трассировкой, установкой точек останова, etc, второй обеспечивает связь по gdb/ms протоколу, чтобы не писать свой дизассемблер и интерфейс. третий - внедряется в отлаживаемый процесс и это может быть как просто создание отладочного процесса (что легко ловиться анти-дебажными приемами), так и прямой инджект кода через WriteProcessMemory или с ядерного уровня или через App_InitDlls...
словом, это как бы набор кубиков и можно использовать любой из имеющихся на каждом уровне. например, работать через kd* когда это удобно или через "самопальный" модуль, реализующий трассировку там...
ИМХО главная выгода от такой схемы в том, что со сменой платформы (например, переход на 64-бита) часть модулей продолжит работать как ни в чем ни бывало (пускай и с урезанным функционалом), ну и, наконец, открытая архитектура позволит использовать любые другие расширения. пока планирую поддерживать только soft-ice и плагины к ms dbgeng.dll. кстати, последний взят пока за основу, то есть все модули отладчика могут работать непосредственно с ним самим хотя меня больше bsd интересует... и сейчас ковыряюсь с ней в основном... будет очень круто заставить dbgeng.dll работать с ней ) ес-но удаленно

t00x
вообще-то, это год wùzǐ (戊子). ну а как сие перевести - это уже не ко мне. словари дают разные переводы.

n0name
их вообще без kd можно юзать. из драйвера, например.

 

kaspersky
Great
И вот каждый для себя что-то пишет, пишет....
Может скооперируетесь и дадите в массы нормальный отладчик?

 

Magnum
хех, ничем хорошим это не закончится =))

n0name

Да, есть такое. Но почему бы его и не заюзать..

kaspersky
модули.. да в принципе чего тут такого уж особенно, с учетом того, что ничего дополнительно делать не нужно, чтобы выделить такие модули в написанном отладчике. Просто считать все функции для работы с бряками одним модулем, для связи по компорту - вторым и т.д. и т.п. У меня сейчас в принципе так и есть, оно даже в отдельных файлах исходных валяется и красиво оформленное =D
поясни тогда конкретнее, что ты понимаешь под такими "модулями".

> bgeng.dll. кстати, последний взят пока за основу, то есть все модули отладчика могут работать непосредственно с ним самим
как я помню, она предоставляет COM интерфейс, геморрой какий-то будет там...

> будет очень круто заставить dbgeng.dll работать с ней ) ес-но удаленно
в смысле? с bsd коннектиться на отлаживаемую машину и на ней (bsd) юзать dbgeng? каким образом.. или чтобы отладчик от нее предоставил кроссплатформенный интерфейс? а локально?

 

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

основная идея - которую я не встретил у других (может плохо смотрел?!)
это не порождать отладочный процесс, а делать в него прямой inject тем
или иным способом, что упрощает борьбу с анти-отладкой...

> ничего дополнительно делать не нужно,
> чтобы выделить такие модули в написанном отладчике.
самое сложное унифицировать модули...
выделить системно-завсимый код и изолировать его от системно-независимого.

> Просто считать все функции для работы с бряками одним модулем,
не совсем так. что есть бряки? мы должны написать функции,
реализующие операции установки бряка на адрес, диапазон, etc.
это - системно зависимая часть. а вот манагер бряков, логгер,
парсер условных бряков - это уже системно-независимый код.
к тому же даже системно-зависимый модуль работы с бряками
может (и должен) уметь работать с модулями более низкого уровня,
используя API оси или ядра, а если оно недоступно, то "рукотворный" модуль.

> поясни тогда конкретнее, что ты понимаешь под такими "модулями".
что-то вроде "кубиков". типа конструктора, из которого можно
собирать отладчик и дописывать свои "кубики". скажем, для
той же установки бряка на диапазон адресов, что можно
реализовать множеством способов...

или вот трейсер... чтобы он обращался к "поставщику услуг",
которым мог быть как просто обычный автоматический трейсер с TF флагом,
так и трейсер через аппаратные точки останова, так и трейсер через
эмуляцию команд, то есть модуль трейсера как бы экспоритует
функции типа step_in, step_over, p_ret, etc а эти команды реализуются
микро-модулями, которые могут быть написаны как угодно и их можно
динамически выбирать в любой момент в ходе трассировки...

>> bgeng.dll. кстати, последний взят пока за основу,
>> то есть все модули отладчика могут работать непосредственно с ним самим
> как я помню, она предоставляет COM интерфейс, геморрой какий-то будет там...
не такой уж и большой гемор, если написать типа "хелпер" или "враппер".

>> будет очень круто заставить dbgeng.dll работать с ней ) ес-но удаленно
> в смысле? с bsd коннектиться на отлаживаемую машину и на ней (bsd) юзать dbgeng?
угу. примерно так. dbgeng.dll поставляется код, который она дизасмит, например.
ес-но, сам по себе dbgeng.dll в чужеродной среде "не заведется",
и тут нужно писать обертки... но имхо это стоит того, поскольку
тогда можно писать плагины, работающие с dbgeng.dll и они же
будут работать и под никсами. ес-но смотря что это будут за плагины

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

 

kaspersky
Мыщьх, а ты не думал бросить всю эту бадягу и наклепать отладчик на технологии Intel vt-x или AMD svm?
всётаки это будет куда более радикальная штука, чем стопицот раз рыть носом то што уже заежжено до дыр. Перспективы у такого отладчика куда более существенные.

 

в некоторых процессорах такого нет.

 

k3internal
не вижу переспектив. это будет low-level дебагер, которому для выполнения простейших дейсвтий потребуется обладать обширными знаниями касательно той оси, которую он дебажит, а это уже 100% системно зависимый код даже в рамках линейки NT. такой отладчик мало написать, его нужно еще и поддерживать используя же системные вызовы и API - с другой стороны - мы и на уровне ring-3 можем получить _почти_ стелс-отладчик, а с небольшой порцией кода, помещенного на ring-0: натуральный стелс отладчик к тому же не забывай, что у интел и амд эта фишка реализована очень сильно по разному и их обоих надо поддерживать, плюс их уже использует Server 2008 и, возможно, будут использовать другие оси, так что мы сразу столкнемся с конфликтов ресурсов и будем вынуждены прибегать к "вложенной" эмуляции (как это предлагала рутковская), что усложняет код... а главное - ну и какие _ПОТРЕБИЛЬСКИЕ_ функции у это отладчика доведут пользователей до огразма, особенно, учитывая, что не у всех есть ЦП с поддержкой виртуализации, а многие предпочитают дебажить программы на варе или другом эмуле, где виртуализация отдыхает... ИМХО гораздо проще на особе борща или другого эмулятора создать отладчик-эмулятор. ну не полный эмулятор, конечно, но прогонять на нем критические участки кода, в которых встречаются навороченные механизмы защиты, юзающие разные регистры проца... я вот как раз сегодня всю ночь курил исходные тексты борща, qemu и dosbox. хочется прикрутить к ольке динамический эмулятор в виде плагина, пока чисто в порядке эксперимента, я об этом уже писал в каком-то посте, но меня не поняли или не захотели понять зачем это нужно. дело в том, что ряд задач решается пошаговой трассиврокой, а она зараза медленная, сволочь. и вот если мы парсим следующий блок кода и видим, что он нам неинтересен, то выполняем его на живом ЦП, в противном случае - на эмуляторе.

 

> или иным способом, что упрощает борьбу с анти-отладкой...
антиантиотладка.. дожили

>не такой уж и большой гемор, если написать типа "хелпер" или "враппер".
ну это да..

> но имхо это стоит того, поскольку
>тогда можно писать плагины, работающие с dbgeng.dll и они же
> будут работать и под никсами.
кошмар какой.. )

Вообщем я понял что ты хочешь сделать.. насчет модулей.

 

kaspersky

Никто не заставляет умещать весь отладчик в коде VMM. Что касается
<используя же системные вызовы и API> никто не мешает выполнить этот код ввиде дополнительных модулей-агентов конкретизирующих ось. То что ты сейчас задумал, я так думаю, это ShadowWalker пригодный лишь для r3-кода по большому счёту. Стелс отладчик в полном смысле слова сомневаюсь что получим, потому как опять же r3 код может иметь и активно юзать свой драйвер. Для отладки хитрых драйверов такая технология не годится.

Никто не спорит. Но не думаю что это будет большим гемороем.

Сервер 2008 так же может обходится и без этих фич, vt-x учитывает CPUID. Остальные оси обломить можно также. Вложенная эмуляция на сегодняшний момент в полной мере возможна только на процессорах AMD, если до конца верить интелловской документации, то с этим там дела обстоят несколько хужее.

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

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

 

k3internal
я понял тебя и полностью согласен.
но... если мы имеем модули-агенты, это уже не стелс-отладчик по любому
возьми, например, раста-дебаггер как пример системно-независимого отладчика.
только если нам нужна не игрушка, а инструмент, то нам нужен и функционал...
а вот как его реализовать, "врезавшись" между ЦП и осью?!
другими словами - какой функционал должен по твоему обеспечивать монитор виртуальных машин/гипервизор? просмотр памяти? трассировку? бряки? это да. это можно (хотя бряки на API функции, WM_ и проч. без учета конкретной оси - уже не получится). в принципе, это хорошо вписывается в концепцию модульности. если отладчик набор модулей, взаимодействующих унифицированным образом, то его можно собирать на ходу....

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

базовый функционал - трассировка/бряки мне неинтересен, т.к. его реализоали уже тысячу и одну раз. мне вот при работе с отладчиком хочется просматривать разные структуры оси и потому я хочу взять ms dbg за основу, т.к. он в этом плане рулит круче всех и показывает кучу самых разных структур, даже больше чем софт-айс но вот в плане анти-отладки он явно не канает ;( и отсюда возникает идея модульного отладчика, в который можно кидать куски, надерганные отовсюду.

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

это что бы опять-таки не изобретать велосипед то есть фактически я работаю не столько над своим кодом, сколько над разбором чужого кода и созданиеи "оберток" для него.


про "стелсовость" я имел ввиду, что при помощи драйвера мы можем превратить ring-3 отладчик в стелс-отладчик на уровне ring-3. ну а в ядре... там, конечно, в x86 архитектуре 100% стелс невозможен, но я на это и не замахиваюсь

 

kaspersky
Ты тоже во многом прав)

 

kaspersky

Да системно-независимый отладчик весьма трудная задача. Модульность - весьма интересный момент, видимо олька и выигрывает у айса только за счет модульности, видимо таким должен быть и отладчик ядра. Крис я извеняюсь за столь рьяное название темы, просто связался я с разработчиками syser, предложил его сделать бесплатным + естественно добавить поддержку современного железа (с моей стороны современных видеокарт), в итоге получил письмо примерно следующего содержания: "Да нам интересна методика вывода инфорации из ядра на экран, пожалуйста пришлите ..." и не слова о бесплатности или об оплате. Хм. лучше взглянуть с IDA внутрь syser (да паралельно листинг айса плагиат-плагиатом) - сразу отпадет желание его описывать.

 

PROFi
системно-независимым _отладчик_ вообще быть не может, т.к. для полноценного дебага нужно работать с конкретными структурами конкретной оси. если мы используем API данной оси, то получаем, что отладчик совсем не стелс, и прочно завязан на эту ось. если же мы начнем разбирать все структуры оси "руками", то поимеем огромную головную боль и необходимость отслеживать изменения этих структур в новых билдах оси (сервис-паках), и времени на это уйдет...

что касается бесплатности... тут я делаю все возможное. в частности, к книге по syser'у будет приложена полноценная не кропнутная версия. другое дело, что сусер в том состоянии, что он пока есть - игрушка и мало кто за нее готов платить. она даже "d fs:0" не переваривает... 16-битный код показывает как 32-битный, т.е. показываем мусор, т.е. если мы делаем i3here on и int 3 выскакиваем в 16-битной аплеухе - сусер всплывает и... дальше начинаются чудеса на виражах... да там много багов и вообще...

но а что делать? мне остается только пинать разработчиков сусера, чтобы они их фиксили. вот скажем такой баг - при загрузке с сетевого диска или съемного носителя отладчик проскакивает EP. обещали пофиксить. а вот поддержку 16-бит делать не хотят ;((

все равно soft-ice умирает. и вот уже есть необходимость подебажить висту и server2008, а нечем. ms kd/windbg/cdb - не рулит. у него даже аналога i3here нету ;(( и вообще он очень ограничен... хотя внутренние струткры оси кажет лучше айса.

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

 

ИМХО это невозможно.

 

kaspersky

так что лучше сначала сделать так, чтобы сусер _работал_, а уже потом думать каким его сделать платным или бесплатным.
Собстенно и я того же мнения, просто разработчики не желают понять однин момент - олька к примеру изначальна бесплатна, да со скрипом, да нехватает ядра, и т.д. - но бесплатна. Конечный итог виста и 86х64 отбивают желание у начинающих программеров исследовать и раскладывать все по полочкам. Я просто задам 2 вопроса, а выводы делать это уже задача ваша:
1) Скольким вы обязаны SoftICE при изучении Windows, CPU и работы с аппаратурой от истоков до сегодняшнего дня?
2) Неужели нехватает профессионализма для написания своего, бесплатного, открытого отладчика ядра - или можно с 2008 на ядре ставить крест для начинающих?

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

 

PROFi
а распишите план действий.
например:
1. собрать команду для организации проекта;
2. составить ТЗ (детальнейшее);
3. поставить сервер с необходимым ПО для работы (SVN, IRC и т.д.);
4. по составленному ТЗ собрать необходимое количество программистов с опытом разработки в заранее определённых областях (архитектура, работа с устройствами, работа со строками и структурами, с документацией, и т.д.);
5. и пользуясь "проблемы надо решать по мере поступления, а создавать по мере решения" распределять задачи.

 

PROFi
давно пора уже понять, что крис не программист и писать отладчики, да еще и такие, которые смогли бы с сисером/софтайсом конкурировать - это выше компетенции Криса

 

Magnum
мда..... с чего такая сила слога)??

 

kaspersky
а, вообще, откуда у этого сусера финансы на разработку??