Можно ли узнать ID процесса, создавшего поток через CreateRemoteThread, или как-то узнать, что в процессе поток создан "извне"?
Хотелось бы через драйвер, вариант идеальный, но у пользователей зачастую нет прав админа и возможности их получить, чтобы его поставить - главная проблема в этом
Ответ полу-серьёзный: Возможности получит админ, даже на самых последних версиях Windows, полно Правда, только методом эксплуатации дыр в ядре (и их на данный день хватает). Google, Twitter, и отчёты с последних конференций по информационной безопасности (на пример, CanSecWest/Pwn2Own на прошлой неделе) даст вам знать многое. Вводим "windows kernel exploitation" в поисковик - тема глубокая и познавательная.
Ещё вариант - создание сессии ETW с прослежкой KERNEL/BASE events (там должна быть информация о создание потоков). Увы, позитивен что запуск такой сессии тоже требует админских прав.
Как юзерспейсный вариант - ведём свой список локально созданных потоков. То есть сначала перечисляем все потоки, потом патчим функции типа CreateThread, чтобы они вносили соответствующие изменения в список, ну и регулярно сравниваем с реальным положением вещей. Или можно проверять точки начала исполнения (как предложил rmn), смотреть в каком модуле они находятся и дальше плясать от чужеродности модуля.
Вот тут ещё http://reverseengineering.stackexch...ck-if-it-has-been-injected-by-another-process есть следующее: Remotely created thread could be detected by several techniques: Periodically check if process threads were created by current process using NtQueryProcessInformation. For each thread check if it is running from the address space of the original executable and not from some orphaned memory page: NtQueryInformationThread Set second parameter to ThreadQuerySetWin32StartAddress GetModuleInformation - check if the thread starting address is in the range of each of the loaded modules and those modules are legit (by known list/by path). Check here too. Monitor thread creating API inside current process and also check if the creating PID belong to current process - NtQueryProcessInformation, CreateToolhelp32Snapshot. Monitor memory protection APIs (VirtualProtect) to detect if someone tries to modify your code and then check if that "someone" belongs to legit process address space. By keeping the list of legit loaded modules, one also can check if each thread in process belong to address space of a legit module from the list. Monitor LoadLibrary for a chance someone trying to load unknown module into your process. Исходя из этого могу предположить что PID для потока получить всё же можно
Да вот сам не пойму. В имеющейся у меня доке по этой функции (точнее NtQueryInformationProcess) нет способов получить подобную инфу. Но дока может быть не полной. NtQueryInformationThread тоже не очень помогает.
Есть кернел логгер, но он должен быть запущен при старте оси, тоесть нужен ребут, причём не известно как с этим в старших версиях системы(так как нужны привилегии(maintain_obj_type)..) и ребут - это никому не интересно). HoShiMin Вы пилите авера или античит(их есчо юзают ?) ?
Античит =_= И вопрос в соседней теме про прерывание потока тоже для него. Драйвер юзать не вариант: у игроков почти никогда нет админских прав. А искать и использовать эксплойты слишком ненадёжно: эксплойты весь онлайн в казино проиграют.
HoShiMin Я знаю что ачит, вы это на прошлом форуме говорили Я помню вас и ваши вопросы, потому что вы в основном эти интересности и поднимали.. Сейчас не имеет значения драйвер(мод). Приложение элементарно может браться под супервизор, гипервизор; полностью или частично(по событиям). Учитывая мощности железа, всякий антидебаг и прочий изврат просто бессмысленный. Хотя теоретически это всё же весьма интересно.
До хардкора с гипервизорами в той игрушке дело даже близко не доходит. Основная проблема - инъекции и последующая подгрузка классов через JNI. Отрубим инъекции - останутся джава-агенты, обрубающиеся через -XX:+DisableAttachMechanism. А вот что делать с инъекциями - до сих пор непонятно. Есть вариант забыть про инъекции и чекать классы через JNI/JVMTI, но снова вопрос - как отличить класс, подгруженный извне, от класса самой игрушки? Поэтому выбрал защищаться на нативном уровне, как более простой и предсказуемый
HoShiMin Не имеет смысла какие то события предсказывать. Загрузиться и захватить управление можно как угодно. А если есчо и есть доступ к процессу, прямое RW или ядерный мод, то вообще ни о какой защите нельзя говорить. Защита не существует без метода обхода. Если же защита от дурака", тоесть запутать ньюби, то достаточно обычных кернел фильтров. Смена контекста - тред выбирается произвольно. Создайте ловушку - пустой тред и мониторьте смену контекста. Или можно использовать системные фичи - обнулить стек и вращаться, тогда при инжекте всё отвалится. Можно есчо много чего придумать, но это реально всё бесполезно.
Кстати говоря, кернель-фильтры написаны. Использовал бы их с удовольствием, если бы не аудитория без админских прав, чтобы эти самые фильтры поставить. Ядерный мод и прямой RW даёт CheatEngine со своим драйвером (его собственный гипервизор в расчёт не беру - никто им пользоваться не умеет), но т.к. это джава, никто байтики в памяти не ищет, это осталось в прошлом: читы ставят через подгрузку классов средствами самой JVM. Поэтому надо или обрубить доступ к процессу из юзермода, или как-то узнать средствами самой JVM, что подгруженный класс чужеродный
HoShiMin > Маппинг либы -> CreateRemoteThread, от него не спасёт, разве нет? Я имел ввиду смену контекста, то что выше упоминалось. > Поэтому надо или обрубить доступ к процессу из юзермода Я говорил что защиты без обхода её нет. Как только на вашу поделку обратят внимание, она сразу вскроется и будет обход. Более того я полагаю что корректно вы те же кернел фильтры написать не способны(это не ваша оценка, просто это крупнейшие корпорации даже не могут сделать, ошибки есть всегда).
Ставлю каллбэки через ObRegisterCallbacks, убираю у хэндла моего процесса все права, этого хватает, но опять же - драйвер, а их нельзя...
HoShiMin Ниочём короче. Да и вообще в юм защита не строится. Это возможно, но не тот уровень задачи и тех, кто её будет решать.
