Вопрос по "скрытию" чита от античита (battleye)

[Frehzy]

Написал ring0 драйвер, который читает память (только читает, тк делаю простой радар, который вывожу в лругом окне в отдельном приложением из полученных координат игроков). Через консольное приложение (c++) "взаимодействую" с ним. Достаточно ли этого будет для обхода античита? Или нужно ещё как-нибудь заморочиться?

P. S. У меня изначально была теория, что, если через kernel будет слишком палевно, тк античит может запалить чтение памяти, то написание драйвера должно решить эту проблему, нооооо....почти дописав всё это чудо, возникли сомнения: "Не отлечу ли я от первой же волны банов" или чего-нибудь подобного".

P. S. S. Возможно, не все мысли совсем корректно передал. Если нужно уточнить что-то, без проблем могу это сделать.

 

[NiceL]

А о чем речь то, ни информации о том, каким образом грузишь драйвер, ни информации о том, как читаешь память. Если грузишь через отключение g_CiOptions - это самоубийство. Если грузишь ммапом драйвер, то как именно ты общаешься с драйвером? Затираешь ли следы после загрузки? Как ты работаешь с памятью, даже этого не написал, может ты совсем и используешь MmCopyVirtualMemory для этого, а может и нет, можно хоть какую-то информацию? То есть текст я вижу примерно так - "Я сделал драйвер, это андетект?", это что-то из разряда врачей, которые "помогают" по телефону

 

[oask]

/del

 

[Ozaron]

Ну если у тебя имя девайса и драйвера "BlackBone" то точно нет)
Если имя не рандомное то при блеклисте имени тебя откинет

 

[xLamantine]

ни слова про метод коннекта, ни слова про метод чтения памяти, с чем мы тебе должны помочь?

 

[Ozaron]

ни слова про метод коннекта, ни слова про метод чтения памяти, с чем мы тебе должны помочь?

100% это связь с помощью IOCTL и чтение с помощью MmCopyVirtualMemory

Если нет - Я очень сильно удивлюсь.

 

[FARMx]

Написал ring0 драйвер, который читает память (только читает, тк делаю простой радар, который вывожу в лругом окне в отдельном приложением из полученных координат игроков). Через консольное приложение (c++) "взаимодействую" с ним. Достаточно ли этого будет для обхода античита? Или нужно ещё как-нибудь заморочиться?

P. S. У меня изначально была теория, что, если через kernel будет слишком палевно, тк античит может запалить чтение памяти, то написание драйвера должно решить эту проблему, нооооо....почти дописав всё это чудо, возникли сомнения: "Не отлечу ли я от первой же волны банов" или чего-нибудь подобного".

P. S. S. Возможно, не все мысли совсем корректно передал. Если нужно уточнить что-то, без проблем могу это сделать.

Как таковой 'Волны банов' нету, есть обновление античита, и совпадение, на сколько мне извесно BE лучше EAC по детектам, и ему будет на одного тебя все равно, он пойдет лучше откинет софт с 20 юзерами, чем будет тебя банить одного, и если ты хочешь продавать его то баны будут очень быстро, так как обхода по факту нету ни какого

100% это связь с помощью IOCTL и чтение с помощью MmCopyVirtualMemory

Если нет - Я очень сильно удивлюсь.

IOCTL детект без подписи

 

[Frehzy]

А о чем речь то, ни информации о том, каким образом грузишь драйвер, ни информации о том, как читаешь память. Если грузишь через отключение g_CiOptions - это самоубийство. Если грузишь ммапом драйвер, то как именно ты общаешься с драйвером? Затираешь ли следы после загрузки? Как ты работаешь с памятью, даже этого не написал, может ты совсем и используешь MmCopyVirtualMemory для этого, а может и нет, можно хоть какую-то информацию? То есть текст я вижу примерно так - "Я сделал драйвер, это андетект?", это что-то из разряда врачей, которые "помогают" по телефону

