Кто знает как обрабатывать прерывания?

вообщем такая штука

имеется код юзер-моуд приложения т.е. ринг 3

Код (Text):

1.  
2.   nop
3.   nop
4.   nop
5.   0xCC
6.   nop
7.   nop
8.   nop
9.  

данный код трассируется через int1 автоматически, т.е. всмысле я не нажимаю кнопку F8 c айсе



трейсер в определенный момент встречает бряк 0xCC и по идее я думаю в этот момент должно быть сгенерировано прерывание инт3 - ну я его и обрабатываю вот таким образом

Код (Text):

1.  
2.   and   dword ptr [esp + 0Ch], not 100h ;сбрасываю флаг трассировки
3.   push  eax
4.   mov   eax, dword ptr [esp + 4] ;извлекаю указатель на eip который сгенерил наш 0xCC
5.   mov   byte ptr [eax], 90h ;заменяю бряк 0xСС на nop
6.   dec   dword ptr [esp + 8] ;декреметирую esp - вроде так надо
7.   pop   eax
8.   iretd ;возвращаюсь в прогу
9.  

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

повторный запуск трейсера уносит систему в вонючую даль



или может этот бряк не обработчик инт3 обрабатывает? Хотя дпл обработчика инт3, как показывает айс равен 3. Я подумал что может обработчик инт13 обрабатывает - дак у него дпл=0 и он на протяжении теста (переход между окон и т.д.) вообще ни уя не обрабатывает :-\



я совсем запутался!!!



а если прога ринг3 производит деление на ноль!, а дпл обработчика инт0 равен 0?! - кто обрабатывает это исключение???



а если дпл всех обработчиков равны нулю! тогда что?

 

как это обрабатывать во время трассировки?

 

Кстати дпл у обработчика инт0 действительно равен 0. Так почему же код с дпл = 3 может генерить это прерывание?

 

Godness

В начале, в стеке имеем:

[esp]=eip

[esp+4]=cs

[esp+8]=eflags

А куда попадает AND?

 

таки да - немного затупил надо вот так

Код (Text):

1.  
2.   and   dword ptr [esp + 8], not 100h ;сбрасываю флаг TF
3.   push  eax
4.   mov   eax, dword ptr [esp + 4]
5.   mov   byte ptr [eax], 90h
6.   dec   eax                           ;декрементирую eip
7.   mov   dword ptr [esp + 4], eax
8.   pop   eax
9.   or    dword ptr [esp + 8], 100h     ;устанавливаю TF
10.   iretd                               ;возвращаюсь к трассировке
11.  

тем не менее это не помогает, этот код просто не выполняется (как выяснилось) т.е. обработчик инт3 не вызывается.

Правда в толмутах интела на странице 490 (глава 15.3.1.4) одна фишка написана

The INT n and INTO

instructions, however, do clear this flag. Therefore, software debuggers that single-step code

must recognize and emulate INT n or INTO instructions rather than executing them directly.



типа трейсер обязательно! должен распозновать бряк 0xCC и др. прерывания INTn и эмулировать их выполнение, т.е. трассировать инструкцию инт нельзя!... но вот обзацем позже написано



The external

interrupt handler does not run in single-step mode. To single step an interrupt handler, single step

an INT n instruction that calls the interrupt handler.



и если я правильно перевел - то инструкцию инт все же можно трассировать, но как же обработать это исключение?! ...ЕПРСТ! ]:-/



ну ладно допустим это таки можно эмулировать, а как же обрабатывать исключения типа mov eax, dword [0] - я сделал аналогично, установил обработчики 13 и 14 прерываний перед выполнением трассировки вот такие

Код (Text):

1.  
2.   and   dword ptr [esp + 0Ch], not 100h  ;cбрасываю TF
3.   add   dword ptr [esp + 4], 5           ;перепрыгываю через глючную инструкцию mov eax, [0]
4. ; перепрыгивать по идее надо т.к. это исключение типа fault, т.е. eip указывает на последнюю
5.   or    dword ptr [esp + 0Ch], 100h
6.   iretd
7.  

и все равно я вижу одну и туже вонючую даль!

 

по поводу непонятки с дпл я вроде уже сообрабзил (или нет) - это если приложение ринг3 попытается сгенерить непосредственно прерывание 0 через инт0, у которого дпл=0, тогда произойдет исключение инт13. А если в ринг3 произошло деление на ноль, то инт0 сгенерит сам проц!



