Всем Zzдар0ва! И сразу хитрая замутка... не могу понять как это работает, смотрите

  
  nop <- останавливаюсь здесь
  nop
  pushad
  push   TTT
  push   dword [fs:0]
  mov    dword [fs:0], esp
  int 1
  nop
TTT:
  pop    dword [fs:0]
  add    esp, 8
  jmp    NNN

Останавливаюсь в указанном месте и делаю так: с помощью !idt вытаскиваю обработчик int1 и командой eb (не bpx) изменяю его первый байт на 0xCC. Также ставлю бряк на обработчике ТТТ и включаю i3here on. Теперь вроде логично - если топнуть F8, то возникнет прерывание int1, т.к. проц находится в режиме трассировки, и сработает поставленный бряк 0xCC т.е. сосулька выльется внутри обработчика int1. А теперь совсем не логично... - если вместо F8 топнуть F5, то (!?!?!?) сначала сработает бряк на ТТТ и только потом поставленный бряк 0xCC в обработчике int1... Так кто же тогда обрабатывает int 1 сгенерированное прогой ;(... Либо я совсем ничего не понимаю (что скорей всего) либо обработчик int1 заменяется другим...

в таких страшных эхспериментах нельзя F5,
надо CTRL-D

Godness
Этот хитрый замутка был притаранен из времён ms dos/real mode. Смотреть у Крис Касперски "Техника и философия хакерских атак". Прикольный замут !!!!

je_

Слово нельзя не употребляю ;)... К тому же CTRL-D или F5 - один хер... хотя попробую, но думаю будет тоже самое...

CARDINAL

Да ну перестань - буду я искать эту книжку в бесконечных просторах инета ради одного вопроса. Сам бы прочитал и рассказал, что за замут ;)...

раз пишу знамо есть разница..

в "Технике и философии" такого не было, во всяком случае в первом издании. А вот во втором уже было. Если кратко, то push label/push fs:[0]/mov fs:[0],esp устанавливает
обработчик структурных исключений на label, а int 1 как раз такое исключение и вызывает. без отладчика, int 1 эквивалентен goto label, а с отладчиком... увы! большинство отладчиков подавляет генерацию исключения по int 1, обрабатывая ее самостоятельно, поэтому управление никуда не передается... если на int 1 повешан расшифровщик, то под отладчиком программа остается нерасшифрованной.
выход (применительно к soft-ice) трассировать программу через аппаратные точки останова - благо он это позволяет.
P.S. а обработчик int 1 надо смотреть (в данном случае!) командной xframe

kaspersky
Простите, Сэр, обшибся может маленько. Но ведь помню, видел это уже и в Вашей же книжке...

Godness
1. дебуггер всё-же может не ответить на бряк в собственном коде;
(видно вы пользуетесь iceext? тогда может iceext игнорирует?)

Вау! Кто тут нас посетил - сам товарищ kaspersky :)))... Спасибо за краткое введение в теорию SEH'ов, но я итак ее неплохо знаю. Вы недочитали мой пост до конца! Недоразумение совсем в другом...

je_

И в ответ на Ctrl-D тоже самое - сначала срабатывает обработчик SEH, а потом бряк внутри int1. Говориш что сразу не реагирует на 0xCC, но ведь потом то реагирует - и смысл? Если обработчик int1 в idt заменяется другим, то это значит, что IceExt тоже показывает неправльный обработчик int1 в idt (ну как и сосулька показывает ntoskrnl!Kei386... а, там на самом деле ntice!.text)... Таааак, похоже столь "простенькой" задачкой я поставил всех в неловкое молчание :))).

Не люди - это же реальная непонятка!? Черт - хочется разобратся, а ведь лень то как! Думал, может кто уже знает ответ... Sten'а случайно поблизости не видели, может он приподнимет завесу тайны...

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

Godness

Ты мне по порядку скажи, что делаешь, а то я совсем запутался. Ты говоришь, что смотришь !idt. Так вот, тебе эта команда до задницы, т.к. айс сам хватает int1/3 (и кучу остальных), а тебе показывает бывшые вектора (от ntoskrnl). Впрочем, ты и сам это знаешь.

