Update - There is some new information in this post relating to iOS 8. The instructions below for obtaining the data dump are still valid.
I’ve recently been having a play with the iOS Diagnostics tool. It turns out that this tool can provide you with a treasure trove of information about your device. From which accessories you have connected, to extremely detailed power usage information. You can get to it by entering the URL diags:// into Safari. You’ll be greeted with a screen asking you for a ticket number:
Where do you get a ticket number from? You could go to the genius bar, but there is an easier way. We can use a a man-in-the-middle proxy and spoof iOS Diagnostics into thinking it has a valid ticket. I decided to use mitmproxy as it supports https and can be scripted. I’ve made a mitmproxy script that you can use to spoof iOS Diagnostics and capture the payload that would be sent to Apple. So let’s being.
When started iOS Diagnostics makes a request to https://iosdiags.apple.com/ios/TestConfiguration/1.2 to find out what diagnostics are available for your device. The response is a plist containing a dictionary keyed on device type mapping to an array of diagnostic types. The only value I’ve seen is powerDiagnostics. A quick poke around in the binary seems to confirm this is the only accepted value at the moment. If your device type matches you’ll be offered ‘Extended Tests’. Currently Apple only seems to offer this for iPhones and not iPads. However, I’ve been able to get extended diagnostics from an iPad too. You’ll need to edit XML_OK_RESPONSE to include your device type, if you want the more detailed power logs.
To get started download and install mitmproxy and download the script here. As iOS diagnostics uses https you’ll need to install the mitmproxy CA on your device. You can find instructions here. You can start the command line version of mitmproxy - mitmdump - like so:
1
mitmdump -e -s capture.py
You’ll then need to set your proxy in the wifi settings on your iOS device to the IP address of your machine running the proxy. The default port is 8080. Once you’re all configured go to Safari and go to diags:// Enter 123456 as the ticket number and select Extended Tests. After a short time you’ll be left with two tar.gz files containing all the good stuff.
The smaller file starting with ‘general’ contains logs relating to iCloud backups, memory and accessories. The accessory logs are in the iAPEvents directory. You’ll need to load them into Console to view them. It looks like each time a device is connected (even those connected over Bluetooth LE) an entry is written. For example:
1234567
Jan 9 21:35:30 Ishras-iPhone-5S iapd[149] <Warning>: AccessoryInfo = {
Jan 9 21:35:30 Ishras-iPhone-5S iapd[149] <Warning>: IAPAppAccessoryNameKey = Apple Digital AV Adapter;
Jan 9 21:35:30 Ishras-iPhone-5S iapd[149] <Warning>: IAPAppAccessoryManufacturerKey = Apple;
Jan 9 21:35:30 Ishras-iPhone-5S iapd[149] <Warning>: IAPAppAccessoryModelNumberKey = A1438;
Jan 9 21:35:30 Ishras-iPhone-5S iapd[149] <Warning>: IAPAppAccessoryFirmwareRevisionKey = 7.0.0 (11A7451);
Jan 9 21:35:30 Ishras-iPhone-5S iapd[149] <Warning>: IAPAppAccessoryHardwareRevisionKey = 1.0.0;
Jan 9 21:35:30 Ishras-iPhone-5S iapd[149] <Warning>: } // End AccessoryInfo
The larger file starting with ‘power’ contains all the power logs. It’s a compressed CPIO file containing a set of compressed text files. There is one file for each day. I found over two weeks of files on my device. Each file is very detailed and on my iPhone 5s about 16mb a day. If you look inside you’ll see lots of entries, each prefixed with a time and type. Most of if is pretty clear, here are some examples:
As well as power information there is periodic logging of the process table and network statistics. This includes how much time each process has used and how much cellular and wifi data has been used on a per process level:
It’s all interesting stuff. Hopefully I’ll get some time to write scripts to extract graphs from the logs. So next time you have one of those days where the battery lasts no time, take a look in the logs and you’ll probably be able to find the culprit!
Update (14/2/14)
The link to the script is now fixed. Sorry about that.
Remember, you’ll only get Quick Test unless your device is included in XML_OK_RESPONSE. You can get a complete list here.