Боротьба з читерами в онлайн-іграх: 22 «треба» і «не можна»

image

Майже неможливо знайти успішну багатокористувацьку онлайн-гру (крім тих, які грають тільки друзі розробника), в якій немає читеров. Іншими словами, якщо у вашої публічної грі немає читеров, вона або недостатньо популярна, або розпізнавання шахраїв працює не дуже добре. У всіх інших випадках вам доведеться мати справу з чітерство. Вивчіть список кроків, які ПОТРІБНО і МОЖНА робити (докладне обговорення теми чітерства наведено в моїй тритомної книги, див. примітку в кінці статті) при боротьбі з шахрайством в іграх.

1. Додайте в умови використання своє право блокувати читеров
Потрібно не просто додати це право, але і вказати, що такі рішення приймаються «на власний розсуд». Проте тут можуть виникнути труднощі:

  • Примітка: я не юрист, і цю статтю не потрібно вважати юридичною радою. Краще проконсультуйтеся зі своїм юристом.
  • Це складна юридична проблема, вирішення якої залежить від країни або території перебування. НЕ приймайте рішень з цього питання самостійно, дізнайтеся у юриста (краще, щоб він був з вашої країни), чи будуть ваші умови використання вважатися дійсним договором у суді. На GDC 2016 я розмовляв з людиною з однієї великої компанії. Найбільшою складністю для них були юридичні проблеми з баном виявлених читеров.
  • Сенс тут простий — мати можливість банити гравців, якщо вони жульничают. Однак потрібно сформулювати умови використання таким чином, щоб було ясно, що вам не потрібно доводити факт шахрайства в суді, інакше переслідування читеров стає занадто дорогою справою. Найважливіший юридичний питання тут в «тягаря доведення» — ви повинні доводити, що чітери шахраюють, або звинувачені чітери повинні доводити свою невинність. Як ви розумієте, останнім набагато вигідніше для вас і гірше для читеров. Я вже згадав вище, що один із можливих способів вирішення цієї проблеми — вставка застереження «такі рішення приймаються на наш власний розсуд». Однак потрібно обов'язково перевірити дійсність такого застереження у відповідній юрисдикції.
  • Якщо це можливо, краще всього мати можливість блокування гравців без повернення коштів, щоб шахраювати було невигідно. Але якщо це неможливо, то блокування з поверненням грошей НАБАГАТО краще, ніж неможливість блокувати читеров взагалі.
  • НЕ дуже хвилюйтеся про скарги гравців на такі формулювання в умовах використання. Більшість гравців все одно не читає умови, і при порівнянні умов різних ігор вони все одно мало відрізняються один від одного для широкої публіки. Проте НЕ намагайтеся зловживати цим формулюванням, інакше у вас дуже швидко виникнуть проблеми.
