LINUX.ORG.RU

«Три в ряд» с античитом

 ,


0

1

Предупреждаю, мне хочется очень странного.

Я хочу алгоритм генерации поля «три в ряд» (как начального состояния, так и заполнения новыми фишками, когда игрок сделал ход). На игровом поле есть обычные фишки и есть бонусы. Игрок получает отдельный очки за удаление обычных фишек и за удаление бонусов. Важна именно сумма собранных бонусов, очки за обычные фишки не принципиальны.

При этом алгоритм генерации должен быть особым. А именно: вначале игры с сервера получается некий seed поля (это может быть что-угодно, хоть один Long, хоть несколько килобайт данных) и затем используется. При этом сервер заранее знает, сколько максимум можно собрать бонусов на поле за всю партию (есть ограничение по времени, а зная длительности анимаций ходов, можно пересчитать это и в ограничение по ходам за партию). Например, он сначала генерирует количество бонусов, а уже потом создаёт seed из него.

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

При этом клиент не должен иметь возможности (должно быть вычислительно сложной задачей) по seed алгоритмически вычислить минимальное и максимальное число очков. Нужно по-честному играть.

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

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

Короче, надо защититься от потенциального читерства а-ля «расковыряли API и просто спамим сервер запросами о том, что набрали максимум бонусов».

Возможно ли такое хотя бы теоретически? В какую сторону копать?

★★★★★

Короче, надо защититься от потенциального читерства а-ля «расковыряли API и просто спамим сервер запросами о том, что набрали максимум бонусов».

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

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

neumond
()

Кажется, все эти заморочки с минимально и максимально возможным — лишние. Просто отправляешь информацию обо всех ходах (это ж совсем не много, в один пакет влезет небось) и валидируешь на сервере их возможность. Если хочется ещё лучше защититься — помимо самих ходов (номер «фишки» и 1 из 4 направлений) можно отправлять ещё и время каждого в милисекундах от начала игры — будет намного больше объём (но всё ещё считанные килобайты), но зато можно сверять расстояние по времени между ходами, не меньше ли оно теоретически возможного для человеческого пальца.

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

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)

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

Просто как палка, всё всем видно, можно это даже не скрывать, но контролишь всё ты получается. :)

В любом случае 100% защиты быть не может, так как твоя программа у него есть и он её может на атомы разобрать, можно просто обновлениями ломать читы. Просто запутывая каждый раз некую логику по разному, пусть пердоляться каждый раз как первый.

Это конечно просто мысли в слух.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Тебе известен бианрник у пользователя, ксорь sed значение телом бинаря, расксоривай на клиенте.

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

Просто как палка, всё всем видно, можно это даже не скрывать, но контролишь всё ты получается.

Не… Это работает как раз только если скрывать. До тех пор, пока не допетрят, что к чему.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)

При этом клиент не должен иметь возможности (должно быть вычислительно сложной задачей) по seed алгоритмически вычислить минимальное и максимальное число очков

Пока это возможно в игре, это возможно вычислить. Расковырять как генерится поле по seed, для начала. Потом играючи обходить всё что ты не придумаешь чтобы это предотвратить. А в конце можно просто написать неотслеживаемого бота играющего идеально.

Нужно по-честному играть.

Использовать голову чтобы получить преимущество в игре - это более чем честно.

Короче, надо защититься от потенциального читерства а-ля «расковыряли API и просто спамим сервер запросами о том, что набрали максимум бонусов».

А зачем от него защищаться? У тебя там глобальный рейтинг ведётся? Ну я буду спамить запросами о том что набрал сколько набрало первое место +1.

anonymous
()
Ответ на: комментарий от anonymous

У тебя там глобальный рейтинг ведётся?

Да, в игре есть соревновательный момент. За «три в ряд» дают монетки, на них покупаешь ништяки в основной айдл игре, а уже результаты там доступны в глобальном рейтинге.

Если кто-то напишет бота, чтобы афк фармить монетки 24 часа в сутках, это убьёт интерес остальных игроков, потому что нормальный человек не будет столько играть. А должно быть интересно среднему человеку.

KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от KivApple

