Зашифрованный контент в играх

У меня возникла идея использовать шифрование, чтобы пользователи не могли выяснить контент в моей программе за пределами самой программы. Подобно тому, как пользователи могут найти текстуры, которые никогда не использовались в игре, предназначенные для того, чтобы быть частью какого-то пасхального яйца при прохождении по данным игры. Это может, например, испортить его для всех, если вы разместите его в Интернете.

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

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

Игрок, если он осведомлен, мог бы легко перебрать его, легко учитывая, что число решений головоломки, вероятно, меньше, чем количество ключей дешифрования. Это действительно сложная задача головоломки, и здесь она не очень важна. Хотя я опубликовал ответ по этому поводу здесь

Есть ли сегодня программы / игры, которые сделали что-то подобное? Хранить зашифрованный контент в своих играх? А если нет, то почему? Есть ли много правил и положений об этом, на уровне магазина или страны? Кто-нибудь видит какие-либо очевидные подводные камни, которые мне не хватает? Игнорируя такие вещи, как пользовательский опыт, эта идея кажется мне здравой и заставляет меня удивляться, почему я этого раньше не видел.

Редактировать : Может быть, не совсем понятно, что я говорю, поэтому вот более конкретный пример.

Допустим, у меня есть функция, которая принимает строку из 20 символов и генерирует симметричный ключ, который я могу использовать для шифрования / дешифрования некоторого содержимого в игре. Единственный способ, которым пользователь может получить доступ к этому контенту, - это узнать эти 20 символов и сгенерировать один и тот же ключ. Этот ключ никогда не сохраняется напрямую и генерируется на лету на основе пользовательского ввода. Эти персонажи будут скрыты в игре в том, что могут быть книги, диалоги с неигровыми персонажами, возможно, даже вне игры, даже на обратной стороне коробки.

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

Редактировать 2 : рассматриваемый контент будет зашифрован произвольным и секретным ключом перед отправкой потребителю. Этот ключ, очевидно, не будет поставляться с игрой. Ему или ей придется каким-то образом ломать голову над ключом, учитывая ряд подсказок, сделанных на основе ключа, которые скрыты в игре или где-то еще. Однако эта система была бы прозрачной для пользователя, поскольку вы не знали бы, что контент зашифрован, если вы на самом деле не просматриваете игровые данные.

Как уже упоминалось, у этого есть один очевидный недостаток в том, что его использование ограничено. Как только один человек понял это, он / она может поделиться этим со всеми, если не ключ / решение, то сам контент. Однако, если вы намерены сохранить что-то настолько секретное, что один человек не сможет решить его, а люди должны будут вместе решать его, или вы боитесь, что ваше пасхальное яйцо настолько хорошо спрятано (умышленно), что оно Скорее всего, кто-то найдет его в коде, а не через игру. Тогда я думаю, что это может работать отлично.

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

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

Насколько мне известно, это определенно возможно. На самом деле, для меня странно, что другие ответы говорят, что это совершенно невозможно, даже если очень четко сказано, что ключ не генерируется и не хранится, просто считывается из состояния игры (что может иметь возможные googleplexes). ценности). Аргумент, что «игра знает, как ее расшифровать», чтобы она не работала, подразумевал бы, что любое программное обеспечение с открытым исходным кодом для шифрования / дешифрования (например, TrueCrypt) изначально небезопасно, потому что вы знаете, «как» дешифровать контейнеры (просто введите строка, основанная на вводе с клавиатуры, это просто верно?).

В простейшем случае представьте, что сама игра является симулятором клавиатуры и задает вопрос «каков пароль к моим зашифрованным файлам?», Ясно, что все мы согласны с тем, что наличие исходного кода для игры не поможет. А теперь представьте, что игра задает вопросы «как называется самое большое животное на Земле, соединенное с именем самого маленького животного?». Разве не ясно, что даже наличие исходного кода игры не поможет, и вам все равно придется решать головоломку?

Относительно того, возможно ли это, ответ является абсолютным ДА, это возможно.

Это было опробовано. Много, много раз. Существует целая отрасль, посвященная попыткам использовать шифрование, чтобы пользователи не могли получить доступ к программе по своему усмотрению. И это никогда не работает. Лучшие схемы защиты, как правило, длятся около месяца до того, как они взломаны, и в интернете главное то, что как только он взломан, он взломан везде навсегда, как только кто-то отправит его. Очевидная ошибка, которую вы упускаете, заключается в том, что для того, чтобы ваша программа использовала данные, она должна содержать всю информацию, необходимую для ее расшифровки, и если компьютер может это сделать, то человек, имеющий доступ к компьютеру, может сделать это. это.

