Облегченная проверка файлов с помощью PKI

Question

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

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

1. Использование средств ОС для блокировки всех файлов ресурсов для записи при запуске процесса, поэтому другие процессы не могут перезаписать файлы послеfact.
2. Рассчитайте суммы MD5 для каждого файла ресурсов.
3. Подключитесь к серверу https, требуя проверки определенного подписанного сертификата, хранящегося в исполняемом файле клиента.
4. Загрузитефайл через https, содержащий «правильные» хэши, хранящий его в оперативной памяти (не на диске).
5. Сравните вычисленные хэши с полученными по https.
6. Выйдите, если хэши неmatch.

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

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

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

Мой второй вопрос: что такое бесплатная (как в свободно распространяемой ИЛИ свободе) библиотека, которую можно вызывать из Win32 C ++ (компилятор Visual Studio 2010) для выполнения этих задач?Могут ли они быть реализованы с помощью встроенных API-интерфейсов Windows или требуется стороннее решение?

Итак, вкратце, вопросы: 1. Достаточно ли надежна предложенная мной схема, чтобы сбить с толку большинство сценаристов?и 2. Какие зависимости или библиотеки я бы использовал для его реализации?

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

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

Спасибо!

Answer 1

Мне нравится ваше решение. Это хорошо продумано. По сути, вы отвечаете на свои вопросы. У меня есть несколько предложений, на которые следует обратить внимание.

Библиотеки Win32, наиболее подходящие для вашей задачи, - Windows Crypto API для хеширования. Он также поддерживает SHA-1, который я бы порекомендовал (так как MD5 считается уязвимым и взломанным в наши дни). Вы также можете посмотреть на использование HMAC с SHA1, чтобы вычисляемый хеш содержал секретный ключ (встроенный в код).

Wininet - подходящая библиотека для скачивания. Я считаю, что он поддерживает HTTPS с проверкой сертификата.

Windows API CreateFile для открытия файла может существенно блокировать файлы содержимого. Просто откройте все файлы без указания каких-либо флагов FILE_SHARE_ *.

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

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

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

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

bool IsContentValid()
{
   // compare the local hash with the hash returned from the https response
   return (0 == memcmp(local_hash, network_hash, sizeof(HASH)));
}

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

Один очевидный обходной путь состоит в том, чтобы различные варианты этой функции были связаны с различными областями кода игры и периодически вызывались во время игры. Реализуйте эту проверку с помощью макроса #define C вместо функции. Реализуйте 10 различных вариантов кода как 10 различных макросов. Назовите эти макросы в 50 различных местах кода - так, чтобы хакер должен был найти их все (и исправить их), чтобы добиться успеха. Сделайте так, чтобы, если контент считался недействительным, игра ведет себя с ошибками. Например, если его файлы содержимого недействительны, здоровье игрока и стоимость боеприпасов случайным образом обнуляются, так что его легко убить!

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

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

4) Еще один хитрый взлом, который выигрывает время: проверка хэша как самого EXE-файла, так и содержимого (как локального, так и сетевого).

5) Используйте другой хэш содержимого и используйте exe-код в качестве простого криптографического ключа для цифровой подписи всех сетевых сообщений на сервере. Вы можете просто добавить к сетевому сообщению: your_simple_fash_hash (content_hash, exe_hash, network_message). Сервер делает то же самое для всех полученных сетевых сообщений. Реализуйте разные версии этого хеш-кода / подписи для разных типов сетевых сообщений. Посмотрите на хэш Murmur в качестве примера быстрой хеш-функции. Теперь хакер тоже должен взломать сетевой код!

6) Хакеру сложно разобрать код игры, используя Softice или любой другой вид отладчика ядра. Любые переменные, используемые для хранения хэшей проверки содержимого (или любых крипто-ключей), также должны быть зашифрованы. Одна хитрая защита - XOR всех важных переменных с 0xAAAAAAAA (или некоторый другой шум) при сохранении их в оперативной памяти. Когда вам нужно использовать эти значения, выполните XOR их обратно во временную переменную, используйте их приблизительно, затем обнулите результат, как только вы закончите вычисления. В дополнение к хэш-файлам содержимого также должны обрабатываться переменные для здоровья игроков, топлива и боеприпасов.

7) Если возможно, найдите умный способ перемещения важных переменных в ОЗУ таким образом, чтобы они никогда не сохранялись в одной и той же ячейке памяти в течение всей игры.

Хорошо, это мозговая утечка. Больше, чем мне нравится писать для кого-то, у кого есть только 1 очко репутации в стеке Надеюсь, это поможет.