Во-вторых, уже у мя к тебе вопрос. Реентерабельность прерывания, говоришь? Что происходит при прерывании в прерывании?

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

Volodya, как же тебя легко запутать... А что непонятно, я вроде все толком обьяснил - даже мне самому понятно (местами :)

>Ты говоришь, что смотришь !idt. Так вот, тебе эта команда до задницы, т.к. айс сам хватает int1/3 (и кучу остальных), а тебе показывает бывшые вектора

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

>поставил бы бряк с помощью айса в самом айсе (в нужном тебе обработчике прерывания)

Дык что же я и пытаюсь сделать. Т.е. ставлю бряк 0xCC в обработчике int1 и ожидаю что он сработает. Но срабатывает он только тогда, когда трейсиш прогу пошагово, но не срабатывает если приложение ring-3 пытается выполнить инструкцию int 1.

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

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

!idt
Interrupt Descriptor Table for CPU0
IDTBase=8003F400  Limit=07FF
0000  IntG32  0008:F41CBFDE  DPL=0  NTice!.text+00086C5E
0001  IntG32  0008:F40131B0  DPL=0  iceext!.text+5D30
...

u F40131B0

F40131B0    cmp    dword [F40417D4], 0
F40131B7    jz     F40131BF
F40131B9    call   [F40417D4]
...

подпачил его следующим образом

F40131B0    jmp    F4041C04
F40131B5    nop
F40131B6    nop
F40131B7    jz     F40131BF
F40131B9    call   [F40417D4]
...
F4041C00    dd 00000000
F4041C04    inc    word [F4041C00]
F4041C0B    cmp    dword [F40417D4], 0
F4041C12    jmp    F40131B7

т.е. никаких бряков - теперь будет наверняка инкрементироваться переменная F4041C00... И таки да - она инкрементируется если трассировать любой попавшийся код. Но если хоть сто раз подряд запустить прогу, которая пытается выполнить инструкцию int1 - хрен там, переменная F4041C00 как была нулевой, так и осталась...

Ну теперь логично предположить, что сосулька перед появлением на экране перенастраивает таблицу idt, как бы приготавливаясь к режиму трассировки, устанавливая обработчики, которые мы видим командой !idt. Я просто запустил драйверок, который скопировал idt до и после появления сосулки, вот он:

format PE native
entry start
include '%fasminc%\win32a.inc'
;+++++++++++++++++++++++++++++++++++++++++++++++++++;
section '.data' data readable writeable notpageable
  rdt_old rd 4
  idt_old rd 8

  rdt_new rd 4
  idt_new rd 8

section '.code' code readable executable notpageable

   start:
	pushad                           ;до появления сосулки
	cld
	sidt   fword [rdt_old]
	mov    esi, dword [rdt_old + 2]
	mov    edi, idt_old
	mov    ecx, 8
	repz movsd
   db 0xCC
	sidt   fword [rdt_new]           ;после появления сосульки
	mov    esi, dword [rdt_new + 2]
	mov    edi, idt_new
	mov    ecx, 8
	repz movsd
	popad
	mov    eax, STATUS_DEVICE_CONFIGURATION_ERROR
	ret    8
;+++++++++++++++++++++++++++++++++++++++++++++++++++;
section '.reloc' fixups data readable discardable

Таблица и регистр ridt как были одними и теми же так и остались - ничего не перенастраивается.

Ну и что?! Тык значит, что инструкция int 1 сгенерированная кодом ring-3 не попадает в обработчик int1, а обрабатывается либо обработчиком invalid'ных команд или обработчиком привелигерованных команд. Ну а как еще?!?!

je_, на вы не надо! Не первый день на форуме ;)...

volodya

>Реентерабельность прерывания, говоришь? Что происходит при прерывании в прерывании?

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

Четко усвоил только одно - бряк 0xCC в обработчике int3 лучще не ставить :-)

подождите!

А у INT01 DPL-то какой!?

Айс меняет DPL int 1. iceext восстанавливает его назад.