Як я можу запобігти помилковим звітам про бали до глобальних таблиць рейтингів?

У браузерних та мобільних іграх зазвичай є глобальні таблиці рейтингу. Також у цих таблицях є загальна кількість 2,147,483,647 - де люди з'ясували дзвінок веб-сервісу, який повідомляє про бали, і використовували його для фіктивного рахунку.

У простих іграх-головоломках ми можемо захищатись від цього, включаючи запис про кожен хід гравця (та будь-які випадкові насіння, які використовуються для генерування рівня) із закликом звітності за рахунком. Після цього всю гру можна відтворити та перевірити на сервері.

Однак це швидко стає нездійсненним для чогось більшого, ніж людина Пак.

Як ще можна запобігти обману подібного роду?

Внутрішня система, яку ми використовували для Moblox (пізніше замінена OpenFeint), працювала так:

• Надішліть повідомлення JSON через звичайний HTTP (не HTTPS). Включіть хеш-код MD5 усіх полів плюс чарівний рядок.
• На сервері перевірте цілісність повідомлення тією ж операцією.

Щоб зламати систему, вам доведеться знайти цю магічну струну. Це можливо при зворотній техніці, але болісно.

Усі OpenFeint, ScoreLoop та CocosLive використовують один і той же трюк, але з HTTPS. Дуже простий у виконанні.

Хоча ви маєте рацію, що не завжди можливо відправити цілі повтори на сервер для складних ігор, подібну систему можна використовувати, якщо сервер періодично (і напіввипадково) запитувати клієнта про якусь частину свого стану, тоді як гра працює.

Наприклад, у FPS щохвилини ви могли запитати "Скільки вбивств у вас?", "Де всі вороги?" І т. Д. Якщо клієнт не повернеться з розумною відповіддю на виклик у розумна кількість часу, вони обманюють.

Звичайно, це працює лише в тому випадку, якщо гра знаходиться в режимі онлайн протягом усього сеансу гри. Оскільки мета полягає в тому, щоб мати можливість завантажувати в онлайн-лідери, я вважаю, що це розумно - не виганяйте гравця з гри, якщо він відповість неправильно, просто не дозволяйте їх у списку очок.

Я б радив вам переглянути розсилку повторів. Все, що вам дійсно потрібно, - це початкове випадкове насіння та вкладення часу. Це дійсно має бути не більше кількох сотень КБ. Багато аркадних ігор вже роблять це, щоб зберегти повтори для цілей перегляду гравців; підтвердження того, що ваш сервер перевірив, це може бути нетривіальним, але це запобігає всіляким обманам, крім боттування.

Ви можете обмежити найбільш грубі зловживання, відстежуючи найвищі результати в таблиці найкращих результатів. Залежно від вашої гри, у вас може бути "ідеальний рахунок", над яким будь-який рахунок повинен бути шахрайським. Якщо ні, ви можете розрахувати найнижчий "неможливий бал". чи може гравець робити 10 пострілів в секунду, гра триває 1 хвилину, а кожен вбитий ворог коштує 100 очок? Тоді будь-яка оцінка, що перевищує 60 000, повинна бути шахрайською.

Ви також можете допомогти усунути проблему, надіславши деякі метадані; не повна історія ігор, як ви описуєте, а лише компоненти, що складають рахунок. Скажіть: забийте 60000, 500 ворогів вбито, і один бонусний предмет схопили. Потім можна виконати прості перевірки. Це "безпека через незрозумілість", а отже, зовсім не безпечна, але вона допомагає усунути найбільш наївних зловмисників.

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

В іншому випадку вам доведеться покладатися на методи обфускування (наприклад, шифрування та надсилання інших статистичних даних, що перевищують лише результат).

Ви також можете періодично надсилати рахунок під час гри, що додасть ще один рівень складності обману - тобто сервер може вирішити, чи гра проводиться досить довго, щоб гарантувати певний рахунок, а також забезпечити достатню кількість проміжних звітів були отримані під час ігрового часу (просто не робіть це на 100%, або поїзд, який їде в тунель по дорозі додому, призведе до того, що я викину телефон у вікно).

Зрештою хтось знайде спосіб зламати це, хоча не вбивайте себе, намагаючись зупинити їх.

Я додав швидку / брудну таблицю з високою оцінкою в проект мого часу назад, і зовсім не розбирався в безпеці в Інтернеті / і т. Д., Виявилося, це дефект. Дивно, але майже 1200 мільйонів зафіксованих балів у мене було лише 5 чи 6 випадків, коли партії явно неправильних оцінок досягли вершини дошки. Більшість балів навіть більше виглядали як глюк у грі, ніж справжнє "хакерство".

