Сейчас на форуме: tyns777, cppasm, dutyfree (+8 невидимых)

 eXeL@B —› Вопросы новичков —› Адреса обработчиков
Посл.ответ Сообщение

Ранг: 18.9 (новичок), 4thx
Активность: 0.030.05
Статус: Участник

Создано: 20 июня 2017 22:35
· Личное сообщение · #1

Есть ли универсальное решение (XP-Win10) для нахождения адресов процедур текущих обработчиков исключений?
Т.е. для SEH проблем вроде как нет, читаем fs:[0] и проходимся по цепочке читая адреса обработчиков, пока в первый элемент не равен 0FFFFFFFFh
А как это сделать для VEH не понятно.
Для ХР обработчики хранятся в ntdll!RtlpCalloutEntryList, для Vista+: в ntdll!LdrpVectorHandlerList[0], притом их еще надо дешифровать через process cookie

Как ни странно в отладчиках нет кнопки "посмотреть список текущих обработчиков VEH", отдельных тулз тоже не нашел, хотел попробовать реализовать сам, но столкнулся с такими вот заморочками...
Моя конечная цель - попробовать идентифицировать модуль который содержит процедуру обработчика (подразумевается, что обработчик ставит стороннее приложения через хуки процедур с установкой int3 в интро).
Понятное дело, что тут много нюансов и если код находится в динамически выделенной памяти, то GetModuleHandleEx не идентифицирует модуль и нужно будет трассировать и смотреть по факту, но проблемы уже на моменте получения списка.

Что можете посоветовать?




Ранг: 337.5 (мудрец), 348thx
Активность: 2.112.42
Статус: Участник

Создано: 21 июня 2017 00:01 · Поправил: difexacaw
· Личное сообщение · #2

Ate

Можно разложить код обработчика RtlDispatchException() на трассу, так можно обнаружить вызов вектора.
Напрямую сделать это через классическую TF нельзя - будет деадлок.
VEH это синхронный вызов с его регистрацией. В младщих версиях системы используются критические секции, в старших - слим блокировки(RWL).
Диспетчер исключений содержит баг во всей линейке - страссировочный деадлок. При трассировке кода может возникнуть исключение. При исключении TF переносится в диспетчер исключений и возникает второе исключение(ловушка) в KiUED. При дальнейшей трассировке будет трассирован код диспетчера до входа в критическую секцию и далее произойдёт деадлок при изменении кс структуры.
По этой причине диспетчер не может быть прямо трассирован.

Есть простое и эффективное решение.
SEH не может быть выполнен вне модуля(DEP: NX). Загрузчики из памяти должны фиксить диспетчер для реализации сех вне image-памяти.
Самый простой и эффективный способ - перенос секции кода нтдлл в буфер(простое копирование области). Это возможно так как данный модуль не релокабельный и секция кода не содержит релатив ветвлений за её пределы. В этом буфере нужно обнаружить вызов VEH из диспетчера и поставить на этот вызов стаб. При начале исполнения диспетчера нужно выполнить переключение на этот буфер. Если это произвольный код, то диспетчер исключений нужно патчить для получения управления. Если это свой код, то можно использовать трассировочный баг - установить TF и вызвать исключение. Из VEH выполнить переключение на буфер и отпустить поток.

Добавлено спустя 5 часов 12 минут
Семпл.

004c_21.06.2017_EXELAB.rU.tgz - VEH.rar

-----
vx


| Сообщение посчитали полезным: mak
 eXeL@B —› Вопросы новичков —› Адреса обработчиков
:: Ваш ответ
Жирный  Курсив  Подчеркнутый  Перечеркнутый  {mpf5}  Код  Вставить ссылку 
:s1: :s2: :s3: :s4: :s5: :s6: :s7: :s8: :s9: :s10: :s11: :s12: :s13: :s14: :s15: :s16:


Максимальный размер аттача: 500KB.
Ваш логин: german1505 » Выход » ЛС
   Для печати Для печати