"powerfull anti-debug tricks" - о чем он ?

https://community.qualys.com/blogs/securitylabs/2011/05/09/analysis-malware-win32rimecudb

Кто может объяснить что это за трикс такой ? Почему в ядре надо хукать что то, для того чтобы обойти эту технику ?

 

WIN32
автор индус!

 

Да не нужно ничего хукать, просто в отладчике вернуть, что исключение обработано

 

ntkernelspawn
Курит индус, или по нац-сти индус?

Velheart
_ttp://ifolder.ru/23582380 такой же трикс только с WriteFile ? Или нет ?

 

да почти любая функа подойдёт, что работает с хендлом на клабе тема поднималась давненько.

 

Это фишка с BaseSetLastNTError, про нее Clerk рассказывал подробно тут: http://wasm.ru/forum/viewtopic.php?pid=334993#p334993

 

Прикольно! Клерк знает фсё!
Так это именно анти-дебаг? То есть при подключенном отладчике срабатывает? Что значит имеется отладочный порт (сорри не знаю что это)?

 

чистый basesetlastnterror - антиэмуляция, closehandle - кагбэ антиотладка + есть нюансы по реакции отладчика на соотв сепшн, если first and second chance notification проигнорить я наблюдал status_success в zwcloze но беглый просмотр сорцов ядра чето ничего не обнаружил похожего, могу легко наврать
а отладочный порт - это хрень которой представляется канал с отладчиком у отлаживаемого процесса, или даже скорее канал диспетчера исключений в ядре с отладчиком, ну это абстрактно и упрощенно

 

Благодарю всех кто уделил свое время!
P.S а почему забанили клерка ?

 

Занятная статья, даже наш криптор там засветилсо )

 

Сепшин почти любой сервис генерить может, при референсе на обьекте. Есть такая кульная штука как HANDLE_TRACE_DB_BADREF.

 

Velheart

Не все так просто, т.к. трюк с CloseHandle может использоваться в сочетании с явным вызовом RiseException
Здесь эта тема тоже обсуждалась (давненько) - тут пример, тут обсуждение

 

leo
Всё более чем просто. Ядро кидает #STATUS_INVALID_HANDLE:

Код (Text):

1.         //  Now if the handle is not null and it does not represent the
2.         //  current thread or process then if we're user mode we either raise
3.         //  or return an error
4.         //
5.  
6.         if ((Handle != NULL) &&
7.             (Handle != NtCurrentThread()) &&
8.             (Handle != NtCurrentProcess())) {
9.  
10.             if (PreviousMode != KernelMode) {
11.  
12.                 if ((NtGlobalFlag & FLG_ENABLE_CLOSE_EXCEPTIONS) ||
13.                     (CurrentProcess->DebugPort != NULL) ||
14.                     (ObjectTable->DebugInfo != NULL)) {
15.  
16.                     if (!KeIsAttachedProcess()) {
17.                         return KeRaiseUserException (STATUS_INVALID_HANDLE);
18.                     } else {
19.                         return STATUS_INVALID_HANDLE;
20.                     }
21.  
22.                 }

При условии что установлен флаг FLG_ENABLE_CLOSE_EXCEPTIONS в конфиге, имеется отладочный порт, либо запущен логгер. KeRaiseUserException() извлекает T-фрейм, загружает туда ссылку на стаб KiRaiseUserExceptionDispatcher(), в стеке сохраняет адрес возврата в шлюз, загружает статус в TEB и больше ничего не делает. Возврат из сервиса произойдёт на стаб. Он передаёт возвращённый статус в RtlRaiseException(), таким образом разворачивает исключение.
Важна модель вызова диспетчера - он вызывается не как диспетчер исключений, это обычный возврат из сервиса, но на новый адрес. Таким образом достаточно выполнить инструкцию Ret для возврата в шлюз(в KiRaiseUserExceptionDispatcher()), или просто занопить всё в этой процедуре. Ну есчо можно статус поправить в TEB.

Зачем нужно лезть в ядерный отладчик совершенно не понятно.

 

gaeprust
Под "все не так просто" я имел в виду только то, что недостаточно в отладчике тупо обрабатывать все STATUS_INVALID_HANDLE без разбора, т.к. иначе можно попасться на другой трюк. Ну а то, что это можно обойти простыми\несложными довесками - и козе понятно (было еще в 2006 г.)

 

leo
По мойму вы всё слишком усложняете. Может быть не достаточно обойти в отладчике NtClose(кстате она может кидать сепшин если описатель защищён от закрытия), если отлаживаемое приложение вообще отладчик отключает(NtRemoveProcessDebug). Реально можно такой защиты навесить, что пользовательские отладчики будут бесполезными. Здесь же это не рассматривается и ТС ваши архисложные методу не нужны судя по всему.