Вопрос состогит в следующем: нужно выполнить отладку кода, которыйвыполняется в третьем кольце. Но делать это не стандартными Debug API-функциями, а реализовать драйвер, чтоб задействовать всякие левые, например, зарезервированные, прерывания или редкоиспользуемые, например, всякие int 2Dh и другие (это упоминается как пример - не обязательно его). Так вот, чисто в теории, чтоб отлаживать приложение с помощью таких прерываний, нужно расположить в коде жертвы опкоды этих самых прерываний, далее изменить DPL этого прерывания на троечку, чтоб не генерировался эксепшн, далее выполнить перехват этого прерывания на свой обработчик в дровине, и, когда происходит это прерывание, выполнять нужные действия: дамп, правку жертвы в памяти, или же просто лог вести. Но вот в чём проблема - можно ли это делать с зарезервированными прерываниями? Если можно, то после перехвата и обработки данных моим фильтром куда передавать управление? И если мой олбработчик срабатывает, то в контексте какого процесса: процесса-жертвы или System?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

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

9aa2_23.03.2009_CRACKLAB.rU.tgz - tracer.zip

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

Если ты и так похукал IDT, накой менять DPL. В х64 патчгарду твои проделки не понравятся.
Да любые хукай, они все недокументированные и все винда не одобрит. Сработает в контексте жертвы, ясный красный. После обработки возвращаешь обратно в ринг3, если обработал.

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

Я что-то не понял: винда будет ругаться, и чем же это мои перехватчики хуже темиды? Ей можно, а мне нельзя?:-D И что значит не менять DPL? Тогда мой чудесный обработчик в нулевом кольце просто не получит управления, или получит? Я не пойму, исключение генерируется после прерывания, и перехватчик не выполнится, если прерывание вызвано
Из пользовательского кода, или он выполнится в любом случае?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

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

> И если мой олбработчик срабатывает, то в контексте какого процесса: процесса-жертвы или System?
Текущий процесс определяется 6-м дескриптором в GDT(более точно в PCR указатели на EPROCESS и пр.), который адресует PCR, его селектор загружается в Fs при смене кольца защиты на нулевое. Никакие инструкции не приведут к его смене, тоесть переключение на другой процесс произойти не может. Исключения и прерывания обрабатываются в контексте процесса, в котором они произошли.

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

Меня вариант с "расположить" вполне устраивает, и тем не менее, когда же будут срабатывать эти прерывания в ядре?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Не понятный вопрос.

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

Я имею ввиду, если пользовательский код вызывает int 1, а его DPL равен 0, получит ли управление обработчик этого прерывания в ядре?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Int 1 в двух вариантах есть. Которой опкод 0xF1 эта генерирует исключение #DB, вторая 0x01CD вызывет исключение #GP, изза того что в дескрипторе DPL нуля равен.

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

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

-----
Stuck to the plan, always think that we would stand up, never ran.

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

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

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

у дероко что-то было или я ошибаюсь?

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

Av0id да , вот наверху и приложено. Проще спросить конечно чем кодить и разбирать

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

Я имею в виду, что не винда будет ругаться, а что разработчики винды не добряют таких хуков вообще, поэтому 1 хрен, какой именно хукать, все не очень хорошо и не документированно. А в х64 с этим дополнительные сложности есть. И помимо патчгарда.
ДПЛ можно и не менять, просто тогда вызовется 13 прерывание, вроде, которое за нарушение защиты отвечает, а не конкретно вызванное тобой, но при нужных хуках это 1 хрен.

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

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

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

Ну, значит dpl лучше всё же сменить, теперь идём дальше. Пока положим на х64 большой и длинный, как и на многопроцессорные машины, как и на всякие отладочные функции как уровня пользователя, так и ядра, и сосредоточимся на перехвате прерываний. Вот какой вопрос у меня назрел: как бы при перехвате этих самых чудесных прерываний узнать, по какому адресу в пользовательском коде оно расположено?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

ARCHANGEL
Для начала наверное лучше изучить матчасть(хотябы что делоет процессор при исключении).
В стеке Eip.)

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

Я и не спорю, нужно изучить, был бы благодарен за ссылки на такую матчасть, потому что "в стеке eip" мне не проясняет ситуацию, а наоборот

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Мат часть тут всегда одна: маны интела. Их достаточно вполне. В крайнем случае хук прерываний у дероко в сорцах на его сайте.

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

