Решил продолжить исследования работоспособности антиотладочных приемов на платформе Windows 7.
В своих исследованиях я как всегда буду опираться на статьи Криса Касперского, в данном случае "Трассировка — в погоне на TF или SEH на виражах" и "cкрытая установка SEH-обработчиков" из небезызвестного журнала, а так же на цикл статей Мэтта Питрека "Win32™ SEH изнутри" и "Новая векторная обработка исключений в Windows XP"
Начнем с SEH (structured exceptions handling). Начиная с висты в виндовс используется технология SafeSEH, обеспечивающая защиту от подмены SEH обработчика. Раньше указатели на обработчики структурных исключений хранились в стеке, беспрепятственно доступном на запись/чтение, то теперь они переместились в специальные секции PE-файла, доступные только на чтение и формируемые статическим образом еще на этапе сборки программы при активном участии со стороны линкера и компилятора. Поэтому при использовании установки обработчика таким образом:
mov ecx, fs:[0] ; // save old SEH handler
mov old_seh, ecx
push -1 ;
push offset main_handler ;
mov fs:[0], esp ; // set-up our SEH handler chain
Нужно указывать линкеру /SAFESEH:NO, для того чтобы он не создавал таблицу обработчиков. Конечно лучше использовать явную инициализацию обработчика:
.386
.model flat
MyHandler proto
.safeseh MyHandler
end
Теперь поговорим о VEH(vectored exception handling). SEH и VEH очень схожи. Они предоставляют аналогичные возможности и вся разница между ними в том, что вместо ручного манипулирования со списками обработчиков теперь у нас есть API-функции AddVectoredExceptionHandler/RemoveVectoredExceptionHandler, устанавливающие/удаляющие векторные обработчики из списка, указатель на который хранится в неэкспортируемой переменной _RtlpCalloutEntryList внутри NTDLL.DLL (по одному экземпляру на каждый процесс). Плюс, упростилось написание локальных/глобальных обработчиков исключений, что в случае с SEH – большая проблема. А OllyDBG2.0 все также палится по флагу трассировки, если его чтение происходит в обработчике исключений((.
В своих исследованиях я как всегда буду опираться на статьи Криса Касперского, в данном случае "Трассировка — в погоне на TF или SEH на виражах" и "cкрытая установка SEH-обработчиков" из небезызвестного журнала, а так же на цикл статей Мэтта Питрека "Win32™ SEH изнутри" и "Новая векторная обработка исключений в Windows XP"
Начнем с SEH (structured exceptions handling). Начиная с висты в виндовс используется технология SafeSEH, обеспечивающая защиту от подмены SEH обработчика. Раньше указатели на обработчики структурных исключений хранились в стеке, беспрепятственно доступном на запись/чтение, то теперь они переместились в специальные секции PE-файла, доступные только на чтение и формируемые статическим образом еще на этапе сборки программы при активном участии со стороны линкера и компилятора. Поэтому при использовании установки обработчика таким образом:
mov ecx, fs:[0] ; // save old SEH handler
mov old_seh, ecx
push -1 ;
push offset main_handler ;
mov fs:[0], esp ; // set-up our SEH handler chain
Нужно указывать линкеру /SAFESEH:NO, для того чтобы он не создавал таблицу обработчиков. Конечно лучше использовать явную инициализацию обработчика:
.386
.model flat
MyHandler proto
.safeseh MyHandler
end
Теперь поговорим о VEH(vectored exception handling). SEH и VEH очень схожи. Они предоставляют аналогичные возможности и вся разница между ними в том, что вместо ручного манипулирования со списками обработчиков теперь у нас есть API-функции AddVectoredExceptionHandler/RemoveVectoredExceptionHandler, устанавливающие/удаляющие векторные обработчики из списка, указатель на который хранится в неэкспортируемой переменной _RtlpCalloutEntryList внутри NTDLL.DLL (по одному экземпляру на каждый процесс). Плюс, упростилось написание локальных/глобальных обработчиков исключений, что в случае с SEH – большая проблема. А OllyDBG2.0 все также палится по флагу трассировки, если его чтение происходит в обработчике исключений((.
Комментариев нет:
Отправить комментарий