Спасибо огромное за обратную связь. Как-то даже в голову не влезло сразу это написать. Прошу прощения за это. Итак, по порядку:
- Гружу драйвер с помощью консольной команды sc start. Подпись украл с файла майкрософт и подписал этим свой драйвер (поэтому он спокойно запускается без тестового режима).
- Память читаю с помощью MmCopyVirtualMemory. Беру handle, адрес (который нужно прочитать или переписать) и с помощью MmCopyVirtualMemory читаю всё это счастье. (надеюсь, правильно выразился)
- т.к. всё это дело, пока что, в отладке, то значения координат просто вывожу в debug (windbg). Вариант с консольным приложением накрылся после 1000 и 1 ошибки, которые я не смог пофиксить из-за не большого количества знаний в этой области.

Насчёт того, как затирать следы - попытался погуглить, но как-то не особо получилось что-то найти.
Сейчас читаю про хуки и как вообще это можно применить. Так же, немного про "патч ядра" (сам ещё не совсем понимаю, что это такое, но надеюсь разобраться).

Собственно, если всё делать вот таким методом (читать память) и...как-то чистить - это будет палиться?

Как таковой 'Волны банов' нету, есть обновление античита, и совпадение, на сколько мне извесно BE лучше EAC по детектам, и ему будет на одного тебя все равно, он пойдет лучше откинет софт с 20 юзерами, чем будет тебя банить одного, и если ты хочешь продавать его то баны будут очень быстро, так как обхода по факту нету ни какого

IOCTL детект без подписи

Я всё это делаю просто для портфолио и не более того. Сам играть не читами не хочу. Просто захотелось изучить данный раздел, т.к. давненько интересовался этой сферой. Может написать несколько функций простеньких и пойти копать дальше (взлом пентагона и прочее =) )
Сможет ли сертификат, который я "беру" у майкрософт (с их файлов), как-то дополнительно защитить или он нужен исключительно для того, чтобы драйвер запустился без тестового режима виндовс?
И ещё, что за IOCTL? Нашёл в интернете парочку статей о том, что это функция для работы с устройствами. Тогда не совсем понимаю, как драйвер с этим связан

100% это связь с помощью IOCTL и чтение с помощью MmCopyVirtualMemory

Если нет - Я очень сильно удивлюсь.

Насколько я понял, MmCopyVirtualMemory - это самый распространённый способ чтения памяти. Вы имели ввиду что-то самописное? Не совсем вас понял

 

[Ozaron]

Спасибо огромное за обратную связь. Как-то даже в голову не влезло сразу это написать. Прошу прощения за это. Итак, по порядку:
- Гружу драйвер с помощью консольной команды sc start. Подпись украл с файла майкрософт и подписал этим свой драйвер (поэтому он спокойно запускается без тестового режима).
- Память читаю с помощью MmCopyVirtualMemory. Беру handle, адрес (который нужно прочитать или переписать) и с помощью MmCopyVirtualMemory читаю всё это счастье. (надеюсь, правильно выразился)
- т.к. всё это дело, пока что, в отладке, то значения координат просто вывожу в debug (windbg). Вариант с консольным приложением накрылся после 1000 и 1 ошибки, которые я не смог пофиксить из-за не большого количества знаний в этой области.

Насчёт того, как затирать следы - попытался погуглить, но как-то не особо получилось что-то найти.
Сейчас читаю про хуки и как вообще это можно применить. Так же, немного про "патч ядра" (сам ещё не совсем понимаю, что это такое, но надеюсь разобраться).

Собственно, если всё делать вот таким методом (читать память) и...как-то чистить - это будет палиться?

Я всё это делаю просто для портфолио и не более того. Сам играть не читами не хочу. Просто захотелось изучить данный раздел, т.к. давненько интересовался этой сферой. Может написать несколько функций простеньких и пойти копать дальше (взлом пентагона и прочее =) )
Сможет ли сертификат, который я "беру" у майкрософт (с их файлов), как-то дополнительно защитить или он нужен исключительно для того, чтобы драйвер запустился без тестового режима виндовс?
И ещё, что за IOCTL? Нашёл в интернете парочку статей о том, что это функция для работы с устройствами. Тогда не совсем понимаю, как драйвер с этим связан

Насколько я понял, MmCopyVirtualMemory - это самый распространённый способ чтения памяти. Вы имели ввиду что-то самописное? Не совсем вас понял

