Лаунчер Пересобранная jvm.

[fereter]

В последнее время развелось очень много dll читов на основе define class. Они загружают классы чита в обход защиты лаунчера. Сейчас для защиты от таких читов используются jni+jvmti dll'ки, накрытые протекторами. Это дополнительная нагрузка на компьютер пользователя. Они замедляют работу игры и могут сделать невозможной игру на слабом компьютере или снизить удовольствие на среднем. От читов они защищают плохо. Слив ehacks на streamcraft это продемонстрировал.

Пересобранная jvm -- принципиально другой подход. Никаких задержек на взаимодействие с api. Оптимизация защиты вместе со всей остальной jvm. Размер файла в разы меньше, чем у jvm от oracle. Защита не отключается изменением 1 бита настроек. Защита выдает корректные java исключения при попытке загрузить чит. При их корректной обработке клиент даже не вылетит.

В этой сборке вырезан Redefine, поставлены проверки на defineclass и findclass. Это защищает от всех известных бесплатных читов на основе defineclass, включая, но не ограничиваясь easycheat rebuild, java injector, jar to dll converter (ehacks).

Эта jvm совместима с любой защитой, не использующей функции DefineClass и FindClass из JNI.
Протестировано на tlauncher на версиях 1.7.10 и 1.8.9. На 1.6.4 возникли проблемы, связанные с openjdk.

Цели:

• Защита от большинства читеров, использующих публично доступные читы,
• Незначительное снижение нагрузки на сеть и дисковую систему пользователя.

То, что целями не является:

• Защита от всех читов, включая не доступные публично,
• Затруднение разработки читов.

ToDo:

• Обработка RegisterNatives
• Обнаружение HZR2
• Вырезать JVMTI
• Шифрование классов
• Ускорить черные/белые списки

Скачать версию 1.1 https://yadi.sk/d/53wgFmVW0mvqtQ
Скачать версию 1.0 с черным списком https://yadi.sk/d/5ljRPs46_VOksQ
Скачать версию 1.0 без черного списка https://yadi.sk/d/L4DGMyesx1zpKQ
Патчи для сборки https://yadi.sk/d/Ss4odo-CEctSwg

Установка проста. Заменить файл jvm.dll в jre лаунчера и обновить список файлов jre.

UPD1:
Добавил x32 версию.
Добавил патчи для самостоятельной сборки.
Убрал ошибочное утверждение про кеш.

UPD2:
Добавлены цели и то, что целями не является.
Добавлена версия без черного списка.

UPD3:
Добавлен todo list.
Добавлена версия 1.1.

 

[Linkinkov]

Для х32 версии нет?

 

[HoShiMin]

Никаких промахов в кеше при загрузке кода защиты из другой страницы

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

Код и данные ложатся в кэш не страницами, а длиной кэш-линий - обычно, 64 байта, но на разных процессорах значения для L1, L2 и L3 могут отличаться. Поэтому нет никакой разницы, из какой страницы вызывается код.

Оптимизация защиты вместе со всей остальной jvm

Что подразумевается под "оптимизацией"?

В этой сборке вырезан Redefine, поставлены проверки на defineclass и findclass

Какие именно проверки?
Как насчёт выложить git-патч?

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

 

[fereter]

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

Код и данные ложатся в кэш не страницами, а длиной кэш-линий - обычно, 64 байта, но на разных процессорах значения для L1, L2 и L3 могут отличаться. Поэтому нет никакой разницы, из какой страницы вызывается код.

Согласен. Про кеш я ошибся.

Что подразумевается под "оптимизацией"?

Оптимизации компилятора.

Какие именно проверки?
Как насчёт выложить git-патч?

Патчи

 

[HoShiMin]

Патчи

Именно для этого и попросил патчи - есть несколько замечаний.

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

Названия "плохих" классов можно организовать в дерево (std::set) со сложностью поиска O(log(n)) или в хэшсет (std::unordered_set) со сложностью поиска O(1).

Если ты собираешь в vs2010, то std::unordered_set'a, скорей всего, там ещё нет.

Алгоритм получится примерно таким:

#include <set>
#include <string>

std::set<std::string> g_blacklist;

void init_blacklist()
{
    g_blacklist.insert("полное/название/класса1");
    g_blacklist.insert("полное/название/класса2");
    ...
}

