Способы шифрования архива в C++

Question

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

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

Мой вопрос заключается в следующем: Будет ли легче сжать все файлы и:

1. Установить пароль к нему (как защищенный паролем ZIP), а затем ввести пароль, когда программа нуждается в этом
2. зашифровать архив с Crypto ++ или аналогичный
3. Изменить заголовок файла немного как «импровизированного» шифрования, и исправить заголовки для каждого файла, когда файл загружен

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

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

Answer 1

Я думаю, вы неправильно понимаете возможности, возникающие при шифровании.

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

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

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

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

И вы знаете, что это хуже? Люди, вероятно, предпочитают треснувшие версию, потому что освобожденные от бремени всех этих мер «безопасности» он будет работать быстрее ...

Примечания: да, это незаконно, но давайте быть прагматичным ...

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

Итак, как вы предоставляете защищенное обслуживание?

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

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

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

Answer 2

Если бы мне пришлось выбирать из трех вариантов, я бы пошел на Crypto ++, так как он отлично вписывается в C++ iostreams.

Но: вы

• Сериализация данных в XML
• сжимая его
• шифрованием

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

Шифрование может быть добавлено через различные расширения (SEE или SQLCipher). Это безопасно, быстро и полностью прозрачно.

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

Answer 3

Установка пароля к нему (как защищенный паролем ZIP), а затем ввести пароль, когда программа нуждается в этом

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

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

Теперь, в другие пункты. zlib does not support encryption и как указано, PKZip is rather broken anyway. Я подозреваю, что если вы так склонны его найти, вы, вероятно, найдете библиотеку zip/compression, способную обрабатывать шифрование. (ZipArchive Я считаю, что это Zip + AES, но вам нужно заплатить за это).

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