Не уверен, но скорее всего MmCopyVirtualMemory хукается и может улететь в детект.
Ты можешь читать память аттачнувшись к процессу и копировать ее в буффер с помощью memcpy, но я не уверен насколько это правильный вариант и насколько безопасный (только недавно начал работать на уровне ядра, надеюсь знатоки поправят)

Расскажи как ты воруешь сертификат майков, просто на моей памяти такой способ действительно ворует подпись, но не верифицирует ее.

IOCTL - распространенный способ для связи kernel<->client
Для работы регистрирует девайс и драйвер (и это может легко улететь в детект)

Есть вариант использовать соединение на сокетах, но тогда тебе придется скрывать поток

Везде есть подводные камни. Вне всяких сомнений, если ты единственный используешь драйвер и чит - шанс детекта минимален, но не равен нулю.

 

[NiceL]

Спасибо огромное за обратную связь. Как-то даже в голову не влезло сразу это написать. Прошу прощения за это. Итак, по порядку:
- Гружу драйвер с помощью консольной команды sc start. Подпись украл с файла майкрософт и подписал этим свой драйвер (поэтому он спокойно запускается без тестового режима).
- Память читаю с помощью MmCopyVirtualMemory. Беру handle, адрес (который нужно прочитать или переписать) и с помощью MmCopyVirtualMemory читаю всё это счастье. (надеюсь, правильно выразился)
- т.к. всё это дело, пока что, в отладке, то значения координат просто вывожу в debug (windbg). Вариант с консольным приложением накрылся после 1000 и 1 ошибки, которые я не смог пофиксить из-за не большого количества знаний в этой области.

Насчёт того, как затирать следы - попытался погуглить, но как-то не особо получилось что-то найти.
Сейчас читаю про хуки и как вообще это можно применить. Так же, немного про "патч ядра" (сам ещё не совсем понимаю, что это такое, но надеюсь разобраться).

Собственно, если всё делать вот таким методом (читать память) и...как-то чистить - это будет палиться?

Я всё это делаю просто для портфолио и не более того. Сам играть не читами не хочу. Просто захотелось изучить данный раздел, т.к. давненько интересовался этой сферой. Может написать несколько функций простеньких и пойти копать дальше (взлом пентагона и прочее =) )
Сможет ли сертификат, который я "беру" у майкрософт (с их файлов), как-то дополнительно защитить или он нужен исключительно для того, чтобы драйвер запустился без тестового режима виндовс?
И ещё, что за IOCTL? Нашёл в интернете парочку статей о том, что это функция для работы с устройствами. Тогда не совсем понимаю, как драйвер с этим связан

Насколько я понял, MmCopyVirtualMemory - это самый распространённый способ чтения памяти. Вы имели ввиду что-то самописное? Не совсем вас понял

Ну, что могу сказать, по всем позициям, что ты расписал, тебе хана. Вообще по всем без исключения, как таким образом ты собрался обходить BE, для меня загадка. Могу порекомендовать на unknowncheats (не реклама) и сурсах github поизучать данную тему, там достаточно много всего, в любом случае, больше, чем те знания, что у тебя сейчас. Так-же рекомендую скачать PDBDownloader майкрософт символов, очень полезно для изучения псведокода ring0 кода майкрософт, того же Ntoskrnl.exe к примеру в IDA.

Не уверен, но скорее всего MmCopyVirtualMemory хукается и может улететь в детект.
Ты можешь читать память аттачнувшись к процессу и копировать ее в буффер с помощью memcpy, но я не уверен насколько это правильный вариант и насколько безопасный (только недавно начал работать на уровне ядра, надеюсь знатоки поправят)

Расскажи как ты воруешь сертификат майков, просто на моей памяти такой способ действительно ворует подпись, но не верифицирует ее.

IOCTL - распространенный способ для связи kernel<->client
Для работы регистрирует девайс и драйвер (и это может легко улететь в детект)

Есть вариант использовать соединение на сокетах, но тогда тебе придется скрывать поток