inline bool is_in_blacklist(const std::string& name)
{
    return g_blacklist.find(name) != g_blacklist.end();
}

Коль скоро нет разницы, привязываться к подстрокам или к полным путям (и то, и то легко меняется разработчиками читов), если и делать такую привязку, то есть смысл её оптимизировать или отказаться от неё вообще.

Аналогично стоит оптимизировать любые простыни из сравнений строк: заменить все if (strcmp(...)) else на один set.find().
Именно такие оптимизации, кроме всего прочего, позволят тебе избежать пресловутых промахов кэшей, т.к. именно на твоих strstr промахи и будут вылетать чаще всего. Весьма иронично.

И, наконец, весь смысл проверок и вот это:

Защита не отключается изменение 1 бита настроек

противоречат друг другу. Что мешает пропатчить проверки, заставив их всегда говорить, что класс полностью доверенный и валидный? Отключается изменением не одного бита настроек, а пропатчиванием пары инструкций.

Или перехватить LoadLibrary и подменить загрузку твоей либы на чистую jvm.dll без твоих проверок.

Чтобы твои проверки сложно было найти, придётся всю либу целиком накрывать протекторами, что сразу сводит на нет все оптимизации и катастрофически сажает фпс. И какой тогда смысл?

 

[alexandrage]

Пфф. До чего же бесполезная защита. Мало того она будет жрать время на поиски по фильтрам, да еще и бесполезная на пересобранных читах.

 

[alexandrage]

Про протекторы вообще несешь полную дичь. Почему же игры под denuvo протектором работают ровно так же быстро как без него?

 

[HoShiMin]

Почему же игры под denuvo протектором работают ровно так же быстро как без него?

Зависит от того, что именно и как накрывать. Если целиком накрыть jvm чем-то типа вмп или темиды, производительность упадёт в ноль. Если накрывать избирательно, можно сохранить приемлемую скорость, но останутся ненакрытые участки, через которые можно будет загрузить чит. Протекторы - это security through obscurity, это всегда ненадёжно и всегда оверхед на саму защиту, но простой и быстрый способ отсрочить обход.

 

[zaxar163]

Качество фиксов оставляет желать лучшего, благо ну вот такие чеки это видоизменённый вайтлист сигнатур EasyAntiCheat и это никак не решение, а с репакагом что? А если читер обнаглеет и хукнет по чёрному то что? А ты знал что сама жабка может registerNativer в себе вызвать?

 

[fereter]

Пфф. До чего же бесполезная защита. Мало того она будет жрать время на поиски по фильтрам, да еще и бесполезная на пересобранных читах.

Черный список -- не единственная проверка. Остальная защита не обходится ремапом чита.

Думаю, что будет правильно сделать 2 версии защиты: с черным списком и без. Тот, кто хочет дополнительно перестраховаться, поставит версию с черным списком. Тот, кто верит в падение fps, поставит версию без этой проверки.

 

[zaxar163]

В 3 - если VMProtect на целую жабу - уже не помочь FPS, начнётся апокалипсис скорости.

 

[zaxar163]

Так чёрный список не поможет
у меня лежит репакагнутый ехукс. Всё -защита. А ещё репакагер от FFt в пабе в их конфу
Во 2 - предотвращать регистрацию натива неверно, надо ловить трейс и проверять.

 

[zaxar163]

Инжектор на стримаче и берёт прокси за основу...

Этот кусок кода обходится дефайном класса с соблюдением этих условий что опять же не сложно. Возврат к основам - защита на основе блеклистов (а всё что я увидел это 1 большой блеклист, 0 проверок стека, а то что есть с JavaThread это не решение).

 

[zaxar163]

А ещё можно прямо сказать - хукнет человек 1 из твоих чеков, вот тот же strstr, вроде банальщина а чеки отлетят.
Так же JavaThread.current() можно хукать и делать трейс вызова через WINAPI и проверять его собственно, что тоже может привести к отлёту защиты.
P. S. Защищает как и аван 1 от всего кроме читов... Относительно квалифицированный читер забьёт на все эти чеки. А ещё нативесы можно регать для net/minecraft/render... (нативный xray).

 

[MaksGruw]

