Как защитить свою игру ключом CD / серийным номером?


25

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

Как добавить систему защиты серийных номеров в мою игру (и клиенты, и основной сервер аутентификации), чтобы ее нелегко взломать?


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

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

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

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


Смотрите также:

Как многопользовательские игры должны обрабатывать аутентификацию?


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

4
Я предполагаю, что это была автоматическая реакция на добавление DRM. Этот тип не особенно плох, но у многих из нас есть плохой опыт с ним - например, когда Spore заблокировал мою установку Windows.
Изката

Вместо CD-ключа вы рассматривали MMO-подобный / Minecraft-подобный подход, требующий ввода имени пользователя / пароля для входа в систему и использования его для аутентификации пользователей?
Тетрад

4
Хотите DRM для приложения .NET !? Это в конечном итоге потерпит неудачу с такими инструментами, как Reflector. Посмотрите на Террарию. Разработка прекратилась из-за пиратства (и большого дохода ...). Мне нравится идея @ Tetrad, основанная на аутентификации, поскольку она не позволяет людям просто исправлять функцию проверки. Сохраните все данные на своем сервере, и, когда они успешно войдут в систему, отправьте им свои данные. Если вы храните данные локально, то они могут просто отключить функцию аутентификации.

2
@ Анко, это была ссылка на известную цитату «Нам нужно больше минералов» . И я имею в виду факты и опыт. Может быть, даже подробно. Я не знаю, когда важной проблеме было уделено достаточно внимания, просто казалось, что есть что добавить, и посетители сайта могут найти эту тему интересной (и, возможно, стать новыми пользователями), поэтому я поднял награду.
user1306322

Ответы:


24

По сути, у вас есть три требования:

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

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


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

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

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


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

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

В качестве альтернативы, вы можете выдавать действительные клиентские сертификаты или что-то вроде них своим клиентам. Вы можете использовать существующий протокол (например, TLS), который поддерживает аутентификацию сертификата клиента (рекомендуется), или реализовать свой собственный, например, так:

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

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


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

Я думаю, что @LorenPechtel имеет сильную точку зрения в отношении удобства использования ключа, и платный пользователь, случайно набравший и отправивший на сервер ключ «ошибочно набран / ошибка правописания» (опечатка), всегда возможен.
Вишну

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

16

Нет 100% сохранения, но вы могли бы начать с довольно простого подхода:

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

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

С этого момента у вас может быть два разных подхода, но в любом случае что-то очень важно:

  • Не проверяйте ключ на стороне клиента. Это очень важно, потому что на самом деле довольно легко декомпилировать вещи, написанные в .net / XNA. Если вам нужно запросить ключ или передать его (логин или регистрация), хешируйте ключ (с добавленной солью и т. Д.) И отправьте его на сервер.

Что касается фактических путей:

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

  • В качестве альтернативы (IMO лучше, хотя многим не нравится этот тип "DRM"): вообще не используйте ключ в клиенте. Вместо этого потребуйте, чтобы пользователь вошел в учетную запись и требуется действительный ключ CD (для этого требуется база данных, указанная выше) для создания учетных записей. Вот как современные игры, например любая платная MMORPG, справляются с этим.

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


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

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

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

1

Pangea Software - создатель нескольких игр для Mac - написал тему о защите от копирования в своей (теперь бесплатной) книге по разработке игр. В книге также объясняется, как бороться с пиратскими ключами и другими взломами, которые используют люди. Книга посвящена разработке игр для Mac, но идеи могут быть полезны и для других платформ. В книгу входит исходный код каждой главы, часть загрузки приведена ниже. Также имеется исходный код (написанный на C), связанный с защитой от копирования.

Книгу можно скачать здесь .


Я не мог найти ничего полезного в этих книгах.
user1306322

Лично у меня, хотя глава 16, было несколько хороших советов, но YMMV.
Вольфганг Шреурс
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.