This document discusses security and privacy considerations for iOS application development. It describes how jailbreaking an iOS device removes restrictions like sandboxing and allows access to the entire filesystem. It also explains how private APIs, encrypted binaries, and app review processes can be bypassed to extract information from iOS apps and modify their behavior. While modification is difficult, metadata can be easily extracted from iOS and Android apps. The document encourages developers to understand platform internals and take a reasonable approach to security rather than a paranoid one.
3. How important is it for a
developer to know…
ž OOP
ž Functional programming
ž Compiler theory, automata theory
ž Algorithm complexity
ž Databases
ž Networking
ž UI/UX
ž Reverse engineering
4. But actually…
ž …let’s take a look how deep the rabbit
hole goes
ž I’ll try to answer some “forbidden”
questions
— private API
— app validation, review
— binary structure, app encryption
— some security consequences
5. The goal
ž To show…
— what Apple can do with your application
— what can you (or others) find out from the app
binary
— what can you do with a jailbroken device
— where do “cracked” apps come from
— what can a determined “black hat” do
ž Not: to break the law
ž Disclaimer: for educational purposes only
ž Disclaimer 2: I’m no security expert, I’m just
some guy who likes digging into things
6. Sandbox
ž Every application has its own sandbox
— it can see its directory + a few of system
directories
— for writing, it has only a few specific
directories
ž There is no point in creating a file
manager
ž App-to-app file transfers are ad-hoc
7. Jailbreak
ž No signature verification
ž Disabled sandbox
— read and write anywhere in the filesystem (!)
ž Turns off ASLR
ž Re-allows blocked syscalls
— fork, exec, …
ž Debugging, attach to process
ž Cydia
ž tethered (easy), untethered (very hard)
— jailbreakers are saving exploits for later
9. Private API
ž Header files in Xcode are “stripped”
— plenty of hidden classes and methods
— the reason?
○ published APIs must be supported by Apple for a
long time
○ Apple wants to be able to change the internals
ž Class-dump
— http://stevenygard.com/projects/class-dump/
— https://github.com/nst/iOS-Runtime-Headers
— dumps all classes and methods from a binary
10. Method swizzling
ž All selectors are called using a dynamic
dispatch
— a method can be replaced by changing a record
in the method lookup tables
— http://darkdust.net/writings/objective-c/method-
swizzling
- (BOOL)swizzled_synchronize {
...
[self swizzled_synchronize];
...
}
+ (void)load {
Method original = class_getInstanceMethod(self, @selector(synchronize));
Method swizzled = class_getInstanceMethod(self, @selector(swizzled_synchronize));
method_exchangeImplementations(original, swizzled);
}
11. App validation
ž What exactly is sent over to Apple?
— Compiled binary for ARMv6 (?), ARMv7,
ARMv7s
— Not: source code, binary for simulator
ž What happens with the app during
validation?
— checks of some “boring stuff”
○ icon, profile, plist, …
— checks for private API usage
12. App review
ž What happens to the app during review?
— Officially: only App Store Review Guidelines
— <my guess>
○ much less testing than you would think
○ they don’t have the source code
○ validation + automated tests
— CPU load, battery consumption
○ manual tests
— can the app be run? does it do something?
— no extensive testing of all app features
○ individual teams have different results
○ hard-to-detect violation of rules are solved later
— when the app is popular enough that someone cares
— </my guess>
13. FairPlay and app encryption
ž App Store apps are encrypted
— just the binary, and only individual sections
# otool -arch all -Vl ...
cmd LC_ENCRYPTION_INFO
cmdsize 20
cryptoff 4096
cryptsize 724992
cryptid 1
ž Imports are intact
ž iOS kernel validates the signature and
deciphers the binary in memory
15. How to obtain a decrypted
binary?
ž .ipa files floating around the Internet
— AppTrackr, apps.su, apps-ipa.com etc.
— iReSign
ž How to create it?
— Basically the only way is to extract the
deciphered memory image from a jailbroken
device
○ using gdb, pause the process, dump memory
16. A quick comparison – Android
ž Java, Dalvik, Dalvik VM, .apk files
— bytecode (.dex)
— dex2jar tool will convert it into common .class files
— then use your favorite Java decompiler (there’s lots
of them)
ž Where to get an .apk?
— google for “<appname> apk”
— directly from a device
○ usually pretty straightforward, sometimes you need to
root the device first
ž Protection: obfuscation
— but the effect of it is questionable at best
17. The reality
ž Obtaining an .ipa or .apk is easy
ž Getting information out of a binary
— Android
○ it’s Java, decompilation is a no-brainer
— iOS
○ it’s ARM assembly
○ but you get plenty of metainformation for free, e.g.
class names and method names
ž Modifying an app is a completely different
story
— definitely doable with ordinary developer access
18. Hacker’s toolbox
ž IDA 6.4
— Great Obj-C support
— Trial version for Mac OS
○ analyzes x86 + ARM
ž iFunBox
— Free
— uses iTunes internal libraries
ž Charles – Web Debugging Proxy Application
— http://www.charlesproxy.com/, $50
— Settings – Wi-Fi – (network) – HTTP Proxy – Manual
— SSL (!)
19.
20. What can you do about it?
ž Short answer: nothing
ž Long answer:
— you can invent plenty of “security by
obscurity” mechanisms, but these are
always breakable, it’s just a matter of
attacker’s determination
— get a realistic point of view, instead of a
paranoid one
○ okay: what’s the worse thing that can happen?
○ better: risk assessment
21. My message
ž You want to know how something is
done?
— Just take a look!
— /Applications/Xcode.app/Contents/Developer/Platforms/
iPhoneSimulator.platform/Developer/SDKs/
iPhoneSimulator6.1.sdk/System/Library/Frameworks/
○ UIKit, QuartzCore, Foundation, CoreGraphics,
CoreFoundation, …
ž Be reasonable about security and
question the implementation
— e.g. iFunBox