Snooping on an iPhone app’s API usage (aka light weight reverse engineering)

November 12th, 2011

I don’t much like using sites that don’t offer APIs. (this is one of the reasons I don’t use Quora anymore, they’ve had plenty of time to offer an API in good faith)

But I do like playing with new sites and that means playing with sites that haven’t opened up an API, yet. It’s funny I keep getting into conversations with folks about, “We’re not sure how to open an API” or “We’ve got an API, but we think we need to rebuild it (and/or outsource maintenance of it to a 3rd party) before we make it public.” For those folks, please see flamework-api, an implementation of the Flickr “API framework” for how easy it can be, and then get over your timidity! But my favorite variant on this is, “Well we have an API for the iPhone app, but it isn’t ready yet for public.” Because that means there is an API, and you can use it.

Some quick notes on reverse engineering an API from an iPhone (mostly because I had to scrape all this back out of my lizard brain this week, and while it’s straightforward, there are a few step)

  1. Grab a proxy, I use Charles, but Burp works just as well and is free.
  2. On a wifi network, fire up the proxy and enable SSL proxying.
  3. Connect to a secure site with a browser via the proxy. (Charles will setup proxying for Firefox automatically)
  4. Using Firefox, drill into Page Info > Security > View Certificate > Details and export the CA certificate, which will be the intermediate proxy’s root cert. (e.g. with Charles it will be CharlesProxySSLProxying.cer) (YMMV with different proxies, and different browsers)
  5. Upload the root cert somewhere you can hit with mobile Safari from your phone
  6. Browse there with your phone, and add the cert.
  7. Throw your phone into “Airplane Mode”, re-enable wifi, connect to the same network your proxy is running on, in the “Choose a Network” menu, drill down and setup Manual proxying pointing at your laptops IP address, and port 8888 if you’re running Charles or 8080 if you’re running Burp (or whatever else your proxy is running at)
  8. Fire up the iPhone app with the API you’re interested in, and sit back and watch the bits flow.

(Reading over this again this morning I noticed I just assumed SSL, my data points suggest that’s a reasonable assumption both as SSL is easy, and as FBOAuth becomes more common, but obviously if the API you’re looking at isn’t running over SSL, skip steps 2-7.)

Tagged: Uncategorized

4 responses to “Snooping on an iPhone app’s API usage (aka light weight reverse engineering)”

  1. karl says:

    Another way to think about « missing APIs » is to think about the HTML web site as an API and you make it automagically self referencing, it creates interesting (yet challenging) design constraints.

  2. Andy Baio says:

    Charles is awesome. Big fan. To be fair, isn’t building the API the easy part? Seems like the hard part is everything else: documenting it (ideally with an API explorer), provisioning keys, handling versioning properly, monitoring/banning abusive API users, and all the additional resources that can come from machine-generated traffic.

  3. Clay Loveless says:

    @Andy Baio — Building an API that isn’t like fingernails on the chalkboard is harder than you’d think. Versioning, by comparison, is a cinch.

    With tools like Mashery, or best practices that many have described, the peripheral stuff isn’t “hard” so much as “time consuming”. The trails have been blazed, it’s just a matter of committing to it.

    Kellan, I’d go a step farther and say that companies who expose APIs but forbid their use for commercial purposes (see FitBit, among others) aren’t really putting an API out at all. Granted, there’s some possibility for hobbyist use, but in the App Store economy, non-commercial use is just as chickenshit as not publishing one at all.

  4. Kellan says:

    @Clay I tend to find “best practices” leave you with an API whose maintenance is divorced from the business of building your site — never a stable situation especially for a fast moving startup.

    @Andy true, but with the possible exception of documentation those aren’t particularly hard problems. Align your API with your site and monitoring and resource consumption should be straightforward (and if those are straightforward then banning/rate limiting having lower stakes, at least from a resource standpoint). And like Karl said, you’ve got an API either way, a proper one at least lets you shape it’s usage.