Отже, я думаю, важливим моментом є: переконайтесь, що система балів вашої гри герметична , або, принаймні, зробіть перевірку техніко-економічного обгрунтування; Тепер ця гра, про яку я говорю, була записом Ludum Dare 48hr, тому це було не найстабільніше навколо .. але в цілому, я думаю, що часто більш імовірно, що випадковий гравець виявить / використає глюк інга, ніж мати когось безпосередньо "зламати" таблицю лідерів.

Це сказало, що я зараз працюю над переписанням цього проекту, і я все закінчую з придумкою. Я не буду надто детально описуватись, але в основному всі бали подають ключове значення, що базується на купі випадкових значень і хешування, і магічній рядку, то будь-який бал, який проходить цю перевірку і достатньо високий, щоб зробити фактичним " Таблиця лідерів Top X "повинна пройти ще один раунд валідації (на цей раз із закінчуючим значенням ключа, сформованим на кінці сервера, і більш ретельними перевірками виконання).

Я б також радив використовувати якийсь інструмент для пошуку пакетів, щоб перевірити, які речі видимі (я спочатку робив набагато простішу перевірку, яка означала, що хтось може використовувати трекер пакетів, щоб знайти та дублювати запит на завантажений рахунок, не знаючи чарівна струна чи що завгодно (означало, що вам спочатку потрібен законний бал, але ви можете надсилати дублікати цього рахунку стільки, скільки хочете ..)). Я використовував Wireshark для перевірки цього.

Так, це вийшло трохи довго, але, сподіваємось, це допомагає ...

Я не фахівець у цій галузі, але якби я був на вас, я спробую зашифрувати рахунок за допомогою ключа, вбудованого у ваш код. Цим людям потрібно буде застосувати зворотну інженерію над вашим кодом замість простого тексту, який використовується для веб-служб.

Speedruns - це в основному запис кожного натискання клавіш, і вони записують про ЦІЛУ гру. Отже, так, ви можете записати всю гру, це неможливо. Будь-який інший спосіб зробити це неможливо за допомогою зворотного проектування (я не можу наголосити на цьому достатньо: ви не додаєте безпеки, ви додаєте неясність).

Тим не менш, навіть якщо ви зробите це так, вони насправді могли б подати speedrun. Ви нічого не можете зробити для того, щоб запобігти цьому.

Поки ви перебуваєте на цьому, виникає питання, чи високий бал - це просто гравець, який знайшов подвиг (наприклад, якщо деякі речі в грі дають штрафний штраф, а помилка спричиняє негативну оцінку "обернутись" щоб стати дуже позитивним ... або просто гравцем, який знаходить певний ігровий стан, як безпечне місце на дошці, де вони можуть просто сидіти там і не повинні турбуватися про втрату, на невизначений час).

Щоб визначити різницю між хаком та ігровим експлуатом, було б добре завантажувати хоча б деякі дані про гру. Це допоможе вам принаймні виправити подвиги.

Для деяких ігор (особливо покрокових), ви можете насправді проводити гру через сервер, де вся логіка гри існує на стороні сервера, а клієнт - це лише інтерфейс. Це не тільки ускладнює злому результатів, але й дозволяє тривіально реєструвати всі дії гравця на сервері і, таким чином, відтворювати будь-яку гру в будь-який час. Я усвідомлюю, що для щось подібне до шутерських дій, це може бути недоцільно.

Зробіть усі випадкові походження з одного насіння та зберігайте вхід для кожного кадру. Щоразу, коли у вас є високий рейтинг (наприклад, топ-50), надсилайте насіння та повний внесок на сервер. Повторіть гру на сервері та оновіть таблицю лідерів, якщо отримаєте високий бал.

Якщо ви вважаєте це нездійсненним для більш складних ігор через розмір запиту, подивіться на цей приклад.

Скажімо, у грі є 8 вхідних кнопок (1 клавіатура та 4 кнопки) та працює в 60 кадрів в секунду. Один годинний вхід гри може передаватися з 3,6 КБ без стиснення. На ваш сеанс, ймовірно, буде менше однієї години, і стиснення має зменшитись на багато, тому що людський внесок має багато надмірності.

Завдання полягає в тому, щоб зробити гру детермінованою, відтворюваною зі записаного вводу та виконуваним на сервері.

Ніколи цього не реалізовували, але ...

Посилайте оцінки поступово за допомогою міток часу. Це дає вам журнал, щоб побачити, як часто покращується оцінка, а також спосіб простежити "імпульс" рейтингу.

Потім ви встановите основні етапи / критерії для своїх результатів.

Наприклад: Оцінка, що перевищує 20 000, не може досягти перших 20 секунд гри. Оцінка, більша за 250 000, не може дійти без запису, що перевищує 200 000.

Це не точно так само, як надсилання ігрового стану, але близьке до нього.

Побічна вигода: Подумайте про всю корисну статистику гри, яку ви отримаєте від цього. Хтось хотів би за це заплатити хороші гроші.