Вы используете устаревший браузер. Этот и другие сайты могут отображаться в нём некорректно. Вам необходимо обновить браузер или попробовать использовать другой.
Всем ку, после отдыха от пастинга на 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, но не пойму как его использовать для обхода неподписанного драйвера. Не налетайте, если использую неправильные формулировки, очень интересует тематика.
боже вы можете закрыть свои рты что с вами не так??? почему обойти eac стало запретным плодом вот помню когда каждый что то придумывал и делился знаниями вот тогда да была дружеская атмосфера а сейчас сидят какие то ннчики не знают даже что такое chheatengine
kdmapper артефакты оставляет, по ним и детектит, остальное можно почистить чтобы был уд.
CVE-2019-16098 и подобные проверяются. нестандартные IRP тоже важный фактор.
external имеет смысл если сумеешь сделать визуалы в отдельном окне без хуков, инжекта библиотек и записи памяти