Если кто-то напишет бота, чтобы афк фармить монетки 24 часа в сутках, это убьёт интерес остальных игроков, потому что нормальный человек не будет столько играть. А должно быть интересно среднему человеку.

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

А должно быть интересно среднему человеку.

Рейтинги в играх для «средних людей» никому не интересны, они нужны только чтобы заставить больше времени в игре проводить и/или донатить. Это бесчеловечно.

Так вот вопрос - у тебя бесчеловечная игра? Если да, то убить к ней интерес - это именно то чего она достойна. А иначе просто выкинь нафиг этот рейтинг, и пусть пользователи что хотят творят. Сохранять интерес можно кучей способов - например, новым контентом. См. Farm RPG как пример.

anonymous
()

Ты всё сделал максимально не так, как надо. Подобная наивность у игроделов была разве что в 90-е и раньше. Клиент не должен слать только результат, он должен слать все клики юзера (в реальном времени, а не задним числом), а сервер должен присылать команды что рисовать на экране. Только так, и никак иначе, любые оффлайн расчёты будут взломаны и проэксплуатированы в поьзу читера.И ни seed, ни алгоритм рисования поля из seed-а клиент знать не должен, сервер должен ему присылать только те (и не больше!) данные, которые нужны для отрисовки текущей игровой ситуации.

И даже несмотря на всё вышеперечисленное, читеры всё равно будут. Но это уже другая тема (не взлом алгоритма а костыли к игроку), не будем о ней.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

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


Моя идея была:

Например, можно обеспечить это дорогим алгоритмом регенерации поля после хода.

Например так:

  • регенерируемые фишки зависят от первых k ходов игрока. Условно сид генерации на ходу n = sha256(сид карты | ходы игрока 1..min(k, n-1) ).
  • серверу при генерации придется перебирать всё дерево чтобы найти мин и макс. бонусы, но для него получить сид генерации не проблема так что он переберет легко.
  • а вот клиенту он вместо сида карты отправит зашифрованные() сиды для всех вариантов первых k ходов игрока. Тут правда вопрос в том на сколько k хватит нескольких килобайт разрешенных в условии, но если у игрока 3-4 варианта хода то k = 4 или 5 можно обеспечить. Соответственно задача сводится к тому чтобы () - зашифровать число так чтобы шифровалось оно быстро, а для его расшифровки требовалась ~1секунда. Тогда легальному клиенту придется расшифровать только k вариантов, а читеру придется для перебора расшифровать 3**k вариантов (но не больше чем влезет в сид, а это всего несколько тысяч).
kipar_2024
()
Последнее исправление: kipar_2024 (всего исправлений: 1)
  1. Play Integrity / App Attest, на ненадежных платформах - не запускаемся, используем упаковщики для затруднения реверса
  2. TLS Certificate Pinning, и дополнительно внутри TLS можно использовать обфусцированный слой шифрования на уровне API
anonymous
()
Ответ на: комментарий от opcode

У Android слишком разная производительность между разными устройствами. Ну а ещё приложения майнящие на самих смартфонах запрещены правилами Google Play.

KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от KivApple

Остаётся.. капча, да и её эффективность под вопросом.😊

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

opcode
()

При этом клиент не должен иметь возможности (должно быть вычислительно сложной задачей) по seed алгоритмически вычислить минимальное и максимальное число очков.

Можно сделать чтобы клиенту нужно было как в блокчейнах найти подходящую соль для перехода к следующему состоянию после хода. А на сервере потом будет дешево проверить что игра была проведена с генерацией по алгоритму.

anonymous
()
Ответ на: комментарий от anonymous

Почему онлайн-only? Можно и оффлайн - но без попыток изображать мультиплеерные рейтинги.

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

Либо честный оффлайн без рейтингов, либо обязательные подробные отчёты в реальном времени.

С пингом придётся мириться, других вариантов нет.

firkax ★★★★★
()
Ответ на: комментарий от anonymous

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от KivApple

Производительность андроида не важна, вычисления можно проводить хоть на суперкомпьютере. Достоверно проверить что клиент - настоящее андроид-устройство и что он не занимается распределёнными вычислениями, невозможно.

firkax ★★★★★
()