chpwn blog

iOS 5 Status

Here’s the status of all my stuff on iOS 5 (all versions: iOS 5.0, 5.0.1, 5.1 and 5.1.1). If you haven’t heard of any of these before and want to check them out: search in Cydia, they’ll all show up. Feel free to send me a support email from Cydia if you have any issues or questions, for paid products I try and respond within a few hours if I’m not sleeping.

I’m going to keep this post updated for all the latest status updates to each of them, so be sure to check back here.

Paid Extensions

• Zephyr: Full iOS 5 support.
• Gridlock: Full iOS 5 support.
• VoiceActivator: Full iOS 5 support.
• Infinidock: Full iOS 5 support. (As of version 1.8, available now in Cydia!)
• Infinifolders: Full iOS 5 support. (As of version 1.4, available now in Cydia!)
• Infiniboard: Full iOS 5 support. (As of version 1.8, available now in Cydia!)

Free Extensions

• IconSupport: Full iOS 5 support. (Via @ashikase, who did the iOS 5 work: thanks!)
• AppSlide: Full iOS 5 support. (As of version 1.1, now available in Cydia!)
• MobileVolumeSound: Full iOS 5 support.
• Internalizer: Full iOS 5 support.
• Five Icon Switcher: Full iOS 5 support.
• Webscrollian: Full iOS 5 support.
• No Page Dots: Full iOS 5 support.
• No Bookmarks: Full iOS 5 support.
• Full WebClips: Full iOS 5 support.
• No Folder Badges: Full iOS 5 support.
• Spire: Supports iOS 5.0 and 5.0.1, but not iOS 5.1 or 5.1.1.
• Empty Folder Icons: Unknown. Let me know?
• Colloquy Tab Complete: Unknown. Let me know?
• Covert: Does not work, but similar functionality is included in iOS 5.
• ListLauncher: Does not work.
• Switcherscape: Does not work.

HTC One X

Since it was released on AT&T this weekend, I was able to try it out at a store today. I only played with it for a few minutes, but here’s what I thought:

• It’s smaller than you think. Definitely still a big phone, but it’s thin, and doesn’t feel huge (like the Galaxy Note).
• The screen is great. It doesn’t have the awful PenTile that Samsung still ruins their high-end phones with, and the density is as good as I want. Probably the best non-iPhone screen I’ve seen yet.
• It’s fast. Definitely the fastest phone I’ve tried so far. And unlike every other Android phone I’ve used, it can scroll a list smoothly. (About as smooth as a single-core Windows Phone or iPhone. And the physics still suck. Sigh.)
• HTC Sense is awful. I’m not a huge fan of Android 4.0, and I think it needs a lot of work, but it’s miles better than the crap HTC added here.
• The hardware is solid. Not quite as solid as the Nokia Lumia 800 or 900 or the iPhone 4/4S, but definitely better than the Samsung phones.
• The glossy case on the white model is suboptimal, and the dark gray model doesn’t look nearly as good. I’d love a matte white model, but HTC apparently decided against it.

Overall, this is the best Android hardware I’ve tried, but the software is even worse than the Galaxy Nexus’ stock Android. The Galaxy S III looks even worse: more awful skin and the usual ugly, creaky Samsung hardware.

Will there ever be an Android phone with hardware and software that anyone would actually want to buy?

How to test your app on older iOS releases

In this week’s Build and Analyze, Marco Arment talks about supporting older iOS versions in Instapaper. As he says, being able to test your app on those versions is not easy, and just getting a device to run a specific iOS release can need “hacky jailbreak tools” or can even be impossible. Since I spend my time with those (admittedly hacky and confusing) tools and have an understanding of how the restrictions here work, I thought I’d write an explanation and a guide on how to successfully test for older iOS releases.

Background

Originally, there weren’t any issues with running any iOS release on your device. You just download the firmware (ipsw) file, open up iTunes, and restore with it. This method worked through iPhone OS 2.0, the iPhone 3G, and the second generation iPod touch.

However, with the iPhone 3GS, Apple changed everything. On that device (as well as the iPod touch (third generation), the original iPad, and the iPhone 4), each and every firmware change must be approved by Apple’s servers, at the time of the install. And Apple will only agree to let you install the current latest release of iOS at that time, so to would prevent downgrading — as well as any re-installs of the iOS release the device is running, as long as that release is not the absolute current version available.

The iPad 2, iPhone 4S, and iPad (third generation) all use similar methods, with additional security measures. (I’ll talk about those later.) In addition, with iOS 4, similar protections were added to the iPhone 3G and iPod touch (second generation). While those devices can still be easily restored to pre-iOS 4 releases, it’s no longer easily possible to restore them to iOS 4.0 or iOS 4.1.

Why It’s Important

