Здравствуйте, у меня вопрос: у меня есть моя программа, можно ее как-то защитить от гуи хуков? то есть чтобы в мое АП не подгружались dll от хуков?

Заранее спасибо за любую инфу!

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, у меня вопрос: у меня есть моя программа, можно ее как-то защитить от гуи хуков? то есть чтобы в мое АП не подгружались dll от хуков?

А>Заранее спасибо за любую инфу!

Просто мысль: хуковые dll-ки вроде грузятся через LoadLibrary(A/W), можно локально перехватить API-вызов LoadLibrary и на входе анализировать, что за длл-ина к нам цепляется... Можно в этих целях попробовать полазить по стеку вызова и посмотреть, что там бывает, когда хук ставят. У меня подозрение, что там должно быть что-то одинаковое для всех устанавливаемых хуков. Правда, затачиваться на такие вещи опасненько, даже в рамках одной версии операционки.
Сам не смотрел.

CEM>Просто мысль: хуковые dll-ки вроде грузятся через LoadLibrary(A/W), можно локально перехватить API-вызов LoadLibrary и на входе анализировать, что за длл-ина к нам цепляется... Можно в этих целях попробовать полазить по стеку вызова и посмотреть, что там бывает, когда хук ставят. У меня подозрение, что там должно быть что-то одинаковое для всех устанавливаемых хуков. Правда, затачиваться на такие вещи опасненько, даже в рамках одной версии операционки.
CEM>Сам не смотрел.
да, только LoadLibraryExW — именно таким образом я в одном (секурити) продукте сделал защиту от этих хуков — пропатчил IAT user32.dll, подменив импорт LoadLibraryExW

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, у меня вопрос: у меня есть моя программа, можно ее как-то защитить от гуи хуков? то есть чтобы в мое АП не подгружались dll от хуков?

Избавиться от подгрузки DLL вроде как нельзя, но вроде как можно запретить срабатывание хука.


SetWindowsHookEx
WH_DEBUG

The DebugProc hook procedure is an application-defined or library-defined callback function used with the SetWindowsHookEx function. The system calls this function before calling the hook procedures associated with any type of hook. The system passes information about the hook to be called to the DebugProc hook procedure, which examines the information and determines whether to allow the hook to be called.

PD>SetWindowsHookEx
PD>WH_DEBUG
Вот только им не запретишь срабатывание другого WH_DEBUG хука

Здравствуйте, ononim, Вы писали:

PD>>SetWindowsHookEx
PD>>WH_DEBUG
O>Вот только им не запретишь срабатывание другого WH_DEBUG хука

Хм.

Вообще-то в списке контролируемых хуков WH_DEBUG есть. То есть вроде как можно запретить / разрешить и его, иначе они разрешат/ запретят тебя . Что-то тут шизофреничное, верно

Здравствуйте, ononim, Вы писали:

CEM>>Просто мысль: хуковые dll-ки вроде грузятся через LoadLibrary(A/W), можно локально перехватить API-вызов LoadLibrary и на входе анализировать, что за длл-ина к нам цепляется... Можно в этих целях попробовать полазить по стеку вызова и посмотреть, что там бывает, когда хук ставят. У меня подозрение, что там должно быть что-то одинаковое для всех устанавливаемых хуков. Правда, затачиваться на такие вещи опасненько, даже в рамках одной версии операционки.
CEM>>Сам не смотрел.
O>да, только LoadLibraryExW — именно таким образом я в одном (секурити) продукте сделал защиту от этих хуков — пропатчил IAT user32.dll, подменив импорт LoadLibraryExW

Ага, стало быть, оно работает!

Я просто боялся, что не получится из-за такой штуки, что нельзя перехватить api-вызовы библиотеки из самой себя, потому что она никогда не пользуется своим экспортируемыми функциями (я просто на вскидку не помнил откуда родом SetWindowsHookEx и LoadLibrary).

Или есть способ?

