Небольшое вступление:

Читая замечательную статью "Об упаковщиках в последний раз" от Volodya / HI-TECH, NEOx / UINC.RU впервые узнал о VEH, заинтересовался, сходил по линку - да и только. Но прошло время, сел писать прогу и знаете ли вспомнилось. Вспомнил о AddVectoredExceptionHandler и RemoveVectoredExceptionHandler, апишки описанные на указанном линке. Все хорошо - да SEH своим

 push fs:[0]
 mov fs:[0],esp 

уж больно понравился. Ну и ...

Исследования:

Лезу в ntdll.dll (а куда ж ещё), нахожу почти что искал - те же две функции, но с префиксом Rtl (не беда - аналогично, например, ZeroMemory -> RtlZeroMemory). Если честно, то ожидал увидеть, что то типа:

 mov eax,XXX
 mov edx,7FFXXXXX
 call edx

edx:
 mov edx,esp
 sysenter

(кто смотрел ntdll - поймет меня) и тогда уже все вопросы к Four-F (огромный респект за уникальные статьи - так держать). Ничего подобного - строчек сорок понятного кода и всё, даже и не верится. В общем, смысл такой: имеется двусвязный (Microsoft, блин) список исключений, указатель на первый элемент находится по определенному адресу (об этом ниже), формат элемента таков:

+0: указатель на запись следующего обработчика
+4: указатель на запись предыдущего обработчика
+8: собственно указатель на ваш обработчик (VectorExceptionHandler)

как добавить\убрать свой обработчик- думаю ясно (можно посмотреть в аттаче). Что можно делать в VEH'е: по моим наблюдения получается, что по [esp+18h] имеем CONTEXT (сугубо IMHO),
ну и немного посмотрев на код после ret'a отрубаем SEH (or eax,-1), думаю, минимум необходимого соблюдён, всё.

Плюсы, минусы, замечания:
+:
Как говорилось в статье "Об упаковщиках ..." VEH имеет приоритет над SEH, первым обрабатывается (developer'ы защит, virmake'ры обратите внимание!)

Для вышеперечисленных особ, only: в данной реализации трудно локализовать (по коду размыть - как два пальца).

По желанию из VEH можно SEH отрубить нахрен:)

Не надо никаких апи - всё довольно просто и по дзенски

-:
Наверное, самый "-", то, что адрес головы VEH'a - константа. Что это значит: скорее всего от версии к версии (а может и от билда к билду) он будет изменятся. Как её получать (кроме как ручками) я пока не знаю, г-да researcher'ы может вы что скажите. У меня Windows Server 2003 Enterprise Edition, здесь 77FC2430 (в WinXP SP1 v1081 - 77FC32C0)

Использование только на платформах XP+ (з-з-зх 95\98 пролетает).

Ну и для самых ленивых, как определить адрес указателя на первый VEH: дизассемблим ntdll, смотрим в RtlAddVectoredExceptionHandler. После RtlEnterCriticalSection идет что-то вроде:

 cmp dword ptr [esp+0c],0
 je XXXXXXXX
 mov eax,dword ptr [77FXXXXX]

где 77FXXXXX и есть искомый адрес.


Подобную инфу не встречал (сорри если уже было и старо), ризёчил сам, так что задавайте вопросы, указывайте на ошибки и неточности.
Благодарю за внимание, с уважением Sem.

Небольшой и простенький пример использования VEH (и SEH - для сравнения) в аттаче, результат смотреть в отладчике.

474805310__VEH.rar

а еще проще врезаться в KiUserExceptionDispatcher и организовать свое подобие veh.
получается универсальный вариант для всех платформ NT+

Да с адресами туго - в той же XP SP1 только билд постарше - 2600 адрес уже 77FC3210. Так что надо или пройтись по ntdll на предмет вхождений этой константы либо ждать статью Питерека о VEH. Кто нибудь знает насколько широко винда его использует?

В общем кроме вышеуказанных функций с этим работает RtlDispatchException (которая вызывается из KiUserExceptionDispatcher). Для XР в самом начале вызывается RtlCallVectoredExceptionHandlers которая собственно начиная с головы пробегается по зарегистрированным обработчикам исключений.
Единственно засмущал меня код немного
RtlCallVectoredExceptionHandlers proc near
.text:77F60C26 ; CODE XREF: RtlDispatchException+Ep
.text:77F60C26 push ebp
.text:77F60C27 mov ebp, esp
.text:77F60C29 push ecx
.text:77F60C2A push ecx
.text:77F60C2B push edi
;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
.text:77F60C2C mov edi, offset VEH_HEAD
.text:77F60C31 cmp VEH_HEAD, edi
.text:77F60C37 jnz loc_77F7F485
;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
.text:77F60C3D xor al, al
.text:77F60C3F
.text:77F60C3F loc_77F60C3F: ; CODE XREF: .text:77F7F4C7j
.text:77F60C3F pop edi
.text:77F60C40 leave
.text:77F60C41 retn 8
.text:77F60C41 RtlCallVectoredExceptionHandlers endp

VEH_HEAD - адрес головы списка на моей платформе.77FC3210

Очень на заглушку похоже - разбирался с этим кто-нибудь?

Xornet

.text:77F60C2C mov edi, offset VEH_HEAD 
.text:77F60C31 cmp VEH_HEAD, edi 
.text:77F60C37 jnz loc_77F7F485

Такой код обычно встечается в программах которые внедряются в чужой процесс в качестве DLL. Мне кажется что в секции reloc есть запись только для mov, а для cmp нету. Так что если библиотека окажется загружена по другому адресу, переход вполне может сработать.

Согласен - вполне логично. Но библиотека как бы NTDLL.DLL - и грузится то скорее всего будет по своей базе. Тем более что основной код как раз и выполняется по переходу.