Comments 34
Спасёт ли это от Locallappstore?
К сожалению, еще не изучал механизм покупок в AppStore. Поэтому написал только про Google Play.
Нет, на сколько я знаю все актуальные программы для подделки IAP на iOS умеют так же подделывать сервер верификации. Для защиты от подобных программ надо передавать и верифицировать покупки на сервере. При чем некоторые программы для взлома могут отдавать валидные ключи верификации, просто, например, от другого приложения. Поэтому сервер должен полностью проверять ответ от эпла.
Не VIKey, а IVKey (IV — initialization vector)
Очепятка, поправил, спасибо!
З.Ы. Да и не ключ это таки совсем, а вектор инициализации. Если придираться к терминологии.
По сути — таже соль только для алгоритма шифрования.
По сути — таже соль только для алгоритма шифрования.
IV оставлять константой не правильно. Он нужен для того что бы одинаковые данные зашифрованные тем же ключем выглядели по разному. А у вас тут уязвимость.
Согласен. По гадлайнам нужно каждый раз при шифровании генерировать случайный IV и хранить его вместе с зашифрованным сообщением. Допишу в TODO.
Вообще говоря нет, это если Mode == CipherMode.ECB (самый небезопасный), то одинаковые последовательные блоки шифровались бы одинаковыми блоками. А при других значениях будет по-другому.
UFO just landed and posted this here
UFO just landed and posted this here
VIKey хранится в приложении. Его, конечно, можно дополнительно закрыть. Но считаем, что если взломщик дошел до анализа и модификации исполняемого кода, то тут уже ничто не поможет. Халявные плюшки ему за труды)
В векторе инициализации мало смысла, если он хранится в открытом виде и может быть извлечен атакующим.
Бред.
Вы бы почитали сперва зачем этот вектор и как влияет на шифротекст. Можете здесь.
Спасибо за статью! Часть про проверку подписи маркета многим пригодится.
Внутри-игровые покупки вообще ставят разработчика в неудобное положение — с одной стороны, все, что связано с деньгами, однозначно нужно проверять на сервере. С другой — что, если это однопользовательская игра и сервера просто нет?
Пока все выгладит так, будто любая игра, которая хранит данные о купленом контенте на клиенте, может оказаться где-нибудь на 4pda, в виде apk файла с фичей «энергия бесконечна, все премиумные шмотки уже куплены». Есть подозрение, что тут нужно уже не просто «прятать» переменные, но закладывать дополнительные проверки в игровой механике.
Если бы кто-то поделился опытом разруливания такой ситуации — было бы очень здорово. Очень интересный момент.
Внутри-игровые покупки вообще ставят разработчика в неудобное положение — с одной стороны, все, что связано с деньгами, однозначно нужно проверять на сервере. С другой — что, если это однопользовательская игра и сервера просто нет?
Пока все выгладит так, будто любая игра, которая хранит данные о купленом контенте на клиенте, может оказаться где-нибудь на 4pda, в виде apk файла с фичей «энергия бесконечна, все премиумные шмотки уже куплены». Есть подозрение, что тут нужно уже не просто «прятать» переменные, но закладывать дополнительные проверки в игровой механике.
Если бы кто-то поделился опытом разруливания такой ситуации — было бы очень здорово. Очень интересный момент.
Спасибо большое. Как раз пришло время реализовывать защиту данных в игре.
А почему бы не пользоваться SecureString, вместо своих велосипедов по шифрованию памяти?
Потому, что это Mono, а не .Net
SecureString тут не имплементирован и находится в TODO:
github.com/mono/mono/blob/master/mcs/class/corlib/System.Security/SecureString.cs#L42
SecureString тут не имплементирован и находится в TODO:
github.com/mono/mono/blob/master/mcs/class/corlib/System.Security/SecureString.cs#L42
XML не советую, т.к. возникнут проблемы с iOS
?
Вкратце — в iOS нет Reflection, т.к. .NET для iOS основана на технологии AOT. При реализации приходится самому переопределять и реализовывать методы для составления и разбора словаря.
Вкратце, это не так, потому что AOT без метаданных не работает, сборки всегда включены в готовое приложение и Reflection на iOS функционирует в той или иной мере (а может и на 100%, не проверял полностью).
Если детально, то утверждение «не пользуйтесь XML, у него проблемы в iOS» не корректно, пока жив и работает System.Xml (а появился он 13 лет назад, работает буквально везде на Mono/.Net и отмирать начал лишь сейчас на WinRT/WP в сторону System.Xml.Linq). Вопрос удобства и разбора уже тема отдельная, но всяко лучше строки с сепараторами :)
P.S. По существу статьи как раз комментариев нет и холивар тут разводить не о чем. Просто утверждение уж очень категоричное было.
Если детально, то утверждение «не пользуйтесь XML, у него проблемы в iOS» не корректно, пока жив и работает System.Xml (а появился он 13 лет назад, работает буквально везде на Mono/.Net и отмирать начал лишь сейчас на WinRT/WP в сторону System.Xml.Linq). Вопрос удобства и разбора уже тема отдельная, но всяко лучше строки с сепараторами :)
P.S. По существу статьи как раз комментариев нет и холивар тут разводить не о чем. Просто утверждение уж очень категоричное было.
Я имел ввиду, что начинающий пользователь обязательно наткнется на проблемы при работе с XML. Об ограничениях на iOS подробно написано тут: developer.xamarin.com/guides/ios/advanced_topics/limitations/
Все-равно не понимаю. На какие проблемы он натолкнется? По ссылке ничего про XML нет, по опыту скажу, что никаких проблем с XML я за последние годы не замечал. Вот с SQLite есть проблемы, но это отдельный раговор.
Если же начинающий пользователь не умеет вообще работать с XML, но отлично оперирует с JSON и AES шифрованием, то я вообще отстал от жизни :)
Если же начинающий пользователь не умеет вообще работать с XML, но отлично оперирует с JSON и AES шифрованием, то я вообще отстал от жизни :)
Вот с SQLite есть проблемы, но это отдельный раговор.
Можно по точнее какие проблемы? — уже как полгода перевел действующий проект на хранение данных в Sqlite? проект на ios, android… проблем с Sqlite не обнаружено, использовал Sqlitekit — который базируется на порте Sqlite под C# ( https://code.google.com/archive/p/csharp-sqlite/ ) что позволяет без препятственно использовать Sqlite на (почти любой платформе)… Собственно на ios, android — 100% работает
В целом, прошло более двух лет с того сообщения, а проблема была еще на год-полтора раньше. Вполне может быть, что все это уже не актуально
Расскажу кратко о своей ситуации: из-за особенностей дизайна программы, она хранит кучу разных данных и дополнительно таблицу с блобами. В итоге файл .db получается достаточно большой, около 5 мегабайт. При этом размере, и System.Data.SQLite и Mono.Data.Sqlite (оба — объектно-ориентированные интерфейсы к libsqlite3) начинают существенно тормозить и периодически не закрывать транзакции при постоянном пересоздании SqliteConnection. Возможно дело было в таймаутах, многопоточности или чем-то еще, но уже разобраться было почти не возможно. В качестве решения я сделал пул SqliteConnection и принудительную однопоточность, что есть костылем костыльным. В следующих приложениях были не такие размеры, да и меньше работы с базой (кеширование вместо постоянного чтения/записи и т.д.), проблема больше не возникала.
P.S. Подход с встраиванием в свое приложение отдельной реализации Sqlite я не очень поддерживаю. Как минимум, нативная и динамически загружаемая libsqlite3.so (.dylib) может иметь более актуальную версию с правками от разработчиков. Как максимум, прекомпилированная C версия работает быстрее.
Расскажу кратко о своей ситуации: из-за особенностей дизайна программы, она хранит кучу разных данных и дополнительно таблицу с блобами. В итоге файл .db получается достаточно большой, около 5 мегабайт. При этом размере, и System.Data.SQLite и Mono.Data.Sqlite (оба — объектно-ориентированные интерфейсы к libsqlite3) начинают существенно тормозить и периодически не закрывать транзакции при постоянном пересоздании SqliteConnection. Возможно дело было в таймаутах, многопоточности или чем-то еще, но уже разобраться было почти не возможно. В качестве решения я сделал пул SqliteConnection и принудительную однопоточность, что есть костылем костыльным. В следующих приложениях были не такие размеры, да и меньше работы с базой (кеширование вместо постоянного чтения/записи и т.д.), проблема больше не возникала.
P.S. Подход с встраиванием в свое приложение отдельной реализации Sqlite я не очень поддерживаю. Как минимум, нативная и динамически загружаемая libsqlite3.so (.dylib) может иметь более актуальную версию с правками от разработчиков. Как максимум, прекомпилированная C версия работает быстрее.
Все помнят такую PC программу, как ArtMoney? Она умела искать значения в RAM и за несколько итераций отсеивания позволяла стать миллионером в игре.
- Если игра сетевая, то главная защита должна быть на сервере, а на клиенте нужно защищать протокол общения с сервером. Деньги у игрока появляются после подтверждения неких действий сервером, а не игрок серверу указывает сколько у него денег.
- Если игра локальная и юзер облегчит себе игровой процесс, то это его сознательный выбор. Может он хочет таким образом побыстрее выиграть все бонусы и избавиться от игровой зависимости к данной игре ;)
- Если Вы хотите добиться рабства от игрока, тогда соглашусь… шифруйте все и вся. Заодно юзер будет вынужден прикупить аппарат попроизводительнее.
Удобно получается, если методами Encrypt и Decrypt расширить string.
public static string Encrypt(this string value, string password)
{
return Encrypt(Encoding.UTF8.GetBytes(value), password);
}Sign up to leave a comment.
Защита игр и мобильных приложений от взлома для чайников (Unity, C#, Mono)