Вы используете устаревший браузер. Этот и другие сайты могут отображаться в нём некорректно. Вам необходимо обновить браузер или попробовать использовать другой.
Всем ку, после отдыха от пастинга на rust вновь пришел сюда. И я захотел делать чит под оффициалку, external само собой
Вот вопрос: как eac детектит что в системе есть драйвер не очень крутой, если мы маппим его через условный kdmapper, или через bootkit(redlotus, etc)
Я знаю что есть какие-то трейсера, pdb cache(или как его)
А ну и ещё: сильно ли сертификат влият на андетект? Ну типо если я буду запускать подписанный драйвер через sc start, будет ли андетект?
И есть ли щас смысл от external на eac?
Всем ку, после отдыха от пастинга на rust вновь пришел сюда. И я захотел делать чит под оффициалку, external само собой
Вот вопрос: как eac детектит что в системе есть драйвер не очень крутой, если мы маппим его через условный kdmapper, или через bootkit(redlotus, etc)
Я знаю что есть какие-то трейсера, pdb cache(или как его)
А ну и ещё: сильно ли сертификат влият на андетект? Ну типо если я буду запускать подписанный драйвер через sc start, будет ли андетект?
И есть ли щас смысл от external на eac?
kdmapper артефакты оставляет, по ним и детектит, остальное можно почистить чтобы был уд.
CVE-2019-16098 и подобные проверяются. нестандартные IRP тоже важный фактор.
external имеет смысл если сумеешь сделать визуалы в отдельном окне без хуков, инжекта библиотек и записи памяти
kdmapper артефакты оставляет, по ним и детектит, остальное можно почистить чтобы был уд.
CVE-2019-16098 и подобные проверяются. нестандартные IRP тоже важный фактор.
external имеет смысл если сумеешь сделать визуалы в отдельном окне без хуков, инжекта библиотек и записи памяти
PsLoadedModuleList - kdmapper должен удалять свою запись из этого списка.
еак вызывает NtQuerySystemInformation и мб парсит PspCidTable, HandleTableь - там должен быть твой драйвер.
потом ci.dll. будет жаловаться на отсутствие подписи.
потом хеши. будет смотреть секции относительно своей константы (база собирается из безопасных драйверов).
CVE-2019-16098 / CVE-2020-15392
еак в своем кеше PDB или по сигнатурам знает, как выглядит уязвимый, но легитимный драйвер (вроде gdrv.sys или procmon.sys). он специально ищет их в памяти.
если находит - сразу бан, потому что эти драйверы не должны быть загружены в защищенной игре.
если находит драйвер, который похож на такой, но изменен (например, в него вшит шеллкод для отключения еак) - это тоже детект по сигнатуре.
IRP: у каждого драйвера есть мажоры, обычно ntoskrnl. если там твои функции в cr3 - ban.
ещё kdmapper не регает бэки: создание потоков, образы и т.д., но хз на счёт этого.
1. детект вектор KdMapper'a заключается в прямом аллоке RWX страницы с огромным размером.
2. бекапы уязвимого драйвера лежат в физической памяти => сиг скан
3. огромная база данных, твой драйвер может быть в детекте только из-за:
1. похожего кода ( выполнение одних и тех же действий )
2. выполнение заведомо детект вещей в самом драйвере ( создание системного потока, создание девайса ( => лог в PsLoadedModuleList / EtwTiLogDriverObjectLoad ) ( а при попытке удаления из PsLoadedModuleList => бсод по причине Critical Structure Corruption ( A.K.A PatchGuard ) )
( а также еще по ряду причин, не буду их перечислять )
никакой разницы не будет между кдмаппером или буткитом, если ты делаешь хоть что-то из этого списка
2. выполнение заведомо детект вещей в самом драйвере ( создание системного потока, создание девайса ( => лог в PsLoadedModuleList / EtwTiLogDriverObjectLoad ) ( а при попытке удаления из PsLoadedModuleList => бсод по причине Critical Structure Corruption ( A.K.A PatchGuard ) )
( а также еще по ряду причин, не буду их перечислять )
Всем ку, после отдыха от пастинга на rust вновь пришел сюда. И я захотел делать чит под оффициалку, external само собой
Вот вопрос: как eac детектит что в системе есть драйвер не очень крутой, если мы маппим его через условный kdmapper, или через bootkit(redlotus, etc)
Я знаю что есть какие-то трейсера, pdb cache(или как его)
А ну и ещё: сильно ли сертификат влият на андетект? Ну типо если я буду запускать подписанный драйвер через sc start, будет ли андетект?
И есть ли щас смысл от external на eac?
Точно. По сути, ты сейчас описал всю эволюцию андетекта в 2024. Сертификат - это просто пропуск через DSE, а не невидимость для еака. Ему важнее что делает драйвер, а не кем подписан.
KDMapper и его аналоги - это как харакири сделать. Следы в PsLoadedModuleList, PDB-пути, кривые IRP - это триггер для бана. Да, на 1-2 недели может пронести, но это как повезёт.
Bootkit - уже серьезнее. Полный контроль на этапе загрузки дает больше возможностей для маскировки, но сложность реализации зашкаливает. Еак и это учится детектить через проверки UEFI/ACPI и тайминги.
Hyper-V сейчас король. Работа из-под хоста выносит тебя за зону детекта. Еак видит только виртуалку, а твой софт работает на реальном железе. Главное - убрать все следы виртуализации (тайминги, SMBIOS, драйверы).
Путь сейчас лежит либо в сторону идеальной чистки артефактов на уровне ядра, либо в сторону полной изоляции через гипервизор. Всё остальное - костыли
спасибо всем тем кто отвечал
и ещё родился один вопрос:
как там на интернеле? там какие приколы есть
я знаю про прикол с протектом памяти(все юзермод инжекторы отпадают), ну вот допустим я ижнектнул дллку с помощью кернел инжектора с заведомо undetect драйвером. какие дальше приколы? я знаю что-то про вызовы, pdb, но очень размыто
спасибо всем тем кто отвечал
и ещё родился один вопрос:
как там на интернеле? там какие приколы есть
я знаю про прикол с протектом памяти(все юзермод инжекторы отпадают), ну вот допустим я ижнектнул дллку с помощью кернел инжектора с заведомо undetect драйвером. какие дальше приколы? я знаю что-то про вызовы, pdb, но очень размыто
Бэки: твой инжект триггерит LoadImageNotify в ядре. Еак видит загрузку левой длл в процесс игры - бан. Нужно чистить/отключать эти колбэки до инжекта.
PDB и имена: еак сканирует список загруженных модулей. Левая dll с подозрительным именем или путем - детект. Нужно мапить DLL без имени или маскироваться под системную.
Syscalls: еак ставит хуки на ntdll (NtRead и др.). Прямой вызов api светит тебя. Работа через прямые сисколлы - лучшее, но их тоже научились детектить по аномалиям стека.
Скан памяти: еак ищет сигнатуры твоего кода, строки, патчи. Нужны сильная обфускация и шифрование.
Рабочий интернал в игре с еаком - это не инжект, а полное уничтожение следов: чистка колбэков + сисколлы + маскировка в памяти + обфускация. Публичные методы давно в банах
Всем ку, после отдыха от пастинга на rust вновь пришел сюда. И я захотел делать чит под оффициалку, external само собой
Вот вопрос: как eac детектит что в системе есть драйвер не очень крутой, если мы маппим его через условный kdmapper, или через bootkit(redlotus, etc)
Я знаю что есть какие-то трейсера, pdb cache(или как его)
А ну и ещё: сильно ли сертификат влият на андетект? Ну типо если я буду запускать подписанный драйвер через sc start, будет ли андетект?
И есть ли щас смысл от external на eac?
Самое мемное, что EAC детектит если драйвер неподписанный ( именно неподписанный, подписанные не трогает)) ) и выполняет рутину ( callback ) с изменением DesiredAccess на PROCESS_ALL_ACCESS для любых процессов, которые EAC затрагивает, то происходит детект.
2. Наверное ты уже знаешь или кто-то писал наверное, что EAC детектит MmUnloadedDrivers, те же iqvw64e.sys, capcom.sys с недавней выгрузкой, если такое происходит, что была недавно выгрузка именно таких драйверов, то сравнивает стартовый адрес с текущими загруженными модулями, если так можно сказать - происходит такое совпадение, то EAC как правило не загружается и выдает ошибку, или же детектит.
3. EAC так-же детектит изменение любое hal.dll, ибо сравнивает чексумму .text секции, если даже ты будешь патчить обратно перед проверкой, то EAC вызывает функцию и как правило записывает какой был delay. Если задержка супер большая, то детектит.
4. Так-же не мало важно, если ты захочешь инжектить с помощью APC, то EAC использует трейсы в системе, т.е. все вызовы ExQueueWorkItem, все KeInsertQueueApc с юзермода ( только в процесс EAC ) или если ETHREAD не принадлежит легитному драйверу - тоже детект.
5. Тоже самое касается и функции для выделения shellcode - MmHighestUserAddress, EAC проверяет через SharedUserData->MmHighestUserAddress.
6. Так-же EAC проверяет все пулы ( ExAllocatePool ) на наличие большого количества аллокаций, т.е. проверяет всю область на shellcode ( детектит кстати по опкодам, по типу syscall, iretq и так далее )
7. EAC детектит все hwbp кто бы, что не говорил. EAC читает дебаг регистры для всех потоков, и если в KM потоке стоят бряки, то это детект.
По сути это единственная база, что тебе нужно знать, не могу посоветовать людей у которых стоит почитать уже готовые обходы, ибо уже устарели, либо скрыты. Стоп, забыл самое главное, ты же у нас собираешься маппить драйвер, так вот, когда драйвер загружается в систему, он как бы получает свой кусок памяти, это его место в ядре, как правило там PE, код, .data, .rdata, ты же как я понимаю будешь маппить драйвер в .rdata, так вот, если драйвер отсутствует в PsLoadedModuleList, но исполняемый код лежит по адресам, которые принадлежат легитному драйверу, но этот код не из ориг драйвера, то EAC проверяет эти адреса с оригом драйвера на диске, если код не совпадает, то и происходит детект. Удачи.
Самое мемное, что EAC детектит если драйвер неподписанный ( именно неподписанный, подписанные не трогает)) ) и выполняет рутину ( callback ) с изменением DesiredAccess на PROCESS_ALL_ACCESS для любых процессов, которые EAC затрагивает, то происходит детект.
2. Наверное ты уже знаешь или кто-то писал наверное, что EAC детектит MmUnloadedDrivers, те же iqvw64e.sys, capcom.sys с недавней выгрузкой, если такое происходит, что была недавно выгрузка именно таких драйверов, то сравнивает стартовый адрес с текущими загруженными модулями, если так можно сказать - происходит такое совпадение, то EAC как правило не загружается и выдает ошибку, или же детектит.
3. EAC так-же детектит изменение любое hal.dll, ибо сравнивает чексумму .text секции, если даже ты будешь патчить обратно перед проверкой, то EAC вызывает функцию и как правило записывает какой был delay. Если задержка супер большая, то детектит.
4. Так-же не мало важно, если ты захочешь инжектить с помощью APC, то EAC использует трейсы в системе, т.е. все вызовы ExQueueWorkItem, все KeInsertQueueApc с юзермода ( только в процесс EAC ) или если ETHREAD не принадлежит легитному драйверу - тоже детект.
5. Тоже самое касается и функции для выделения shellcode - MmHighestUserAddress, EAC проверяет через SharedUserData->MmHighestUserAddress.
6. Так-же EAC проверяет все пулы ( ExAllocatePool ) на наличие большого количества аллокаций, т.е. проверяет всю область на shellcode ( детектит кстати по опкодам, по типу syscall, iretq и так далее )
7. EAC детектит все hwbp кто бы, что не говорил. EAC читает дебаг регистры для всех потоков, и если в KM потоке стоят бряки, то это детект.
По сути это единственная база, что тебе нужно знать, не могу посоветовать людей у которых стоит почитать уже готовые обходы, ибо уже устарели, либо скрыты. Стоп, забыл самое главное, ты же у нас собираешься маппить драйвер, так вот, когда драйвер загружается в систему, он как бы получает свой кусок памяти, это его место в ядре, как правило там PE, код, .data, .rdata, ты же как я понимаю будешь маппить драйвер в .rdata, так вот, если драйвер отсутствует в PsLoadedModuleList, но исполняемый код лежит по адресам, которые принадлежат легитному драйверу, но этот код не из ориг драйвера, то EAC проверяет эти адреса с оригом драйвера на диске, если код не совпадает, то и происходит детект. Удачи.
Можно ли использовать утекшие сертификаты для подписи своего драйвера? Или легче прокинуть через уязвимые драйвера, и если да, то какие стоит использовать? Только подозреваю, что ковчег использует уязвимости в obs 25.08 2021 года, но точно ли: не знаю. Недавно начал с этим работать, рассматривал способ через kdmapper, но не пойму как его использовать для обхода неподписанного драйвера. Не налетайте, если использую неправильные формулировки, очень интересует тематика.
