Как я могу полностью скрывать и защищать строки от игрока в Unity?

Я использую Unity для создания 2D-игры, которая будет полностью автономной (в чем проблема), для игры требуется, чтобы вы вводили определенные строки на определенных уровнях, а Unity компилируется в библиотеки DLL, которые можно легко отменить , так есть ли способ защитить эти строки (игра отключена, поэтому я не могу извлечь из другого источника)?

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

Его можно декомпилировать следующим образом: «введите

46 голосов | спросил TheBinaryGuy 24 52017vEurope/Moscow11bEurope/MoscowFri, 24 Nov 2017 21:42:32 +0300 2017, 21:42:32

4 ответа


155

Не храните эти строки, сохраняйте (криптографический) хэш из них.

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

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

Предупреждение (Эрик Липперт): НЕ ИСПОЛЬЗУЙТЕ встроенную функцию GetHashCode как таковую функцию - ее результат может различаться между различными версиями .NET и платформами, что делает ваш код работать только по конкретным. NET версии и платформы.

ответил user49822 24 52017vEurope/Moscow11bEurope/MoscowFri, 24 Nov 2017 23:42:26 +0300 2017, 23:42:26
104

То, что вы пытаетесь сделать, бесполезно и бессмысленно.

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

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

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

ответил Philipp 24 52017vEurope/Moscow11bEurope/MoscowFri, 24 Nov 2017 22:44:53 +0300 2017, 22:44:53
4

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

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

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

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

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

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

Итак ... прежде чем вы что-то сделаете, подумайте очень внимательно, хотите ли вы этого и чего хотите. Вполне возможно, что человеческие читаемые строки (или тривиально сделанные «нечитаемые» с xor) достаточно хороши и действительно предпочтительны.

ответил Damon 28 22017vEurope/Moscow11bEurope/MoscowTue, 28 Nov 2017 13:30:54 +0300 2017, 13:30:54
3

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

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

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

  1. Медведь прошел через мой дом.
  2. Мой дом защитил меня от медведя

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

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

ответил user1118321 24 52017vEurope/Moscow11bEurope/MoscowFri, 24 Nov 2017 23:17:05 +0300 2017, 23:17:05

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132