Dark Side of iOS [SmartDevCon 2013]
Upcoming SlideShare
Loading in...5
×
 

Dark Side of iOS [SmartDevCon 2013]

on

  • 1,230 views

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 ...

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.

Statistics

Views

Total Views
1,230
Views on SlideShare
1,213
Embed Views
17

Actions

Likes
2
Downloads
17
Comments
0

1 Embed 17

https://twitter.com 17

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Dark Side of iOS [SmartDevCon 2013] Dark Side of iOS [SmartDevCon 2013] Presentation Transcript

    • Dark Side of iOS Kuba Brecka @kubabrecka Play Ragtime Czech Republic
    • @kubabrecka www.kubabrecka.com
    • How important is it for a developer to know… ž  OOP ž  Functional programming ž  Compiler theory, automata theory ž  Algorithm complexity ž  Databases ž  Networking ž  UI/UX ž  Reverse engineering
    • 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
    • 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
    • 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
    • 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
    • iOS 6.1 jailbreak – evasi0n ž  http://theiphonewiki.com/wiki/Evasi0n
    • 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
    • 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); }
    • 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
    • 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>
    • 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
    • Encrypted binary
    • 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
    • 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
    • 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
    • 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 (!)
    • 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
    • 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
    • Questions? Thank you. Kuba Brecka @kubabrecka www.kubabrecka.com
    • Dark Side of iOS Kuba Brecka @kubabrecka Play Ragtime Czech Republic