What Apple has done here, essentially, is sacrifice the ability for developers to test code on older versions of iOS, for the sake of increased control of how we use our devices. It’s hard to see a benefit: if someone is knowledgeable to downgrade a device, they probably also have a good reason to.

It’s unclear that Apple realizes what this does to developers. Xcode, even, doesn’t realize that this happens at all: the Organizer still has a file picker and version selector under “Restore”, oblivious to the fact that this option no longer, in fact, works (and hasn’t for almost three years). The enterprise iPhone Configuration Utility and education Apple Configuration tool are similarly confused.

A good, simple solution would be for Apple to simply allow devices registered for development to install older iOS releases, just as they are allowed to install betas. To encourage Apple to fix this problem for developers, please dupe my radar and help call attention to it. Thanks!

What To Do

Often, even if Apple doesn’t support it, you still do need to ensure your code runs on older iOS releases. Since you can’t trivially restore your device to an older version, I’ve made a list of the possible workarounds:

• Use the Simulator

  This is definitely the easiest method. Rather than testing your app on a device, you just use the iOS Simulator to test it on that version. While Xcode itself only is bundled with the simulators for the latest two iOS releases, it’s pretty easy to import older ones: just drag the SDK bundle (iPhoneSimulatorX.Y.sdk) into the iPhoneSimulator.platform/Developer/SDKs folder. If you didn’t keep around copies of the older SDK, they are very findable online. Update: for registered iOS developers, you can apparently find old versions of Xcode you can extract the SDKs from available on Apple’s developer download page.

• Save Devices

  The easier method, although the most expensive, is to simply begin a collection of devices running various iOS releases. Most developers I’ve talked to take this route, but it’s hard to enter. First, it’s expensive to buy all the iOS devices necessary to test each release. Secondly, it’s quite difficult to obtain a complete spread of iOS releases to test on. Since downgrading is blocked, you have to purchase these devices still running older releases — something that gets harder every day, as more older devices break and get replaced.

  And, once you have the devices, you have to be very careful to never break them — or to accidentally accept the endless stream of update prompts from iTunes. Remember: even if you just need to restore the device to the same older version of iOS as is already on the device, Apple doesn’t even allow that. So be very sure that they never get messed up.

• Evading SHSH (the “hacky jailbreak tools” method)

  When Apple accepts your request to restore a device, they give back a cryptographic agreement to allow it, called an “SHSH blob”. In the iPhone 3GS, iPhone 4, original iPad, and iPod touch (third generation), however, Apple forgot to include one crucial piece of data in these signed blobs: a time range of when that acceptance was valid for. Using that mistake, Jay Freeman (saurik) developed a massive MITM attack: storing the authorized responses for millions of device/firmware combinations, and replaying them to restore the device on demand.

  If did happen to store your “SHSH blobs” for a specific iOS version with the Cydia server for one of these devices when Apple was still signing that release (most jailbroken users probably did), you need to do some tricks to use the saved response.

  The tools for this are TinyUmbrella and redsn0w. First, use TinyUmbrella to download the SHSH files saved for your device. (Be sure to have “Request from Cydia” checked so it asks Cydia’s server, rather than Apple, for the saved blobs.) Then, use redsn0w to create an IPSW you can restore in iTunes.

  To save SHSH blobs for the future, also use TinyUmbrella, just have it ask Apple (uncheck “Request from Cydia”). If you didn’t manage to save this data but do have one of these devices on an older iOS release but want to extract the data for the version it is running, it is actually possible to do so. Use redsn0w and choose “Fetch” to copy the blobs off the device.

  Unfortunately, this loophole was essentially fixed in the iPad 2, iPad (third generation), and the iPhone 4S. (It may still be possible with GSM and Wi-Fi only models of the iPad 2, but don’t rely on it.)

Apple, please help!

The only way for this issue to be truly resolved for developers is for Apple to create a supported method to downgrade devices to test apps. While the iOS 5 over-the-air updates do appear to increase update penetration and speed, it’s simply not possible for many apps to only be available (or, worse: only tested) on the very latest version of iOS.

Right now, it does not seem likely that Apple will change anything here, so we are stuck with the workarounds above. However, there’s a chance that they will, and more people letting them know it’s an issue can only help.

Let me know if you know of any other workarounds or things I missed: I’m on Twitter as @chpwn, or you can email me at chpwn@chpwn.com.

Page Turning

This is how you turn the page of a book:

This is how Apple’s iBooks turns the pages of a book:

This is not how you turn the page of a book:

This is how Google Boo— oops, sorry, Google Play Books — turns the pages of a book:

This is a good example of how Google manages to only make it around 70% of the way to a good UI. They often get the basic idea right, but the details (like, for instance, “does anyone actually turn a book this way?”) slip through, and it shows.