Это называется «фундаментальная проблема криптографии»: Алиса хочет послать сообщение Бобу, и Чарли не сможет прочитать его, даже если он его схватит. Проблема с подходом, который вы предлагаете, состоит в том, что Боб и Чарли в этом случае - один и тот же человек .

Я понимаю желание не портить ваших пользователей, но если людям нужны спойлеры, они их найдут, а если нет, то будут активно избегать спойлеров. Но если вы хотите по-настоящему сделать отличную игру, идите противоположным путем: радикальной открытости. Посмотрите на такие вещи, как Neverwinter Nights , Starcraft или серия Elder Scrolls , игры, которые остаются популярными в течение многих лет после выпуска. Они делают это потому, что поставляют с игрой мощные инструменты дизайна, которые позволяют пользователям копаться во всем, выяснять, как это работает, создавать и делиться своим собственным контентом. Игра - это просто игра, пока она не станет сообществом , а сообщества терпят.

Я был здесь достаточно долго, чтобы знать, что если контент есть, кто-то найдет его. Сложнее будет просто привлечь более решительных людей. Чем популярнее ваш продукт, тем интереснее он становится. Частично потому, что это проблема, частично потому, что есть так много мест, где вы можете получить «кредит», разместив такую ​​информацию.

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

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

Основная причина, по которой это должно быть на gamedev.SE, заключается в том, что шифрование имеет игровые последствия.

Вы хотите, чтобы решение одной головоломки было ключом шифрования для следующей. То есть фактические данные этого решения должны расшифровать следующую загадку. Это означает, что ключ дешифрования нигде не является частью данных вашей игры; это генерируется игроком.

И вот как следствие. Расшифровка обычно двоичная. Либо у вас есть точный ключ дешифрования, необходимый для дешифрования данных, либо у вас его нет.

Следствием этого является то, что любая игра, которую вы разрабатываете, должна быть настолько узкой, чтобы на каждом уровне было только одно возможное решение . Таким образом, ваша механика головоломки должна быть очень тщательно разработана, чтобы игрок не мог решить головоломку иначе, чем ваши намерения.

Взять, к примеру, Портал, Испытательная камера 10. Вы должны идти налево, делать что-то, затем идти направо и делать что-то, все, чтобы опустить платформу.

Или вы можете просто дать себе некоторую скорость и броситься на платформу, когда вы идете прямо внутрь.

GLaDOS: Итак, вы создали игру-головоломку. Игра-головоломка, которая наказывает людей, которые больше всего любят головоломки. Отличная работа. Но, по крайней мере, эти хакеры не получат ваши драгоценные данные. Потому что люди, которым нравится решать головоломки, это именно те люди, которые ищут решения для головоломок в Интернете.

Так что это того стоит.

Таким образом, логические игры, такие как Adventures of Lolo, SpaceCHEM и Portal (среди миллионов других), прямо сейчас. Вместо этого вы должны разработать свою игру так, чтобы невозможно было создать головоломку, имеющую более одного решения. Это требует очень большой осторожности и обычно требует существенного ограничения игрового процесса.

GLaDOS: Итак, вы создали игру-головоломку. Игра, в которую должны играть люди, которые любят находить творческие решения головоломок. И вы сделали игру, в которой нет креативных решений головоломок. * Медленно хлопать *

Я не говорю, что вы не можете создать такую ​​игру. Или что такая игра не может быть хорошей. Только то, что такая игра должна быть разработана определенным образом.

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

GLaDOS: Итак, вы создали игру-головоломку. Игра-головоломка, которую интереснее взломать, чем играть. Отличная работа.

Конечно, есть одна оговорка к этому: значение «решения». Или, что более важно, какие элементы решения вы принимаете во внимание?

В любой игре, в которой задействован движущийся персонаж, вы, вероятно, не будете использовать точные движения персонажа для создания ключа расшифровки. Например, если у вас есть игра-головоломка, в которой игрок должен подобрать определенные предметы, чтобы «решить» головоломку, вы можете сделать ключ зависимым от порядка, в котором эти предметы касаются.

Конечно, это сталкивается с проблемой, описанной выше, когда игрок находит способ сделать что-то не по порядку. Что опять же означает, что вы должны спроектировать головоломку так, чтобы был только один порядок, в котором вы могли бы что-то поднять.

Кроме того, любые элементы, которые вы используете для создания ключа дешифрования, должны обеспечивать достаточную энтропию, чтобы затруднить дешифрование методом перебора. Используя описанную выше механику порядка сбора, каждый новый элемент фактически представляет собой один дополнительный бит. Если уровень содержит только 8 элементов, вы делаете 8-битное шифрование. Что это дерьмо; большинство смартфонов могут справиться с этим за считанные секунды.

