Завершения драйвера вместе с процессом...

Согласен, действительно не внимательно прочитал

Windows 2000, код NtShutdownSystem начинается с "mov eax, [esp + 0x4]". Ладно, это решаемо, сохранили инструкцию, потом выполнили. Только вот проблема: в пределах short jump`a от нее нет свободного места под far jump. И как же быть? Наверное, нужно пойти msdn почитать, или выспаться и перекомпилячить винды с выравниваем функций по параграфу

ЗЫ: фишка с short jump`ом будет работать, если модуль скомпилирован с поддержкой hot patching. Эта штука в ядре винды появилась только с XP SP 2. А в драйверах ее никто не использует в принципе до сих пор.

 

именно это я и имел ввиду, старые ОС действительно не поддерживают эту фишку

 

есть механизмы в винде, чтобы такого не произошло.

 

Откуда вы такие умные взялись? Если не верите мне, то поверьте хотябы Марку Руссиновичу:

http://blogs.technet.com/markrussin...-decloaking-patch-eulas-and-phoning-home.aspx

 

Deyton
да про механизмы я не то сказал, я имел ввиду хранить число запущенных потоков в глобальной переменной. Однако руссинович прав, если на первой инструкции, то увеличения не произойдет и бсод.

Однако, кто же мешает пробежатся по KiWait[In/Out]ListHead и KiDispatcherReadyListHead, проверяя pThread->Tcb.TrapFrame->Eip для каждого? и если он совпадёт с началом нашего хука то отдать квант времени и опять проверить.

 

Это все известно и понятно. Не надежный это способ, нет гарантий, что формат этих структур не изменится в очередном обновлении, после чего драйвер перестанет корректно работать; кстати, в KTRAP_FRAME может быть нуль (системный поток). К тому же аналогичная ситуация может возникнуть в самом конце обработчика, после того, как число потоков в глобальной переменной уменьшится, но на последней инструкции поток прервется, не успев войти в тело оригинальной функции. Прийдется еще и это учитывать и определять как-то длину твоего обработчика, чтобы проверить EIP потоков. Короче ненужный это геморой, проще не выгружать драйвер.

 

А не проще в обработчиках, юзать флаг(при входе установка, при выходе снятие ивента или простой переменной) о не возможности выгрузки драйвера ? И при выгрузке в цикле проверять этот флаг, или зделать набор таких ивентов, и удалять постепенно все хуки, по мере возможности. Ведь может быть такая фигня что пройдя по одному списку и перейдя к второму, в первом появится новый поток, и как раз влезет в обработчик. Нужно делать локально, это более стабильно.

 

про это я как раз и говорил в первой части поста. Однако как правильно заметил Deyton этот флаг не будет выстовлен, если напирем поток закончит выполнение на певых N инструкциях, до выставления этого флага.

Отрубить прерывания на всех процах. Делается это не так уж и сложно. Даже если использовать DPC, а не напрямую работать с APIC.

Гм, а хук SDT разве документирован? Может в новом SP нельзя будет сделать SDT[*((PUCHAR)NtSome + 1)] = NewNtSome.
Не думаю что здесь есть альтернативы - либо пользуешься недокументированными вещами, и не заикатся об совместимости, либо следую букве DDK.

Мне так тоже кажется, однако я всё же предпочитаю давать возможность выгружать драйвер, тк это облегчает отладку, и тестирование.

 

Win64

 

Ну так зделать установку флага одной командой(первой в обработчике). Самое первое что пришло в голову это перехватить int ХХ и в обработчике делать ин(де)кримент. Но это уже изврат пошел.