Хотя какая разница?!?! :-\



Люди, может у кого есть искодники трейсера ну или дебагера? какие-нибудь не слишком замучанные силой мысли

 

Да, и еще такой вопрос интересный - как определить, что дебажное прерывание произошло из ринг3 (т.к. в этом случае в стеке еще сохраняется стековый селектор и указатель, которые потом надо восстановить). Вроде как надо по дебажным регистрам смотреть, но я ничего на нашел.

 

RTFIM (read the f..king Intel Manuals).



В каком режима произошло прерывание можно определить по CS в стеке (по 2м младшим битам).

 

но вот по поводу RTFM ты, чувак, не прав! найди мне хоть один тутор нормальный по режиму дебага! - ни одного! по поводу Интел мануал - дык я их и читаю, как ты можеш догадаться по моим постам, но их читать это все равно что читать DDK, НУНП (Ни ..Уя Не Понятно)



и вообще:

а) что-то по колличеству ответов в этом топике я не вижу чтобы кто-то шарил в дебаге

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

с) форум наверно для того и есть, чтобы выяснять неясные вопросы (а этот вопрос далеко не из простых!)

д) меня понесло поэтому без обид



про два байта не догадался - пасиба!

 

Очень жаль, но придется разбираться. Если совсем уж НУНП, то можешь оставить эту затею.

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

А ты сам приложил хоть какие-то усилия?

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

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

 

Godness



Надо было смайлик поставить после RTFIM.



Ты бы сказал, что хочешь сделать-то. Трассировку с заходом в обработчики прерываний? Просто пропускать int3 при трассировке?



Имей ввиду, при возникновении программных/аппаратных прерываний при трассировке процессор сохраняет в стеке флаги с установленным TF, а затем сбрасывает TF и обработчик выполняется в обычном режиме! При завершении обработчика, команда iret извлечет из стека флаги с установленным битом TF и трассировка продолжится.





Ну а если же ты хочешь реализовать неуязвимый трэйсер, вот список threat'ов (не всех) для трэйсера:



1) трассируемая команда вызывает исключение -- сюда много входит.

2) трассируемая программа выполняет pushfd (а там TF=1...)

3) трассируемая программа выполняет popfd -- может начать трассировать сама себя

4) трассируемая программа выполняет iretd -- тоже самое

5) mov ss,xx/pop ss -- подлая штука, может быть с префиксами

6) трассируемая программа выполняет intxx/int3/icebp

7) трассируемая программа выполняет into

8) трассируемая команда читает int1 descriptor

9) трассируемая команда пишет в int1 descriptor

10) трассируемая программа выполняет sidt (...)

11) трассируемая программа выполняет lidt

12) трассируемая команда пишет в dr6 (использует для хранения чисел/проверки)

13) Вариации: трассируемая программа ставит свой обработчик INT1/3, начинает трассировать себя, ставит Hardware-breakpoint'ы на чтение/запись/выполнение, использует исключения для своих нужд и всё это может срабатывать одновременно (и приоритет играет роль).



Желательно очень твердо знать особенности обработки программных/аппаратных прерываний и исключений, чтобы писать трейсер... Кстати, есть отличная книга В.Л. Григорьева "Микропроцессор i486" (в 4-х книгах). Гораздо приятнее мануалов читается.

 

Ms Rem



Согласен. Я, таки да, погарячился с фразой я не вижу чтобы кто-то шарил в дебаге, что конечно задевает - поэтому прошу прощения!



Утрудись почитать серию статей "Процессор в защищенном режиме"



Понятно, что ты ее не читал - там нет ничего вообще про прерывания! А саму серию я достаточно хорошо изучил, может по битикам и не разложу, но суть понимаю.



Этот форум создан для выяснения интересных вопросов



Ну тогда давай считать, что этот вопрос я задал в разделе "For begginers". Тогда бы ты ответил?



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





_BC_



Это я кажется торопился и поэтому не внятно изложил суть непонятки.



Непонятка в следующем - какое прерывание возникает, когда трейсер встречает бряк 0xCC. Насколько я проверял при этом прерывание инт3 не происходит. (обойти этот бряк я и так смогу конечно).



А если он встречает исключение mov ax, [0], то тоже какое прерывание возникает? и почему те мои обработчики падают?

 

кстати, чето с этим я реально тупанул -

Код (Text):

1. and   dword ptr [esp + 8], not 100h ;сбрасываю флаг TF

пурга, действительно

 