Везде есть подводные камни. Вне всяких сомнений, если ты единственный используешь драйвер и чит - шанс детекта минимален, но не равен нулю.

Чего... Какой хук. Я бы понял если ты такое в эру x32 сказал еще когда только XP вышла, но сейчас это так не работает, за модификацию кода ядра, что защищен PatchGuard'ом ты получишь бсод, а именно защищены .CODE секции модулей Ntoskrnl.exe, Hal.dll, Ci.dll, Kdcom.dll, Pshed.dll, Clfs.sys, Ndis.sys, Tcpip.sys, может даже это не весь список. Античиты могут просто спалить стек процесса, а именно использование KeStackAttachProcess к процессу, который используется в MmCopyVirtualMemory. К примеру, на билде 10.0.22000.1 берешь PEPROCESS процесса, который надо защитить, и чекаешь значение в *(ULONG*)((QWORD)pProcess + 0x348), и всё, вот тебе и простейший детект присоединения к стеку, а именно количество стеков, а я уверен их куда больше, а это лишь наипростейший. Можно так-же перебирать все потоки и там тоже информация по стекам имеется в структуре

 

[FARMx]

Спасибо огромное за обратную связь. Как-то даже в голову не влезло сразу это написать. Прошу прощения за это. Итак, по порядку:
- Гружу драйвер с помощью консольной команды sc start. Подпись украл с файла майкрософт и подписал этим свой драйвер (поэтому он спокойно запускается без тестового режима).
- Память читаю с помощью MmCopyVirtualMemory. Беру handle, адрес (который нужно прочитать или переписать) и с помощью MmCopyVirtualMemory читаю всё это счастье. (надеюсь, правильно выразился)
- т.к. всё это дело, пока что, в отладке, то значения координат просто вывожу в debug (windbg). Вариант с консольным приложением накрылся после 1000 и 1 ошибки, которые я не смог пофиксить из-за не большого количества знаний в этой области.

Насчёт того, как затирать следы - попытался погуглить, но как-то не особо получилось что-то найти.
Сейчас читаю про хуки и как вообще это можно применить. Так же, немного про "патч ядра" (сам ещё не совсем понимаю, что это такое, но надеюсь разобраться).

Собственно, если всё делать вот таким методом (читать память) и...как-то чистить - это будет палиться?

Я всё это делаю просто для портфолио и не более того. Сам играть не читами не хочу. Просто захотелось изучить данный раздел, т.к. давненько интересовался этой сферой. Может написать несколько функций простеньких и пойти копать дальше (взлом пентагона и прочее =) )
Сможет ли сертификат, который я "беру" у майкрософт (с их файлов), как-то дополнительно защитить или он нужен исключительно для того, чтобы драйвер запустился без тестового режима виндовс?
И ещё, что за IOCTL? Нашёл в интернете парочку статей о том, что это функция для работы с устройствами. Тогда не совсем понимаю, как драйвер с этим связан

Насколько я понял, MmCopyVirtualMemory - это самый распространённый способ чтения памяти. Вы имели ввиду что-то самописное? Не совсем вас понял

Забанит тебя сразу, за подпись которую ты забрал

 

[Ozaron]

Ну, что могу сказать, по всем позициям, что ты расписал, тебе хана. Вообще по всем без исключения, как таким образом ты собрался обходить BE, для меня загадка. Могу порекомендовать на unknowncheats (не реклама) и сурсах github поизучать данную тему, там достаточно много всего, в любом случае, больше, чем те знания, что у тебя сейчас. Так-же рекомендую скачать PDBDownloader майкрософт символов, очень полезно для изучения псведокода ring0 кода майкрософт, того же Ntoskrnl.exe к примеру в IDA.