It’s why I’ve ditched the new Gmail web UI for Sparrow, even though it’s missing many features I liked and actually runs worse on my laptop. And it’s why I’ve recently switched my browser to (gasp) Safari: after a year from the first betas of OS X Lion, it still only had “most” of what you would want from a full Lion-ready browser.

I certainly hope Google finds a way to solve this issue. Most of their products are ahead of the competition in other respects, and I’d love to use them. But if Google still can’t make it all the way, even with a new focus on design, I’m not going to shove an inferior experience on myself.

See also: ICS Paper Cuts.

Ski Trip to iOS 3.1.2

Last weekend, I went skiing at Northstar — the codename of iOS 3.1. (Each iOS release is codenamed after a ski resort, usually in Tahoe or Colorado.) I don’t have anything to match comex’s awesome PDF slope slope from JailbreakMe 3.0, but it wasn’t all bad:

SpringBoard was there, right near the top of the mountain. Also, there was a new lodge this year, to go with one of my new tweaks:

But, sadly, it was closed. Maybe that’s because Zephyr doesn’t support iOS 3.1. ;P

Spire Proxy “FAQ”

Spire needs a proxy!? It’s useless!

As has been noted, my recently released tweak Spire requires a proxy and data from an iPhone 4S to operate. As the point of Spire is to get Siri on devices that aren’t the iPhone 4S, this might at first seem to imply that Spire is useless.

However, this is not because I hate you or because I’m lazy, it’s because Apple has made it very likely impossible to defeat the authorization requirement. I reverse engineered it, and it does not appear possible to connect Siri to the cloud without information from an iPhone 4S.

However, that doesn’t necessarily mean that Spire is therefore useless.

So, how do I get a proxy?

There’s any number of ways for you to get a proxy that will help you connect Siri to Apple. Here’s a few of my ideas:

• westbaer’s SiriProxy fork
  • Own an iPhone 4S too: Maybe you already own an iPhone 4S, and just want Siri on another device of yours. This is simple; you can just use the above proxy yourself.
  • Find a friend: Maybe your friend has an iPhone 4S and will let you use their authentication tokens (maybe in exchange for some cool SiriProxy plugins). Then, you can share the authentication. Or, maybe you gave your relative your old iPhone when you got your iPhone 4S: now you can share your token and give them Siri.
• Pay up: It’s very likely that soon we will see for-pay services online to rent you some space on a Siri proxy, attached to one of their iPhone 4S devices. I haven’t seen anything like this yet, but I’ll keep my eye out, and I would encourage anyone who is interested to set something like this up.
• And now for something completely different: As I suggested earlier, you might be able to replace Siri entirely. A simple method might be to use Google Chrome’s speech “API” hooked up to some code to decode the Siri requests and parse Google’s result. Or, someone could hook it up to some logic backends like many of the clones available on Android: the possibilities are endless.

Okay, I’ll find something!

Good! Spire is far from perfect, but at least at this point in time, it’s the best that I can do. Maybe in the future someone will find a way to evade the authorization requirement, but from my position here that’s unlikely. Hopefully, however, you’ll be able to figure something out.

Introducing Spire

Spire is my (along with Ryan Petrich) new tool for installing Siri on previously unsupported, but jailbroken, devices. Spire is a small download, but while installing it will download Siri itself (directly from Apple). Spire is available in Cydia right now — go get it! This will use about 100 MB of data, so please connect to Wi-Fi before installing.

However, Spire is not a complete solution. Apple still requires authorization to use Siri, so information from an iPhone 4S is still required. To insert this information, Spire allows you to enter your own proxy server address. I’ve put up a list of my ideas on how you might get access to a proxy; hopefully you can figure something out.

Spire uses a new method to obtain the files necessary for Siri, so it doesn’t have the copyright issues encountered by previous attempts. Similarly, rather than directing all traffic through a specific proxy server (and the associated privacy issues), Spire allows you to specify your own proxy server.

Thanks to planetbeing for PartialZip and Ryan Petrich for his fixes and improvements.

Siri Authentication

Siri may be specific to the iPhone 4S, but very little of the actual processing takes place on the iPhone. Rather, Siri streams the voice data to Apple, and then displays the response from Apple and renders it. So, to even simply transcribe your voice into text, Siri needs to be able to contact Apple.

Siri requires authentication to connect to Apple. This is likely to prevent unauthorized use: I’m sure Siri takes a lot of computing power to run, as voice transcription, looking up responses, and bandwidth aren’t free. However, if your goal is to run Siri on a device which isn’t officially supported, you need to bypass this authentication requirement in some way.

The authentication is based on what I’m going to call “tokens”, which are signed by Apple. If I remember correctly (I haven’t looked at this for a month or so, and this is from memory), Siri (through the assistantd binary) first asks Apple for certificate data. This is then used to sign a blob of data generated by the iPhone and encrypted using AES. That signed data is then sent back to Apple, processed. If that was found to be valid, the device receives the “token” (called sessionInfo in the code) and an expiration date (the token is generally renewed daily).

