программа запрещает ставить хуки

Здравствуйте.
В своей программе я устанавливаю хуки (на мышь, на клаву), проблема в том, что при запущенном sXe Injected (античит для контры), моя программа выдает "Hook not set". После вызова SetWindowsHookEx возвращается NULL. Мне интересно каким образом этот античит запрещает хуки? Быть может здесь используется перехват API функций? И конечно хотелось бы узнать как с этим можно побороться, то есть при запущенном sXe все же поставить свой хук.

 

RKU возьми посмотри shadowtable на сколько я помню, одна из старых версий перехватывал в sst функции для защиты от инжэкта, записи в память..

 

ntp_
Если говорить конкретно о SetWindowsHookEx, то есть системные сервисы в Shadow SST - NtUserSetWindowsHookEx и NtUserSetWindowsHookAW.

 

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

 

sXe из Shadow SST сервисов хукает NtUserSetWindowsHookEx и NtUserSetWinEventHook

 

Пусть выложит список хуков там скорее всего можно обойти каким-то из паблик инжэктов, если нет то просто очистить таблицу или с эмулировать.

 

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

 

Оффтоп:
blast, а есть юзермодный метод блока apc инжекта, или хотябы чекания.. ?

 

blast

А можно поподробней пожалуйста. Не понятно мне причем здесь процесс cs? Я понятия не имею что мне нужно сделать со своей прогой или же с античитом чтобы хук поставился

PS. что за апц?

 

Из юзермода только перехватить во всех процессаx KiUserApcDispatcher/ZwQueueApcThread.

 

blast
Зачем во всех процессах ?

 

Clerk
Ну можно перехватить KiUserApcDispatcher только в защищаемом процессе, все зависит от задачи это имелось ввиду.

 

blast, стоит защита от внедрения удаленных потоков, реализовано через KiUserApcDispatcher. От apc инжекта не спасает. Моно чуть подробней как защитится?

 

Flasher
Мне тоже интересно что он по этому поводу думоет.

 

Как ты вообще узнал что не спасает, выполнился код в твоем процессе без вызова твоего обработчика KiUserApcDispatcher?, тогда это либо не апц инжект, либо кто-то снял перехват.

 

Flasher
> Используй MmSecureVirtualMemory(), чтобы любая модификация кода в пределах секций кода нтдлл пошла боком(насчёт освобождения проекции тоже подходит вроде хз).
> Запрещай во всех сервисах ожидания обработку очереди потока, в этом случае если левый поток поставит событие в очередь оно никогда не будет обработано.

 

Ну я вить уже написал
Обе прилажения мои, и 1 - где KiUserApcDispatcher стоит, и 2 - инжектор, раелизованный через InjectProcessMethodThreadApcHidden, Clerk'ом.
Clerk, MmSecureVirtualMemory - это вить уже не usermode :P
А вот второе через что реализовать?

 

Flasher
Юзермод весьма ограничен.
Второе реализовать проблемно. Например твой поток выполняет задержку NtDelayExecution, либо ждёт на обьекте в NtWaitForSingleObject. У подобнах сервисов есть параметр - Alertable, он разрешает прерывать поток для обработки событий в очереди потока. Поток вызвает сервис с этим параметром установленным в TRUE и если есть APC он вызывает диспетчер. Способ очевиден - запрещать во всех сервисах эту обработку, установкой Alertable в FALSE. Также не юзоть NtQueueApcThread, что сильно усложнит код, ибо например нельзя будет использовать таймеры. Так что этот вариант слишком плох.
Есть способ противостоять внедрению посредством APC, способ основан на одной особенности. Апк - инжект исполняется двумя способами. простой инжект - просто ставится апк в очередь потока, более эффективный - перехватывается диспетчер апк и самый эффективный - редирект диспетчера апк на диспетчер исключений, это может быть декремент переменной ядра KeUserApcDispatcher и установка точки останова ниже либо прямо на KiUserApcDispatcher. Следующий способ позволяет всё это обойти
Особенность заключается в том, что регистр флажков который был при входе в сервис ожидания передаётся в диспетчер апк при обработке апк. Тоесть мы вызываем какойлибо сервис, к примеру тотже NtDelayExecution, но перед вызовом шлюза взводим eflags.tf, если в очереди есть апк, то поток прервётся для его обработки, войдя в диспетчер, но тут будет взведён флаг пошаговой отладки и после исполнения первой инструкции диспетчера возникнет отладочное исключение(STATUS_SINGLE_STEP) и вход потока в диспетчер исключений. Реализация весьма проста.
> Устанавливаем хэндлер исключений пошаговой отладки, это может быть VEH, перехват диспетчера и тп.
> Перехватываем шлюз, хэндлер будет определять по номеру сервиса/адресу стуба возможность ожидания с обработкой апк, если это сервис позволяет и обработка разрешена, то перед вызовом шлюза взводит TF.
> При начале любой обработки апк управление получит установленный диспетчер исключений, мы должны отфильтровать вызов, тоесть обнаружить что не мы поставили апк в очередь, при возврате из сервиса ожидания сбросить TF и пр.

 

1) Реализация метода установки Alertable в FALSE.
Хукаем ZwDelayExecution, ZwWaitForSingleObject, ZwSignalAndWaitForSingleObject, ZwWaitForMultipleObjects и везде если .if Alertable != 0 ставим 0.

В прилажении, которую охраняю - не юзает NtQueueApcThread, проверял..
Я Так понял это и есть вся реализация? Какие противопоказания? Если таймер не Alertable, он вить по нормальному суравно выполнится да ?

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

И игры с диспетчером исключений не очень подходит, я нуб, год буду разбираться

Остается самый первый вариант с Alertable > FALSE. Выслушаю противопоказанию и пойду реализовать :P