CEM>Я просто боялся, что не получится из-за такой штуки, что нельзя перехватить api-вызовы библиотеки из самой себя, потому что она никогда не пользуется своим экспортируемыми функциями (я просто на вскидку не помнил откуда родом SetWindowsHookEx и LoadLibrary).
CEM>Или есть способ?
способ есть, но он тут не нужен

Здравствуйте, ononim, Вы писали:

CEM>>Я просто боялся, что не получится из-за такой штуки, что нельзя перехватить api-вызовы библиотеки из самой себя, потому что она никогда не пользуется своим экспортируемыми функциями (я просто на вскидку не помнил откуда родом SetWindowsHookEx и LoadLibrary).
CEM>>Или есть способ?
O>способ есть, но он тут не нужен
Тут не нужен. А какой?

А>Здравствуйте, у меня вопрос: у меня есть моя программа, можно ее как-то защитить от гуи хуков? то есть чтобы в мое АП не подгружались dll от хуков?

Ну, про блокировку LoadLibraryEx() уже написали, но если уж хочется абсолютной секурности и защиты от любых левых .dll, не только UI-хуков, тогда придётся учесть, что левые модули могут быть подгружены ещё при запуске процесса, при чём очень разными способами (user init dlls, policy dlls, etc.). А тут уже прямая дорога к написанию драйвера-перехватчика загружаемых модулей.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, у меня вопрос: у меня есть моя программа, можно ее как-то защитить от гуи хуков? то есть чтобы в мое АП не подгружались dll от хуков?

А>Заранее спасибо за любую инфу!

Можно попробовать (сам не проверял) использовать WaitForDebugEvent (LOAD_DLL_DEBUG_INFO).
Разумеется, запускать само приложение придется с флагом DEBUG_PROCESS.

CEM>>>Я просто боялся, что не получится из-за такой штуки, что нельзя перехватить api-вызовы библиотеки из самой себя, потому что она никогда не пользуется своим экспортируемыми функциями (я просто на вскидку не помнил откуда родом SetWindowsHookEx и LoadLibrary).
CEM>>>Или есть способ?
O>>способ есть, но он тут не нужен
CEM>Тут не нужен. А какой?
Сплайсинг

Здравствуйте, ononim, Вы писали:

CEM>>>>Я просто боялся, что не получится из-за такой штуки, что нельзя перехватить api-вызовы библиотеки из самой себя, потому что она никогда не пользуется своим экспортируемыми функциями (я просто на вскидку не помнил откуда родом SetWindowsHookEx и LoadLibrary).
CEM>>>>Или есть способ?
O>>>способ есть, но он тут не нужен
CEM>>Тут не нужен. А какой?
O>Сплайсинг
А адрес функции как получить? GetProcAddr не вернёт адреса внутренних функций библиотеки.
К примеру, FillRect в свою очередь вызывает какую-нибудь FillRectInternal, адрес которой в таблице экспорта отсутствует. И перехват FillRect с точки зрения gdi32.dll ничего не меняет — она всегда красит рект напрямую, через FillRectInternal.

CEM>>>>>Я просто боялся, что не получится из-за такой штуки, что нельзя перехватить api-вызовы библиотеки из самой себя, потому что она никогда не пользуется своим экспортируемыми функциями (я просто на вскидку не помнил откуда родом SetWindowsHookEx и LoadLibrary).
CEM>>>>>Или есть способ?
O>>>>способ есть, но он тут не нужен
CEM>>>Тут не нужен. А какой?
O>>Сплайсинг
CEM>А адрес функции как получить? GetProcAddr не вернёт адреса внутренних функций библиотеки.
Как-нибудь так...

Здравствуйте, ononim, Вы писали:

CEM>>>>>>Я просто боялся, что не получится из-за такой штуки, что нельзя перехватить api-вызовы библиотеки из самой себя, потому что она никогда не пользуется своим экспортируемыми функциями (я просто на вскидку не помнил откуда родом SetWindowsHookEx и LoadLibrary).
CEM>>>>>>Или есть способ?
O>>>>>способ есть, но он тут не нужен
CEM>>>>Тут не нужен. А какой?
O>>>Сплайсинг
CEM>>А адрес функции как получить? GetProcAddr не вернёт адреса внутренних функций библиотеки.
O>Как-нибудь так...
Как? Есть формализованный метод?

CEM>>>>>>>Или есть способ?
O>>>>>>способ есть, но он тут не нужен
CEM>>>>>Тут не нужен. А какой?
O>>>>Сплайсинг
CEM>>>А адрес функции как получить? GetProcAddr не вернёт адреса внутренних функций библиотеки.
O>>Как-нибудь так...
CEM>Как? Есть формализованный метод?
И да и нет. Если функция не эукспортируется, то можно воспользоваться информацией из .pdb если таковая есть. Если нету — поиск по сигнатурам, ну можно чутарь эвристики

Здравствуйте, x64, Вы писали:

А>>Здравствуйте, у меня вопрос: у меня есть моя программа, можно ее как-то защитить от гуи хуков? то есть чтобы в мое АП не подгружались dll от хуков?

x64>Ну, про блокировку LoadLibraryEx() уже написали, но если уж хочется абсолютной секурности и защиты от любых левых .dll, не только UI-хуков, тогда придётся учесть, что левые модули могут быть подгружены ещё при запуске процесса, при чём очень разными способами (user init dlls, policy dlls, etc.). А тут уже прямая дорога к написанию драйвера-перехватчика загружаемых модулей.
...ага. И тогда уж сразу отправить в Способ принудительной загрузки DLL в адресное пространство процесса

Автор: Сторожевых Сергей
Дата: 14.11.07

.

PS Кстати, добавил статью в FAQ asm форума.

А есть еще SetWinEventHook, ею тоже можно подгружаться замечательно

PD>SetWindowsHookEx
PD>WH_DEBUG

PD>The DebugProc hook procedure is an application-defined or library-defined callback function used with the SetWindowsHookEx function. The system calls this function before calling the hook procedures associated with any type of hook. The system passes information about the hook to be called to the DebugProc hook procedure, which examines the information and determines whether to allow the hook to be called.

Я кстати чисто развлекухи (вернее для своего вялотекущего хобби-проекта) ради сделал такой финт ушами — запуск процесса через специальный загрузчик. Казалось бы ниче удивительного но... Этот загрузчик (будучи запущенным "слегка" модифицированным CreateProcess'ом) делает следующее — чистит свое АП, убивает все треды в своем процессе кроме текущего, восстанавливает код ntdll с файла на диске, правит PEB так чтобы загрузить taget .exe и... перезапускает ntdll!LdrpInitialize. В результате девственно чистое АП. Matrix reloaded Хотя конечно если задаться целью выжить при этом вполне реально — захукав меня

Здравствуйте, ononim, Вы писали:

O>Я кстати чисто развлекухи (вернее для своего вялотекущего хобби-проекта) ради сделал такой финт ушами — запуск процесса через специальный загрузчик. Казалось бы ниче удивительного но... Этот загрузчик (будучи запущенным "слегка" модифицированным CreateProcess'ом) делает следующее — чистит свое АП, убивает все треды в своем процессе кроме текущего, восстанавливает код ntdll с файла на диске, правит PEB так чтобы загрузить taget .exe и... перезапускает ntdll!LdrpInitialize. В результате девственно чистое АП. Matrix reloaded Хотя конечно если задаться целью выжить при этом вполне реально — захукав меня
ну что тут скажешь. у нас был метод внедрения своего добра использован похожий на тот что в статье Сторожевых. Так вот, наибольшее кол-во проблем было с продуктами третьих фирм — которые что-то вечно сплайсят, грузят-чистят, хучат и т.п. Самые интересные варианты начинались "от двух" таких товарищей одновременно.