Чего... Какой хук. Я бы понял если ты такое в эру x32 сказал еще когда только XP вышла, но сейчас это так не работает, за модификацию кода ядра, что защищен PatchGuard'ом ты получишь бсод, а именно защищены .CODE секции модулей Ntoskrnl.exe, Hal.dll, Ci.dll, Kdcom.dll, Pshed.dll, Clfs.sys, Ndis.sys, Tcpip.sys, может даже это не весь список. Античиты могут просто спалить стек процесса, а именно использование KeStackAttachProcess к процессу, который используется в MmCopyVirtualMemory. К примеру, на билде 10.0.22000.1 берешь PEPROCESS процесса, который надо защитить, и чекаешь значение в *(ULONG*)((QWORD)pProcess + 0x348), и всё, вот тебе и простейший детект присоединения к стеку, а именно количество стеков, а я уверен их куда больше, а это лишь наипростейший. Можно так-же перебирать все потоки и там тоже информация по стекам имеется в структуре

Да, про PatchGuard я читал, но думал что на драйвера с подписью это не распространяется (ошибался)

Не думал что аттач так легко детектится, для меня это реально открытие. Потоки же можно скрыть, не знаю правда насколько это практично. А зачем нужен PDBDownloader, если IDA Pro сама с серверов скачивает файл символов, или это немного другое ?

Я тебя услышал, спасибо за указание на ошибки, буду углубляться в эту тему дальше)

 

[NiceL]

Да, про PatchGuard я читал, но думал что на драйвера с подписью это не распространяется (ошибался)

Не думал что аттач так легко детектится, для меня это реально открытие. Потоки же можно скрыть, не знаю правда насколько это практично. А зачем нужен PDBDownloader, если IDA Pro сама с серверов скачивает файл символов, или это немного другое ?

Я тебя услышал, спасибо за указание на ошибки, буду углубляться в эту тему дальше)

Все pdb'шки майкрософт по умолчанию отсутствуют в системе, в visual studio вроде можно выбрать, чтобы они все скачались, либо их можно скачать разом командами и т.д., однако это не особо удобно. А вот PDBDownloader скачивает .pdb для определенного модуля, например даже если ты находишь на 11 винде, но у тебя есть Ntoskrnl.exe файликом от 7 винды, ты можешь скачать именно .pdb 7-ой винды в пару кликов. Как по мне вещь класная, особенно в такой ситуации, когда нужна поддержка всех билдов винды начиная от висты (в моем случае):


KeStackAttachProcess не так сложно детектится, это наглый способ, вот можно например различные структуры недокументированные посмотреть на этом сайте для разных билдов винды -

Пожалуйста, авторизуйтесь для просмотра ссылки.

Тоже незаменимый сайт, как по мне, если работаешь с ring0.

PatchGuard наоборот создан майкрософт был для того, чтобы кучи хуков и патчей не было в ядре от всяких антивирусов, это понижало производительность/стабильность и т.д. В свое время многим это не понравилось, особенно антивирусам

 

[Frehzy]

Расскажи как ты воруешь сертификат майков, просто на моей памяти такой способ действительно ворует подпись, но не верифицирует ее.

Касаемо сертификатов и цифровой подписи. Есть одна программка. Вот git:

Пожалуйста, авторизуйтесь для просмотра ссылки.

.Единственное что - сейчас перечитал документацию и действительно - тут максимум идёт копирование (т.е. она не валидная). Ну, думаю, лишним оно не будет. Вдруг чем-нибудь да поможет

Ну, что могу сказать, по всем позициям, что ты расписал, тебе хана. Вообще по всем без исключения, как таким образом ты собрался обходить BE, для меня загадка. Могу порекомендовать на unknowncheats (не реклама) и сурсах github поизучать данную тему, там достаточно много всего, в любом случае, больше, чем те знания, что у тебя сейчас. Так-же рекомендую скачать PDBDownloader майкрософт символов, очень полезно для изучения псведокода ring0 кода майкрософт, того же Ntoskrnl.exe к примеру в IDA.


Чего... Какой хук. Я бы понял если ты такое в эру x32 сказал еще когда только XP вышла, но сейчас это так не работает, за модификацию кода ядра, что защищен PatchGuard'ом ты получишь бсод, а именно защищены .CODE секции модулей Ntoskrnl.exe, Hal.dll, Ci.dll, Kdcom.dll, Pshed.dll, Clfs.sys, Ndis.sys, Tcpip.sys, может даже это не весь список. Античиты могут просто спалить стек процесса, а именно использование KeStackAttachProcess к процессу, который используется в MmCopyVirtualMemory. К примеру, на билде 10.0.22000.1 берешь PEPROCESS процесса, который надо защитить, и чекаешь значение в *(ULONG*)((QWORD)pProcess + 0x348), и всё, вот тебе и простейший детект присоединения к стеку, а именно количество стеков, а я уверен их куда больше, а это лишь наипростейший. Можно так-же перебирать все потоки и там тоже информация по стекам имеется в структуре

