I'm building an iOS app but my app binary shows all my NSStrings that I've. Is there a way to encrypt it ? I want to hide all my NSStrings from my app binary file.
-
Heres an option: http://stackoverflow.com/a/3919783/2446155 – Andrew May 18 '14 at 20:15
-
Another option: http://stackoverflow.com/a/6211290/2446155 – Andrew May 18 '14 at 20:16
-
Try doing hex-text and binary encoding, and just reverse the process to get the NSString? – Nate Lee May 18 '14 at 20:20
-
@user3638590 See my comment to an answer about value. – zaph May 18 '14 at 21:51
2 Answers
You would not be able to encrypt your app binary in an secure way. You would at least need to pass the key next to the application bundle so the operating system would be able to encrypt the application before running it. And when you pass the key next to the application somebody interested in your application would be able to decrypt it too. So encrypting the whole binary file would be useless.
Do you ship passwords or API keys with your app bundle?
The best deal would be to redesign your application so such stuff isn't needed. You could try to prevent user from reading them directly out of your binary file, but they would always be able to get them. A couple of very smart guys have already tried that and failed, so don't waste your time trying to be better then them. So don't ship passwords or API keys!
If you still want to ship sensitive data in your binary:
You could give the following a try:
NSString *encryptedSensitiveString = @"mysensitivdatapreviosulyencpryted"; // <- this will be stored in your binary since it's a constant string
NSString *sensitiveString = [someHiddenKey decryptString:encryptedSensitiveString];
// Now you can use your sensitive string which is decrypted at runtime
If you are looking for some cryptography library for Objective-C you can use MIHCrypto framework based on OpenSSL.

- 11,765
- 7
- 42
- 85
-
How _would_ you redesign your application so API keys aren't needed in the binary? – Andrew May 18 '14 at 21:34
-
3@Santa First answer these questions: What are you protecting? Who want's it and how much are they willing to pay or do to get it. What is the value to the person who owns it. For example if you are trying to protect against a government and they really want it: give up. If you are protecting against a nosy kid, obfuscate. – zaph May 18 '14 at 21:49
-
1@Santa By limiting the API to only allow the same actions the user could do via the user interface anyway. For example: Don't grant access to an database from app and instead provide an web service which interface only allows expected actions will prevent you from shipping database credentials. This example is adoptable for most other security problems too. – miho May 18 '14 at 22:07
-
-
No need to import a third-party cryptographic library; Apple has included `CommonCrypto` in iOS since iOS 5. Link to cryptographic services guide: https://developer.apple.com/library/mac/documentation/security/conceptual/cryptoservices/GeneralPurposeCrypto/GeneralPurposeCrypto.html – Robotic Cat May 19 '14 at 00:36
-
@user3638590 Of course there is an simple way to encrypt strings. But as stated above, it's useless if you ship the key to decrypt it next to it. As mentioned by @Zaph `a nosy kid` would be the only one you would prevent from catching your keys. Anybody who has knowledge about how to use the debugger would be able to fetch your keys when you store them encrypted and ship the key next to it. – miho May 19 '14 at 07:29
-
that's to say, if I can get the hiddenKey and encrypted string, I still can get it decrypted. so how to hide the key? – PeiSong Oct 16 '14 at 03:01
As someone already stated, building or decrypting the strings dynamically is one choice.
Another is to use a 3rd party app protection system, like Arxan. I have never personally used it so can't really recommend it, but it does all sorts of obfuscation to prevent users from peeking into your app.

- 9,650
- 2
- 38
- 34