Security is a big issue with banks, especially since the famous Citibank problem. It shows how important is the security with apps, as basically now money is digital.

From Apple side, now, even if FBI brings a phone of a suspect to Apple with the intention to get the content on the phone, Apple would not be able to (iOS Security Guide). Apple has decided to encrypt the contacts, emails, messages and photos, among other things.

Some of Apple security measures:

  1. Code-signing for each page
  2. System Software Authorization: which blocks a device from downgrading to previous versions of OS (to exploit vulnerability issue).
  3. Secure Enclave coprocessor (a new processor that is designed for security – protects even if the phone is jailbroken)
  4. Touch ID
  5. Dedicated AES 256 crypto engine built (making cryptography very efficient)
  6. UID unique-device-id (fused) and GID (compiled) into application processor during manifacturing (data is specific to device, so moving memory chips/flash drive to another computer you can’t read it).
    1. No software or firmware can read the UID directly,
    2. remember UUID is not available since iOS7, but  UUID probably is just an encryption result based on real UID.
  7. Effaceable Storage: (erasable place to store all the per-file keys) specifically designed secure erasing for flash drive (flash drive use wear-levelling technique, which balances the writing over the whole accessible memory, even re-writing the whole disks may not be perfect) – therefore the best way is to use encrypted drive and securely erase the key.
  8. There are 2 keys used to encrypt the file: ClassKey and Per-file key.

Screen Shot 2015-01-08 at 12.15.18 pm



Basics of Security Issues

When the device is locked, some of the folders can be encrypted and therefore won’t be open to access from anyone, including the app. Each of the app in iOS system has his own sandbox space, in it stored are the files, preferences and network resources. Each app is given a unique ApplicationID and stored in /ApplicationRoot/ApplicationID/

However, there is no app that is completely secure, and with the help of a jailbroken phone, there are more ways to circumvent security mechanisms of Apple. And if your apps are money-related apps, definitely you have to investigate how the apps can be hacked on a jailbroken phone. See the danger of a jailbroken phone.

Using Terminal (or iExplorer), you can go into the directory of your app on the phone, command line like

cd `ls -tr | tail -n 1` // go in the most recent created directory;
go into App
and then otool -L App\ Name // see what frameworks the bundle links to

class-dump-z App\ Name > look.txt // you will see the skeleton of the app – not only the public interfaces, even the private methods, instance variables, protocols …

However, it’s not easy for just anyone to use class-dump, as Apple AppStore binary with FairPlay encryption- but there are tools to do it, hackers can easily do it. So, be prepared to have the skeleton exposed.

Don’t save in plist/ NSUserDefaults

Saving any detail in a plist is dangerous, using plutil -p Name.plist to look and use open to open the plist, this is too easy change. NSUserDefaults are also plist, the location is

 {App Directory}/Library/Preferences/{Bundle Identifier}.plist


  1. Encrypt data before saving into plist. But be careful as the decrypt function can also be run by the attackers to decrypt the encrypted data.
  2. Migrate to Keychain – this is harder to crack, but on jailbroken phones there are command line utils to print out Keychain database, so:
    1. Encrypt using Apple’s Common Crypto APIs – now, with Keychain Data Protection enhanced by Apple,
    2. Don’t hardcode encryption key – a long string in the binary is quite suspicious to hackers. Instead, make unique encryption key based on each device.  (strings is the command that will go over the binary and print out all the items that qualify as string)

Charles can intercept SSL 

Your Https data communication can be intercepted, so all the data sent and received will be exposed through Charles.

Runtime Manipulation

It is not hard to perform runtime manipulation once you have access to the skeleton and know which functions can be called on the views.

> gdb -q #launch debugger

(gdb) attach –waitfor “App Name” #wait to attach to process AN

(gdb) b viewDidLoad #set breakpoints on viewDidLoad, >1 # use 1 to confirm breakpoints

(gdb) c to continue

(gdb) call [[CurrencyManager sharedSingleton] addMore]

There is a way to check if program is being debugged, but to guard against runtime manipulation, better enable the security check in the singletons (and other security-critical sections).

#ifndef DEBUG



This is a preprocessor of NSObject, we use it in release mode to protect against Runtime Manipulation. A more heavy approach is using ptrace(PT_DENY_ATTACH, 0, 0, 0);  to deny any attachment of any process to this application’s process.

Disassemble and Reverse 

Using tools, it’s possible for the hackers to disassemble your binary and base on the skeleton, detect how to change the binary – for example to reverse a IF condition to go another way.

Something we can do is to strip the C/C++ information from the app is to change Deployment Postprocessing and Strip Linked Product flags to YES.

 A lot more to learn on Apple’s guide:

And check this