Ну, тут, собственно, всё ясно, буду читать матчасть, просвещаться, но в этом мне уже никто не поможет (разве что кто-то будет мне картинки в голову проецировать для лучшего усвоения, если кто умеет - пишите в личку:s5, единственное - может, кто знает, где их можно скачать, эти мануалы интеловские, а то гуглю инахожу их по кускам, что не очень удобно. Тему пока закрывать не буду - может, ещё кто-нибудь что-то посоветует...

-----
Stuck to the plan, always think that we would stand up, never ran.

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

ARCHANGEL
sasm.narod.ru
В общих чертах вполне хорошо описано. На васме тоже стотьи есть.

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

Clerk
Спасибо, в общем, почитаем, но ещё хотелось бы где-то добыть именно оригинальные IA-32 Manuals, ничего страшного, что на английском, главное, чтоб были, вдруг пригодятся

-----
Stuck to the plan, always think that we would stand up, never ran.

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

На сайте интела, по названию ищи в гугле. Intel® 64 and IA-32 Architectures
Software Developer’s Manual

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

ARCHANGEL
> хотелось бы где-то добыть именно оригинальные IA-32 Manuals
Мне тоже хотелось бумажные и я их заказал. Из этого ничего хорошего не вышло, кроме как кучи проблем, так что юзаю в электоронном виде.

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

Собственно, с прочтением некоторой инфы ситуация стала проясняться. Например, чисто в теории, предположим, что я взял и натыкал в исследуемую софтину опкодов int 3 (0ССh), т.к. в юзермоде я никак не обрабатываю исключения, возникающие при попытке жертвы выполнить эту инструкцию, то со 100% вероятностью софтина такая попросту будет валиться, но когда я устанавливаю свою дровину, которая перехватывает исключение #BP, для чего на практике мне придётся установить свойобработчик прерывания int 3h в ядре (конечно же, где ж ещё ), то мойобработчик будет срабатывать, когда юзермодный код попытается выполнить int 3, регистр CR3 укажет на таблицу страниц процесса-жертвы, сегментный регистр fs переключится и будет содержать по смещению 24h указатель, который по смещению 44h будет содержать EPROCESS процесса-жертвы, а в стеке будет содержаться EFLAGS, CS:EIP, а код ошибки для данного исключения будет отсутствовать, тогда как значение CS:EIP будет указывать на следующую за int 3 ячейку памяти жертвы. Чтоб обработать эту радость, я должен:
1. Используя указатель на структуру EPROCESS, определить, тот ли это процесс, т.е. это ли процесс-жертва.
2. Используя трюк с CR0, отключить зашиту от записи в пользовательский код.
3. Переписать опкод int 3 на тот опкод, который там был первоначально.
4. Декрементировать СS:EIP.
5. Включить защиту от записи, т.е. вернуть прежнее значение регистру CR0.
6. Выйти из обработчика перываний.
7. Если исключение возникло не в жертве, то передать управление на оригинальный обработчик.

Всё ли верно?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

CR0 не обязательно, вроде. Из основного в принципе всё, однако стоит подумать, где ты будешь хранить список бряков, оригинальных байтов и тд, ибо на том иркле, что есть в обработчике, вызывать ты сможешь очень мало функций. Второе-thread safe код должен быть.

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

Ой, там не 24, а 124 должно быть, ошибочка вышла, а второй пункт - это про синхронизацию? Ну, тогда это вообще другая история, но мне кажется, что тут как раз вопрос синхронизации не особо сложен, мне тут реально нужно только InterlockedExchange использовать, а с хранением оригинальных опкодов вообще проблем никаких-их можно в пуле невыгружаемой памяти хранить, как и код своего обработчика, чтоб не было голубых экранов. Но подумать тут есть над чем: например, всё же непонятно, нужно ли менять DPL?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

ARCHANGEL
И как ты собираешся трассировать код с помощью жёстких точек останова в коде ?
Как ты узнаешь куда инструкция передаёт управление ?
Как обойти самопроверки целостности кода ?
Archer
> том иркле, что есть в обработчике, вызывать ты сможешь очень мало функций.
Что мешает повысить его с PASSIVE_LEVEL на более высокий ?

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

Повысить иркл ничто не мешает, только он при входе и так уже FF, куда уж выше. По крайней мере, если верить виндбг. Лично я просто функций не вызываю, поэтому такой проблемы нет, посему не стал разбираться, какой же там реально иркл.
Второй пункт да, про синхронизацию. История, может, и другая, но иметь в виду надо, чтоб без записи в глобальные переменные обойтись. Ну и стоить иметь в виду многоядерные/многопроцессорные тачки, тут код поменяется мало. И про х64-а тут вообще работать не будет. Просто лично я не вижу особого смысла писать софт под медленно, но верно подыхающую платформу. А ты как хочешь.

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

Archer
Пока в Cs потока юзермодный селектор, поток не может(и не должен) иметь IRQl больше PASSIVE_LEVEL. Также и при входе в обработчик исключения/програмного прерывания.

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