Защита игр и мобильных приложений от взлома для чайников (Unity, C#, Mono)

[spbdimka]

Спасёт ли это от Locallappstore?

[natexriver]

К сожалению, еще не изучал механизм покупок в AppStore. Поэтому написал только про Google Play.

[r1zar]

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

[REU]

Не VIKey, а IVKey (IV — initialization vector)

[natexriver]

Очепятка, поправил, спасибо!

[Propheta13]

З.Ы. Да и не ключ это таки совсем, а вектор инициализации. Если придираться к терминологии.
По сути — таже соль только для алгоритма шифрования.

[Nirvano]

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

[natexriver]

Согласен. По гадлайнам нужно каждый раз при шифровании генерировать случайный IV и хранить его вместе с зашифрованным сообщением. Допишу в TODO.

[KvanTTT]

Вообще говоря нет, это если Mode == CipherMode.ECB (самый небезопасный), то одинаковые последовательные блоки шифровались бы одинаковыми блоками. А при других значениях будет по-другому.

[natexriver]

Среди моих знакомых Unity-программистов большинство пишет на C#. Насчет JSON — если использовать реализацию SimpleJSON, то все так же просто, как и в php, foreach тоже будет работать. Дело привычки.

[natexriver]

Там есть геттер AsArray

[natexriver]

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

[Propheta13]

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

Бред.
Вы бы почитали сперва зачем этот вектор и как влияет на шифротекст. Можете здесь.

[Propheta13]

Я всё это прекрасно знаю.
Тут проблема в выборе режима алгоритма для конкретной задачи а не в том что IV открыт.
Не нужно людей вводить в заблуждение.

[VlaZ]

Спасибо за статью! Часть про проверку подписи маркета многим пригодится.
Внутри-игровые покупки вообще ставят разработчика в неудобное положение — с одной стороны, все, что связано с деньгами, однозначно нужно проверять на сервере. С другой — что, если это однопользовательская игра и сервера просто нет?
Пока все выгладит так, будто любая игра, которая хранит данные о купленом контенте на клиенте, может оказаться где-нибудь на 4pda, в виде apk файла с фичей «энергия бесконечна, все премиумные шмотки уже куплены». Есть подозрение, что тут нужно уже не просто «прятать» переменные, но закладывать дополнительные проверки в игровой механике.
Если бы кто-то поделился опытом разруливания такой ситуации — было бы очень здорово. Очень интересный момент.

[Agent_Smith]

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

[MuXaJIbI4]

Спасибо большое. Как раз пришло время реализовывать защиту данных в игре.

[andreishe]

А почему бы не пользоваться SecureString, вместо своих велосипедов по шифрованию памяти?

[natexriver]

Потому, что это Mono, а не .Net
SecureString тут не имплементирован и находится в TODO:
github.com/mono/mono/blob/master/mcs/class/corlib/System.Security/SecureString.cs#L42

[Nomad1]

XML не советую, т.к. возникнут проблемы с iOS

?

[natexriver]

Вкратце — в iOS нет Reflection, т.к. .NET для iOS основана на технологии AOT. При реализации приходится самому переопределять и реализовывать методы для составления и разбора словаря.

[Nomad1]

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

Если детально, то утверждение «не пользуйтесь XML, у него проблемы в iOS» не корректно, пока жив и работает System.Xml (а появился он 13 лет назад, работает буквально везде на Mono/.Net и отмирать начал лишь сейчас на WinRT/WP в сторону System.Xml.Linq). Вопрос удобства и разбора уже тема отдельная, но всяко лучше строки с сепараторами :)

P.S. По существу статьи как раз комментариев нет и холивар тут разводить не о чем. Просто утверждение уж очень категоричное было.

[natexriver]

Я имел ввиду, что начинающий пользователь обязательно наткнется на проблемы при работе с XML. Об ограничениях на iOS подробно написано тут: developer.xamarin.com/guides/ios/advanced_topics/limitations/

[Nomad1]

Все-равно не понимаю. На какие проблемы он натолкнется? По ссылке ничего про XML нет, по опыту скажу, что никаких проблем с XML я за последние годы не замечал. Вот с SQLite есть проблемы, но это отдельный раговор.
Если же начинающий пользователь не умеет вообще работать с XML, но отлично оперирует с JSON и AES шифрованием, то я вообще отстал от жизни :)

[patch1]

Вот с SQLite есть проблемы, но это отдельный раговор.

Можно по точнее какие проблемы? — уже как полгода перевел действующий проект на хранение данных в Sqlite? проект на ios, android… проблем с Sqlite не обнаружено, использовал Sqlitekit — который базируется на порте Sqlite под C# ( https://code.google.com/archive/p/csharp-sqlite/ ) что позволяет без препятственно использовать Sqlite на (почти любой платформе)… Собственно на ios, android — 100% работает

[Nomad1]

В целом, прошло более двух лет с того сообщения, а проблема была еще на год-полтора раньше. Вполне может быть, что все это уже не актуально
Расскажу кратко о своей ситуации: из-за особенностей дизайна программы, она хранит кучу разных данных и дополнительно таблицу с блобами. В итоге файл .db получается достаточно большой, около 5 мегабайт. При этом размере, и System.Data.SQLite и Mono.Data.Sqlite (оба — объектно-ориентированные интерфейсы к libsqlite3) начинают существенно тормозить и периодически не закрывать транзакции при постоянном пересоздании SqliteConnection. Возможно дело было в таймаутах, многопоточности или чем-то еще, но уже разобраться было почти не возможно. В качестве решения я сделал пул SqliteConnection и принудительную однопоточность, что есть костылем костыльным. В следующих приложениях были не такие размеры, да и меньше работы с базой (кеширование вместо постоянного чтения/записи и т.д.), проблема больше не возникала.

P.S. Подход с встраиванием в свое приложение отдельной реализации Sqlite я не очень поддерживаю. Как минимум, нативная и динамически загружаемая libsqlite3.so (.dylib) может иметь более актуальную версию с правками от разработчиков. Как максимум, прекомпилированная C версия работает быстрее.

[HomoLuden]

Все помнят такую PC программу, как ArtMoney? Она умела искать значения в RAM и за несколько итераций отсеивания позволяла стать миллионером в игре.

• Если игра сетевая, то главная защита должна быть на сервере, а на клиенте нужно защищать протокол общения с сервером. Деньги у игрока появляются после подтверждения неких действий сервером, а не игрок серверу указывает сколько у него денег.
• Если игра локальная и юзер облегчит себе игровой процесс, то это его сознательный выбор. Может он хочет таким образом побыстрее выиграть все бонусы и избавиться от игровой зависимости к данной игре ;)
• Если Вы хотите добиться рабства от игрока, тогда соглашусь… шифруйте все и вся. Заодно юзер будет вынужден прикупить аппарат попроизводительнее.

[SherlockD]

Удобно получается, если методами Encrypt и Decrypt расширить string.

        public static string Encrypt(this string value, string password)
        {
            return Encrypt(Encoding.UTF8.GetBytes(value), password);
        }

[natexriver]

Ну это уже на ваш вкус)