Saved Unhook engine

Собственно говоря сабЖ : Идея реализации hook\unhook.

Saved unhook with unload module:
Как можно проверить что в текщий момент код hook не используется, и можно смело делать unhook и выгружать DLL.
1. Вариант подсчета ссылок при входе в hook routine не катит.
1.1 Потоку могут сделать Terminate.
1.2 Перехватоваемое апи может сгенерировать сепшен.
1.3 Инструкции которые увеличивают счетчик : в это время счетчик будет нулевым.

2. Допрос потоков: не гарантии полной раскрутки стека. (jmp, etc.. + alertable threads) .

 

Останов всех потоков их перечисление с проверкой значений %eip контекста на предмет попадения в диапазон адресов. Если кто-то попадает, отпустить потоки, подождать и повторить снова.

 

7mm
В коде перехватчике есть вызовы других библиотек в частности системных, так что по rEip не получится. про допрос поток пункт 2.

 

Если вы где-то в обработчике, то поможет создание полного кодового графа обработчика и оценка того попадает ли %eip полученный из контекста в этот граф.

 

7mm
Hooking идет не только системного кода ... под этим подрозумевается виртуальные таблицы и калбеки ... Так что постоить граф на LDE не возможно ... нужен еще эмуль ... И это будет эвристик причем очень слабый ... надежней будет анализатор стека но сново таки это не дает 100%, а откат должен быть гарантированный ...

 

А если связывать счётчик использований перехваченных функций не с местом перехвата, а с потоком -- что-то типа TLS, упрощённо. Тогда убили поток - ну и хрен бы, вместе с ним сдохли и ссылки. А в случае необходимости определения сидит ли поток где-то в хуке -- перебор потоков и оценка значений этих счётчиков?

 

7mm
Прооблема в том что пререхваченые функции могут просить исключения ... Это не допустимо ... то есть
Increment(TlsVariable)
call HookedFunctions
RaiseException()
Decrement(TlsVariable)
- Установка SEH не очень хорошая идея ...

+ время когда поток будет на инкремент иструкция ...

 

shchetinin

Т.е. установку хука вы как то гарантируете на 100%.

Да и если вы установили 10 хуков, то где вероятность того, что в момент Х все 10 хуков не будут юзаться?
Т.е. вы хотите каждый хук по отдельности "деинсталировать", а после избавляться от DLL ?

 

Напишите свой обработчик исключений. Вообще, у вас по-моему слишком общие условия для задачи -- снимайте ограничения...

 

7mm
Да вы правы, вот только ограничения не я ставлю ... (((


T800
Не гарантии что 10 хуков не используются сразу....
Да именно по отдельности и выгрузить DLL.

 

T800
В смысле по отдельности? а как еще можно?)) ...

 

Хук - всмасле патч ?
Так это древнее примитивное. Восстановите кодосекции с диска. Нормальный код ничего не патчит.

 

klzlk
Да именно патч, пробле не в восстановлении, а вот что надо откатить патчи , но в когда происходит отктак они могут использоватся, надо узнать точно исполняется ли код патча.

 

shchetinin
Тогда также, как и при патче - эмулировать инструкции, либо отпустить поток, чтобы он вышел из изменяемого блока. Обратная патчу задача.

 

klzlk
Вопрос в том как узнать использует ли он сейчас эти патчи или нет ? то и есть обработчик хука .

 

shchetinin
CONTEXT.rEip

 

klzlk
#3

 

shchetinin
Пользовательский тред не может не иметь контекста - ядерный запрос на получение контекста приводит к межкольцевому переключению и формированию Т-фрейма неизбежно.

Разумеется если например было вызвано процедурное ветвление, которое требует возврата в восстанавливаемый код, то просто изменить его нельзя - после возврата код должен быть исполнен оригинальный. В общем случае задача не решаема, так как могут использоваться совершенно произвольные коды. Обычно просто переписываются кодосекции с некоторой вероятностью краха. Нет смысла пилить чтото более сложное.

 

klzlk
Проблема в том что не получается выгрузить код который делает исправления и он находится в DLL. Точнее не получается только в случае когда генерируется сепшены либо переход в Alertable и разумуется Wait. вот тут вообще не понятно что делать .

 

shchetinin
В комерс, это единственное для вас решение, раз других туда посылаете.