Поэтому я решил, что хочу запретить пиратским копиям моей игры XNA доступ к официальным игровым серверам (которые модерируются, чтобы люди, заплатившие за игру, получили наилучшие впечатления), отключая клиентов от неправильных или сгенерированных, дублированных или заблокированных CD ключи (или серийные номера, так как игра цифровая и никаких компакт-дисков нет).
Как добавить систему защиты серийных номеров в мою игру (и клиенты, и основной сервер аутентификации), чтобы ее нелегко взломать?
Обратите внимание, что у меня нет опыта создания такой защиты для программного обеспечения.
Я никогда не делал этого раньше, но я понимаю основы. Я понимаю, почему я не могу выполнить проверку ключей на клиенте, поэтому я могу использовать аутентификацию входа / прохода с одноразовым вводом ключа.
В настоящее время цель этой защиты состоит в том, чтобы не допустить потенциальных читеров и деструктивных игроков на официальные серверы. Любой может играть на частных серверах с ключом или без него, но вероятность того, что они могут получить нежелательный опыт работы с другими игроками, выше. Я полагаю, что это достаточно просто при покупке игроков, так как они должны быть онлайн, чтобы играть на официальных серверах.
Поскольку взломать клиент слишком просто, я собираюсь защитить только процедуры начальной регистрации (и, возможно, аутентификации на стороне сервера), поэтому никто не сможет украсть ключи во время их передачи.
Смотрите также:
Как многопользовательские игры должны обрабатывать аутентификацию?
Ответы:
По сути, у вас есть три требования:
Первая часть должна быть довольно простой: просто не позволяйте двум игрокам одновременно заходить на один и тот же сервер с одним и тем же ключом. Вы также можете заставить серверы обмениваться информацией о вошедших в систему пользователях или связаться с общим сервером аутентификации, так что даже использование одного и того же ключа для разных игроков на разных серверах одновременно не удастся. Вам также, вероятно, захочется найти подозрительные схемы использования ключа и, если вы решите, что ключ был утек, добавьте его в список запрещенных ключей.
Для второй части один из способов - просто поддерживать базу данных всех действительных выданных ключей. До тех пор, пока ключи достаточно длинные (скажем, 128 бит или более) и выбираются случайным образом (с использованием безопасного RNG), шансы того, что кому-то удастся угадать действительный ключ, по существу равны нулю. (Даже намного более короткие ключи могут быть безопасными, если вы используете какое-то ограничение скорости при неудачных попытках входа в систему, чтобы остановить попытки найти действительные ключи с помощью грубой силы.)
Кроме того, вы можете генерировать ключи, взяв любой уникальный идентификатор и добавив код аутентификации сообщения. (например, HMAC ), рассчитанный с использованием секретного главного ключа. Опять же, до тех пор, пока MAC достаточно длинный, шансы того, кто не знает мастер-ключ, сможет угадать действительный MAC для любого идентификатора, ничтожны. Одним из преимуществ этого метода, помимо устранения необходимости в базе данных ключей, является то, что идентификатор может быть любой уникальной строкой и может кодировать информацию о клиенте, для которого был выдан ключ.
Одна проблема с использованием MAC заключается в том, что официальные игровые серверы (или, по крайней мере, сервер аутентификации) должны знать главный ключ для проверки MAC, что означает, что, если серверы взломаны, главный ключ может быть утечен. Одним из способов снижения этого риска может быть вычисление нескольких MAC-адресов для каждого идентификатора с использованием разных мастер-ключей, но только хранение одного из мастер-ключей на игровых серверах. Таким образом, если этот мастер-ключ когда-либо просочится и будет использован для создания поддельных идентификаторов, вы можете отозвать его и переключиться на другой мастер-ключ. В качестве альтернативы вы можете заменить MAC цифровыми подписями , которые можно проверить, используя только открытую половину мастер-ключа.
В третьей части один из подходов заключается в том, чтобы клиент не отправлял свой ключ кому-либо, не убедившись, что получатель действительно является законным официальным сервером. Например, вы можете использовать SSL / TLS (или DTLS ) для процесса входа в систему, выпускать пользовательские сертификаты для своих игровых серверов и иметь только сертификаты доверия клиентов, выданные вами. Удобно, что использование TLS также защитит клиентские ключи (и любые другие данные аутентификации) от перехватчиков, например, в общедоступных беспроводных локальных сетях.
К сожалению, такой подход не позволяет сторонним серверам проверять ключи клиентов, даже если они этого хотят. Вы можете обойти эту проблему, настроив официальный сервер аутентификации, который могут использовать сторонние игровые серверы, например, если клиент войдет на сервер аутентификации и получит случайный одноразовый токен, который он может использовать для входа в систему. игровой сервер (который затем передает токен серверу аутентификации для проверки).
В качестве альтернативы, вы можете выдавать действительные клиентские сертификаты или что-то вроде них своим клиентам. Вы можете использовать существующий протокол (например, TLS), который поддерживает аутентификацию сертификата клиента (рекомендуется), или реализовать свой собственный, например, так:
(Этот протокол может быть еще более упрощен, если клиент сгенерирует «запрос», состоящий из идентификатора сервера и метки времени, и подпишет его. Конечно, затем сервер должен проверить, что идентификатор и метка времени действительны. Также обратите внимание, что этот простой протокол сам по себе не помешает злоумышленнику-посреднику получить возможность перехватить сеанс клиента, хотя он не позволит им получить закрытый ключ клиента, необходимый для будущих входов в систему.)
источник
Нет 100% сохранения, но вы могли бы начать с довольно простого подхода:
Вам понадобится какой-нибудь способ проверки сгенерированных ключей, например, включенные контрольные суммы. Конечно, это не должно быть слишком легко понять.
Необязательно (но рекомендуется) будет база данных на стороне сервера, проверяющая ключи с базой данных всех выданных ключей, так что вы не сможете сгенерировать ключи, даже если у вас есть алгоритм (давайте проигнорируем его взлом).
С этого момента у вас может быть два разных подхода, но в любом случае что-то очень важно:
Что касается фактических путей:
Требовать, чтобы хешированный ключ (см. Выше) был отправлен во время процедуры аутентификации / входа в систему.
В качестве альтернативы (IMO лучше, хотя многим не нравится этот тип "DRM"): вообще не используйте ключ в клиенте. Вместо этого потребуйте, чтобы пользователь вошел в учетную запись и требуется действительный ключ CD (для этого требуется база данных, указанная выше) для создания учетных записей. Вот как современные игры, например любая платная MMORPG, справляются с этим.
Лично я бы выбрал учетную запись по простой причине: в конце концов, вы не можете удержать людей от кражи ключей CD (брутфорс, реверс-инжиниринг или мошенничество). Люди могут просто создать новый ключ, чтобы продолжить играть или заблокировать других в игре. С ключами, привязанными к учетной записи, никто не может ничего сделать с ключом, который уже используется. В случае, если кто-то купил ключ, сгенерированный кем-то другим, вы все равно можете передать право собственности на аккаунт, если есть достаточные доказательства этого.
источник
Pangea Software - создатель нескольких игр для Mac - написал тему о защите от копирования в своей (теперь бесплатной) книге по разработке игр. В книге также объясняется, как бороться с пиратскими ключами и другими взломами, которые используют люди. Книга посвящена разработке игр для Mac, но идеи могут быть полезны и для других платформ. В книгу входит исходный код каждой главы, часть загрузки приведена ниже. Также имеется исходный код (написанный на C), связанный с защитой от копирования.
Книгу можно скачать здесь .
источник