The interesting part here is the AES-encrypted and signed data that is submitted to Apple for validation. The code that generates this is obfuscated (similar to FairPlay), but the general gist of what it does is reasonably simple. Firstly, assistantd calls out to the obfuscated absinthed, a part of the iPhone’s FairPlay subsystem. That then asks libMobileGestalt for both the UniqueDeviceID (the same UDID used for provisioning) and SerialNumber (the device’s serial number), and reads four bytes from a shared memory region. I currently do not know the source of these four byes (although I suspect the FairPlay daemon) or the purpose. This is then AES encrypted and sent back to assistantd to send to Apple, and (if valid) is exchanged for the session info.

As Apple can simply blacklist any device ID used for mass distribution of Siri, there is no way for a widespread and popular distribution of Siri to piggyback on one valid iPhone 4S identifier. However, a more distributed approach may be possible. A fork of SiriProxy, available here, allows everyone with an iPhone 4S to run their own proxy for their own devices. Or, it may be possible to replace Siri entirely, using something like Google’s speech “API” for speech transcription and logic like Hubot to create something usable for at least simple tasks like dictation.

The above technical info was discovered through a combination of static and dynamic analysis. If anyone would like to see my (not well documented, sadly) .idb or to contribute more to the investigation, just let me know on IRC. Thanks to anyone who helps, in addition to Steven Troughton-Smith and Aman Gupta.

Carrier IQ is on iOS

Carrier IQ, the now infamous “rootkit” or “keylogger”, is not just for Android, Symbian, BlackBerry, and even webOS. In fact, up through and including iOS 5, Apple has included a copy of Carrier IQ on the iPhone. However, it does appears to be disabled along with diagnostics enabled on iOS 5; older versions may send back information in more cases. Because of that, if you want to disable Carrier IQ on your iOS 5 device, turning off “Diagnostics and Usage” in Settings appears to be enough.

I do realize the info below is a bit technical, but that’s the best way for me to share what I’ve figured out so far at this point. Please feel free to let me know if you discover something else here.

Carrier IQ is run from a number of different daemons, depending on the firmware version of the device: (You can view this on a jailbroken iPhone with iFile or extract it from a software update bundle if you want to check the files out yourself.)

• iOS 3: /usr/bin/IQAgent
• iOS 4 and 5: /usr/bin/awd_ice2 or /usr/bin/awd_ice3

The startup routine verifies that it is running on either a compatible device and exits if it is not. In addition, and most importantly: it appears it will only run if:

• iOS 3: The DiagnosticsAllowed key is set to true in the com.apple.iqagent preferences — which it does not appear to be enabled on any of my devices. (If anyone knows what would cause this key to be set to true, please let me know.)
• iOS 4: Unknown, probably like iOS 3.
• iOS 5: Copies the ShouldSubmit value from lockdownd, under the domain com.apple.MobileDeviceCrashCopy. I believe this value is set by the “Submit Logs to Apple” option during the iOS 5 setup sequence, and so Carrier IQ logging is toggled with that setting.

There is also a check to ensure that your carrier supports the logging: it appears some carriers support it only over WiFi, others over 3G. However, despite those restrictions and never enabling the above checks, I do see Carrier IQ log files stored on all of the devices I tested:

• iOS 3: /var/logs/IQAgent
• iOS 4: /var/wireless/Library/Logs/IQAgent
• iOS 5: /var/wireless/Library/Logs/awd

But is this version of Carrier IQ the same keylogger/rootkit as on Android? The answer appears to be: not quite. It does access a reasonable amount of information, however: (Be sure to note that I have not confirmed which, if any, of this data is sent remotely.)

• CoreTelephony
  • your phone number
  • your carrier
  • your country
  • active phone calls
    • (However, I only saw it noting that a phone call was active, not what number was dialed or it was received from. But, I am not going to claim it doesn’t do that: it’s certainly possible, but didn’t see it.)
• CoreLocation
  • your location (Only, however, if Location Services are enabled.)
• (Possibly more I haven’t yet found.)

As Carrier IQ claims in their video, communication with the remote server is all done via SSL. Importantly, it does not appear the daemon has any access or communication with the UI layer, where text entry is done. I am reasonably sure it has no access to typed text, web history, passwords, browsing history, or text messages, and as such is not sending any of this data remotely.

It appears that if you really care about this, Windows Phone 7 is the only mobile operating system without this installed. ;P However, I think the blame here really belongs with the US carriers who obviously demanded this: personally, I am completely fine with this data being sent off (especially if it helps AT&T’s network improve), but I would definitely prefer if it was more transparent — even if you can disable it with that toggle, Apple only explains that it “might contain location data”.

Update: From my examinations, Apple’s recent statement on the issue appears to be entirely accurate.