Завдання Античит для OpenSource-ігри
GameDev → Завдання: Античит для OpenSource-ігри
Хочу запропонувати вам одне завдання, яке, як я вважаю, досить цікаве.
Уявіть собі, що ви розробляєте OpenSource гру (під будь-якою улюбленою вами ліцензією, але гравці повинні мати можливість створювати моди). А саме – шутер. Оцінюючи ваші ресурси, ви дійшли висновку, що можете дозволити собі тільки майстер-сервер, який видає список ігрових серверів і більше нічого. Для простоти умови, будемо вважати, що у вас відразу після запуску гри вже є тисяч десять гравців, тобто. гра буде досить популярна і дуже потрібна античит система (яку ви можете вбудувати прямо в код гри). Але оскільки ресурсів у вас так і немає, ви повинні покласти роботу античит системи на плечі ігрових клієнтів та на ігрові сервери. Умови: • Практично 100%-гарантія роботи античить системи без хибних спрацьовувань; • Можливість адміністраторського впливу на античит систему; • Як сервери, так і клієнти можуть бути з деякими модифікаціями в коді; • Античит повинен відловлювати практично всі види читерства на клієнті та на сервері; • Античит не повинен занадто сильно заважати гравцям • Кросплатформеність
Коментарі ( 18 )
Ну вперше задумався я про цю проблему саме через захоплення грою та кодингом Teeworlds. Вже з'явилася парочка клоунів (а точніше три), які написали свої власні версії античитів (Teeworlds Trusted Client, Apofig AntiCheat, Simple AntiCheat TeeWorlds). Всі з них мають велику траблу — вони не підтримують альтернативні клієнти. Перший — це сам собою окремий клієнт. Третій - найгірший варіант (ламається за 15 хвилин у поточному вигляді). А щодо другого – був дуже веселий тред на форумі z-team.
Ще одинваріант античита - на сервері збирати докладний лог дій і ґрунтуючись на таких характеристиках як співвідношення вдалих та невдалих пострілів - визначати рівень гравця. Так можна відловити більшу частину чітерів, але неминуче частина хороших гравців може вважатися читерами. Щось подібне є на деяких серверах, але я не знаю їхнього алгоритму.
Як це можна було зробити: 1. Античит система (пропрієтарна, із закритими вихідними кодами) при запуску звіряє файл з оригіналом або попередньою версією гри. 2. Якщо є відмінності, то файл гри завантажується на спеціальний сервер, де згодом перевірятиметься (процес завантаження можна оптимізувати, допустимо для кожного 4096-байтного блоку вважати md5 і відправляти на сервер з метою впізнавання, чи була така версія гри вже).
Звичайно, така система має недолік, який полягає в тому, що використовується ручна перевірка, але принаймні це не вбило б всю систему моддінгу. — Однак завдання зазначене в топіці — трохи інше. Там взагалі не повинно бути витрат із боку адміністраторів. Тобто. запустив один раз - і залишив до наступної версії.
На жаль, мої пізнання в галузі реверс-інжинірингу бінарників та злому комп'ютерних програм надзвичайно обмежені. Тому є ймовірність того, що нижчевикладене ґрунтується на невірних передумовах.
Проведемо паралель із іграми у реальному світі. Хто є присутнім на кожному футбольному матчі? Арбітр. Третя особа, яка знає правила і стежить за тим, щоб усі гравці цих правил дотримувалися, причому всі гравці повинні дотримуватися тих самих правил. Гравці (і глядачі) також можуть спостерігати за процесом гри і, в принципі, можуть зловити арбітра на шахрайстві (якщо арбітр починає рандомно показувати червоні картки, то він абодебіл, або куплений, або збожеволів). Арбітр (як правило?) цінує свою репутацію. Гравці довіряють арбітру за умовчанням.
З комп'ютерними іграми можна зробити те саме: взяти якусь третю особу (не обов'язково сервер, що належить розробникам гри) і зробити його арбітром. Арбітр стежить, щоб ПО всіх гравців було однієї версії, і навіть моніторить звіти, які у реальному часі посилає контрольний модуль, присобаченный до клієнта. Контрольний модуль реагуватиме на спроби модифікації виконуваного коду гри на льоту та інші поширені методи злому.
Як це стикується зі СПО? Ось тут, загалом, і міститься основне слабке місце цієї схеми. Контрольний модуль - це бінарник, причому міцно зашитий. Переважно — зашитий якимось випадковим чином (я хз, як взагалі це робиться). Плюс, його код може містити випадкові послідовності. Загалом, будь-які методи, які запобігають автоматичному зламуванню. Бінарник цей посилається арбітром одночасно всім гравцям. Можливо знадобиться синхронізація передачі даних, щоб усі гравці перестали завантажувати бінарник приблизно в один і той же момент. У цей момент бінарник активується на кожному з клієнтів і протягом N секунд повинен законнектитися (PSK, ключ вшитий в бінарник) до арбітра і підтвердити свою справжність та цілісність. Після чого він запускає гру, перевіряє версію її модулів, і починає стежити за її процесами, запобігаючи їхній зміні. Періодично (раз на M хвилин) арбітр генерує нову версію бінарника і відсилає її гравцям разом із вихідними заголовками попередньої версії (таким чином гравці отримують дійсно вільне ПЗ — тільки з деякою затримкою) та інформацією про те, як розшифрувати дані, які передавав бінарник весь цей час .
ПЗ гравців знає, як генеруються вихідні дані контрольного модуля і що контрольний модуль може робити. Тому працюючий паралельно з клієнтом модуль контролю та спостереження за модулем контролю може не дозволяти модулю контролю робити щось, що йому робити не належить (наприклад пропатчити ядро). Після отримання чергової порції вихідників та ключів для декодування потоку модуль контролю та спостереження за модулем контролю може декодувати інформацію (не обов'язково в реальному часі, це можна робити паралельно, або взагалі відкласти декодування на потім), яка була надіслана раніше, щоб переконатися, що модуль контролю не посилав нічого інкримінуючого (у разі, якщо йому вдалося обійти модуль контролю та спостереження і все-таки нарити якусь інформацію), а також, що арбітр не давав модулю контролю жодних читерських команд. Також гра записує та шифрує ріплей (записує та шифрує сама, ключ для шифрування отримує від модуля контролю, цей ключ також розкривається кожні M хвилин), після гри він може бути проаналізований для визначення чесності арбітра та гравців (оскільки система дозволяє уникнути модифікацій клієнта та шифрувати передачі, можна дозволити клієнтам мати вичерпну інформацію про хід гри - все одно гравці не зможуть нею скористатися в реальному часі).
Тобто система заснована на припущенні, що можна генерувати бінарники, які не можуть бути зламані гравцями (і в яких ключі не можуть бути знайдені) швидше ніж за N секунд. Також передбачається, що гравці не можуть модифікувати код модуля контролю після його запуску (або можуть, але не здатні обчислити та внести всі необхідні зміни швидко та атомарно). Також передбачається, що гравці довіряють арбітру, тобто арбітри — невипадково обранікомп'ютери в Інтернеті, а відомі (мають закритий ключ для підтвердження) особистості. Звичайно, це не дає 100% гарантію того, що вони ніколи не скористаються одержуваною владою з неправедною метою, але й у реальному світі ніхто цього не гарантує. Крім того, можливості, які дають їм модулі контролю, досить обмежені.
Гра розбивається на кілька шматків, усі важливі для ігрового процесу дані пересилаються через модуль контролю і тому передаються у зашифрованому вигляді. Шматки, що не містять елементів, що впливають на ігровий процес, можуть модифікуватися вільно, модуль контролю не заперечуватиме. Шматки, які впливають на ігровий процес, у своїй сукупності повинні бути сумісні один з одним і сумісні з клієнтським кодом інших гравців («сумісні» означає, що вони підтримують одну і ту ж версію протоколу та правил гри, вони не обов'язково мають бути ідентичними. точністю до біта, тому що можуть бути на різних платформах), арбітр це перевіряє по хеш цих шматків (хеш вважає і передає модуль контролю). Арбітр зберігає у собі великий набір таблиць сумісності шматків з їхньої хешу, цей набір він також показує гравцям перед початком гри (щоб гравці знали, які версії клієнта підтримуються). Схвалені як «чисті» версії походять насамперед із центрального репозиторію спільноти розробників гри (підписуються реліз-інженером; списки схвалених версій регулярно оновлюються), але арбітр вільний підтримувати і модифіковані версії на власний розсуд (головне, щоб усі гравці мали сумісні моди).
Модуль контролю може надсилати скріншоти (скриншоти робить гра) та дані про стан гри на момент зняття скріншота арбітру та іншим гравцям, згодом їх можна дешифрувати (для гравців; арбітр може дешифрувати вреальному часі) і перевірити, що рендеринг було проведено правильно. Це не дуже красиво, зате дозволяє гравцям мати будь-які версії драйверів, які відповідають за малювання (модифікуючи рендерер можна, в принципі, домагатися прозорості стін та інших цікавих і не зовсім чесних ефектів). Арбітр може звіряти скріншоти з їх очікуваними версіями (знаючи стан гри, арбітр може сам відрендерити відповідну сцену та автоматично перевірити, що різниця між зображеннями не перевищує похибки).