2. Якщо ви використовуєте движок захисту стороннього виробника, ПОТРІБНО додати поверх нього якомога більше свого захисту (або, що ще краще, об'єднати сторонню і захист)
Звичайно, сторонні розробники движків захисту часто знають, що роблять, але в умовах зламу систем з принципом security-by-obscurity такі движки стають мішенню для всього хакерського співтовариства. Тому додавання захисту зверху значно покращує ваше положення.

3. ПОТРІБНО боротися з читерами з самого початку
Як тільки з'явиться співтовариство читеров, що роблять гроші на продажу читів до вашої гри, будь-яка дія з вашої сторони буде викликати ЗНАЧНО більший опір. Іншими словами, не МОЖНА годувати читеров.

4. ПОТРІБНО використовувати повноважний сервер
Це дійсно дуже важливо. Більше того, ПОТРІБНО перемістити всю логіку на сервер. В ідеальній ситуації в клієнті взагалі не повинно прийматися рішень. Оскільки це не завжди можливо на 100% (в основному тому, що ігри мають дуже високий темп) ПОТРІБНО боротися проти кожного рішення, що приймається в клієнті. Чим більше розрахунків виконується у клієнта, тим більше можливостей у атакуючого. Якщо ви не будете агресивно переносити все на внутрішню сторону, це поступово стане Дуже Великою Проблемою (я стикався з цим, і по такій темі було один доповідь на GDC 2016).

Не МОЖНА дотримуватися deterministic-lockstep архітектур (в яких синхронізація відбувається тільки відправкою даних введення). Хоча ігри з deterministic-lockstep архітектурою менше страждають від рішень, що виконуються на стороні клієнта, вони досить уразливі до атак витоку інформації (таких як Wallhack і Maphack. См. нижче пункт про те, як обмежити клієнт тільки необхідної для нього інформацією).

5. ПОТРІБНО шифрувати трафік
Шифрування трафіку дозволяє відгородитися від кількох типів атак, в тому числі на основі проксі (з якими майже неможливо впоратися) і деяких типів ботів.

Зауваження в зв'язку з цим:

  • Ні, використання UDP не є виправданням відсутності шифрування трафіку. Тут на допомогу приходить DTLS і деякі інші протоколи.
  • ПОТРІБНО прив'язувати бібліотеки OpenSSL статично. OpenSSL.DLL (або будь-яка інша реалізація шифрування через DLL) надає атакуючому гарантований спосіб обходу шифрування.
  • не МОЖНА використовувати анонімний протокол Діффі-Хелмана (Anonymous Diffie-Hellman, ADH). Так, про це написано в кожній книзі, але все ще знаходяться ігри, в яких розробники застосовують його (як мінімум одна гра навіть згадала ADH у вікні About!).
  • ПОТРІБНО перевіряти збережений кореневий сертифікат на стороні клієнта (так, деякі розробники цього досі не роблять).
  • не МОЖНА використовувати сертифікат з машини користувача. Замість цього створіть свій центр сертифікації і вбудуйте кореневий сертифікат в клієнт (інакше підвищується ймовірність MITM-атак).
  • Обфусцируйте кореневий сертифікат у виконуваних файлах клієнта, інакше піддастеся іншого типу MITM-атак.
6. ПОТРІБНО відстежувати публічно доступні і платні чити
Знаходите їх, аналізуйте і випускайте виправлення як можна раніше. Якщо гра досить успішною, варто виділити для цього окрему команду.

Не забувайте при аналізі читів наступні принципи:

Очевидно, що чим популярніше чит, тим вище повинен бути в списку виправлень.

  • Що ще більш очевидно, не МОЖНА запускати чити всередині власної мережі (інакше виповниться мрія дуже багатьох читеров). Замість цього створіть надійно огороджений файрволом «пісочницю» (в ідеалі — в окремому місці, не має VPN між внутрішньою мережею і «пісочницею»).
7. Не МОЖНА наймати відомих читеров

Насправді у цього правила є винятки. По-перше, воно не стосується white hat-хакерів. По-друге, МОЖЕ бути прийнятно найняти відомих читеров, з дотриманням ВСІХ наступних умов:

  • У них НЕ буде спеціального доступу до «нутрощів» програми (особливо до вихідного коду)
  • Вони повинні займатися ТІЛЬКИ «black-box-зломом» (якими вони і так би зайнялися). Єдина різниця в тому, що вони повідомлятимуть про результати злому, а не використовувати його.
  • Всю зв'язок з найнятими читерами ПОТРІБНО вести з окремою облікового запису електронної пошти (повністю ізольованою від решти частини системи).
  • Доступ до всієї інформації з цієї окремої облікового запису ПОВИНЕН бути тільки всередині «пісочниці», налаштованої для аналізу читерских програм
8. ПОТРІБНО думати про політику блокувань
Чи ви Будете банити читеров навічно, або всього на кілька днів? А як щодо рецидивістів (на GDC 2016 говорили, що 72% читеров знову пробують шахраювати)? Яка у вас є захист від читеров, відкривають нову обліковий запис (підказка: у F2P-іграх на ПК така захист майже відсутній)?

9. Перевірене правило: не МОЖНА покладатися на гравців у скаргах на шахрайство
Крім того, не МОЖНА заохочувати гравців скаржитися на читеров. Вони в кожному разі будуть скаржитися на те, що вважатимуть за чітерство, але підштовхування до скарг може легко перетворити досить велика кількість гравців у параноїків. Хоча в деяких випадках блокування голосуванням МОЖЕ бути необхідною, дозвіл гравцям викидати супротивників рідко буває гарною ідеєю.

З іншого боку, ПОТРІБНО сприймати скарги про читерстве серйозно і вручну переглядати інформацію в таких звітах. Для цього ПОТРІБНА окрема команда, якщо гра успішна. І вам ПОТРІБНО зібрати достатню інформацію (статистичну та іншу) для виконання такого аналізу. ПОТРІБНО зберігати таку інформацію в базі даних і додавати звіти за запитами античитерской команди.

10. ПОТРІБНО передавати клієнтові тільки необхідну інформацію
Іншими словами, реалізуйте так звану систему «управління інтересами». Будь-які дані у клієнта можуть бути зламані, тому передача конфіденційної інформації, яка не повинна бути публічною — це Дуже Погана Ідея. Якщо не реалізувати управління інтересами, то ви майже гарантовано піддасте гру читам, яке здійснює стіни прозорими (Wallhacks) і прибирають туман війни (Maphacks), а також ESP-читам (дозволяє бачити здоров'я та інші параметри противника).

11. ПОТРІБНО використовувати C++ клієнта
C++ можна зламати, але я зазвичай поділяю «крекінг» і «повномасштабну зворотний розробку». З мого досвіду, хоча програму на C++ можна «крякнути» (тобто можна знайти і відключити обмежений набір перевірок, та знайти та змінити обмежена кількість місць в пам'яті), повномасштабна зворотна розробка для C++ набагато більш складна, ніж для C#/Java (я навіть не кажу про JavaScript без компіляції Emscripten).

Якщо вже ми згадали про це, то треба зауважити, що для цієї мети Emscripten майже так само гарний, як і C++. Зараз я нічим не можу підтвердити свої слова, але судячи з того, що я знаю, все виглядає саме так.

12. НІ В ЯКОМУ РАЗІ не випускайте гру з налагоджувальною інформацією всередині
Потрібно це пояснювати?

13. ПОТРІБНО пройтися по коду і відфільтрувати всі повідомлення про помилки
Тобто вам потрібно позбутися від усіх повідомлень, які не важливі ні для кого, крім вас (якщо ви хочете їх зберегти, то можна завжди замінити їх відповідними хэшами).

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

14. ПОТРІБНО берегти вихідний код життя
Якщо исходники витечуть до хакерам, то 99% обфускации не будуть мати сенсу.

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

15. ПОТРІБНО перевіряти цілісність клієнта (у тому числі ресурсів і/або конфігурації)
Це потрібно виконувати хоча б при запуску клієнта (в ідеалі — і в процесі його роботи, але це вже інша історія).

Також забезпечте відправку звітів на сервер у разі компрометації сервера — якщо це і не чіт, то, безумовно, тривожний сигнал.

16. ПОТРІБНО встановити в клієнті «пастки» для читеров
Ось типові приклади пасток:

  • Одне і те ж значення зберігається двічі в пам'яті клієнта і час від часу перевіряють на рівність. Для ефективності такої пастки потрібно обфусцировать пам'ять хоча б в одному місці зберігання (наприклад, XOR який-небудь константою, хоча можна реалізувати це НАБАГАТО більш складно). Якщо значення не однакові, то це Дуже Тривожний Сигнал, хоча я і проти того, щоб один випадок такого неспівпадання вважався переконливим доказом. Коли у гри мільйон гравців, з деякими з них іноді відбуваються Дуже Дивні Речі.
  • Перевірка цілісності критичних частин коду клієнта і перевірка на наявність підозрілих вбудованих DLL.
  • Вимірювання часу виконання коду для пошуку незвично довгих затримок, що вказують на налагодження клієнта. У цьому випадку цікавим варіантом є інструкція RDTSC x86/x64, тому що вона часто дозволяє вимірювати час навіть при наявності відладчика ядра.
  • Ще один особливий тип пасток — «honey pot». Технічно «honey pot» відрізняється від звичайної пастки в тому, що для чітера створюється штучна мішень.
17. Не МОЖНА повідомляти читеру відразу ж, що ви його спіймали
Замість того, щоб відразу ж блокувати чітера, зазвичай завжди краще відкласти бан. Особисто я не великий шанувальник «хвиль блокувань» і волію випадкові затримки для кожного гравця, але навіть хвилі блокувань НАБАГАТО краще негайних банів.

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

19. Не МОЖНА покладатися ні на які способи ідентифікації комп'ютера
Ви МОЖЕТЕ реалізувати їх, але не забувайте, що ідентифікація комп'ютера обходиться тривіально (і забезпечте, щоб відділи маркетингу/монетизації/бізнес-аналітики теж знали про це, інакше вони будуть покладатися на ідентифікацію для запобігання зловживань рекламою).

20. ПОТРІБНО збирати статистику, яка може бути пов'язана з чітерство
Наприклад, якщо гравець потрапляє в обіймає 5 відсотків тіла центр тяжіння супротивника 95% часу, то можна щось запідозрити.

Залізне правило: статистика НЕ ПОВИННА використовуватися як прямий доказ, це тільки тривожний сигнал. Як з'ясувати, що робити з цим сигналом — окрема історія.

Останнє за порядком, але не за значущістю: не МОЖНА покладатися тільки на статистику, зібрану клієнтом. Іншими словами, збирайте якомога більше статистики на стороні сервера.

21. ПОТРІБНО обдумати CAPTCHA для розпізнавання гриндящих ботів
Один з типів захисту, досить добре працює проти небажаних ботів (зазвичай зайнятих гриндом) — це CAPTCHA. Треба визнати, що вона досить дратує, але я бачив приклади того, як розробник пояснював необхідність CAPTCHA спільноти гравців, і ті визнавали її «необхідним злом», якщо вона перевіряє користувачів тільки зрідка.

Врахуйте, щоб вона працювала, це НЕ ПОВИННА бути CAPTCHA для всіх, її ТРЕБА активувати тільки при спрацьовуванні одного з тривожних сигналів.

22. ПОТРІБНО бути готовими до сканування комп'ютерів гравців на предмет відомого читерского
Це досить суперечливе питання, але швидше треба реалізувати цю функцію, ніж ні. Для більшості ігор сканування комп'ютерів гравців — це НАБАГАТО менше зло, ніж безперешкодне шахрайство (воно руйнує для гравців цікавість процесу, а значить, вбиває вашу гру).

В цілому, реалізація такого сканування дуже складна (вона досить схожа на написання власного антивірусу), так що я дам тут кілька порад:

  • ПОТРІБНО додати умови використання розділ про право на таке сканування.
  • не МОЖНА отримувати будь-яку іншу інформацію, крім необхідної для розпізнавання читів.
  • Якщо ви програєте читерів в цій битві, ПОТРІБНО розглянути варіанти рішень на підставі драйверів пристроїв (підказка: існують такі комерційні продукти)
  • При використанні сканування ПОТРІБНО розпізнавати запуск у віртуальній машині (ВМ часто використовуються для приховування програмного забезпечення, і їх зазвичай ПОТРІБНО вважати тривожним сигналом)
  • ПОТРІБНО розглянути необхідність ДВОХ рівнів розпізнавання. Перший рівень може бути простим розпізнаванням найбільш очевидних і популярних читів, і повинен призводить до дружелюбного повідомленням: «Ти використовуєш дещо, заборонене правилами. Не потрібно цього робити, А НЕ ТЕ...». На другому рівні виконується повномасштабне розпізнавання, що приводить до бану. Задумка тут в тому, щоб зупинити потенційного чітера, поки не буде занадто пізно, по можливості не втративши при цьому гравця. Я бачив приклади того, що такий підхід добре працював у досить великій грі (але тут, як мовиться, немає ніяких гарантій)


Висновок
Звичайно ж, наведений вище список не вичерпний. Якщо ваша успішна гра, вам доведеться самому дізнаватися на цьому шляху щось нове (іноді це дається дуже тяжко). Проте ось найважливіший принцип, який СИЛЬНО допоміг нам у цьому відношенні:

«Щоб врятуватися від ведмедя, не потрібно бігти швидше за нього. Досить бігти швидше, ніж людина поруч з тобою».
Джим Батчер
В нашому випадку це можна перефразувати так:

«Не обов'язково захищатися від чітерства на 100%, щоб врятувати гру від читеров. Досить бути краще за своїх конкурентів».
«No Bugs» Hare
Економіка читів (особливо продаються за гроші) говорить нам, що при наявності двох цілей, одна з яких дуже приваблива, але добре захищена, а інша середньо приваблива, але захищена слабо, комерційні чітери виразно виберуть останню. Зрештою, це просто бізнес, нічого особистого.

image

В цій статті коротко розглянута тематика чітерства на підставі матеріалів книги «Development and Deployment of Multiplayer Online Games («Розробка і випуск багатокористувацьких онлайн-ігор»).
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.