Я так понимаю, грузить драйвер через sc start - слишком нагло и палевно? =) А что, если через ProcessHacker? Там, насколько я помню, есть что-то вроде создания сервиса. Или может лучше создавать сервис через отдельное консольное приложение

Ну, что могу сказать, по всем позициям, что ты расписал, тебе хана. Вообще по всем без исключения, как таким образом ты собрался обходить BE, для меня загадка. Могу порекомендовать на unknowncheats (не реклама) и сурсах github поизучать данную тему, там достаточно много всего, в любом случае, больше, чем те знания, что у тебя сейчас. Так-же рекомендую скачать PDBDownloader майкрософт символов, очень полезно для изучения псведокода ring0 кода майкрософт, того же Ntoskrnl.exe к примеру в IDA.


Чего... Какой хук. Я бы понял если ты такое в эру x32 сказал еще когда только XP вышла, но сейчас это так не работает, за модификацию кода ядра, что защищен PatchGuard'ом ты получишь бсод, а именно защищены .CODE секции модулей Ntoskrnl.exe, Hal.dll, Ci.dll, Kdcom.dll, Pshed.dll, Clfs.sys, Ndis.sys, Tcpip.sys, может даже это не весь список. Античиты могут просто спалить стек процесса, а именно использование KeStackAttachProcess к процессу, который используется в MmCopyVirtualMemory. К примеру, на билде 10.0.22000.1 берешь PEPROCESS процесса, который надо защитить, и чекаешь значение в *(ULONG*)((QWORD)pProcess + 0x348), и всё, вот тебе и простейший детект присоединения к стеку, а именно количество стеков, а я уверен их куда больше, а это лишь наипростейший. Можно так-же перебирать все потоки и там тоже информация по стекам имеется в структуре

И как же тогда обходить, если всё это настолько легко можно спалить? Читать - нельзя, использовать хуки - нельзя. Остаётся писать нейронку, которая будет анализировать все игры в мире и предсказывать будущее предположение противника =)


Нашёл несколько интересных статей. Думаю, они будут полезны:

Пожалуйста, авторизуйтесь для просмотра ссылки.

Пожалуйста, авторизуйтесь для просмотра ссылки.

Пожалуйста, авторизуйтесь для просмотра ссылки.

Может это как-нибудь объединить с этим:

Пожалуйста, авторизуйтесь для просмотра ссылки.

 

[DTRR]

IOCTL - Пизда.
Socket - Пизда.
EAC/BE в разных играх работает по разному)
К примеру, в Rust еак работает лучше чем везде, но всё же очень странно, он до сих пор не научился детектить Сокеты.
В escape from tarkov - BE работает лучше чем везде. на счёт сокетов не знаю.
Так что всё зависит от твоего метода чтения памяти.
В принципе, тебе уже хватает "Скрытности", просто на 10-20 пользователях которые юзают драйвер без подписи тебе просто откинут драйвер в блэклист.

за модификацию кода ядра, что защищен PatchGuard'ом

На сколько я помню, в версиях ниже 1809 PatchGuard либо не работает, либо работает хуёво.)
к тому же, никто не запрещал собрать свой образ винды, который будет грузить драйвер раньше всех остальных.
(EAC/BE это не детектит (13.06 проверяли, работало.))

Я так понимаю, грузить драйвер через sc start - слишком нагло и палевно? =) А что, если через ProcessHacker? Там, насколько я помню, есть что-то вроде создания сервиса. Или может лучше создавать сервис через отдельное консольное приложение

