Поскольку структура IPA представляет собой просто заархивированный файл, содержащий скомпилированные коды и мультимедийное содержимое, такое как изображения и аудио, как я могу защитить содержимое от извлечения и кражи другими? Есть ли какое-либо шифрование, которое я могу добавить в IPA?
Шифрование содержимого в скомпилированном приложении iOS (IPA)
Ответы (1)
В этом ответе упоминается, что приложение уже зашифровано к тому времени, когда оно попадает на устройства ваших пользователей: Изменяет ли Apple исполняемые файлы приложений iOS в приложениях, отправленных в App Store?
Извините, это только бинарный файл приложения. Другие носители не зашифрованы, и нет никакого способа зашифровать .ipa. Вы можете попробовать зашифровать свои изображения и другие медиафайлы в своей системе, предоставив кучу кода приложения для расшифровки этих ресурсов при запуске приложения, и тогда ваш код дешифрования станет частью зашифрованного двоичного файла приложения. Однако вы не можете отправить зашифрованный IPA, это должен быть файл, напрямую выведенный из Xcode.
В ответ на ваш комментарий я использовал в прошлом CommonCrypto. Вы можете использовать эту криптографическую библиотеку в качестве отправной точки.
Простой пример использования вышеизложенного:
NSError *error;
NSMutableData *encryptedData = [NSMutableData dataWithContentsOfFile:pathToEncryptedFile];
NSData *decryptedData = [RNDecryptor decryptData:encryptedData
withPassword:@"SuperSecretDecryptionKey"
error:&error];
UIImage *decryptedImage = [UIImage imageWithData:decryptedData];
ВАЖНОЕ ЗАМЕЧАНИЕ: ЕСЛИ кто-то запустит утилиту strings
на вашем .app
на взломанном iphone или даже на iPhone, к файловой системе которого есть доступ через USB, он получит список всех строк, объявленных в ваше приложение. Сюда входит «SuperSecretDecryptionKey». Таким образом, вы можете захотеть использовать целое число, число с плавающей запятой или другую константу для создания на лету ключа расшифровки строки или убедиться, что строка, которую вы используете для расшифровки, точно такая же, как обычная системная строка, поэтому никто не подозревает, что это истинный ключ. Безопасность через неясность в данном случае выгодна.
Чтобы зашифровать/расшифровать файлы *.strings
, вы должны каким-то образом зашифровать строки ключа и значения (возможно, таким, который возвращает вам шестнадцатеричный код или любые буквенно-цифровые символы), и когда вы хотите получить доступ к заданному значению, скажем, LicenceNumber
, сделайте это:
NSError *error;
NSData *unencryptedKey = [@"LicenceNumber"
dataUsingEncoding:NSUTF8StringEncoding];
NSData *encryptedKey = [RNEncryptor encryptData:unencryptedKey
withSettings:kRNCryptorAES256Settings
password:@"SuperSecretEncryptionKey"
error:&error]
NSData *encryptedValue = [[NSBundle mainBundle]
localizedStringForKey:[NSString
stringWithUTF8String:[encryptedKey bytes]]
value:@"No licence"
table:@"EncryptedStringsFile"];
NSData *decryptedValue = [RNDecryptor decryptData:encryptedValue
withPassword:@"SuperSecretDecryptionKey"
error:&error];
*.strings
.
- person ; 21.08.2012
strings
на скомпилированном и подписанном .app
еще в 2011 году и нашел свой ключ дешифрования. Возможно, с тех пор Apple изменила процесс подписи, чтобы скрыть эти строки. Несмотря на это, все же более безопасно иметь ключ дешифрования, сгенерированный во время выполнения, чем хранить предварительно сгенерированный.
- person ; 13.05.2016