Я ее читал, просто мне показалось, что прерывания там не забыли описать.

Не знаю как у тебя, а у меня оно всегда происходит. Код обработчика у меня примерно такой:

Код (Text):

1. void _declspec (naked) NewInt3Handler()
2. {
3.     __asm
4.     {  
5.         pushad
6.         mov di, 0x30
7.         mov fs, di
8.         mov eax, [esp + 0x20]
9.         dec eax
10.         push eax
11.         call Int3Check
12.         test eax, eax
13.         jnz True
14.         mov di, 0x3B
15.         mov fs, di
16.         popad
17.         dec [esp]
18.         iretd
19.  
20. True:   mov di, 0x3B
21.         mov fs, di
22.         popad
23.         jmp OldInt3
24.  
25.     }
26. }

Вызываемая функция Int3Check выполняет обработку и решает передать ли управление оригинальному обработчику.



Вот мой обработчик int 1:

Код (Text):

1. void _declspec (naked) NewInt1Handler()
2. {
3.     __asm
4.     {      
5.  
6.         pushad
7.         push fs
8.         mov di, 0x30
9.         mov fs, di
10.  
11.         push eax
12.         call Int1Check
13.  
14.         test eax, eax
15.         jz True
16.        
17.         mov eax, [esp + 0x2C]
18.         and eax, 0xFFFFFEFF  // сбосить флаг TF
19.         or  eax, 0x10000     // установить флаг RF
20.         mov [esp + 0x2C], eax
21.  
22.         xor eax, eax
23.         mov dr7, eax
24.         mov dr0, eax
25.  
26.         pop fs
27.         popad
28.         iretd
29.  
30. True:   pop fs
31.         popad
32.         jmp OldInt1
33.  
34.     }
35. }

Возникает прерывание 0E.

А обработчики падать могут по одной причине - потому что они кривые.

 

Ms Rem



RF ставить не надо, процессор сам установит его (если конечно не требуется специально пропустить апп. брекпоинт по выполнению на след. команде).

 

забавно



Intel Manual:

Вышеупомянутый В.Л. Григорьев:

(прим.: у Григорьева нарушение = fault, ловушка = trap)

 

Наконец то получилось протрассировать инт3! ура! тут вроде понятно, но вот снова два прикола -



первый:



не трассируется исключение mov eax, dword [0]

вот мой обработчик интE

Код (Text):

1.  
2.   cmp  isTrace, 1
3.   jne  sys        
4.   add  esp, 4
5.   add  dword ptr [esp], 4 ;перепрыгиваю через mov eax, [0]
6.   or   dword ptr [esp + 8], 100h
7.   iretd                   ;возвращаюсь в трассировку
8. sys:
9.   jmp [OldIntE]
10.  

вроде же все правильно, так, но система вылетает с IRQL_NOT_EQUAL и т.д. Что же не так?



и второе недоразумение - вот мой трассировщик инт1

Код (Text):

1.  
2.    pushad
3.    mov     eax, CountOfCommand
4.    inc     eax
5.    mov     CountOfCommand, eax
6.    cmp     eax, NumberOfTracedCommand
7.    jz      stop_trace
8.    popad
9.    or      dword ptr [esp+8], 100h
10.    iretd
11.  
12. stop_trace:
13.    mov     isTrace, 0
14.    mov     TracerCallBack, 0
15.    mov     NumberOfTracedCommand, 0
16.    popad
17.    and     dword ptr [esp+8], not 100h
18.    iretd
19.  

вроде бы тоже нормально, но он не трассирует код ринг3! т.е. выполняет одну трассировку (там скажем 5 команд). а когда я задаю повторную (не выходя из отладчика) система рушится без каких либо синих экранов?! при этом код ринг0 (ну скажем вылился там внутри системы) выполнятся хоть тысячу раз по пять и все нормально?! ничего не валится.

я в недоумении?!

 

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

 

Обработчик int 1 выполняется при IRQL > DISPATCH_LEVEL, так что проверь не обращаешся ли ты в нем к подкачиваемой памяти (например к памяти трассируемого процесса).

Не пользуйся отладчиком. Софтайс плохо совместим с трассировщиками хукающими int 1. Или в обработчике прерывания определяй когда надо передать управление оригинальному обработчику который стоял до тебя. И то система под софтайсом при этом будет вести себя крайне нестабильно.

 

А там точно 4-х байтовая версия этой команды (67A3)? Посмотри, может там 5-байтовый вариант.