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

Enable iOS 5 Multitasking Gestures on iPad 1

Now that iOS 5 has been released, it’s easy to enable multitasking gestures on the iPad 1, using the same trick as before for display mirroring.

Edit the /System/Library/CoreServices/ file and add a boolean key multitasking-gestures in the capabilities dict, and set its value to true. You can add both display mirroring and multitasking gestures to the iPad 1 using this method.

That’s it!

Alternatively you can use Cydia or redsn0w to do this for you.

Python bindings for iTunesMobileDevice.dll

Oddly enough I can’t seem to find a Python wrapper for iTunesMobileDevice.dll. I did manage to find a C# equivalent called Manzana though, which is quite widely used.

Anyhow, I bit the bullet and read through the ctypes documentation and wrote which exposes some simple classes to handle connecting to an iPhone. I only implemented the minimal set of functions required to download and upload files to the iPhone, as I wrote this primarily for my iPhone SMS import script.

As I use the iPhone SMS import script on a regular basis (the Samsung Jet frequently runs out of SMS memory), I got tired of opening iPhone Explorer, copying the file out, running the script, and then copying the file back. If only the bookmark feature actually worked, I wouldn’t have to navigate to the directory every single time.

With this bit of code (and a jailbroken iPhone) the script will now download the sms.db file, insert new SMSes from Samsung New PC Studio, and upload the file back into the iPhone. Very convenient.

On top of that, I can also use the Python wrapper for other purposes. If you need it, you can find in the Bitbucket repository for my import script.

Stop iPhone Backup Encryption

Before the days when you could easily opt to use a “complex” passcode from the iPhone Settings, you had to manually use the iPhone Configuration Utility (iPCU). When I created a profile to use a complex passcode, I inadvertently forced my iPhone backups to be encrypted and now that the “Encrypt iPhone backup” checkbox is grayed out, I can’t stop encrypting my backups.

But after I jailbroke my phone (because the baseband died), I had the option of mucking around with the system files to see if it could be undone. Backup encryption happens on the phone, so the phone must know your password, and where are (most) passwords stored? In /var/Keychains/keychain-2.db of course.

Download the file using iPhone Explorer (or whichever tool you prefer), and execute sqlite3 keychain-2.db. Poke around. Hmmm this looks interesting:

sqlite> select * from genp where svce = 'BackupAgent';
rowid = 10
cdat =
prot =
acct = BackupPassword
svce = BackupAgent
gena =
data =
agrp = apple
pdmn = aku

Let’s see what happens when I remove it (of course after I made a backup first):

sqlite> delete from genp where svce = 'BackupAgent';

Now upload the file back to the iPhone.

By removing the BackupPassword, the next time you sync/backup to iTunes, it will prompt you to enter your password to “unlock” your backups or something similar. It should be pre-filled from your keychain if you had opted to save it.

After that, it creates an unencrypted backup and the “Encrypt iPhone backup” checkbox can now be unchecked. I’m using iOS 4.3.2 by the way. The table names or fields could be different in other iOS versions.

On the flipside, your passwords will no longer be carried over when you restore the backup into a new device.

Importing SMSes into the iPhone

Since my iPhone 3GS died, I have been using my dad’s Samsung Jet as a temporary replacement phone. I really can’t stand the resistive touch screen – tapping backspace will at times hit the T9 button when I’m composing an SMS. Also, I miss the display of SMSes as a conversation with both sent and received messages in a single place.

I obsess over keeping chat history, so naturally I want to find a way to preserve these messages on the phone. I keep hitting the maximum limit of about 200 odd SMSes and I have to delete old messages. The first step would be to download the SMSes onto my PC, using the Samsung New PC Studio (NPS) software.

The Nokia PC Suite used to save the SMSes in some CSV-like format, so I wonder if the Samsung NPS does the same thing. Peering into the AppData directory, I found a couple of files and (empty) folders. I inspected the .dat files, and I found that they were of the type “Standard Jet DB”. To open them, I renamed them to .mdb and opened them in MS Access. One file had password protection, and the other did not. Using this other database, it seems that the sync-ed SMSes were stored in the MESSAGE table. Great!

So I began looking for a way to access this database. Since I’m using 64-bit Windows, I was having difficulty using the Windows Scripting Host (WSH) and the ActiveX objects, but JetSQLConsole worked fine. JetSQLConsole was written in C/C++ and it relied on QT, so recompiling it for my purposes is going to be a little bit troublesome. In its current state, it provides an SQL console to the database, but I would prefer programmatic access to the database, so eventually I settled for Python + pywin32 extensions.

iPhone SMS Database

The iPhone (or iOS, rather) uses an SQLite database to store the SMSes. In this database, there are a couple of tables, indices and triggers. The tables we are interested in is the message table, the msg_group table for grouping the SMSes into different conversations, and a mapping table called group_member.

Accessing this database will not be easy (or should I say convenient) if you do not jailbreak your iPhone. There are two methods for accessing this database:

  1. jailbreak the iPhone, then use something like iPhone Explorer to extract the SMS database
  2. sync to backup the iPhone, then locate this database in the backup to copy it

Since we are importing SMSes into the iPhone, the database will need to be copied back into the phone. If you choose to use method #2, you will need to perform a restore to get the updated database back into the phone.

Putting it Together

Armed with the knowledge of both databases and their schema, all that was left is to create a converter between the two. The typical use case would be:

  1. connect the Samsung Jet to download SMSes from the phone into NPS
  2. copy the iPhone SMS database (/var/mobile/Library/SMS/sms.db) to the script directory
  3. run the script to import the Samsung SMSes into the iPhone SMS database
  4. copy the updated iPhone SMS database back into the phone

Since I will be running it frequently, I did not want to have to worry about importing duplicate SMSes. I made the script check for duplicate SMSes using the SMS text, the timestamp and the number and direction (sent or received) it came from. With most older phones, sending a blank SMS was allowed; the script will ignore blank messages.

As I did not have iTunes on the Windows machine, I had to use my Mac, copy the database to the Mac, then to the PC, run the script, then copy it back to the Mac, and then onto the iPhone. To streamline this process, I decided to install iPhone Explorer and only the necessary dependencies, instead of everything that comes with iTunes. You will need only the AppleMobileDeviceSupport(64) and the AppleApplicationSupport packages.

The script uses the Python port of libphonenumber, which parses phone numbers. This is needed because my telco prefixes the country code even if the SMS is local, and obviously my address book doesn’t have those, so I needed a way to match these. The databases is filled with both versions of these numbers, depending on whether the SMS was outgoing or incoming, and sometimes the other party’s telco.


I’ve made the script available on Bitbucket. You can use the “get source” link to grab a copy of it, or alternatively, by using Mercurial.

Update: I gotten my iPhone 4S since Nov 2011 and successfully managed to restore the SMS database from my iPhone 3GS backup.

The iPhone 3GS was running iOS 4.3.2. I ran my SMS import script every few days to update the iPhone’s SMS database, and I still connected my iPhone 3GS to iTunes to perform regular backups. When I got my new 4S, which was running iOS 5.0, I simply “restored” the latest backup to the new phone. All my SMS history (except those special cases I’ve mentioned) was on the new phone, as if I had been using an iPhone all the while.

As such, I will not be updating my script to work with iOS versions greater than 4.3.x. In iOS 5 the SQLite database schema would most probably have changed to accommodate iMessage. However, I would be happy to accept patches from someone who has implemented the functionality.