ИМХО, все эти античиты на стороне клиента выглядят как огроменный костылище, который можно в любой момент немного подумав обойти, ведь все это просто отображение проблем мультиплеера, которые никто не решает. Чем изощренней античиты на стороне клиента, тем изощренней и читы. И рано или поздно может дойти вплоть до банальной имитации лаунчера с клиентом (в конце концов, отследить сетевые запросы не трудно).
Вот прекрасная аналогия из мира веб-программирования: античиты на стороне клиента — это как спихивание вычислений веб-сервака на клиент (браузер) посредством JS. А-ля serverless. А то, что от этого всякие старые смартфоны падают пытаясь просто одну незамысловатую страницу отобразить, почему-то не особо кого волнует.
Увы, но лично мне до сих пор кажется, что лучше уж как альтернативный костыль нагрузить сервер античитами на его стороне, нежели городить эту ересь на стороне клиента, которая еще и повышает требования к железу, губит кроссплатформенность (которой уже можно считать и нет).

 

[HoShiMin]

нагрузить сервер античитами

Как только напишут античит с нормальной поддержкой модов - все клиентские костыли вмиг станут не нужны. Только прошло уже 10 лет, а воз и ныне там.

Впрочем, и нормальные клиентские античиты есть только на двух-трёх проектах, а всё, что в паблик-лаунчерах и паблик-либах, не защищает ни от чего.

 

[MaksGruw]

Как только напишут античит с нормальной поддержкой модов - все клиентские костыли вмиг станут не нужны. Только прошло уже 10 лет, а воз и ныне там.

А поскольку имеется связка "сервер с модами <—> клиент с модами", было бы логично, если б были патчи конкретно для сетевых пакетов (у нас же в распоряжении клиент да сервак, а не как когда-то один только ванильный сервак из разряда Spigot), но вместо этого все любят "античиты по старинке".
Мне вот почему-то нравится мультиплеер у MineTest. Поиск читов выдает только нечисть в виде "добавьте чит на сервак".

 

[HoShiMin]

патчи конкретно для сетевых пакетов

А что подразумеваешь под патчами сетевых пакетов?

Единственное адекватное решение - переписать логику сервера и обсчитывать ВСЁ (или бОльшую часть) на серверной стороне - все передвижения, удары. А кто может себе такое позволить? Единицы - топовые сервера. Для всех остальных - клиентское плацебо, которое обходится парой хуков.

 

[MaksGruw]

А кто может себе такое позволить? Единицы - топовые сервера.

Если подразумеваются тяжелые вычисления, то откуда известно, что они тяжелые, если почти все кроме игроков и так вычисляется на стороне сервера?
Если же подразумевается трудность патчей, то, как по мне, достижение недр JVM, манипуляция с байт-кодом — ну это куда более похоже на путь мазохиста, нежели банально подумать в объекто-ориентированном стиле.

 

[HoShiMin]

Если же подразумевается трудность патчей

Подразумевается именно сложность патчей. В недрах JVM нет ничего сложного: открыть исходники, посмотреть, как грузятся классы, поставить проверки. Её собрать сложнее, чем патчить. А для переписывания протокола придётся проделать очень много работы, т.к. ты пишешь не новый функционал, как в случае кастомной JVM, а меняешь существующий - и меняешь весьма существенно, и нужно сделать это аккуратно, не сломав работу модов. Эта работа не ограничивается "подумыванием в объектно-ориентированном стиле" - нужно учитывать, что игроков может быть много, как и факторов, воздействующих на их движение, и нужно обсчитать все координаты и коллизии быстро для всех игроков. А значит, есть поле для распараллеливания вычислений. А где многопоточность - там и проблемы синхронизации. И если разматывать портянку возможных проблем, окажется, что это очень большая работа, которую просто нерентабельно делать серверам средней руки.

И я уже не говорю, что это работа "под ключ" для конкретного сервера с конкретной версией ядра и заданным набором модов. Если выкладывать в паблик, потребуется поддержка и разных версий, и разных модов - задача, непосильная для одного человека. И всё это на фоне вопроса "зачем", когда можно написать клиентскую защиту и получить ДОСТАТОЧНЫЙ античит, который отсечёт какой-то (возможно, даже бОльший) процент читеров. И время от времени его обновлять. Простое и дешёвое решение, которое позволит высвободить ресурсы для, собственно, самого сервера. Хорошие примеры - вармайн, вайм и сталкрафт с очень достойными клиентскими античитами. Сделают ли на них читы? Сделают, но не сейчас. А проблемы надо решать по мере их поступления.