Cogitations poenam nemo patitur (лат.)
Никто не несет наказания за мысли
©2009​

Активная антиотладка и антиинжект​

Проекты в конце статьи – под
Microsoft Visual Studio. Разговор далее пойдет только о Ring3.
Недавно (2014 год) работая над написанием плагина под Sysinternals Process Explorer, случайно столкнулся с функцией RtlQueryProcessDebugInformation из ntdll.dll, которая оказывается использует удаленные потоки для получения информации о стороннем процессе, закидывая свой шелл код в сторонний процесс. Т.к. мой плагин был реализован в виде DLL, сразу вспомнились далекие годы, когда я читал Рихтера и его описание функции DllMain, а именно уведомление DLL_THREAD_ATTACH, получаемое этой процедурой при инициализации нового потока в процессе, обычно довольно редко используемое. Как оказалось вызов DllMain с этим уведомлением происходит именно из контекста вновь создаваемого потока. Это натолкунуло на естественную, в данном случае, мысль о возможности защиты своего и не только своего приложения от инжекта и выполнения чужеродного кода в своем адресном пространстве методом создания удаленнных потоков без всяких глобальных перехватов ZwWriteProcessmemory и ZwCreateThread, (как это делают многие антивирусы и программные сетевые экраны (фаерволлы)). Так для однопоточного приложения достаточно нижеприведенного кода для получения невозможности создания потока в нем:

Код (Text):

1.  BOOL APIENTRY DllMain(HMODULE hModule, ULONG ul_reason_for_call,LPVOID lpReserved)
2. {
3.   if(ul_reason_for_call==DLL_THREAD_ATTACH) NtSleep(INFINITE); //или RtlExitUserThread () или еще чего..
4. }

где NtSleep – это макрос, аналог Sleep из kernel32.dll (я в основном использую нативные функции):

Код (Text):

1.  void WINAPI NtSleepEx(ULONG DurationMs,ULONG Alertable)
2. {  struct  {ULONG Low;
3.     ULONG Hi;
4.     } MLI={{-10000*DurationMs},{0xFFFFFFFF}};
5.   NtDelayExecution(Alertable,(PLARGE_INTEGER)&MLI);
6. }
7. #define NtSleep(_x)  NtSleepEx(_x,0)

В данном примере мы просто замораживаем созданный поток на неопределенный период.
Как же быть в многопоточных приложениях, где мы рискуем «не разрешить» свой собственный (нужный нам поток). Здесь есть два простых варианта:

1. Вызывать какую-либо созданную нами функцию из нашей DLL при создании нового потока для того что бы передать в нее ThreadID создаваемого потока, с последующим сравнении в функции DllMain с текущим (думаю все поняли, расписывать этот метод нет смысла).
2. Более продвинутый метод, - позволяющий защищать не только свои приложения, – это перехват функции NtCreateThread в своем процессе для получения ThreadID потоков создаваемых именно нашим приложением (сторонние потоки будут созданы из вне, а т.к. там ничего нами не перехвачено ThreadID нами получено не будет) для последующей проверки соответствия полученного ThreadID и ThreadID который мы получим в функции DllMain в контексте создаваемого потока из структуры TEB или GetCurrentThreadID. В общем нагляднее все выглядит в коде.

Вот практически полный исходный код протектора csrss от внедрения в него, который был мной когда то опубликован на руткитсах: https://www.sendspace.com/file/26e3o8
(пароль er324t765864tDFCLHGLKyhuioh+KLHyrtfi76)
А это описание:
Client Server Runtime Process Inject Protector
Защита от внедрения методом удаленных потоков
Последнее время очень многие вредоносные программы режима пользователя,
стараясь получить контроль над всеми процессами в системе,
динамически внедряют свой код в сервер подсистемы Windows
(csrss.exe Client Server Runtime Process), запуская его затем
удаленно при помощи функции NtCreateThread. Этот код получает
при этом практически ничем не ограниченные привилегии этого процесса.
Данный проект позволяет на 100% защитить сервер подсистемы от
запуска чужеродного кода из другого процесса, работающего
по описанной выше технологии.Это фактически сразу позволяет
защитить всю Вашу систему от подобного вредоносного ПО.
В нормальной системе удаленных потоков в сервере не создается,
напротив он сам их активно использует.
Установка/снятие данной защиты осуществляется с правами Администратора.
Защита начинает работать только после перезагрузки.
Это тестовая версия.
Совместимость: Все мастдаи, включая серверные (only x86);
Никаких потерь производительности и расходов памяти в систему не вносится.
В Ваши и вновь создаваемые процессы никакой код не внедряется,
никаких драйверов не устанавливается, системные файлы не изменяются.
Разработано в 2008г по своей оригинальной технологии, до сих пор
не встречавшейся в сети. Решил опубликовать т.к. была возможность
протестировать на вышеуказанных "чистых" лицензионных ОС.
При разработке применены минимальные stealth- технологии, но так что
работа незаметна как для пользователя так и для самого вредоносного ПО
(Попытка инжекта удаленным потоком в csrss, просто "тихо обламывается").
Представленное программное обеспечение не предусматривает никаких
гарантий. Автор не несет ни прямой ни косвенной ответственности за
правильное или не правильное использование данного ПО. Если хотите-
используйте данное ПО на свой страх и риск.
Совместно с антивирусами не проверялась, т.к. я их не использую.
Проверить невозможность инжекта, например можно скачав мой плагин к
Sysintermnals Process Explorer по ссылке:
http://depositfiles.com/files/0ivxp9jwe
P.S.: 1. Перед установкой данного протектора рекомендуется создать точку восстановления системы;
2. Если Ваша ОС перестанет загружаться, нужно из консоли восстановления или из другой ОС
удалить файл jnjprot.dll в директории Windows\System32\

1. Если Вы не понимаете о чем ведется речь выше - не устанавливайте данное ПО.

Опубликовано в познавательных целях.
(c)2009 SYSENTER
Комплект: файл xinstall.exe (инсталлятор он же деинсталлятор в native предзагрузке).