Но тогда возникает вопрос, как отлавливать создание новых фреймов

Ну... В принципе, неуниверсальное решение - это перехват соответствующих функций ntdll.dll. Никаких DR-регистров, ничего такого использовать не надо.

MoonShiner

KiUserExceptionDispatcher нет в мастае (а у меня мастдая нет, что бы посмотреть как там всё), но я предлагаю падчить не непосредственно его, а конечную точку, непосредственно вызывающую твой SE Handler - этот фрагмент ExecuteHandler2 я привёл. как обстоят дела на других системах я не знаю, но что-то мне подсказывает, что адрес вызываемого SEH всё так же будет лежать в [dword ss:ebp+18] - нужно тока убедиться в этом.

Max
„речь идет о том, что ринг0 лезет к секции данных, или к секции кода?“
„Ты не проверял?“

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

И потом, кто сказал что нельзя передавать управление на данные? XP SP2? Вот на него и будем ориентироваться.
Только я спешить не буду, а подожду (пусть даже пару лет), пока AMD-64 подешевеет - и тогда смогу пользоваться NoExecute-флагом в свое удовольствие :)

S_T_A_S_
„Что-то всё сложно так, мне до DR регистров далеко ещё,“

Это ты просто не пробовал :)
ba (break-on-access) в отладичках использовал? Вот он как раз и реализован через DR-регистры. Всего-то делов, вызвать SetThreadContext для их изменения...

Бредовая идея:
Если речь идет об "универсальном пакере", то не стоит исключать непростой, но "изящно-эстетичный" вариант - патчить саму прогу, т.е. вылавливать установку SEH-ов по обращению к fs:[0] и подменять push оригинального обработчика на санки по типу переадресации таблицы импорта при отладке под 9x. Наверное это можно делать не только в процессе распаковки в runtime, но и до или в процессе упаковки.
Думаю вариаций установки SEH-ов по жизни не более двух-трех, а в языках высокого уровня наверняка используется один из излюбленных вариантов (например в дельфях это всегда xor eax,eax + push fs:[eax] + mov fs:[eax],esp).

PS: чувствую будут бить, возможно ногами :)

MoonShiner
Заводить второй процесс, который будет отлаживать другой как в армадилле я не могу

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

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

нуу, ReadFile в секцию кода (которая у всех нормальных людей real-only) может сделать только настоящий оптимизатор :))
а вот то, что HLL компилятор засовывает в секцию кода данные (строки) - сплошь и рядом.
ты не мог бы припомнить, какие именно параметры при вызове RegisterClassEx указывали на PAGE_NOACCESS?
хотца востановить эту ситуацию да поэкспериментировать.

leo
патчить саму прогу, т.е. вылавливать установку SEH-ов по обращению к fs:[0] и подменять push оригинального обработчика

чиста теоретически, можно перевести fs:[0] в линейный адрес через GetThreadSelectorEntry и поставить DR регистр на этот адрес по записи.
или попробовать поставить page_readonly на тот-же адрес.
в результате, при попытке установки seh'а вылетит искючение, надо только обработать его первым...

Max
„ты не мог бы припомнить, какие именно параметры при вызове RegisterClassEx указывали на PAGE_NOACCESS?
хотца востановить эту ситуацию да поэкспериментировать.“

Так как у меня все подряд (в том числе и секции данных) было PAGE_NOACCESS, то туда наверняка указывал первый и единственный параметр функции :)

„или попробовать поставить page_readonly на тот-же адрес.“
Я же говорю - пробовал (на win2K), не работает. :(

P.S. Кстати, умные люди советовали под NT вместо PAGE_NOACCESS использовать PAGE_GUARD. Но к тому времени, как я увидел этот совет, желание писать свой монитор у меня уже пропало :(

я вот тут решил заставить систему обращаться к странице с PAGE_NOACCESS...
ну, думаю, щас поставлю PAGE_NOACCESS на fs:[0] и вызову исключение...

fs:[0] есть 0x7FFDE000.
так вот вызов VirtualProtect на этот адрес с флагами PAGE_NOACCESS или PAGE_GUARD система не пропускает.
в тоже время PAGE_EXECUTE_READWRITE проходит.

умная зараза :)

вообщем тут по синьке я немного поэкспериментировал, и вот что получилось...
1. устанавливаем dr0 на fs:[0] (по чтению/записи)
2. вызываем исключение.

по идее, должно произойти обращение к fs:[0] системой, с целью определения цепочки обработчиков...

так вот, получается, что процесс-отладчик сначала получает уведомление о эксепшене, который я вызвал...

...а потом идет поток эксепшенов (~1200 штук) внутри ZwSetIoCompletion, после чего отлаживаемый процесс нестандартно сносится с уведомлением EXIT_PROCESS_DEBUG_EVENT.

sorry, на большее меня пока не хватило....

з.ы. ZwSetIoCompletion пахнет уже железнячеством, в котором я не силен :(

попробуй ставить только по записи?