-
Автор темы
- #1
Преимущество любого проекта, у которого персональный лаунчер — можно использовать клиентский античит для уверенной защиты своих игровых серверов от разных видов отлома (читеры \ взломы \ обходы). Сегодня, вероятнее всего каждый из вас, кто читает эту тему играли на популярных серверах по типу Vimeworld, Excalibur, StreamCraft и похожие проекты.
Текущая статья была написана для читателей узнать — как же работают лаунчерные античиты (clientside ac) и по какому способу они защищают себя от конкретных видов отломов?
В статье будут рассказаны проблемы, с которыми Вы можете столкнуться в моментах разработки античита\взлома проекта:
Работа каждого античита, будь то драйверный или JNI (англ. Java Native Interface). Но, всё же — JNI качественная среда разработки виртуального запуска, несмотря на то, что система защиты Vimeworld написана на нём, то это совсем не значит, что сама база плохая, просто у кого-то плохие ручки :). Насчёт первого типа, то тут всё сложнее. Для подключения драйвера необходимо получить подпись от разработчиков Java (регистрация драйвера JDBC).
Возьмём на примере всеми известный проект — Vimeworld. Изначально вся защита писалась Дмитрием Манчинским, то это пример хорошего исполнения. Конечно, со временем античит писали уже совсем другие разработчики, о которых, скорее всего, даже неизвестно. Xtrafrancyz не пытался скрыть расположение подгружаемого модуля для защиты потоков, наперёд, он это прописал в API-документации, но, вскоре убрал (причины неизвестны). К чему это я? — Это нам очень сильно поможет для изучения его классов и его модулей.
Подопытным в этой теме у нас является, как я повторяюсь — Vimeworld, поэтому с разборов его классов защиты мы и начнём. Француз, как не самый глупый человек смог сделать простой "антизапускатор" (на деле обычная проверка и удаление процесса):
Однако, после небольшого время (после открытия лаунчера) — посыпались тонны извержений от девелоперов других проектов. А весь конфликт был в том, что в недавнем прошлом никто не мог написать свою классовую защиту на JNI, потому что это было непопулярно, но очень эффективно. И вот, спустя 1.5 года появилась такая табличка, появляется, если мы запустим jar-файл лаунчера. Локация файла в коренной лаунчера (.vimeworld | %appdata%).
Но, полностью защититься в этом мире невозможно, именно поэтому самый примитивный способ был после данного нововведения — открывать через WinRaR и просматривать нужные классы, что и мы будем делать сегодня. Защитный класс античита и всей системы находиться в.. а вот и проблема.. Француз и тут смог помешать девелоперам читов или других проектов, он "замаскировал" свои классы однотипными названиями (i, ili, illi):
Хочу сразу внести ясность — это не компилирование! Компиляция SE не влияет на изменения названия, более того - она их нумерует (1, 2, 3), то это не допускается. Нужный класс с открытием хендла майнкрафта называется "ii.class", с него запускается следующие рестрикты (запреты):
Как понятно по описанию рестриктов — вся античит система оттакливается оттого, что накладывает запрет, а дополнительный "агент" отслеживает стабильность нужных потоков и самого процесса. При попытке, что либо изменить всё возвращается на исходную точку. Если попытаться уничтожить необходимые для работы агента потоки, то весь процесс игры моментально приостановится для попытки восстановить работоспособность. Если не получается — происходит краш и отключение всех модулей и отправка баг репорта на сервера Vimeworld.
Темы сырая, полностью согласен, но, это вся информация, которая была известна мне и другим персонам, которые когдато занимались отломом защиты Vimeworld.
Текущая статья была написана для читателей узнать — как же работают лаунчерные античиты (clientside ac) и по какому способу они защищают себя от конкретных видов отломов?
В статье будут рассказаны проблемы, с которыми Вы можете столкнуться в моментах разработки античита\взлома проекта:
- Разработка собственной рабочей области для обхода подписи классов\драйвера
- Основание и подключения искусственной системы распознавания скрытых процессов
- "Прятки" с фреймворками игры и Java-утилит
- Отслеживание текущего состояние процесса нужной рабочей области
- (отловка замораживания потоков)
- Внедрение "агента" для отслеживания подписи класса
Работа каждого античита, будь то драйверный или JNI (англ. Java Native Interface). Но, всё же — JNI качественная среда разработки виртуального запуска, несмотря на то, что система защиты Vimeworld написана на нём, то это совсем не значит, что сама база плохая, просто у кого-то плохие ручки :). Насчёт первого типа, то тут всё сложнее. Для подключения драйвера необходимо получить подпись от разработчиков Java (регистрация драйвера JDBC).
Возьмём на примере всеми известный проект — Vimeworld. Изначально вся защита писалась Дмитрием Манчинским, то это пример хорошего исполнения. Конечно, со временем античит писали уже совсем другие разработчики, о которых, скорее всего, даже неизвестно. Xtrafrancyz не пытался скрыть расположение подгружаемого модуля для защиты потоков, наперёд, он это прописал в API-документации, но, вскоре убрал (причины неизвестны). К чему это я? — Это нам очень сильно поможет для изучения его классов и его модулей.
Подопытным в этой теме у нас является, как я повторяюсь — Vimeworld, поэтому с разборов его классов защиты мы и начнём. Француз, как не самый глупый человек смог сделать простой "антизапускатор" (на деле обычная проверка и удаление процесса):
Проверка сделана через new File во всё том же JNI.
Однако, после небольшого время (после открытия лаунчера) — посыпались тонны извержений от девелоперов других проектов. А весь конфликт был в том, что в недавнем прошлом никто не мог написать свою классовую защиту на JNI, потому что это было непопулярно, но очень эффективно. И вот, спустя 1.5 года появилась такая табличка, появляется, если мы запустим jar-файл лаунчера. Локация файла в коренной лаунчера (.vimeworld | %appdata%).
Но, полностью защититься в этом мире невозможно, именно поэтому самый примитивный способ был после данного нововведения — открывать через WinRaR и просматривать нужные классы, что и мы будем делать сегодня. Защитный класс античита и всей системы находиться в.. а вот и проблема.. Француз и тут смог помешать девелоперам читов или других проектов, он "замаскировал" свои классы однотипными названиями (i, ili, illi):
Хочу сразу внести ясность — это не компилирование! Компиляция SE не влияет на изменения названия, более того - она их нумерует (1, 2, 3), то это не допускается. Нужный класс с открытием хендла майнкрафта называется "ii.class", с него запускается следующие рестрикты (запреты):
- Запрет на заморозку потоков
- Отключение сканирования от антивирусных систем (Windows Defender, Avast, e.t.c)
- Автоматическое "убийство" процессов, которые конфликтуют с хендлом античит системы
- Внедрение агента для подписи класса.
Как понятно по описанию рестриктов — вся античит система оттакливается оттого, что накладывает запрет, а дополнительный "агент" отслеживает стабильность нужных потоков и самого процесса. При попытке, что либо изменить всё возвращается на исходную точку. Если попытаться уничтожить необходимые для работы агента потоки, то весь процесс игры моментально приостановится для попытки восстановить работоспособность. Если не получается — происходит краш и отключение всех модулей и отправка баг репорта на сервера Vimeworld.
Темы сырая, полностью согласен, но, это вся информация, которая была известна мне и другим персонам, которые когдато занимались отломом защиты Vimeworld.
Благодарю за прочтение темы!
Любые вопросы, которые будут возникать оставляйте в ответах к теме.
Мотивирующая тема: клик
Источник: rubukkit.org (noad), thaparbesting
Любые вопросы, которые будут возникать оставляйте в ответах к теме.
Мотивирующая тема: клик
Источник: rubukkit.org (noad), thaparbesting
Для просмотра содержимого вам необходимо авторизоваться.
