Cracking iTunes Backup Passwords with hashcat

Following the recent announcement of LUKS support in hashcat, I noticed that there have been some commits to support iTunes Backup passwords as well.

This is only useful if the backup was encrypted by setting a backup password on the iOS device. If the backup is not encrypted then all the files are in clear and there is nothing to bruteforce.

The keys used to encrypt the backup are stored in the BackupKeyBag, which can be found in the Manifest.plist file. This keybag is a binary blob, the format of which has already been documented by researchers from Sogeti ESEC Lab.

I have written a simplified script which dumps the BackupKeyBag.

Speeding up iOS Backups

iOS device backups usually take a while, depending on how much storage has been used on your device.

The iOS backup process is driven by the device itself, through the BackupAgent process. This process treats the host PC like a dumb disk store, by sending it commands like DLMessageCreateDirectory, DLMessageUploadFiles, DLMessageRemoveFiles, DLMessageGetFreeDiskSpace, etc. so that it can determine what has been backed up previously and what to send/update for incremental backups.

For password cracking, we don’t need the entire 64 GB (or God forbid, 128 GB) of data on the iOS device. We just need the Manifest.plist, which is typically less than 50 KB. But because the backup process is controlled by the device and not the PC, we can’t simply ask it to send over that single file. Sometimes when we setup a VM with libimobiledevice, we might also not have allocated such a large virtual disk. Of course when I say “we”, I really mean “I”.

Continue reading

Apple’s Lightning Digital AV Adapter

Recently, Panic noticed the odd output resolution and MPEG-like artifacts with the new Lightning digital AV adapter and decided to take a hacksaw to it. They found an ARM processor inside.

Lightning digital AV adapter

image credit: Panic blog

Shortly after, they received an anonymous comment that explains it all:

The reason why this adapter exists is because Lightning is simply not capable of streaming a “raw” HDMI signal across the cable. Lightning is a serial bus. There is no clever wire multiplexing involved. […] We did this to specifically shift the complexity of the “adapter” bit into the adapter itself, leaving the host hardware free of any concerns in regards to what was hanging off the other end of the Lightning cable.

This system essentially allows us to output to any device on the planet, irregardless of the endpoint bus (HDMI, DisplayPort, and any future inventions) by simply producing the relevant adapter that plugs into the Lightning port. Since the iOS device doesn’t care about the hardware hanging off the other end, you don’t need a new iPad or iPhone when a new A/V connector hits the market.

While I understand what they are trying to achieve, I think it’s sad that this new Lightning system can no longer carry the uncompressed HDMI output. Maybe they could have streamed the raw video output in a format close to what HDMI expects, then have the adapter add headers and trailers to the data, but that would still be tricky since the system needs to stop sending frames while the adapter is doing its work. And what about HDCP?

Just one of the many tradeoffs that engineers need to make.

The Apple 30-pin Dock Connector

The 30-pin dock connector first appeared on the iPod 3G in 2003, and has been on all iPods, iPhones and iPads ever since, with the sole exception of the first generation iPod Shuffle. The first gen Shuffle looks like a thumbdrive (or what some would call a pen drive) and used a USB male connector, whereas the first and second generation iPods had a FireWire port at the top.

iPod Accessory Protocol

Since its introduction, Apple made several minor modifications to the electronics interface of the dock connector, but the physical connector itself remains unchanged. Collectively, this and the communications protocol is called the iPod Accessory Protocol (iAP).

Initially, they introduced different resistor values on the “accessory detect” pin when they allowed third-party companies to make docks and car adapters. At that time, the dock connector mainly had audio in and line out functionality (connected to the back of the docks), as well as a serial interface for remote control via the dock. The serial protocol was largely reverse-engineered by maushammer (website no longer accessible) and this guy here (I think he’s called Christoph but it’s not on that page). This was also used by car manufacturers to allow iPod playback control from buttons on the steering wheel.

When Apple released the iPod Video that was capable of playing videos in 2005, they added video out (composite and S-video), as well as an authentication chip to allow only authorized docks and cables to receive video out (including audio). Soon enough, China caught up with their release of “authorized” accessories, which contain the authentication chip that can be re-purposed for other use.

Authentication chip (image from

Presumably, that was also when they added USB support for iAP, which I’m pretty sure also requires an authentication chip. USB support would allow a host to communicate and control the iPod through a USB cable. My car stereo correctly recognizes the iPhone as an iPod over a USB cable.

The iPod Camera Connector was also introduced for the iPod Photo and iPod Video in 2005. This was a small “dongle” that has a dock connector on one end and a USB port on the other. Oddly, according to an Everymac article, later iPods released in 2006 do not support this accessory any more. It is unknown if they somehow switched the USB interface to host mode, or if they used a separate chip to emulate this.

In 2008, charging via FireWire was no longer supported with the introduction of the 2nd generation iPod Touch and 4th generation iPod Nano. The pins dedicated to FireWire in the dock connector are now unused.

Continue reading