Анти-чіт Javascript для браузера / гри HTML5

Я планую зайнятися створенням одного гравця RPG дій у js / html5, і я хотів би запобігти обман. Мені не потрібен 100% захист, оскільки це не буде багатокористувацькою грою, але я хочу певний рівень захисту.

Отже, які стратегії ви пропонуєте за межі спрощення та затуманення?

Я б не покладався зробити просту перевірку на стороні сервера, але я не хочу йти шляхом Diablo 3, зберігаючи всі зміни стану гри на стороні сервера.

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

Що щодо змінних та функцій ескопів? Працювати над меншими ескопами, коли це можливо, безпечніше, але варто докласти зусиль?

Чи є в будь-якому випадку, щоб javascript самостійно перевіряв його текст, як у контрольній сумі?

Є конкретні рішення для браузера? Я б не намагався стримувати це для Chrome лише в початкових версіях.

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

Хороша новина полягає в тому, що, як правило, дуже мало обману в одиночних іграх. Єдиним головним винятком є ​​ігри, у яких є великі спільноти "ютуб-рейтингу", такі як Line Rider, де гравці змагаються між собою через YouTube.

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

Я хотів би, щоб на це була краща відповідь, але немає.

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

• Мінімізуйте та заблокуйте свій JS, що абсолютно зробить код важчим для читання. Ви можете де-мінімізувати та сортувати знешкодження, але ви ніколи не зможете отримати правильну назву змінної та функції, а також коментарі.
• Випікайте значення з іншою мовою. У цьому випадку ви можете використовувати PHP або інші серверні мови для обробки статичних змінних параметрів. Якщо відстань стрибка завжди повинна становити 2 пробіли, зазвичай слід визначити відстань стрибка для об’єкта гравця. Не працюйте з PHP, щоб джерело JS закінчувалося 2-мами, замазаними по всьому коду в мільйоні місць. Це має щасливий додатковий побічний ефект того, що ви також можете прискорити свій JS.
• З деякою практикою ви отримаєте досвід у поєднанні, і навіть зможете скласти свій JS для кожного гравця. Це ще один спосіб запобігти обману. Якщо код кожного гравця якимось чином відрізняється, тоді важче написати чіт, який може бути частиною набору інструментів.
• Нарешті, ви можете перевірити суму джерела на основі особи гравця. Скажіть їх IP-адресу та / або ім’я користувача. Ви знаєте, якою буде версія для гравця JS, ви можете запікати в контрольній сумі і вимагати, щоб вона була такою ж на іншому кінці. Легко відключити, як і будь-який JS на стороні клієнта, але ще раз ускладнює створення інструментарію.

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

Я вже відповів на таке запитання тут , і прошу пробачення, але:

Я б не покладався зробити просту перевірку на стороні сервера, але я не хочу йти шляхом Diablo 3, зберігаючи всі зміни стану гри на стороні сервера.

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

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

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

Добре місце для початку - використовувати функцію Object.freeze (яка дозволить захистити від виправлення об'єктів).

Це "запобігає доданню нових властивостей", "запобігає видаленню існуючих властивостей", "запобігає зміні існуючих властивостей або їх перелічуваності, конфігуруваності чи записуваності"; будь-які зміни у внутрішньому стані повинні здійснюватися через приладдя. Наступний приклад працює на chrome (повинен працювати на firefox, я не знаю про IE, хоча ...):

var b = {}
// Fill your object with whatever you want
b.a = "ewq"
// Freeze all changes
Object.freeze(b)
// Try to put new value. This wont throw any error, put wont work either, 
// as we shall see ...
b.b = "qwe"

// Values 
console.log(b.a); // outputs "eqw"
console.log(b.b); // outputs  undefined

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

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

... і так далі

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

• Я на місці1 @ T1, я на місці2 T2, який мінімальний час потрібно для подорожі з place1 до place2, і це відповідає моєму T2 - T1. Ви можете мати відображення цього від малого до великого залежно від розміру карти. У вас повинен бути список принаймні основних областей, таких як NPC - бос, NPC - нерестовий ворог (не обов'язково точне місце)

Сподіваюся, це допомагає, це звучить важко, але вам потрібно навчитися робити справжні робочі ігри

В основному це неможливо. Було б так просто обійти все, що ви поставите, щоб запобігти обману.

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

Крім того, якщо вони хочуть обдурити, нехай. Вони просто руйнують гру для себе. Немає реального практичного використання для того, щоб обдурити в цій ситуації, ви просто знищите геймплей для себе.

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

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

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

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

Це розширення, на яке я повторю інші відповіді.

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

З цим сказаним:

• Пом'якшення грубих клієнтів: Обслуговуйте HTTPS, використовуйте перехресний посилання ресурсів (CORS), дозволяйте лише те саме походження, використовуйте цілісність субресурсів. Я пропоную впровадити сервісного працівника, щоб застосувати його до всіх запитів, що також означатиме, що гра не працюватиме, просто перемістивши її на HTTP (адже без HTTPS немає сервісного працівника, серверний працівник виконує клієнтську частину CORS і сервер очікує CORS), і якщо вони обслуговуються через HTTPS, він не працюватиме, оскільки сервер відкине інше походження.
• Пом'якшити сценарій: використовуйте автентифікацію та вимагайте маркер, щоб зробити будь-які дії. Кожен цикл оновлення сервер повинен дати клієнту новий маркер, і маркер споживається, роблячи все, що він робить ... робити все, що потрібно, потрібний маркер, маркер завжди змінюється, і, таким чином, не піддається здогадуванню, і якщо клієнт надсилає той самий маркер двічі або неправильний маркер, сервер знає, що щось зроблено. Для додаткового захисту: створіть код автентифікації повідомлення (MAC) маркера за допомогою секретного ключа та додайте його до файлу cookie. Змінення файлу cookie знищить сеанс (і їм потрібно відгадати ключ), а зміна маркера призведе до того, що перевірка MAC не вдасться.
• Пом’якшення модифікацій коду: окрім цілісності субресурсів (які сучасні браузери також перевірятимуть під час виконання), тримайте змінні в обмеженому обсязі (використовуючи дозволене, самостійне виконання анонімних функцій та модулі javascript). Крім того, не покладайтеся на DOM (DOM призначений лише для IO, а не для зберігання даних, якщо вам потрібно приєднати атрибути, обгорнути ваші DOM-об'єкти та додати їх до обгортки). Таким чином, все, що ви знаходитесь на консолі, не повинно досягати логіки гри (якщо ви не використовуєте деяку вразливість браузера). Ви можете також розглянути можливість використання методів виявлення інструментів для розробників (вони конкретні для кожного браузера, і можуть не працювати у всіх випадках або припинити роботу в майбутньому ... таким чином, це гонка озброєнь).
• Щось вгору? Сесія перервалася? Відірвіть гравця від поточного матчу, попросіть знову увійти. Розглянемо капчу ... яка також має перевагу сказати користувачеві, що "ми знаємо, що відбувається щось рідкісне" (це не випадковий збій сервера), і так, це форма пом'якшення. О, і не пускайте їх в журнал. Вам потрібно мати можливість перевірити, чому вони сталися, як для запобігання помилкових постів, так і для відповіді на квитки на підтримку.

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