Комментарии 71
Уровень физически невозможно пройти менее чем за одну минуту. Поэтому игры, прошедшие за 30 секунд или за 2 минуты, считаются взломанными.
Что-то не сходится…
Согласен, я с не совсем точно выразился. Уровни создаются такой длины, чтобы их можно было пройти до конца примерно за 1 минуту, плюс/минус несколько секунд. Поэтому большие расхождения подозрительны.
С нижней гранью я согласен, но вот с верхней — нет. Игрок может быть медленным, может быть падение фпс, игры или вообще игрок афк, что тогда?
Насколько я понял, игрок постоянно бежит — остановить его нельзя.
Персонаж бежит постоянно (внешне это выглядит как будто он расположен возле левого края экрана, а на него справа налево «бежит» уровень). Падение фпс мы тоже учитываем — пропускаем фреймы. Так что даже с малым фпс игра идет примерно одно и то же время как и с 60 fps.
Хакер может взломать систему оповещения о событиях и она будет посылать на сервер «правдивые» данные.
Так и очков за такие «честные» данные будут давать честно и мало, разве нет?
Как раз для этого и было написано несколько методов обнаружения читеров для анализатора. Например, хакер может и не догадаться как работает «Взятие ложных элементов» и будет отсылать данные о сборе всего подряд.
Мы придумывали эти методы исходя из того, что все данные от клиента ненадежные.
Мы придумывали эти методы исходя из того, что все данные от клиента ненадежные.
Понял. Ложные элементы — звучит интересно. Можно, пожалуйста, детальней о реализации этого метода? Я себе это представляю так, что есть элементы, которые не видны юзеру, но имеют те же свойства, что и собираемые. Если юзер собрал все такие элементы — значит «читил».
Элементы юзеру как раз видны, но до них персонаж не допрыгивает — они чуть выше находятся. И при нормальной игре они никогда не собираются. А бот может просто все собрать, не обратив внимание.
После генерации уровня и до отправки уровня клиенту анализатор добавляет парочку таких элементов и запоминает их id. После игры смотрим: если, например, элемент с id = 421 собран, то значит чит.
После генерации уровня и до отправки уровня клиенту анализатор добавляет парочку таких элементов и запоминает их id. После игры смотрим: если, например, элемент с id = 421 собран, то значит чит.
Ну раз уж вы собираете данные с клавиатуры, то можно сделать расчет равномерности нажатий, у бота (если только он специально не заточен) нажатия будут более равномерны, чем у человека.
До разработки этой игры gamedev представлялся нам чем-то не понятным.Нескромный вопрос: а заказчик был об этом в курсе, когда делал заказ?
У компании опыт разработки игр есть. У конкретной команды — не было. Тем не менее, считаю, что справились мы неплохо.
Вполне себе обычный отечественный бодишоп)
Продают заказчику кого могут, под вывеской «большой и успешной компании с богатым опытом».
А потом эти ребята клепают велосипеды на ровном месте, т.к. банально не знают как эти стандартные проблемы решают те кто «в теме».
Не поймите неправильно, я не хочу никого обидеть, сказать, что ребята плохо справились. Все же работает и вроде заказчик доволен.
Просто по статье же видно, что мыкались по разных углам не зная как решать типичную проблему.
А так, к сожалению, работают 99.9% бодишопов.
Продают заказчику кого могут, под вывеской «большой и успешной компании с богатым опытом».
А потом эти ребята клепают велосипеды на ровном месте, т.к. банально не знают как эти стандартные проблемы решают те кто «в теме».
Не поймите неправильно, я не хочу никого обидеть, сказать, что ребята плохо справились. Все же работает и вроде заказчик доволен.
Просто по статье же видно, что мыкались по разных углам не зная как решать типичную проблему.
А так, к сожалению, работают 99.9% бодишопов.
Да, кстати, «как эти стандартные проблемы решают те кто «в теме».» — поделитесь, как описанную задачу могли бы решить те, кто в теме?
Толсто тролите. Какой секрет вы рассчитываете тут услышать?
Все варианты давно известны и боле менее расписаны в статье.
Но в целом, те кто «в теме» например не стали бы даже пытаться рассчитывать на такие глупости как обфускация клиента и шифрование пакетов. И не смеялись бы над просчетом игры на сервере, ибо это вообще единственный способ максимально защитить игру.
Именно такие моменты и показывают уровень.
Все варианты давно известны и боле менее расписаны в статье.
Но в целом, те кто «в теме» например не стали бы даже пытаться рассчитывать на такие глупости как обфускация клиента и шифрование пакетов. И не смеялись бы над просчетом игры на сервере, ибо это вообще единственный способ максимально защитить игру.
Именно такие моменты и показывают уровень.
Как все эти методики защитят от атаки «в лоб»? Бот, используя знание обо всем уровне, может заранее рассчитать точные моменты, которых нужно подпрыгнуть или пригнуться, чтобы набрать максимальное количество прелестей, при этом вы не сможете отличить его от просто экспертного игрока, который прямо гроссмейстер в вашей игре — ведь бот будет честно отправлять KeyboardEvent. Можно еще бесполезные прыжки и приседания делать на участках, где они не смогут повредить запланированным точкам.
И как быть в таком случае?
И как быть в таком случае?
Конечно, непросто будет различить гроссмейстера и бота. Надеюсь, что коллеги подскажут еще другие методы обнаружения читеров.
Сейчас я вижу несколько вариантов, которые увеличивают вероятность:
1) Уровень каждый раз генерируется заново.
2) Скорость персонажа периодически изменяется в зависимости от столкновений с препятствиями и уровня энергии. Так что тут надо будет физику игры сэмулировать хитрее, а не просто жать кнопку UP за 20 пикселей до каждого бонуса.
3) Можно использовать базу данных уже сыгранных игр, и слишком уж идеальные забеги брать на карандаш.
4) Вероятно, для запуска бота будут нажаты некоторые клавиши, которые отправятся на сервер. Можно будет это словить.
5) Этот хакер мог уже быть замечен в других нечестных играх. Можно будет проверить его через анализ «отпечатков пальцев».
Сейчас я вижу несколько вариантов, которые увеличивают вероятность:
1) Уровень каждый раз генерируется заново.
2) Скорость персонажа периодически изменяется в зависимости от столкновений с препятствиями и уровня энергии. Так что тут надо будет физику игры сэмулировать хитрее, а не просто жать кнопку UP за 20 пикселей до каждого бонуса.
3) Можно использовать базу данных уже сыгранных игр, и слишком уж идеальные забеги брать на карандаш.
4) Вероятно, для запуска бота будут нажаты некоторые клавиши, которые отправятся на сервер. Можно будет это словить.
5) Этот хакер мог уже быть замечен в других нечестных играх. Можно будет проверить его через анализ «отпечатков пальцев».
Я исхожу из того, что бот — это не внешняя программа, а Greasemonkey-скрипт или расширение браузера. Т.е. бот имеет полную и безраздельную власть над браузером, что полностью соответствует действительности.
1) я посмотрю структуру уровня в памяти. Залезть внутрь closure не проблема.
2) зачем? я ведь могу использовать вашу же физику со всеми ее тонкостями реализации.
3) это да, но что плохого в идеальных забегах? :) для правдоподобности, бот может поднимать свой уровень постепенно.
4) это не проблема — бот может или запускаться через меню или кнопку на тулбаре, или по событию загрузки страницы, или просто перехватывать нажатия клавиш и не спускать их на обработку скриптам страницы вовсе :)
5) «отпечатки пальцев» можно ведь и рандомизировать — например, переопределить некоторые свойства navigator и возвращать случайные значения, сгенерированные заново каждый раз перед загрузкой страницы. Или добавлять рандомные биты в canvas. Или перетасовывать местами navigator.plugins, или прятать-добавлять некоторые плагины и их mime-типы. Т.е. можно сделать неограниченно много вариантов отпечатка, на самом деле. Есть и обратный подход — притворяться чем-то стоковым и популярным. Например, последним Safari на последней iOS на последнем iPhone. Конфигурации у всех одинаковые, железо у всех одинаковое, софт одинаковый, фингерпринт одинаковый, отличить хакера без бана кучи невинных пользователей Apple не получится.
1) я посмотрю структуру уровня в памяти. Залезть внутрь closure не проблема.
2) зачем? я ведь могу использовать вашу же физику со всеми ее тонкостями реализации.
3) это да, но что плохого в идеальных забегах? :) для правдоподобности, бот может поднимать свой уровень постепенно.
4) это не проблема — бот может или запускаться через меню или кнопку на тулбаре, или по событию загрузки страницы, или просто перехватывать нажатия клавиш и не спускать их на обработку скриптам страницы вовсе :)
5) «отпечатки пальцев» можно ведь и рандомизировать — например, переопределить некоторые свойства navigator и возвращать случайные значения, сгенерированные заново каждый раз перед загрузкой страницы. Или добавлять рандомные биты в canvas. Или перетасовывать местами navigator.plugins, или прятать-добавлять некоторые плагины и их mime-типы. Т.е. можно сделать неограниченно много вариантов отпечатка, на самом деле. Есть и обратный подход — притворяться чем-то стоковым и популярным. Например, последним Safari на последней iOS на последнем iPhone. Конфигурации у всех одинаковые, железо у всех одинаковое, софт одинаковый, фингерпринт одинаковый, отличить хакера без бана кучи невинных пользователей Apple не получится.
Надо попробовать придумать еще варианты защиты. Очевидно, что есть понимание проблемы. Есть мысли с какой еще стороны можно к этому подступиться?
Предлагаю хотя бы тезисно это оформить. Либо выйти на решения через имеющиеся ограничения (типа, «доверия ответам игрока нет» и т. п.).
Предлагаю хотя бы тезисно это оформить. Либо выйти на решения через имеющиеся ограничения (типа, «доверия ответам игрока нет» и т. п.).
Я обычно с обратной стороны баррикад, поэтому мне тяжело предложить что-то, с чем я бы не смог справиться :) Абсолютная защита точно и гарантированно невозможна, какими бы вы техниками не пользовались.
Предположим, что вам удалось спрятать от клиента абсолютно всю игровую логику настолько, что браузер передает на сервер нажатия клавиш, а сервер генерирует картинку и отправляет ее клиенту — несмотря на лаг. Даже в этом случае вы не сможете защититься от тех, кто будет брать вашу картинку, распознавать ее при помощи OpenCV или других техник, вычленять нужные элементы, выполнять расчет оптимальной стратегии и отправлять нажатия кнопок так, как их бы отправлял человек. Этот интерфейс упрощать уже дальше некуда, и он все еще уязвим. Да, у бота не будет доступа к игровой физике, но что помешает сделать бота, который тренируется при помощи генетических алгоритмов? Такому боту не нужна будет точная модель физики, он построит ее самостоятельно.
Вот, кстати да. Вы можете ограничивать число возможных игр. Например, одна игра с одного IP не чаще, чем раз в два часа. Правда, я бы или не стал играть в такую игру вовсе, или записывал бы игровую сессию на видео с аннотациями нажатых клавиш, чтобы потом, используя эту запись, построить модели и обкатывать их позже, в том числе, возможно, через всяческие прокси.
Предположим, что вам удалось спрятать от клиента абсолютно всю игровую логику настолько, что браузер передает на сервер нажатия клавиш, а сервер генерирует картинку и отправляет ее клиенту — несмотря на лаг. Даже в этом случае вы не сможете защититься от тех, кто будет брать вашу картинку, распознавать ее при помощи OpenCV или других техник, вычленять нужные элементы, выполнять расчет оптимальной стратегии и отправлять нажатия кнопок так, как их бы отправлял человек. Этот интерфейс упрощать уже дальше некуда, и он все еще уязвим. Да, у бота не будет доступа к игровой физике, но что помешает сделать бота, который тренируется при помощи генетических алгоритмов? Такому боту не нужна будет точная модель физики, он построит ее самостоятельно.
Вот, кстати да. Вы можете ограничивать число возможных игр. Например, одна игра с одного IP не чаще, чем раз в два часа. Правда, я бы или не стал играть в такую игру вовсе, или записывал бы игровую сессию на видео с аннотациями нажатых клавиш, чтобы потом, используя эту запись, построить модели и обкатывать их позже, в том числе, возможно, через всяческие прокси.
Есть мнение, что если вы в состоянии сделать такую систему с видеокамерой, и чтобы еще в реальном времени жать на физические кнопки клавиатуры, то вам этот «краденый» айпад не очень-то и нужен.
Ну зачем сразу с видеокамерой и физическими кнопками? Это если у нас вместо браузера игровой автомат, в который не разрешают влазить. А если у нас именно браузер, то нет ни малейшей проблемы анализировать рендер элемента, в который отрисовывается игра, и отправлять документу свои собственные синтезированные события — в самом худшем случае. И да, он в таком случае не «краденный», а честно заработанный :)
Я не специалист, но есть ведь способы отличить события «в документ» от настоящего ввода пользователя. Вон гугл даже капчу сделал с одной кнопкой «Я не робот».
Нет, таких способов на самом деле нет. В документации MDN по
Принцип работы однокнопочной капчи гугла в немного другом. «Чекбокс» на самом деле собран из нескольких div-ов со сложными стилями и обработчиками событий, которые просто выглядят, как чекбокс. Объект рекапчи собирает информацию о движениях мыши, скроллах, нажатиях клавиатуры и т.д. Операция подтверждения капчи многоэтапная и включает в себя выполнение в контексте страницы какого-то кода, который присылает сервер. Как минимум — это проверка того, что «браузер» умеет выполнять javascript. На практике, скорее всего, это или какой-то простой proof-of-work, или анализ окружения — всяких объектов типа
Поэтому капча гугла, скорее, должна бы называться «я не глупый робот, который посылает mouse click ровно в середину капчи, даже не передвинув туда курсор».
EventTarget.addEventListener приводится пример приватной сигнатуры, в которой присутствует параметр wantsUntrusted. Он как раз позволяет отличить синтетическое событие, созданное контент-скриптом, от «настоящего», созданного хромом. У самой страницы такой привилегии нет, для нее все события, вне зависимости от того, кем они были созданы — настоящие. С другой стороны, так как я изначально говорю о том, чтобы бот был расширением браузера, то у бота привилегии хрома есть в любом случае.Принцип работы однокнопочной капчи гугла в немного другом. «Чекбокс» на самом деле собран из нескольких div-ов со сложными стилями и обработчиками событий, которые просто выглядят, как чекбокс. Объект рекапчи собирает информацию о движениях мыши, скроллах, нажатиях клавиатуры и т.д. Операция подтверждения капчи многоэтапная и включает в себя выполнение в контексте страницы какого-то кода, который присылает сервер. Как минимум — это проверка того, что «браузер» умеет выполнять javascript. На практике, скорее всего, это или какой-то простой proof-of-work, или анализ окружения — всяких объектов типа
Components.interfaces в Firefox — на предмет того, что эти объекты действительно работают; или же и то, и другое вместе.Поэтому капча гугла, скорее, должна бы называться «я не глупый робот, который посылает mouse click ровно в середину капчи, даже не передвинув туда курсор».
есть ведь способы отличить события «в документ» от настоящего ввода пользователяХороший вопрос, ведь если можно будет отличить реальный ввод, то это сделает невозможным автоматическое тестирование, в крайнем случае которого успешный бот может, например, проверять игру на сложность, а менее успешный — на проходимость.
Ну и да, вы не можете доверять никаким действиям игрока. Все данные, которые приходят на ваш сервер, могут и будут подделаны, но zero-trust в этом случае не защитит от бота. Капчу показывать бесполезно — всевозможные сервисы распознавания капчи автоматизируют процесс за сущие копейки (это в среднем 1$ за тысячу капчей), капча — не выход. Бан по IP в случае ценных призов тоже не вариант, прокси стоят в среднем одна за 0.50$/мес.
>Конечно, непросто будет различить гроссмейстера и бота
Мне кажется, если будет получен бот, который успешно пройдёт все ваши проверки, то это гроссмейстерский бот. Получается, приз получит гроссмейстер — а в какой сфере гроссмейстер (программирование или игры), уже не так важно — награду получит достойный.
Мне кажется, если будет получен бот, который успешно пройдёт все ваши проверки, то это гроссмейстерский бот. Получается, приз получит гроссмейстер — а в какой сфере гроссмейстер (программирование или игры), уже не так важно — награду получит достойный.
Да, именно так :) На сайтах типа codingame.com даже пропускается место с встраиванием в браузер — просто надо написать хорошего бота.
Мы себя тоже такой идеей успокаиваем. :) Но вот заказчику такой вывод сложно будет объяснить.
хмм… я вот подумал. Такой гроссмейстерский бот не будет отличим от игрока, по крайней мере — онлайн. А вот если всех победителей пригласить на офлайн-соревнование, и там они должны будут показать хотя бы наполовину такие же результаты — то они не боты.
Для серьезных игр — да, хороший вариант, отсекает ботов сразу. А вот касаемо казуальных онлайн-развлекалок — громоздкое решение имхо. Много ли народа согласится приехать лично побороться даже за iPad (не говоря уже о usb-флешках.)
Я подумал об альтернативе — в прямом эфире стримить изображение клавиатуры и нажимаемых на ней кнопок, и объединить это с полным изображением экрана. Модераторы затем смотрят, действительно ли логические нажатия клавиш предваряются физическими. Минус — нужно, чтобы у испытуемого была вебкамера. Плюс — достаточно сложно подделать. Если уровень, который будет проходиться, заранее не известен, то придется сделать систему, которая синтезирует изображение клавиатуры и рук, а сделать это в реалтайме… Думаю, награду в таком случае автор точно заслужил :)
вы предлагаете решить задачу в общем случае? Тогда решение сможет отличать искусственный разум от человеческого. Это известная проблема — Тест Тьюринга . Я думаю достаточно сделать стоимость подделки результатов игры значительно выше стоимости призов. С этим, команда успешно справилась.
У меня есть головоломка (Triplex), которая в своём javascript исходнике на клиенте хранит уровни: каждый следующий зашифрован кодом решения предыдущего. Самый простой взлом — написать свой решатель уровней.
У меня есть головоломка (Triplex), которая в своём javascript исходнике на клиенте хранит уровни: каждый следующий зашифрован кодом решения предыдущего. Самый простой взлом — написать свой решатель уровней.
Тоже решали аналогичную задачу, только игра была в жанре Tower Defense, что накладывало свои особенности.
Тоже пришли к сбору данных о действиях игроков.
В итоге ловили нечестных игроков на одинаковых во многих сессия координатах кликов, на слишком быстрых действиях (разнца между действиями 3мс), на одинаковых отсылаемых значениях.
Правда анализировали действия самостоятельно — на автоматическую систему проверки никто времени не закладывал.
Тоже пришли к сбору данных о действиях игроков.
В итоге ловили нечестных игроков на одинаковых во многих сессия координатах кликов, на слишком быстрых действиях (разнца между действиями 3мс), на одинаковых отсылаемых значениях.
Правда анализировали действия самостоятельно — на автоматическую систему проверки никто времени не закладывал.
Но ведь поставленная задача в принципе не разрешима. Если вся логика игры у клиента, то он может накрутить так, чтобы это выглядело честно. А JS полностью под контролем пользователя. В крайнем случае можно и «честного» бота сделать — такого, который будет неотличим от пользователя.
Тем не менее браузерных игр много, и они как-то живут. А Flash ненамного сложнее JS в накрутке.
В конце статьи я написал, что у сервера все же есть нечто, что недоступно клиенту-мошеннику — база данных сыгранных игр. Вот туда надо копать, если задача в принципе не разрешима.
«Честный» бот с точки зрения хакера может получиться далеко не типичным со стороны сервера.
В конце статьи я написал, что у сервера все же есть нечто, что недоступно клиенту-мошеннику — база данных сыгранных игр. Вот туда надо копать, если задача в принципе не разрешима.
«Честный» бот с точки зрения хакера может получиться далеко не типичным со стороны сервера.
Но бремя доказательства лежит именно на вас, а не на хакере. Если бот использует тот же интерфейс для игры, что и человек, он неотличим от человека. Логичность-алогичность действий — это субъективные метрики, и «мне кажется, что это играет не человек, уж больно у него хорошо получается» — ну извините, это никуда не годится.
Браузерные игры основаны на временных затратах и переводе времени в деньги. Боты несомненно дают в них профит, но как правило донат все равно позволяет обогнать бота, да и разработка бота тоже стоит времени / денег.
Я думаю стоит исходить из того, что сложный бот имеет некую «цену» создания. Чем больше проверок, тем «дороже» будет бот. Если «цена» написания бота будет заметно «дороже» возможного выигрыша, то смысла в таком боте, кроме академического, не будет.
Можно провести аналогию с фальшивоменотчеством. Деньги можно подделать, но средства защиты стремятся сделать стоимость подделки неретабельной.
Можно провести аналогию с фальшивоменотчеством. Деньги можно подделать, но средства защиты стремятся сделать стоимость подделки неретабельной.
Вы недооцениваете влияние увлеченности :) Сложного бота можно сделать из принципа, чтобы показать, что «невзламываемая игра» все-таки поставлена на колени, даже несмотря на то, что профит от подобного решения может быть чисто психологическим.
Сделать трудновзламываемую игру — тоже челендж в некотором смысле. :)
К сожалению, это невыполнимый челлендж. Вы можете усложнить взлом, например, написав игру на C и OpenGL, и скомпилировав ее в asm.js. Или можете сделать PPAPI/NPAPI-плагин, который будет загружать шифрованный пакет с логикой игры и играть ее. Но все это удаляет вас от, собственно, делания игр. Вы меньше занимаетесь играми и больше занимаетесь побочными задачами. И все ваши ухищрения не имеют смысла, пока бот может просто сесть за клавиатуру, посмотреть в монитор и пройти игру так, как прошел бы ее человек с нечеловеческими способностями к прогнозу и реакции.
Допустим, что это [пока] невыполнимый челлендж.
Есть ли предложения (для ближайшего будущего) какие принимать допущения для подобных проектов?
Иными словами, если будет снова предложение написать браузерную игру с реальными призами, то как видится процесс?
Не хочется думать, что придется отказаться с формулировкой «невыполнимо».
Есть ли предложения (для ближайшего будущего) какие принимать допущения для подобных проектов?
Иными словами, если будет снова предложение написать браузерную игру с реальными призами, то как видится процесс?
Не хочется думать, что придется отказаться с формулировкой «невыполнимо».
Могу только подсказать несколько аспектов, которые могут усложнить анализ при правильном стечении звезд обстоятельств.
1. Пишите не на JavaScript, а на языке со статической типизацией, который может компилировать LLVM — т.е. C, C++, D и т.д. Полученный проект собирайте emscripten-ом в asm.js-овый бандл, предварительно включив LTO и IPO. Проследите, чтобы у вас не было именованных экспортов.
+ будет работать намного (на порядок) быстрее, чем типичная реализация руками непосредственно в JS;
+ исходник будет крайне сложен для анализа, без довольно специфичного опыта реверс-инжениринга выхлопа кодогенератора биткода LLVM не обойтись;
+ внутреннее состояние игры раскрывается, но зачастую не в той мере, чтобы позволить модификацию;
– вы все равно зависите от браузера в том, чтобы доставить ваши данные к серверу
2. Используйте ECDSA и подписывайте состояния объектов, а потом в случайные моменты проверяйте правильность подписей. Можно скомбинировать с кодом Рида-Соломона, чтобы словить модификацию подписей или содержимого и потом уже придумать, что делать.
+ может обмануть читера, если он первым делом полезет менять память, а уже потом запоздало подумает
– накладно с точки зрения производительности
– трудно реализовать правильно
3. Как вариант, вместо предыдущего пункта — шифруйте все состояние в памяти чем-то типа AES128CTR, чтобы иметь возможность параллельной расшифровки блоков.
+ читеру придется писать декриптор
+ возможно, придется лезть в дебри реализации asm.js JIT и вставлять туда свои заглушки, чтобы дампить расшифрованную память
+ ключ можно генерировать на ходу
– сгенерированный ключ придется хранить открытым текстом
– будет работать медленно. возможно, имеет смысл шифровать не всю память вообще, а какой-то отдельный объект, или перемежать шифрованные и нешифрованные блоки
– нужно будет писать свой препроцессор, потому что любые обращения к памяти нужно будет обернуть в криптор;
4. Используйте secure web socket-ы для связи с сервером.
+ сложнее отследить и перехватить
+ сложнее модифицировать
– может не работать по ряду причин — файрвол, прокси, настройки приватности, оргия сатанинских котят, запрет SSL
5. Деструктуризируйте графику. Если рисуете плоские объекты, не используйте DOM, рисуйте сразу на <canvas>. Если используется векторная графика, разверните все SVG-группы, пусть сцена будет просто одноуровневой мешаниной безье-кривых, а группировку держите у себя в памяти. Если используете объемную графику, рисуйте прямыми вызовами WebGL.
+ для отслеживания состояния придется анализировать картинку
+ emscripten дает эти плюшки из коробки
– обновление групп объектов будет менее эффективным
Эти приемы позволят усложнить анализ и корректировку поведения программы в свою пользу, но ни один не поможет со 100% уверенностью. Просто при приеме заказа на «невзламываемую игру», уведомите заказчика, что полностью от взломщиков защититься невозможно даже теоретически, но даже пункт №1 из моего списка позволит вам отсечь 99% «казуальных читеров» с минимальными затратами и ощутимыми профитами, а вот стоит ли игра свеч, чтобы бодаться с оставшимся 1% — решать заказчику.
1. Пишите не на JavaScript, а на языке со статической типизацией, который может компилировать LLVM — т.е. C, C++, D и т.д. Полученный проект собирайте emscripten-ом в asm.js-овый бандл, предварительно включив LTO и IPO. Проследите, чтобы у вас не было именованных экспортов.
+ будет работать намного (на порядок) быстрее, чем типичная реализация руками непосредственно в JS;
+ исходник будет крайне сложен для анализа, без довольно специфичного опыта реверс-инжениринга выхлопа кодогенератора биткода LLVM не обойтись;
+ внутреннее состояние игры раскрывается, но зачастую не в той мере, чтобы позволить модификацию;
– вы все равно зависите от браузера в том, чтобы доставить ваши данные к серверу
2. Используйте ECDSA и подписывайте состояния объектов, а потом в случайные моменты проверяйте правильность подписей. Можно скомбинировать с кодом Рида-Соломона, чтобы словить модификацию подписей или содержимого и потом уже придумать, что делать.
+ может обмануть читера, если он первым делом полезет менять память, а уже потом запоздало подумает
– накладно с точки зрения производительности
– трудно реализовать правильно
3. Как вариант, вместо предыдущего пункта — шифруйте все состояние в памяти чем-то типа AES128CTR, чтобы иметь возможность параллельной расшифровки блоков.
+ читеру придется писать декриптор
+ возможно, придется лезть в дебри реализации asm.js JIT и вставлять туда свои заглушки, чтобы дампить расшифрованную память
+ ключ можно генерировать на ходу
– сгенерированный ключ придется хранить открытым текстом
– будет работать медленно. возможно, имеет смысл шифровать не всю память вообще, а какой-то отдельный объект, или перемежать шифрованные и нешифрованные блоки
– нужно будет писать свой препроцессор, потому что любые обращения к памяти нужно будет обернуть в криптор;
4. Используйте secure web socket-ы для связи с сервером.
+ сложнее отследить и перехватить
+ сложнее модифицировать
– может не работать по ряду причин — файрвол, прокси, настройки приватности, оргия сатанинских котят, запрет SSL
5. Деструктуризируйте графику. Если рисуете плоские объекты, не используйте DOM, рисуйте сразу на <canvas>. Если используется векторная графика, разверните все SVG-группы, пусть сцена будет просто одноуровневой мешаниной безье-кривых, а группировку держите у себя в памяти. Если используете объемную графику, рисуйте прямыми вызовами WebGL.
+ для отслеживания состояния придется анализировать картинку
+ emscripten дает эти плюшки из коробки
– обновление групп объектов будет менее эффективным
Эти приемы позволят усложнить анализ и корректировку поведения программы в свою пользу, но ни один не поможет со 100% уверенностью. Просто при приеме заказа на «невзламываемую игру», уведомите заказчика, что полностью от взломщиков защититься невозможно даже теоретически, но даже пункт №1 из моего списка позволит вам отсечь 99% «казуальных читеров» с минимальными затратами и ощутимыми профитами, а вот стоит ли игра свеч, чтобы бодаться с оставшимся 1% — решать заказчику.
Достаточно древний пример того, как выглядят 3D-приложения после emscripten.
Огромное спасибо за подробный ответ! Правда это выглядит на порядки сложнее, чем мы умеем сейчас. Но! Знать перспективное направление в решении проблемы — уже мотивирует копать.
Вот, кстати, идея. Дать нечестному игроку ощущение что игра уже взломана и ничего делать больше не нужно. :)
Я думаю что при наличии существенного по цене приза даже все проделанное Вами не поможет
Проблема в том, что бота можно написать, он может даже как человек кликать и давить на кнопки. Сам я писал такого бота для флеш игры, где надо было запоминать порядок зажигания цветных элементов и повторять последовательность. Спокойно ставил его играть на ночь и к утру он неспеша накликивал топовый результат. Обвинить меня в нечестности в принципе очень сложно, если бы захотел — смог бы сделать и случайные интервалы и координаты и все что угодно. Написать бота было несложно, пару вечеров и все. Видел недавно похожего бота на OpenCV.
Тоже самое в волхаком на десктопе — его может вычислить только человек и то с определенной статистикой на руках и опытом, программно его не выщемить.
Тоже самое в волхаком на десктопе — его может вычислить только человек и то с определенной статистикой на руках и опытом, программно его не выщемить.
Не обязательно использовать тяжелую артиллерию в виде OpenCV, для многих простых игр проще написать скрипт за 5 минут с помощью Sikuli
По-моему, тут имеет место гонка средств нападения и защиты, соответственно нужно не столько защищаться, сколько распознавать и классифицировать новые схемы(соответственно, не столько нападать, сколько скрывать механизм нападения).
Ситуация аналогична гонке вирусов и антивирусников:
В: исполнить код
А: помешать исполнить код
В: исполнить код
А: распознать В
В: скрыть себя от А
А: исполнить В в песочнице
В: сделать использование песочницы ресурсоемким(proof-of-work)
А: исполнить В в песочнице
В: детектировать песочницу
А: обмануть детектор песочницы В
Два последних пункта повторяясь должны привести к появлению песочницы, неотличимой от реальности, в которой В рано или поздно себя выдаст, но
В: может притвориться, что был обманут его детектор песочницы
А: может притвориться, что не заметил притворства В
Следовательно, В продолжает работу даже после того, как А его распознает, и даже после того, как узнает, что его распознали… И только ресурсоемкость может заставить А остановить песочницу с В. В же с одной стороны выгодно работать в песочнице: на него тратятся ресурсы А, с другой: выгодно только если знать, в песочнице он или нет, потому как если В будет действовать одинаково, то выдаст свои методы и цель.
На клиенте можно заменить в приведенных выше рассуждениях вирус на игру, а антивирусник на бота(сторона, контролирующая среду исполнения), на сервере наоборот.
То есть проблема в общем виде неразрешима, поскольку аналогична тесту Тьюринга (агента) и детектированию виртуальности(среды): сервер не может распознать бота выше некоторого уровня, но и бот не может знать был ли он распознан, поскольку не знает уровня сервера.
Но поскольку имеем дело с гонкой, то есть опережающая и отстающая сторона.
Ситуация аналогична гонке вирусов и антивирусников:
В: исполнить код
А: помешать исполнить код
В: исполнить код
А: распознать В
В: скрыть себя от А
А: исполнить В в песочнице
В: сделать использование песочницы ресурсоемким(proof-of-work)
А: исполнить В в песочнице
В: детектировать песочницу
А: обмануть детектор песочницы В
Два последних пункта повторяясь должны привести к появлению песочницы, неотличимой от реальности, в которой В рано или поздно себя выдаст, но
В: может притвориться, что был обманут его детектор песочницы
А: может притвориться, что не заметил притворства В
Следовательно, В продолжает работу даже после того, как А его распознает, и даже после того, как узнает, что его распознали… И только ресурсоемкость может заставить А остановить песочницу с В. В же с одной стороны выгодно работать в песочнице: на него тратятся ресурсы А, с другой: выгодно только если знать, в песочнице он или нет, потому как если В будет действовать одинаково, то выдаст свои методы и цель.
На клиенте можно заменить в приведенных выше рассуждениях вирус на игру, а антивирусник на бота(сторона, контролирующая среду исполнения), на сервере наоборот.
То есть проблема в общем виде неразрешима, поскольку аналогична тесту Тьюринга (агента) и детектированию виртуальности(среды): сервер не может распознать бота выше некоторого уровня, но и бот не может знать был ли он распознан, поскольку не знает уровня сервера.
Но поскольку имеем дело с гонкой, то есть опережающая и отстающая сторона.
Если все дело в глобальных результатах и призе, то проблему вовсе не обязательно решать так основательно на мой взгляд. Можно же просто сделать запись реплеев и возможность их воспроизведения. Никакой автоматизации или чего то подобного не нужно. Просто с каждым результатом на сервер присылается файл реплея и хранится. Пользователю показывается его результат сразу, но в глобальной таблице рекордов висит надпись «Обновляется раз в пару дней». И раз в пару дней специальный человек берет лучшие 10 игр и просматривает их реплеи. Если в них все хорошо — заносит их в глобальный лидерборд.
Конечно, такой подход подразумевает, что в глобальном лидерборде будут только 10(или 100) человек отображаться, а не все, но так ли это страшно? В конце концов можно показывать помимо главного лидерборда и, к примеру, «среди друзей» без модерации да и просто свой счет без модерации. Самое интересное в таком подходе то, что игрок сразу видит и понимает, что результат модерируется, а значит и желания взломать будет намного меньше и хакеров будет очень мало.
Да и по поводу ботов — их неуловить. Если взломали протокол или игру — это одно, но если имитируют человека, то это уже очень сложно доказать будет, что это был не человек. Прошел с первого раза? Я на аккаунте друга тренировался! Идеально кликает раз в 33 мс? Я в этом не виноват, презумпция невиновности, все дела. Да и бот скорее всего будет кликать с рандомом. Но если уж очень хочется ловить в том числе и ботов, то описанный способ как никакой другой подходит и для этого. Просмотр реплея вручную может дать очень много и бота придется писать очень сложного, при этом хакеру такой писать не захочется — он же не знает как происходит модерация, но знает, что она есть. Тратить неделю на супер бота при большом риске не пройти модерацию не захочет даже опытный хакер.
Конечно, такой подход подразумевает, что в глобальном лидерборде будут только 10(или 100) человек отображаться, а не все, но так ли это страшно? В конце концов можно показывать помимо главного лидерборда и, к примеру, «среди друзей» без модерации да и просто свой счет без модерации. Самое интересное в таком подходе то, что игрок сразу видит и понимает, что результат модерируется, а значит и желания взломать будет намного меньше и хакеров будет очень мало.
Да и по поводу ботов — их неуловить. Если взломали протокол или игру — это одно, но если имитируют человека, то это уже очень сложно доказать будет, что это был не человек. Прошел с первого раза? Я на аккаунте друга тренировался! Идеально кликает раз в 33 мс? Я в этом не виноват, презумпция невиновности, все дела. Да и бот скорее всего будет кликать с рандомом. Но если уж очень хочется ловить в том числе и ботов, то описанный способ как никакой другой подходит и для этого. Просмотр реплея вручную может дать очень много и бота придется писать очень сложного, при этом хакеру такой писать не захочется — он же не знает как происходит модерация, но знает, что она есть. Тратить неделю на супер бота при большом риске не пройти модерацию не захочет даже опытный хакер.
>> Тратить неделю на супер бота при большом риске не пройти модерацию не захочет даже опытный хакер.
По этому вопросу есть иное мнение:
— Голубчики, — сказал Фёдор Симеонович озабоченно, разобравшись в почерках. — Это же проблема Бен Бецалеля. Калиостро же доказал, что она не имеет решения.
— Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетиниваясь. — Мы хотим знать, как её решать.
— Как-то странно ты рассуждаешь, Кристо… Как же искать решение, когда его нет? Бессмыслица какая-то…
— Извини, Теодор, но это ты очень странно рассуждаешь. Бессмыслица — искать решение, если оно и так есть. Речь идёт о том, как поступать с задачей, которая решения не имеет. Это глубоко принципиальный вопрос…
© Стругацкие.
По этому вопросу есть иное мнение:
— Голубчики, — сказал Фёдор Симеонович озабоченно, разобравшись в почерках. — Это же проблема Бен Бецалеля. Калиостро же доказал, что она не имеет решения.
— Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетиниваясь. — Мы хотим знать, как её решать.
— Как-то странно ты рассуждаешь, Кристо… Как же искать решение, когда его нет? Бессмыслица какая-то…
— Извини, Теодор, но это ты очень странно рассуждаешь. Бессмыслица — искать решение, если оно и так есть. Речь идёт о том, как поступать с задачей, которая решения не имеет. Это глубоко принципиальный вопрос…
© Стругацкие.
Потому что мы надеемся, что она станет началом продуктивной дискуссии о том, как разработчики браузерных игр могут противостоять кибер-мошенникам.
Мне не очень нравится определение «кибер-мошенник». Я например считаю логичным, что человек должен использоваться свои сильные стороны. У кого-то есть отличная реакция, у кого-то сутки свободного времени, а я предпочитаю использовать ум.
Защиту от хаков сделать не так уж и сложно. Уже упомянутый вами эмулятор, полное недоверие к получаемым данным, грамотный серверсайд-код — дефолтные практики в этом деле.
Защиту от ботов сделать невозможно в принципе, можно лишь усложнить разработку. В конечном счете затраченные усилия должны окупаться, хотя это уже зависит от разработчика бота.
Из необычны могу вспомнить небольшую флеш-игру, которую мэйловцы делали, когда разыгрывали ключи раннего доступа к Archeage. Игрок видел N одинаковых статуй и должен был выбирать «правильную» для получения очков. Когда я посмотрел код я обнаружил, что при нажатии на сервере банально кидается рандом независимо от статуи на которую ты кликал, создавая иллюзию выбора. Это конечно не помешало создавать сотни аккаунтов и «брутфорсить», но тем не менее «иллюзия управления» очень меня удивила, т.к. игрок действительно считал что его выбор значим.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Защита от накруток в онлайн играх