Использовать esp для адресации массива

Если esp = 0 при CPL = 3 (т.е. в user mode), то ничего страшного, т.к. для сохранения EFLAGS/CS/EIP используется стек обработчика прерывания, т.е. стек ядра.

 

Great
Вот тут я тоже не совсем понимаю. Точнее, я не знаю, что значит для отладчика First Chance/Second Chance.

Возможно, FirstChance вызывается если при первом обходе цепочки обработчиков никто не согласился обработать исключение, а SecondChance когда обработчики вызываются повторно, в процессе раскрутки? Но это только предположение. Да и какой смысл в этом я не понимаю.

 

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

например так

push handler
push fs:[0]
mov fs:[0], esp
xor eax, eax
mov [eax],eax

отладчик сначала брякнется на mov [eax], eax и скажет мол access violation at 00401020 while writing to 00000000, а уж потом можно выбрать - pass to the program или что там еще.

 

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

pushf
push cs
push offset _1
iretd
_1:

 

Great
Да, проверил, в обработчике вернул ExceptionContinueExecution, но отладчик поймал исключение раньше моего обработчика. М.б. он перехватывает что-то начиная с KiUserExceptionDispatcher?

 

Mika0x65
олька работает насколько я помню на DebugEvent-ах

 

Great

А что в нем иллегального? Выполняется iretd, процессор сравнивает CPL с CPL, который находится в стеке, в регистре cs, видит, что смены привилегий не произошло, извлекает из стека регистры, загружает их, и выполнение происходит дальше.

 

просто наблюдение, следующий код в режиме ядра ведёт к багчеку 0x0000007f (UNEXPECTED_KERNEL_MODE_TRAP) :

Код (Text):

1.     __asm xor esp, esp
2.     __debugbreak();

значит всё равно ядро как-то обрабатывает такое исключение, значит используется другой стек ядерного обработчика, иначе был бы аппаратный еррор

 

Mika0x65
да, согласен что протупил.. не про то думал когда писал)

 

rain
Давно хотел провести такой эксперимент. А какой номер обработчика при этом вызывается? Я раньше думал, что будет #DF, но сейчас не уверен.

 

Mika0x65
надо посмотреть какой тип trap-а. вполне возможно что и double fault

 

угу угадали 0x00000008, or Double Fault

 

rain
Но непонятно, как дальше идет работа со стеком? Уго ж, фактически, нет.

 

во-во, вот это и мне не понятно =\

 

n0name
Тогда почему олли нормально отрабатывает такой код

Код (Text):

1. mov  edx,esp
2. xor  esp,esp
3. nop
4. int3
5. nop
6. int 3
7. nop
8. mov  esp,edx
9. int3
10. ; mov  esp,some_buf
11. ; push eax
12. ; call [ExitProcess]

 

rain
вероятно в обработчике Double Fault это предусмотрено и он пересоздается..

 

тут спрашивали про first/second-chanse debug message. Ниже отрывок из руссиновича, он правда неуточняет насчёт стеков, но для общего развития прочитать стоит:

 

Если в ring-0 происходит исключение, обработчик которого тоже сидит в ring-0, то процессор пытается запихнуть адрес возврата и флаги в существующий стек. Если у него это не получается, а происходит снова исключение, получается Double Fault. А обработчик DF под виндой оформлен как отдельная задача, указан TSS, так что процессор делает task switch и использует новый стек, а он заведомо существует.

 

diamond пасиб, это вы из своего опыта или вычитали где-то?

 

rain Про общую обработку исключений - мануалы Интела, про #DF в винде - так показывает дамп IDT любым инструментом, #DF там один из очень немногих обработчиков, использующих собственную задачу.