Насколько безопасен plist, включенный в мой проект xcode после компиляции?

Если я сохраняю важные значения в plist в xcode, это менее безопасно, чем если бы это было жестко закодировано в классе? Могли ли сломанные устройства тюрьмы легко испортить эти ценности? Я знаю, что существует определенный уровень риска во всем, но может ли кто-то объяснить относительные риски плоского файла против жестко закодированных значений (в MyClass.м файл)?

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

5 2
ios security compilation plist

5 ответов:

Что касается считывания данных:

Данные Plist совсем не безопасны - получение содержимого plist практически не занимает времени! (и поскольку ipa - это просто переименованный zip, вам даже не нужно устройство ;))

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

Что касается написания к нему:

Данные, которые вы доставляете, никогда не могут быть записаны без нарушения подписи кода. Поэтому любой метод хорош. Часто один корабль Базы данных CoreData при использовании CD, но я также использую xmld, jsons, plist.. чтобы доставить мое содержание. все, что наилучшим образом соответствует потребностям

Примечание: взлом подписи кода делает приложение непригодным для использования на обычном устройстве iOS, но я думаю, что оно останется пригодным для использования на джейлбрейкнувшем телефоне, поскольку ядро действительно не проверяет подпись там

3

Значения, хранящиеся в исходных файлах (.м) безопасны, к ним довольно трудно получить доступ. С другой стороны, доступ к plist-списку приложения, источникам изображений и другим файлам довольно прост, для этого есть программы (например, Iexplorer), и он вообще не должен быть взломан.

Поэтому, если у вас есть конфиденциальная информация, хранящаяся в вашем plist, стоит закодировать файл или сохранить его в исходном коде.

0

Любой может получить доступ к a .файл plist. Но если жестко закодировано в классе намного безопаснее, используйте второй вариант. Ничто не является 100% безопасным, но жестко закодированным в классе, если кто-то хочет получить доступ к этому значению, работа более трудная.

0

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

Преобразование NSDictionary в NSData: 

NSData *someDatas = [NSKeyedArchiver archivedDataWithRootObject:aDictionary];

Преобразование NSData в NSDictionary: 

NSDictionary *aDictionary = (NSDictionary*) [NSKeyedUnarchiver unarchiveObjectWithData:someDatas];

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

0

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

В кавычках:

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

Наличие значений, жестко закодированных в коде или в файле plist, безусловно, считается рискованным.

0