В настоящее время вам нужно как минимум 128, чтобы сделать это даже немного сложным. Что теперь означает, что на каждом уровне должно быть много вещей, что опять же влияет на ваш игровой дизайн.

Ответы здесь хорошие; Я бы посмотрел на это с другой стороны. То, что вы описываете, является особенностью . Особенности имеют свои издержки и преимущества. Затраты включают как долларовые затраты на создание функции, так и «альтернативные затраты». Это так: в мире, где у вас есть конечные доллары и конечные часы и конечные программисты, каждая функция, которую вы делаете, означает бесконечное количество возможных функций, которые не были реализованы на своем месте.

Поэтому возникает вопрос: можете ли вы указать стоимость этой функции в реальном выражении? Там нет бесплатных функций, так что будьте реалистичны в отношении затрат. Вы готовы заплатить тысячу долларов за эту функцию? Сто тысяч? Миллион? Какие функции вы хотите сократить, чтобы иметь эту функцию?

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

Проблема Алисы Боб и Ева хорошо иллюстрирует это. Как сказал Мейсон в своем ответе, вы не можете хранить секреты от Евы, если Ева тоже Боб.

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

Но в конце концов это становится спорным. Если кто-то может играть в игру самостоятельно, то он также может написать программу, чтобы проглотить игру тоже. Таким образом, все, что вы делаете, это заставляете их возвращаться назад и вперед от вашего внешнего источника (вероятно, какого-то сервера). Как только они поймут, как создавать сообщения на ваш сервер, это та же самая старая история.

Но вы забыли ключевой элемент здесь. Это игра. Если кто-то обманывает в игре, большой возглас. Вы не написали игру для читеров. То же самое можно сказать и о прохождении квестов или руководствах по прокачке: люди, которые хотят сами разобраться в этом, будут игнорировать опубликованные решения. Даже если бы вы смогли сделать взлом игры невозможным, не играя в нее (мы знаем, что это логически невозможно, но ДАЖЕ ЕСЛИ вы могли это сделать), чтобы пройти всего лишь одного парня, он опубликовал бы все необходимое, чтобы победить. Так что вы только откладываете неизбежное.

Потратьте свое время на создание классной игры. Есть десять вещей, которые нужны каждой игре, и, в последний раз, я смотрел, шифрование не было одним из них.

Я считаю, что ваша идея бессмысленна.

Когда кто-то играет в вашу игру, он предпочитает играть в нее, он не делает это, чтобы выиграть награду, он делает это ради развлечения.

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

Также, как только кто-то нашел решение головоломки, то есть вашего ключа, он может просто опубликовать ее где-нибудь в Интернете.
Игроки, которые хотят обмануть, все равно смогут это сделать.

Однако если в вашей игре представлено несколько решений, таких как секретные уровни Super Mario Land, шифрование ваших активов не позволит получить легкий доступ к этим решениям.

Хотя это кажется точкой в ​​пользу вашей идеи, в конце концов, это не так.

Даже с помощью шифрования можно было бы узнать, что такие секретные решения существуют.
Как только станет известно, что существует секретное решение, предотвращение просмотра секретных активов игроками не будет иметь значения, поскольку они все равно захотят получить доступ к скрытым частям игры через саму игру (да, даже если они уже видели все скрытые объекты). текстуры / клип / аудио / текст).

Вы можете предотвратить утечку существования секретных решений, используя некоторую забывчивую технику ¹ , но это все равно будет подозрительно (зачем делать это, если нет секретных решений?), Игроки потеряют интерес к их поиску, и у вас будет меньше игроков , не больше.
В конце концов, после завершения игры мы можем сыграть еще пару часов, чтобы вызвать несколько пасхальных яиц, но мы не будем играть больше минуты, если их запуск потребует колоссальных усилий!

То, что вы хотите сделать, это как тетрадь, в которой следующая глава зашифрована словом текущей главы, чтобы читатели не испортили себе окончание.
Подумай об этом, не бессмысленно ли?

_{¹ Очень похоже на то, как VeraCrypt делает это со скрытыми томами.}

Я не буду комментировать коммерческую жизнеспособность, однако с чисто технической точки зрения это забавная задача.

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

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

Ваша идея использовать решение загадки в качестве ключа довольно интересна, однако использование ключа, предоставленного напрямую, скорее всего, будет легко подстроено. Вместо этого обрабатывайте пользовательский ввод как пароль и используйте современную схему хеширования паролей: созданный хеш является ключом.

Однако даже в этом случае вы ошиблись, если предположить, что ключ отсутствует в игре. Если это не так, вы не могли бы направить своих игроков к этому; следовательно, вместо того, чтобы пытаться взломать сейф, вместо этого можно было бы перепроектировать игровые активы в поисках ключей. Одна потенциальная загадка, о которой я могу подумать, - это использование текстур для кодирования глифов, и тогда пароль будет состоять из нескольких доступных на клавиатуре, как показывают места, которые игрок должен был посетить (по порядку):

