Возможно ли такое? Нужно для борьбы с внедрением DLL через оконные хуки методом получения THREADINFO и выставления TIF_DISABLEHOOKS в TIF_flags (PsGetCurrentThread -> PsGetThreadWin32Thread). Проблема в том что если не удалось загрузить DLL с хуком или она вернула FALSE из DlllMain то система будет пытаться ее загрузить снова и снова.
Это ведь юзермод, зачем ядро ? Обратный ядерный вызов пропатчить(KiUCB), тогда будет вся последовательность инит, clientsetup etc. И проблем в ядре не будет.
THREADINFO это структура ядра, TIF_flags из юзермода не доступно. Патчить ntdll::KiUserCallbackDispatcher на крайний случай, лучше уж сразу ClientLoadLibrary подменить в User32 при ее загрузке, так как уже установлен PsSetLoadImageNotifyRoutine
Vicshann, Почему не доступно, может флажки можно через апи изменить, это не имеет значения. В ядре это всё сложно сделать, там сессии с клонами ядерного гуя - они не в общей ядерной памяти; от патча защита в самом ядре(KPP(PG)), если использовать какие то нотифи то совместимости в версиях не будет. Вам что бы работало лишь в 10-ке, а остальное не нужно, либо колхозить интернал разбирать, сигнатуры составлять для версий ? > Патчить ntdll::KiUserCallbackDispatcher на крайний случай Выше я это предложил, не обязательно патчить, можно ссылку на таблицу векторов поменять(apfn), конечно придётся отключить защиту(cfg). Но если это защита ядерная, то любое решение юзермод не годится, так как сразу будет обход в том же моде, а при нём есчо и атака на кривой ядерный код. Как это решить правильно красиво хз. --- Сообщение объединено, 17 дек 2020 --- А откуда инфа про эти интернал флаги, w2k ? Код (Text): * History: * 02-07-91 DavidPe Created. * 1994 Nov 02 IanJa Hooking desktop and console windows. \***************************************************************************/ LRESULT xxxCallHook2( PHOOK phkCall, int nCode, WPARAM wParam, LPARAM lParam, LPBOOL lpbAnsiHook) { UINT iHook; PHOOK phkSave; LONG_PTR nRet; PTHREADINFO ptiCurrent; BOOL fLoadSuccess; TL tlphkCall; TL tlphkSave; BYTE bHookFlags; BOOL fMustIntersend; CheckCritIn(); if (phkCall == NULL) { return 0; } iHook = phkCall->iHook; ptiCurrent = PtiCurrent(); /* * Only low level hooks are allowed in the RIT context * (This check used to be done in PhkFirstValid). */ if (ptiCurrent == gptiRit) { switch (iHook) { case WH_MOUSE_LL: case WH_KEYBOARD_LL: #ifdef REDIRECTION case WH_HITTEST: #endif // REDIRECTION break; default: return 0; } } /* * If this queue is in cleanup, exit: it has no business calling back * a hook proc. Also check if hooks are disabled for the thread. */ if ( ptiCurrent->TIF_flags & (TIF_INCLEANUP | TIF_DISABLEHOOKS) || ((ptiCurrent->rpdesk == NULL) && (phkCall->iHook != WH_MOUSE_LL))) { return ampiHookError[iHook + 1]; Ниже есть это: Код (Text): nRet = xxxHkCallHook(phkCall, nCode, wParam, lParam); Lock(&ptiCurrent->sphkCurrent, phkSave); if (ptiCurrent->pClientInfo) ptiCurrent->pClientInfo->phkCurrent = phkSave; ThreadUnlock(&tlphkSave); /* * This hook proc faulted, so unhook it and try the next one. */ if (phkCall->flags & HF_HOOKFAULTED) { PHOOK phkFault; phkCall = PhkNextValid(phkCall); phkFault = ThreadUnlock(&tlphkCall); if (phkFault != NULL) { FreeHook(phkFault); } continue; } - обратный вызов в юзер. Видно что ловушка снимается, если юзер сфейлит. Больше паблик ссылок в 2к нет, разве что на запись при завершении оконного обьекта.
Я смотрел в WinXP, там действительно нет способа выставить этот флаг через API. Фактически это все для семерки нужно, если в десятке можно выставить процессу флаг защищенного (PS_PROTECTED_TYPE в EPROCESS) и это будет без последствий для его работы. Но как всегда, хочется найти красивое и универсальное решение
Не не, там идет все в сисколы, только эмуляция спасёт, Клерыч поправь, но я тоже все пробовал без патча ядра - нифига не выходит, шадов блин, а потом...... --- Сообщение объединено, 18 дек 2020 --- >Нужно для борьбы с внедрением DLL через оконные хуки методом получения THREADINFO Почитай мою статью, это не обязательно в ядре хучить , а в APC твоей dll всего лишь юзермод, смотришь треды свои и чужие, отсеиваешь и убиваешь. Руткисов давно нет сайта, я там сорцы выкладывал с полиморфом встроенным, ну хз, щас не найду [Без лавэ ]
Есть только драйвер, который фильтр файловой системы и установил LoadImageNotifyRoutine. Вот из него и нужно боротся с внедрением DLL в защищаемый процесс. Он просто блокирует доступ к файлу, LoadLibraryExW в User32::ClientLoadLibrary возвращает NULL и из-за этого win32k постоянно пытается загрузить эту DLL снова.
Vicshann, Начнём с начала что бы не лезть в интернал. Есть апи, которая устанавливает ловушку загрузкой модуля. Если модуля нет, то апи вернёт ошибку, не будет пытаться загрузить вновь и не впадёт в рекурсию; где то там в недрах гуя ты допустил ошибку приводящую к рекурсивной загрузке.
Если DLL, которая регистрируется через SetWindowsHookEx вернет FALSE из DLLMain, или просто LoadLibrary не сможет ее загрузить, то win32k не отметит ее как уже загруженную и будет пытаться загрузить снова, когда поток к нему обратится. Драйвер защиты от инжектов как раз и не дает открыть файл этот dll и LoadLibrary возвращает NULL и этот NULL возвращается ответом в win32k через NtCallbackReturn. Я не DLL с инжектами делаю, у меня для такого особый инжектор Моя задача сделать так, что бы драйвер защиты спокойно работал и не вызывал нагрузку на систему. А постоянные попытки загрузки DLL с хуками систему грузят. Потому что многие приложения суют свои DLL в чужие процессы таким способом. И когда драйвер их все блокирует, win32k постоянно пытается их загрузить при разных GUI событиях.
Vicshann, Тоесть если нет файла система впадёт в цикл его ожидания, это врядле. Давно ничего не отлаживал тк не нужно было, но это наверно нужно посмотреть. Как такое может быть, это повесит систему. Обратные теневые вызовы просты, перед передачей управления в юзер освобождаются ресурсы. Нельзя провести на это атаку, были попытки и фиксы. Как же тогда апи вернёт управление, для загрузки ловушки не создаётся второй поток. Что то тут не то, либо ты ошибся либо какой то баг что мало вероятно гуй на ошибки вылезан, это нужно проверять.
Нет, я сначала в отладчике проверил, менял просто одну букву пути к DLL в User32::ClientLoadLibrary и тогда ClientLoadLibrary вызывалась снова и снова для этой DLL. Потом сделал DLL, возвращающую FALSE из DLLMain и получил тот же эффект. Почему так происходит станет понятно если декомпилировать win32k::xxxLoadUserApiHook::xxxLoadHmodIndex
Vicshann, Причём тут вообще обратные вызовы, зачем ты в дебри полез. Снимай сервисный лог с апи загрузки ловушки, там будет файловая проверка и возврат управления. Если у тебя ядерный фильтр, то он референс на файловом обькте легально увидит, останется лишь посмотреть откуда вызов. Вот нравится вам колхозить --- Сообщение объединено, 19 дек 2020 --- Vicshann, > Нет, я сначала в отладчике проверил, менял просто одну букву пути к DLL Полностью неверный ошибочный подход к задаче. Поэтому ты и полез в интернал, в дебри гуя. Не составил тех задание(задачу не сформулировал), а выдал лишь своё ошибочное решение, которое нужно разбирать и в конце решения не может быть. Я могу посмотреть любой лог, для этого есть инструмент, но думаю не годится - потеряем будущего спеца, в тень гуя мало кто залазил..
Как мне лог поможет пометить DLL в битовой маске как загруженную? Потому что win32k сам ее не пометит, получив NULL от ClientLoadLibrary. *(_DWORD *)(*(_QWORD *)(vptiCurrent + 0x158) + 0x154i64) |= 1 << vHookIdx;
Vicshann, Если вызвать SetHook() с не существующим файлом, поток повиснет ? Врядле, вначале файл будет наверно открыт, до каких то обратных вызовов как ты не поймёшь. Это ты завис на ClientLoadLibrary :lol:
Не существующую DLL вряд ли получится передать в SetWindowsHookEx, так как там уже ее HMODULE надо передать. Проверять лень потому что это к делу ни как не относится
SetWindowsHookEx - это из шадова - да, отловить можно, но попыток с 2010г я помню множество. На то он и шадов, там прямые знаешь ли сисколы и прочая лабудень. Возможно не в тему. но дрова я писал, для перехвата шадова в играх. А так все кастомно на уровне админа в юзерморде без проблем.
Сделал нормальный тест хуков для этого драйвера. За одним и для тех, кто не верит что такое на самом деле происходит Проблема в том, что драйвер блокирует загрузку этой DLL только в защищаемый процесс. Если бы он блокировал ее и в том, который ставит хук, то SetWindowsHookEx сразу бы вернула ошибку. https://dropmefiles.com/VQi1w
Vicshann, Файлы удалены, но это не важно. Следует понимать суть того что ты тестом называешь. Если в системном механизме участвует не системный драйвер то его не тестят а проводят на него атаку. Вначале выясняется возможно ли это реверс. Если там крипта(те он криптован), то есть метод который всю инфу наглядно нужную дает - монитор выборки. Наверно можно и локально через вд сделать, не могу точно сказать. Обычно применяется вирта которая даёт нужный лог.
