Идея Замена системе аутентификации MCPC+

Привет всем, кто хочет, чтобы на вашем сервере не резвились читеры!
У меня стоит ядро MCPC+, и, когда я закончил делать сборку, попытался прикрутить систему аутентификации посредством изменения ссылок в классах. Но не тут то было, клиент выдавал ошибку, при чём даже с включенным флагом

-Dfml.ignorePatchDiscrepancies=true

и не запускался.

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

Тогда я придумал следующее:

1) Плагин AuthMe настроен на удалённое подключение к бд, находящейся на хостинге, где стоит и сайт с регистрацией. AuthMe также настроен на кик незарегистрированных игроков, а кик из-за таймаута логина отключен (позже объясню, почему). В бд находится две таблицы: для, собственно, регистраций, и для плагина AuthMe. Первая таблица заполняется по мере регистрации пользователей, вторая изначально пустая. Не забываем отключить регистрацию в конфигах AuthMe.

2) Лаунчер прямо перед запуском игры посылает запрос на сайт, где, если пароль и логин введены верно, происходит копирование соответствующей строки из таблицы регистраций в таблицу AuthMe.

3) После игра запускается, а лаунчер сворачивается, но не закрывается, ожидая окончания процесса java.

4) Игрок поиграл, закончил и закрыл minecraft, лаунчер посылает ещё один запрос на сервер, и сервер удаляет запись из таблицы AuthMe.

5) Лаунчер сам закрывается.

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

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

В третьих, вы можете быть уверены, что игроки запускают игру именно через ваш лаунчер, и проверка библиотек (или что вы там засунули в лаунчер) прошла успешно.

В четвёртых, если игрок всё же запустил ваш клиент каким-нибудь там батником или чужим лаунчером, он всё равно не войдёт на сервер, ибо AuthMe кикнет это беспечное дитя, выдав ему напоследок строку "Only for registered players. Please, visit http://moyserverazaza.org.ucoz.xuy to register." (строку можно поменять в конфигах AuthMe)

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

P.P.S. Кто-то наверняка спросит, зачем такой гемор, ведь можно просто подразобраться с сессиями, и всё будет норм. Отвечаю: если вам помогло выставление флага запуска
-Dfml.ignorePatchDiscrepancies=true, то на этом можно и остановиться, но мне это не помогло, а копать дальше ((пункт 1)декомпилировать сорцы майна, плясать вокруг них с бубном и т.д.) мне было как-то лениво. Плюс, если вы захотите впилить в сессии больше надёжности, то придётся выполнять этот адский пункт 1.

Для тех, кто дочитал до сюдо
В AuthMe отключена функция кика игроков из-за таймаута логина, потому что не раз возникала ошибка с полётом. Поскольку база данных удалена от сервера, ему приходится к ней подключаться, и это требует времени, поэтому игрок может ввести команду "/login " и быть кикнутым по прошествии некоторого времени, т. к. он "не вошёл". Однако, когда он зайдёт снова, AuthMe будет думать, что он уже вошёл, и, следовательно, ему не будут инжектироваться Permissions. Из-за всего этого нередко возникает "баг", когда человек нажданно-негаданно получает одминку криатив и т. п. подарки. На всякий случай: если у вас хороший интернет канал, то таких бед не будет
Желаю удачи в освоении аутентификации minecraft!)

 

Что будет, если я на виртуалке запущу твой лаунчер, а сам буду играть с читерского клиента на основной системе?

 

Хм, вроде бы интересная идея. Надо будет попробовать.

 

Вроде к параметрам запуска ещё надо прикручивать -Dfml.ignoreInvalidMinecraftCertificates=true.

Вариант без виртуалки: убить лаунчер в процессах.

 

Можно попробовать доработать, все таки система не идеальна. Но вот что-то в ней есть.

 

Я не утверждал, что защита лаунчера является абсолютной защитой от читерства. Любой лаунчер можно обойти, вопрос в том, насколько это гемморойно. Для защиты собственно сервера я использую NCP и AntiCheat, а также им подобные. Кроме того, лично мой клиент зашифрован и модифицировать его не удастся, а собирать свой с таким кол-вом модов, как у меня, с изменёнными id предметов, не очень приятно, и вероятность того, что анонимус бросит это занятие ещё на начальной стадии, весьма велика.

В процессах не отображается, проверял. Осваиваем C# потихоньку.
Насчёт доп. флага, у меня была ошибка не в расхождении патчей, а возникала ошибка индекса, выходящего за предел диапазона массива. Оба флага стояли, и всё равно. Просто я про второй флаг забыл написать

 

Стоять, C#? А может лучше плюсы? Просто на шарпе не реализуешь запуск на всех ОС.

 

C# лучше java только более тесным взаимодействием с winapi. В остальном также легко декомпилируется и ломается извне.
На плюсах тебе прийдется изучать особенности каждой ОС и для каждой писать свой код.

 

А какой тогда код использовать для кроссплатформенности? Просто плюсы, ИМХО, лучший вариант для написания подобного.

 

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

 

Да, я где-то в темах предлагал включать защиту как нативки для разных ОС внутри джарника лаунчера.
Не верю, чтобы в процессах не было видно.