BE не даст тебе это сделать))))
Лучше юзай кастом EFI-Mapper (Форк KDMapper'a с нововведениями), геморроя больше - шансы детекта ниже.

 

[FARMx]

Касаемо сертификатов и цифровой подписи. Есть одна программка. Вот git:

Пожалуйста, авторизуйтесь для просмотра ссылки.

.Единственное что - сейчас перечитал документацию и действительно - тут максимум идёт копирование (т.е. она не валидная). Ну, думаю, лишним оно не будет. Вдруг чем-нибудь да поможет

Я так понимаю, грузить драйвер через sc start - слишком нагло и палевно? =) А что, если через ProcessHacker? Там, насколько я помню, есть что-то вроде создания сервиса. Или может лучше создавать сервис через отдельное консольное приложение

И как же тогда обходить, если всё это настолько легко можно спалить? Читать - нельзя, использовать хуки - нельзя. Остаётся писать нейронку, которая будет анализировать все игры в мире и предсказывать будущее предположение противника =)


Нашёл несколько интересных статей. Думаю, они будут полезны:

Пожалуйста, авторизуйтесь для просмотра ссылки.

Пожалуйста, авторизуйтесь для просмотра ссылки.

Пожалуйста, авторизуйтесь для просмотра ссылки.

Может это как-нибудь объединить с этим:

Пожалуйста, авторизуйтесь для просмотра ссылки.

Всю основуную информацию дал человек выше, воровать подпись это прямой отлет драйвера, т.к она не валидная а просто есть, сделал 3-4 драйвера, взял мапер, загрузил, играешь, есть еще эмулятор BE на uc(no ad) можешь посмотреть

 

[Frehzy]

Спасибо, ещё раз, всем, кто принял участие в обсуждении данной темы. Скорее всего, ближе к следующим выходным сяду за макулатуру и почитаю информацию по этой теме. Если что-нибудь интересное найду, то обязательно оставлю ниже ещё один комментарий с ссылками на полезные источники, в которых можно будет что-нибудь подчерпнуть для себя (вдруг в будущем это кому-нибудь очень сильно поможет....)

 

[es3n1n]

MmCopyVirtualMemory

а в чем проблема MmCopyVirtualMemory?)) если руки прямые, то тот же аттач не делает драйвер детектед..

 

[Vazzup]

Ну, что могу сказать, по всем позициям, что ты расписал, тебе хана. Вообще по всем без исключения, как таким образом ты собрался обходить BE, для меня загадка. Могу порекомендовать на unknowncheats (не реклама) и сурсах github поизучать данную тему, там достаточно много всего, в любом случае, больше, чем те знания, что у тебя сейчас. Так-же рекомендую скачать PDBDownloader майкрософт символов, очень полезно для изучения псведокода ring0 кода майкрософт, того же Ntoskrnl.exe к примеру в IDA.


Чего... Какой хук. Я бы понял если ты такое в эру x32 сказал еще когда только XP вышла, но сейчас это так не работает, за модификацию кода ядра, что защищен PatchGuard'ом ты получишь бсод, а именно защищены .CODE секции модулей Ntoskrnl.exe, Hal.dll, Ci.dll, Kdcom.dll, Pshed.dll, Clfs.sys, Ndis.sys, Tcpip.sys, может даже это не весь список. Античиты могут просто спалить стек процесса, а именно использование KeStackAttachProcess к процессу, который используется в MmCopyVirtualMemory. К примеру, на билде 10.0.22000.1 берешь PEPROCESS процесса, который надо защитить, и чекаешь значение в *(ULONG*)((QWORD)pProcess + 0x348), и всё, вот тебе и простейший детект присоединения к стеку, а именно количество стеков, а я уверен их куда больше, а это лишь наипростейший. Можно так-же перебирать все потоки и там тоже информация по стекам имеется в структуре

Обнаружить аттач к процессу еще проще, структура _KTHREAD (наш поток) содержит структуру ApcState по смещению в 0x98(21h1), у структуры _KAPC_STATE есть поле Process (указатель на _KPROCESS), к удивлению(нет) по этому указателю будет лежать _KPROCESS к которому мы заатачились, само собой это не причина для бана, но как минимум ты будешь флагнут античитом

 

[Leon4rdo]

Детект.

Откуда информация просочилась? Драйвер за день до сообщения написан...