Dark Side of iOS [SmartDevCon 2013]

1,354 views
1,231 views

Published on

A workshop about the "dark side" of iOS, Objective-C and Xcode. Discussion about private API, why Apple doesn't want you to use it and how they enforce that. What information can you extract from a compiled binary? Let's take a look at the possibilities of reverse engineering including demos and showcases.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,354
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
22
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Dark Side of iOS [SmartDevCon 2013]

  1. 1. Dark Side of iOS Kuba Brecka @kubabrecka Play Ragtime Czech Republic
  2. 2. @kubabrecka www.kubabrecka.com
  3. 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. 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. 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. 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. 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. 8. iOS 6.1 jailbreak – evasi0n ž  http://theiphonewiki.com/wiki/Evasi0n
  9. 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. 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. 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. 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. 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. 14. Encrypted binary
  15. 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. 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. 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. 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. 19. 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
  20. 20. 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
  21. 21. Questions? Thank you. Kuba Brecka @kubabrecka www.kubabrecka.com
  22. 22. Dark Side of iOS Kuba Brecka @kubabrecka Play Ragtime Czech Republic

×