-
Автор темы
- #1
Введение
Салют Всем. Недавно решил потыкать новый GG, после многих обновлений мой спуфер все же не смог обойти бан по железу от этого античита, поэтому я решил уже нормально так потыкаться в нем.
Внешняя оценка
Античит не проверяет Testsigning, а в качестве защиты от процмонов и т.д. выступает VMP, которым накрыт наш GameGuard.
До определенного времени он позволял запускать все неподписанные драйвера, поэтому обход был тривиальным, теперь же при попытке запуска драйвера, который подписан левым сертом вылезает такая ошибка (скрин старый, так как сейчас GG не запускается из-под VM, даже со всем байпасом)
Какой использовался спуфер
Мой спуфер подменял весь SMBIOS, и серийники всех хардов без IOCTL хука, который, кстати, детектит Gameguard и сразу кидает BDSOD, так что если вы будете делать спуфер, то используйте статическую подмену через \Device\RaidPortX
Анализ через procmon
Анализировать я решил через procmon, так он не обнаруживается GameGuard'ом, к тому же он может получить почти все действия, которые выполняет античит. Для анализа я использовал следующие фильтры. Видно, что использую я еще фильтр на имя процесса, так как GG создает доп процесс с именем ggXXX.exe где XXX - случайные символы. Снимок я делал вместе с установкой и до сообщения о том, что я забанен. Так что инфы у нас будет с избытком.
1. File System Activity of acsvc.exe
Тут видно, что сервис получает базовую информацию о многих файлах системы
А именно
Но вы можете сказать. что это просто загрузка библиотек. Да, по результату функции CreateFileMapping все похоже на то, что вначале просто происходит подгрузка библиотек
Дальше идет запись данных в Кеш античита. Тут тоже ничего такого. Ибо, в случае чего, эти данные можно легко удалить
Дальше идут более интересные запросы. Например на к кешу с Local\Microsoft\Windows\Caches. Однако записи никакой не происходит. просто запрос стандартной информации о файле.
А вот блетб зачем получать информацию о desktop.ini для меня тоже остается загадкой. Хотя у меня возникла идея, что античит собирает инфу о датах, когда файлы были созданы, чтобы потом создать отпечаток устройства.
Самый неоднозначный момент. Вот эти запросы. Если верить процмону идут запросы только на аттрибуты, однако что-то мне подсказывает, что получаем мы еще и инфу о ID самого раздела (хотя не факт, ибо нахрен это античиту в 2020)
Если не смитать запросы к разным кеш файлам и чтению desktop.ini, то ничего такого серьезного в работе с ФС у сервиса нет (я не учитываю, разумеется, функции, которые дергает ач, ибо это уже другая история.
Список процессов.
Тут мне попалась одна интересная команда, которая убирает какой-то драйвер из верификации.
И тут я понял, что есть еще acdrv.sys (AC Driver). Это мне выдал Process Hacker при логированнии. Однако он не собирает инфу с пк (информацию о бане я получил еще до запуска). Так что, он, скорее всего. нужен только для блокировки доступа к игре
Что делает gguard и другой доп процесс
gguard записывает данные только в сам драйвер, в steam_api.dll, ну и почему-то в nvApp Timestamps (зачем? Непонятно)
А вот читают они почти все, что можно и что нельзя. Думаю тут как раз и проверяются приложения без подписи, однако, не факт
Работа с реестром.
Действий с реестром много, поэтому я покажу только те моменты, который дествительно мб где-то интересны.
1. Запрос на имя PC (от acsvc.exe)
2. Запрос на MachineGUID (хотя, скорее всего, используется для криптографии) (от gameguard.exe)
3. Запрос на имя хоста (думаю для работы с сетью) и запрос на много чего (кстати на Video девайсы тоже)
Это то, что бросилось мне сразу в глаза. Я пока не занимался реверсом самих exe-шников, так что будет позже.
Выводы
Проведя небольшой анализ я считаю, что для бана (создания отпечатка) Gameguard использует
1. Имя PC
2. Данные о видеодевайсах
3. Volume ID (не факт, но вероятнее всего)
4. Данные о времени создания системных файлов
5. Данные сетевых адаптеров
Это используется вместе с WMI запросами точно, так что сбор HWID точно существует.
На этом пока все. Если кто-то также занимается анализом GG, то кидайте то, что нашли, буду рад :)
Салют Всем. Недавно решил потыкать новый GG, после многих обновлений мой спуфер все же не смог обойти бан по железу от этого античита, поэтому я решил уже нормально так потыкаться в нем.
Внешняя оценка
Античит не проверяет Testsigning, а в качестве защиты от процмонов и т.д. выступает VMP, которым накрыт наш GameGuard.
До определенного времени он позволял запускать все неподписанные драйвера, поэтому обход был тривиальным, теперь же при попытке запуска драйвера, который подписан левым сертом вылезает такая ошибка (скрин старый, так как сейчас GG не запускается из-под VM, даже со всем байпасом)
Какой использовался спуфер
Мой спуфер подменял весь SMBIOS, и серийники всех хардов без IOCTL хука, который, кстати, детектит Gameguard и сразу кидает BDSOD, так что если вы будете делать спуфер, то используйте статическую подмену через \Device\RaidPortX
Анализ через procmon
Анализировать я решил через procmon, так он не обнаруживается GameGuard'ом, к тому же он может получить почти все действия, которые выполняет античит. Для анализа я использовал следующие фильтры. Видно, что использую я еще фильтр на имя процесса, так как GG создает доп процесс с именем ggXXX.exe где XXX - случайные символы. Снимок я делал вместе с установкой и до сообщения о том, что я забанен. Так что инфы у нас будет с избытком.
1. File System Activity of acsvc.exe
Тут видно, что сервис получает базовую информацию о многих файлах системы
А именно
C:
typedef struct _FILE_BASIC_INFORMATION {
LARGE_INTEGER CreationTime;
LARGE_INTEGER LastAccessTime;
LARGE_INTEGER LastWriteTime;
LARGE_INTEGER ChangeTime;
ULONG FileAttributes;
} FILE_BASIC_INFORMATION, *PFILE_BASIC_INFORMATION;Дальше идет запись данных в Кеш античита. Тут тоже ничего такого. Ибо, в случае чего, эти данные можно легко удалить
Дальше идут более интересные запросы. Например на к кешу с Local\Microsoft\Windows\Caches. Однако записи никакой не происходит. просто запрос стандартной информации о файле.
А вот блетб зачем получать информацию о desktop.ini для меня тоже остается загадкой. Хотя у меня возникла идея, что античит собирает инфу о датах, когда файлы были созданы, чтобы потом создать отпечаток устройства.
Самый неоднозначный момент. Вот эти запросы. Если верить процмону идут запросы только на аттрибуты, однако что-то мне подсказывает, что получаем мы еще и инфу о ID самого раздела (хотя не факт, ибо нахрен это античиту в 2020)
Если не смитать запросы к разным кеш файлам и чтению desktop.ini, то ничего такого серьезного в работе с ФС у сервиса нет (я не учитываю, разумеется, функции, которые дергает ач, ибо это уже другая история.
Список процессов.
Тут мне попалась одна интересная команда, которая убирает какой-то драйвер из верификации.
И тут я понял, что есть еще acdrv.sys (AC Driver). Это мне выдал Process Hacker при логированнии. Однако он не собирает инфу с пк (информацию о бане я получил еще до запуска). Так что, он, скорее всего. нужен только для блокировки доступа к игре
Что делает gguard и другой доп процесс
gguard записывает данные только в сам драйвер, в steam_api.dll, ну и почему-то в nvApp Timestamps (зачем? Непонятно)
А вот читают они почти все, что можно и что нельзя. Думаю тут как раз и проверяются приложения без подписи, однако, не факт
Работа с реестром.
Действий с реестром много, поэтому я покажу только те моменты, который дествительно мб где-то интересны.
1. Запрос на имя PC (от acsvc.exe)
2. Запрос на MachineGUID (хотя, скорее всего, используется для криптографии) (от gameguard.exe)
3. Запрос на имя хоста (думаю для работы с сетью) и запрос на много чего (кстати на Video девайсы тоже)
Это то, что бросилось мне сразу в глаза. Я пока не занимался реверсом самих exe-шников, так что будет позже.
Выводы
Проведя небольшой анализ я считаю, что для бана (создания отпечатка) Gameguard использует
1. Имя PC
2. Данные о видеодевайсах
3. Volume ID (не факт, но вероятнее всего)
4. Данные о времени создания системных файлов
5. Данные сетевых адаптеров
Это используется вместе с WMI запросами точно, так что сбор HWID точно существует.
На этом пока все. Если кто-то также занимается анализом GG, то кидайте то, что нашли, буду рад :)
