Dark Side of iOS [SmartDevCon 2013]
2 likes1,803 views
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.
![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);
}](https://image.slidesharecdn.com/smartdevconpresentation-130913064401-phpapp01/85/Dark-Side-of-iOS-SmartDevCon-2013-10-320.jpg)
![Dark Side of iOS [SmartDevCon 2013]](https://image.slidesharecdn.com/smartdevconpresentation-130913064401-phpapp01/85/Dark-Side-of-iOS-SmartDevCon-2013-19-320.jpg)
Dark Side of iOS [SmartDevCon 2013]
- 1. Dark Side of iOS Kuba Brecka @kubabrecka Play Ragtime Czech Republic
- 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
- 8. iOS 6.1 jailbreak – evasi0n ž http://theiphonewiki.com/wiki/Evasi0n
- 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
- 14. Encrypted binary
- 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 (!)
- 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
- 23. Dark Side of iOS Kuba Brecka @kubabrecka Play Ragtime Czech Republic