• суть проблемы в том, что распознавание изображений все еще несколько затруднено для компьютеров
• поверх которого мы подчеркиваем тот факт, что взломщики CAPTCHA настроены на буквы и цифры, а не на собственные глифы
• поверх которого мы накладываем тот факт, что путем объединения нескольких текстур (с прозрачностью), чтобы показать игроку глиф, ни один актив в игре не содержит того, как этот глиф должен выглядеть
• использовать другую текстуру (с фрагментами) повсюду, но никогда не таким образом, чтобы генерировать полный глиф, кроме как в скрытых местах, в которые игрок никогда не сможет добраться

и любая программа для автоматического извлечения выигрышной комбинации глифов будет иметь адский день.

В-третьих, следующая трудность - делиться. После того, как решение секрет найден, он будет показан. В идеале, каждому человеку должна быть вручена немного другая версия программного обеспечения: та, в которой ключ уникален для своей версии игры. Чтобы сделать это практичным, я предполагаю, что было бы легче отделить игру (с ее активами) от «секретов» (зашифрованных) и «секретного драйвера» (генератора ключей, который размещает множество фрагментов текстуры во многих разных местах). некоторые из которых образуют пароли).

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

Здесь потенциальным решением было бы связать файлы с учетной записью пользователя и ввести пароль, как обычно рекомендуется:

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

Затем, когда пользователь готов предоставить пароль:

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

Цель здесь состоит в том, чтобы как можно больше препятствовать совместному использованию аккаунта:

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

И мы почти у цели.

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

Решение простое (и делает практически все вышеперечисленное устаревшим ¹ ): не доверяйте клиенту.

Создайте таблицу лидеров на своем веб-сайте и отслеживайте прогресс игроков в своей учетной записи. Игроки могут утверждать, что они закончили игру, сколько хотят, но если их учетная запись не отражает это, все знают, что они обманывают ...

... это называется социальным давлением;)

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

Это интересная идея; вариант на дисках с загадками и системы защиты от копирования типа «слово из руководства». Я думаю, что некоторые из игр "ARG" работают так, когда понимают, что игроки действуют коллективно против игрового дизайнера.

Очевидно, что как только первый человек расшифрует его, они опубликуют его в Интернете.

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

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

Рассмотрение дополнительных мер безопасности является интересным, но оно не добавляет конкретной ценности вашему продукту - оно демонстрирует вашу ловкость взломщикам, которые сталкиваются с вашим продуктом. В принципе, ваш антагонист догонит вас.

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

Если вы хотите принять участие в этом конкурсе, это ваш призыв - но не позволяйте ему отвлекаться от вашего конечного продукта, который должен понравиться клиенту. Причудливая схема шифрования, которая превращает игру в слизняк, не помогает.

Мейсон Уилер правильно понял: ты не можешь этого сделать. Кто-то всегда может перепроектировать вашу игру, если захочет.

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

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

Насколько случайные пользователи выкладывают ваши текстуры на аватарку своего форума, ну и что? Считайте, что это реклама на низовом уровне.

Навязчивое отношение к "защите" вещей просто отвлечет вас от таких сложных реалий, как создание игры .

Когда я вижу, что люди, у которых нет продуктов, рассказывают о своих схемах защиты ИС для вещей, которых даже не существует, для меня это своего рода неожиданный момент, потому что это поднимает огромный красный флаг по всему проекту.

Некоторые возможности:

• Обычный старый код запутывания . Это не сделает код невозможным для декодирования, но по крайней мере это будет сложно.

• Серверное решение. Вы отправляете некоторые специальные команды на сервер, и сервер может отправить вам код ... или даже загрузить DLC.

• Вы можете использовать стеганографию, чтобы скрыть исполняемый код в другом контенте.

Это не сделает ваш секрет 100% безопасным, но кажется, что никто не потеряет деньги, если секрет будет раскрыт.

Это бесполезно, как и любая другая схема, где вы храните ключ и алгоритм на клиенте. Если вы спросите «где ключ, я полагаюсь на данные пользователей и не храню их сам?», Помните, что у вашей головоломки есть правила и ресурсы по ее определениям - она ​​решается неким алгоритмом, а не грубым принуждением. Этот точный алгоритм и его ресурсы - это алгоритм генерации ключей, который вы только что жестко запрограммировали в игре в запутанном состоянии. Любой может получить ваш «несуществующий» ключ, просто написав небольшую программу, которая решает вашу головоломку в соответствии с вашими правилами.