Альтернативы хукингу SSDT

Deyton
BitDefender выгрузил свой драйвер.

А как может получиться, что хук неверно корректирует стек, и при этом при передачи управления настояшей функции OS она не падает? Т.е. почему система начинает падать только в момент появления цепочки хуков?

 

Почему не 5?) Опытным путём или есть источник?

 

Great
Я с тобой согласен, у меня вообще немного по-другому из-за кое каких особенностией, это для примера, чтобы понятно стало суть; ну а реализацию я думаю уже каждый сам себе сделает.

Потому-что код в месте вызова системного сервиса выглядит примерно так:

Код (Text):

1. call ebx
2. mov esp, ebp

То есть правильное значение ESP восстанавливается из регистра.

Пока что встречал, когда переписывается всего один DWORD, который принадлежит моей функции, так, для запаса, взял 4. Думаю если кто-то будет херить стек еще больше, то врядли вообще будет работать, даже если больше никто не хукает, хотя хз...

 

Ну конечно. Только вот
1. Вероятность достаточно мала.
2. Было как-то предложение смотреть на eip каждого потока перед хуком, да только это пахнет гемороем.

 

Deyton
Сценарий похожий на Comodo у меня наблюдается с Panda. Проверил с кучей антивирусов: norton, nod, kasp, trend micro, mcaffee, ... Единственный проблемаичный - panda. Примерно раз в неделю делает BSOD, причем crash dump не дает никакой разумной информации где именно произошла проблема. Обидно, что panda не работает с checked build. Скажи, как бы можно было локализовать проблему?

 

да, я постил эту тему с поиском EIP. в итоге я так и не написал нормальную реализацию и решил, что лучше патчить однобайтовой командой, например, CC

 

katrus
Альтернатива подменить указатель на SSDT в ETHREAD. Для гуишных потоков это сканает наура, для негуишных придётся сконвертировать поток в гуишный, потому как если поток самостоятельно попробует сконвертировацца - он умрёт. Функция для этого спецальная есть. И смысл было такой флейм разводить.

 

Нет, он имеет указатель на SSDT, а вот уникальной она по умолчанию быть не может, поскольку в НУ существует лишь 2 указателя, один для гуи, второй для гуи. Это уже по вашему усмотрению решать, будет ли SSDT уникальная для потока или нет бугага

 

k3internal

Вопрос то не в этом... У меня драйвер который является "фильтром" нескольки системных вызовов системы для всех процессов. Драйвер антивируса является точно таким-же драйвером. Вместе они жить иногда отказываются...

 

Код (Text):

1. KeInitThread:
2. ;Esi:PETHREAD
3. mov [esi].ServiceTable,KeServiceDescriptorTable
4.  
5. KiSystemServiceRepeat:
6.         mov     edi, eax                ; copy system service number
7.         shr     edi, SERVICE_TABLE_SHIFT ; isolate service table number
8.         and     edi, SERVICE_TABLE_MASK ;
9.         mov     ecx, edi                ; save service table number
10.         add     edi, ETHREAD[esi].ServiceTable ; compute service descriptor address

Можно установить свою таблицу сервисов, далее любые перехваты в KeServiceDescriptorTable для этого потока раблтать не будут.

 

Просто так вы не подмените sdt в kthread, дело в том что на первом вызове гуевой ф-ии win32k.sys конвертит поток в гуевый (ыы, "гуевый поток") и если указатель не указывает на стандартную sdt то ф-я возвращает статус ошибки и все летит к чертям. Проще всего похукать сплайсингом (саспендить при этом совершенно ничего не надо) сисентер, что я и делаю, для этого надо только немного покурить стандартный обработчик, ибо те кто заявляет что для этого достаточно __writemsr() - просто нашли в гугле кучу неверных примеров, и сами никогда этого не делали, чтобы просто похукать достаточно записать msr, но чтобы этот хук хоть как-то использовать - надо совершить немало телодвижений в стостоянии расширенного сознания.

 

Дак я тебе и дал ответ на твой вопрос.

 

tylerdurden
Шэф, знаем, плавали. Если сильно захотеть то самому можно конвертнуть). Это вполне реально.

 

Ага, а лучче фсево покурить интелловский ман по данной инструкции, а то всё время про edx забывають

 

Всё правильно, с гуи не получится:

Код (Text):

1.     cli
2.     mov ecx,176h
3.     rdmsr   ;89Fh
4.     dec eax ;указатель на команду nop перед KiSystemService
5.     xor edx,edx
6.     wrmsr
7.     sti

Это падает, но если поток не будет гуевским, то работать должно.
В ntoskrnl на KiSystemService(этот адрес в msr) всего две ссылки: первая - код, который загружает обработчик в msr, вторая - в обработчике Int 01h. Причем, код загружающий SYENTER_EIP_MSR, KiLoadFastSyscallMachineSpecificRegisters:
KeRestoreProcessorSpecificFeatures->KiRestoreFastSyscallReturnState->KiLoadFastSyscallMachineSpecificRegisters
Находится в переменной в секции .data, на данную функцию много ссылок, даже если и будет востанавливатся msr,
то можно перехватить KiLoadFastSyscallMachineSpecificRegisters. Как будет для win32k не знаю.

 

Great

не вижу трудностей.

 

Я не пойму, в чем проблема ? Разве трудно :
1) найти РЕАЛЬНУЮ функцию ядра
2) похукать SSDT
3) вызывать реальную функцию ( а не ту что была в SSDT )
? Ребята последнее время вы все геморойней, и геморойней решения принимаете. обидно.

 

WIN32

Сегодня врядли это работать будет.

 

WIN32

Основное требование - не влиять на нормальное функционирование антивируса.

 

А что мешает переписать первые байты функции, и вписать прыжок на свою функцию? я так делаю и с антивирусами живёт отлично