Спасибо за поправку. Да, конечно же, при большом желании можно реализовать, но и в клиенте придется много чего дорабатывать.
В статье подразумевалась возможность просчета физики теми же алгоритмам, что и в Unity, как это сейчас делается в клиенте. У нас изначально задача стояла получить максимум защиты без больших затрат на его кардинальную переработку.
Да, изначально вводили по сути обсервер. В каких-то вещах получилось полностью закрыть лазейки для взломов, в каких-то — скромно осталась мизерная возможность. Главное, мы достигли цели: честные игроки перестали страдать от читеров.
Сейчас при проектировании новых фичей мы сразу учитываем возможности плагина, и он уже больше мастер-клиент, чем обсервер.
Привет! Мы внимательно следим за этими игроками — такое получение пушек используется нами как один из триггеров для детального изучения взломов. С них собирается и изучается дополнительная информация, которую мы используем для выявления технологий взломов. А аккаунты затем отправляются в бан.
Решение 9, ч. 2 не работает. Поиск неизвестного значения идёт по изменению. Массив не меняется, т.е. при поиске изменения отсеется полностью.
Здесь речь о защите неизменяемых значений в течение запуска приложения. Например, цена (чисто для примера, значение, конечно же, засолено) — там невозможно пользователю своими действиями изменить и отсеять. Тогда берут и меняют все значения, в такие выборки и этот массив попадает.
А чем вам готовая сторонняя аналитика не угодила?
Основная проблема: там агрегируются данные, и мы не можем сопоставить ивенты с конкретными нашими пользователями.
А сколько по времени хранит данные база аналитики и сколько она весит?
Без ограничения срока. Сейчас хранится около 800 ГБ данных примерно за 2 года.
Так и есть. Раньше активно пользовались, сейчас меньше, так как при большом DAU их очень сложно качественно обработать. Чтобы выявлять потенциальных читеров больше пользуемся аналитикой: автоматическими выгрузками с нее или приоритетно жалобами от модераторов.
Да, система репортов есть. Прямо в игре можно в таблице нажать на игрока и в открывшемся интерфейсе (где автоматически заполняются необходимые поля, например, ID пользователя) написать жалобу.
Основная проблема этой системы в том, что часто жалуются и на честных игроков, которые легальными способами получили новое оружие и имеют высокий скилл. Таких писем много, а процесс переработки полностью не автоматизировать. Более эффективно в данном направлении проходит работа отдела комьюнити с активными модераторами — там процент достоверных жалоб очень высокий.
Постоянное соединение, наоборот, помогает избавиться от ряда уязвимостей, но присутствовал другой для геймдева момент — при переходе на него была опасность потерять часть пользователей, так как для них сильно менялся пользовательский опыт
В целом предложение выглядит рабочим, опрос только надо проводит так, чтобы в итоге все части проверялись, так как изменение может быть в любой части бинарника
В отдельности это, конечно, преодолимая защита, как и большинство других, но в совокупности со всем остальным делает взлом ресурсозатратнее. А это в свою очередь снижает количество взломщиков, сумевших переступить порог
Думаю, их можно использовать, но как дополнительную защиту, когда все основные уже реализованы. В отдельности это будет больше похоже на лечение симптомов, а не болезни, так как пройдет какое-то время, пока читер обнаружится
Интересный вопрос! Думаю, она есть, но сильно зависит от смысла игры и целевой аудитории. Более взрослую аудиторию, которой важна честность, читеры будут отталкивать. А на тех игроках, у которых на первом месте фан, на начальном этапе это, возможно, сильно и не скажется
Да, на начальных этапах это было реализовано в рамках прототипа, в дальнейшем перевели хранение на наш сервер
Как в итоге выглядит сохранение прогресса?
Прогресс хранится на сервере, при запуске клиент берет с сервера текущее состояние. Далее при каждом изменении сравниваются итоговые значения, и если они отличаются, то операция отменяется — клиент снова берет с сервера последнее валидное состояние. Думаю, еще напишем о хранении прогресса отдельно
Я вот очень внимательно читал и так и не увидел: а почему вы пытаетесь защитить клиент?
Защита клиента это только часть глобальной задачи по защите приложения. Мы перенесли на наш сервер хранение прогресса и добавили валидацию всех операций его изменения. Сейчас продолжаем работу по переносу с клиента на сервер логики начислений
А по поводу обфускации, если у пользователей будут ошибки, можно ли будет понять где это произошло, или в callstak будет белеберда?
При обфусцировнии плагин сохраняют в файл соответствия исходных имен и обфусцированных. Мы эти файлы сохраняем и в дальнейшем используем для восстановления коллстеков.
И как быть с публичными переменными в Юнити, они же присваиваются по имени?
Публичные переменные не обфусцируются, их используем только для интерфейсов, интерфейсы, как правило, не представляют интереса для взлома
В статье подразумевалась возможность просчета физики теми же алгоритмам, что и в Unity, как это сейчас делается в клиенте. У нас изначально задача стояла получить максимум защиты без больших затрат на его кардинальную переработку.
Сейчас при проектировании новых фичей мы сразу учитываем возможности плагина, и он уже больше мастер-клиент, чем обсервер.
Основная проблема: там агрегируются данные, и мы не можем сопоставить ивенты с конкретными нашими пользователями.
Без ограничения срока. Сейчас хранится около 800 ГБ данных примерно за 2 года.
Основная проблема этой системы в том, что часто жалуются и на честных игроков, которые легальными способами получили новое оружие и имеют высокий скилл. Таких писем много, а процесс переработки полностью не автоматизировать. Более эффективно в данном направлении проходит работа отдела комьюнити с активными модераторами — там процент достоверных жалоб очень высокий.
Да, на начальных этапах это было реализовано в рамках прототипа, в дальнейшем перевели хранение на наш сервер
Прогресс хранится на сервере, при запуске клиент берет с сервера текущее состояние. Далее при каждом изменении сравниваются итоговые значения, и если они отличаются, то операция отменяется — клиент снова берет с сервера последнее валидное состояние. Думаю, еще напишем о хранении прогресса отдельно
Защита клиента это только часть глобальной задачи по защите приложения. Мы перенесли на наш сервер хранение прогресса и добавили валидацию всех операций его изменения. Сейчас продолжаем работу по переносу с клиента на сервер логики начислений
Он написан на Python, в скором времени планируем рассказать про серверную архитектуру в отдельной статье
При обфусцировнии плагин сохраняют в файл соответствия исходных имен и обфусцированных. Мы эти файлы сохраняем и в дальнейшем используем для восстановления коллстеков.
Публичные переменные не обфусцируются, их используем только для интерфейсов, интерфейсы, как правило, не представляют интереса для взлома