Зашифрований вміст в іграх

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

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

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

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

Чи є сьогодні програми / ігри, які зробили щось подібне? Зберігання зашифрованого вмісту в своїх іграх? А якщо ні, чому? Чи існує багато правил і норм щодо цього на рівні магазину чи країни? Хтось бачить явні підводні камені, які мені не вистачає? Ігноруючи такі речі, як досвід користувача, ця ідея здається мені звуковою і викликає цікавість, чому я цього раніше не бачив.

Редагувати : Можливо, не ясно, що саме я говорю, тому ось конкретніший приклад.

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

Тож, якщо спробувати 2 * 10 ^ 28 можливих комбінацій, ймовірно, буде більш ймовірно, що люди знайдуть вміст таким чином, як задумано, а не за допомогою перегляду даних гри.

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

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

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

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

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

В абсолютному простому випадку, уявіть, що сама гра є симулятором клавіатури, і вона задає питання "що таке пароль для моїх зашифрованих файлів?", Явно ми всі згодні, що наявність вихідного коду для гри не допоможе. А тепер уявіть, що гра задає питання "як називається найбільша тварина на Землі, поєднана з ім'ям найменшої тварини?". Чи не зрозуміло, що навіть наявність вихідного коду гри не допомогло б, і вам все одно доведеться вирішувати головоломку?

Що стосується того, чи можливо це, відповідь є абсолютною ТАК, це можливо.

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

Його називають "основною проблемою криптографії": Аліса хоче надіслати повідомлення Бобу, не маючи змоги прочитати Чарлі, навіть якщо він його знайде. Проблема підходу, який ви пропонуєте, полягає в тому, що Боб і Чарлі в цій справі одна і та ж людина .

Я можу зрозуміти бажання не псувати ваших користувачів, але якщо люди хочуть спойлерів, вони знайдуть їх, а якщо цього не зробити, вони схильні активно уникати спойлерів. Але якщо ви хочете по-справжньому зробити чудову гру, підіть навпаки: радикальна відкритість. Подивіться на такі речі, як Neverwinter Nights , Starcraft або серія Elder Scrolls , ігри, які залишаються популярними роками та роками після виходу. Вони роблять це через те, що вони постачають потужні інструменти дизайну з грою, які дозволяють користувачам занурюватися у все, з'ясовувати, як це працює, а також створювати та ділитися власним вмістом. Гра - це лише гра, доки вона не стане спільнотою , і громади не витримають.

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

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

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

Основна причина, чому це повинно бути в gamedev.SE, полягає в тому, що виконання цього шифрування має наслідки ігрових процесів.

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

І ось наслідок. Розшифрування зазвичай двійкове. Або у вас є точний ключ розшифровки, необхідний для розшифровки даних, або ви цього не зробите.

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

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

Або ви можете просто дати собі деяку швидкість і підкинути себе до платформи, коли ви заходите прямо.

GLaDOS: Отже, ви склали головоломку. Гра-головоломка, яка карає людей, які найбільше насолоджуються головоломками. Хороша робота. Але принаймні ці хакери не отримають ваших цінних даних. Тому що люди, які насолоджуються розгадуванням головоломки, є саме тими людьми, які шукають рішення головоломки в Інтернеті.

Тож цього цілком варто.

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

GLaDOS: Отже, ви склали головоломку. Гра, яку покликані грати люди, яким подобається знаходити креативні рішення головоломок. І ви зробили гру, яка не має творчих рішень для пазлів. * повільний кліп *

Я не кажу, що ви не можете створити таку гру. Або що така гра не може бути хорошою. Тільки, що таку гру потрібно було б замислити певним чином.

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

GLaDOS: Отже, ви склали головоломку. Гра-головоломка, яку цікавіше зламати, ніж грати. Хороша робота.

Звичайно, є одне застереження до цього: значення "рішення". Або, до речі, які елементи рішення ви враховуєте?

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

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

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

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

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

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

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

Проблема Аліси Боб і Єви це добре ілюструє. Як зазначив Мейсон у своїй відповіді, ви не можете зберігати таємницю від Єви, якщо Єва також є Боб.

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

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

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

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

Я вважаю, що ваша ідея є безглуздою.

Коли хтось грає у вашу гру, він вирішує пограти в неї, вони не роблять це, щоб виграти нагороду, вони роблять це для задоволення.

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

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

Однак якщо у вашій грі представлено кілька рішень, як-от секретні рівні Super Mario Land, шифрування ваших активів запобіжить легкий доступ до цих рішень.

Хоча це здається моментом на користь вашої ідеї, врешті-решт це не так.

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

Ви можете запобігти витіканню секретних рішень, використовуючи якусь забуту техніку ¹ , але все одно буде підозріло (навіщо це робити, якщо немає секретних рішень?), Гравці втратять інтерес до їх пошуку, і у вас буде менше гравців , НЕ більш.
Зрештою, ми можемо пограти ще пару годин після того, як закінчимо гру, щоб запустити кілька писанок, але ми не будемо грати ні хвилини більше, якщо запускати їх знадобиться титанічне зусилля!

Те, що ви хочете зробити, - це як написання книги, де наступна глава зашифрована словом поточної глави, щоб запобігти читачам не зіпсувати собі закінчення.
Подумайте, чи не безглуздо?

_{¹ Досить схоже на VeraCrypt роблять це з прихованими томами.}

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

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

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

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

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

• Суть проблеми полягає в тому, що розпізнавання зображень все ще дещо складно для комп'ютерів
• поверх чого ми шаруємо те, що сухарики CAPTCHA налаштовані на літери та цифри, а не на замовлені гліфи
• З іншого боку, ми розшаровуємо той факт, що, поєднуючи кілька текстур (з прозорістю) для виявлення гліфа гравцеві, жоден актив у грі не містить того, як повинен виглядати гліф
• використовувати іншу текстуру (з фрагментами) у всьому місці, але ніколи таким чином, що не створює повний гліф, за винятком прихованих місць, до яких гравець ніколи не зможе дістатися

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

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

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

Тут можливим рішенням буде прив’язати файли до облікового запису користувача та солити пароль, як зазвичай рекомендується:

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

Потім, коли користувач готовий надіслати пароль:

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

Мета полягає в тому, щоб максимально унеможливити обмін обліковими записами:

• спільний доступ до облікового запису для створення таємних файлів (а) обмежений, оскільки в день може створюватися лише один, і (б) марний, оскільки останнє створене робить іншого застарілим
• обмін обліковим записом та розповсюдження пов’язаних секретних файлів марно, оскільки даний пароль можна використовувати лише N разів, перш ніж він більше не видасть ключ

І ми майже там.

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

Рішення просте (і робить майже все вище застарілим ¹ ): не довіряйте клієнту.

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

... це називається соціальним тиском;)

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

Це цікава ідея; варіант на дисках-головоломках та системах захисту від копіювання введіть слово. Я думаю, що деякі ігри "ARG" працюють так, де зрозуміло, що гравці виступають колективно проти ігрового конструктора.

Очевидно, що коли перша особа розшифрує її, вона опублікує її в Інтернеті.

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

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

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

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

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

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

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

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

Що стосується випадкових користувачів, які розміщують ваші текстури на аватарі форуму, то що? Розглянемо це трав’яна реклама.

Нав'язливість щодо "захисту" речей просто відволіче вас від складних реалій, таких як: створення гри .

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

Деякі можливості:

• Простий старий припухлість коду . Це не зробить код неможливим розшифрувати, але, принаймні, буде важко.

• Рішення на стороні сервера. Ви надсилаєте на сервер деякі спеціальні команди, і сервер може надіслати вам код ... або навіть завантажити DLC.

• За допомогою Steganography можна приховати виконуваний код в іншому вмісті.

Це не зробить вашу таємницю на 100% захищеною, але, здається, ніхто навіть не втратить гроші, якщо секрет буде розкритий.

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