Encrypting backups on the iphone is now crucial. The following was taken from my personal phone which
I backup to my local machine sans encryption. As you can see there is a scary amount of personal
data that can be garnered with even the most basic knowledge of forensics. I say forensics in the
loosest terms here as all I really did was play around with a few commands that I always run
when I find files I know nothing about.
Let’s get started..
The backups are located in ~/Library/Application Support/MobileSync/Backup/xxxx… there xxxx…
is the unique identifier for your current mobile device. How this ID is made up I couldn’t
say. It’s not based on the EMEI number or anything like that, although at a glance it does
certainly look like a SHA1 hash of something…
Moving on. In the root directory you will see many, many files, mostly made up of the following
files:
xxxx.mddata
xxxx.mdinfo
These files seems to be SHA1 hashed file names to perhaps mask the original file name, although I
can’t say for sure as I no longer have a jail broken iPhone.
There are also three plist files:
Info.plist
Manifest.plist
Status.plist
We will take a look at these files later on. But first, let’s take a look at those “mddata” and “mdinfo”
files. There is just far too much “noise” coming from them to ignore.
Within my backup directory there are 957 .mddata files and 956 .mdinfo files. Purely out of habit
I ran a simple “file *.mddata” and “file *.mdinfo” on the directory and lo and behold we had something
interesting. Very interesting in fact….
All the .mdinfo files are in fact Apple “binary property list” files (or plist files) [1]. These files seem
to point to data files on the actual phone itself. Running the “strings” command on some of them
gives some pretty interesting (although probably boring in the long run) results [2].
Not really a dead end, but the “.mddata” files are FAR more interesting….
Lots of different files to pick through
—————————————
A quick scan with the “file” command comes up with the following file types for all the 957 samples I have
in my backup directory:
ASCII text
ASCII text, with no line terminators
Apple binary property list
DOS executable (device driver)
GIF image data, version 89a, 596 x 542
HTML document text
JPEG image data, EXIF standard
JPEG image data, EXIF standard 2.21
JPEG image data, JFIF standard 1.01
JPEG image data, JFIF standard 1.01, comment
PDF document, version 1.3
PDF document, version 1.4
PNG image, 310 x 400, 8-bit/color RGBA, non-interlaced
PNG image, 320 x 460, 8-bit/color RGBA, non-interlaced
PNG image, 320 x 480, 8-bit/color RGB, non-interlaced
PNG image, 320 x 480, 8-bit/color RGBA, non-interlaced
PNG image, 480 x 320, 8-bit colormap, non-interlaced
PNG image, 805314566 x 396263525, 0-bit grayscale,
SQLite 3.x database
SQLite 3.x database, user version 3
SQLite 3.x database, user version 327686
XML document text
data
Out of this list, the SQLite databases were probably the most fun. Most of the images in the samples were
from my photos library, either the originals that I took with the iPhones’ camera, images that I had taken
and added to my iPhoto database or they were the thumbnails that the iPhone or iTunes generated for
display.
Databases, it’s always about the databases
——————————————–
Let’s take a look at the SQLite databases. There were 37 different databases on my phone. Going through
each of them manually was a little tiresome but more than that a little scary.
Some of the more “entertaining” things stored in these _unencrypted_ databases include the following:
Calls (incoming, outgoing and missed) [3] [4]
Contact List [5]
SMS messages [6]
Getting the data
—————-
All of this information could be gathered using the built in sqlite3 command and either running
“.dump” or using SQL “select” statements if you wanted a more specific data set.
There is more than enough reason here to encrypt your backups. I don’t really have anything to hide
in terms of state secrets or such like, but the thoughts of having personal information and
messages hanging “out in the wind” like they are in these databases is a very scary though.
But wait, we have forgotten something
————————————-
What about those three .plist files in amongst all those other juicy files ?
Info.plist
———-
The Info.plist file contains a whole bunch of useful information about the phone including:
Device name
IMEI Number
Last Backup Date
Phone Number of the device
Serial Number
Build Version
Calendars
Contact Groups
Itunes Version
As well as a bunch of other references to what look like Base64 encoded files within the XML file.
Lots of useful information here….
Manifect.plist
————–
The Kicker
———–
1password / password hashes….
References:
[1] mdinfo_screenshot_1.png
[2] mdinfo_screenshot_2.png
[3] calls_dump.png
[4] calls_select.png
[5] contacts_dump.png
[6] sms_dump.png
It’s common knowledge that I have an iPhone. I love the damn thing. Even when it bumps my monthly debit orders up to around the R1300 mark. It’s just damn awesome to be in touch 100% of the time. Who I am in touch with I don’t really know…
The following was taken from my personal phone which I backup to my local machine sans encryption. As you can see there is a scary amount of personal data that can be garnered with even the most basic knowledge of forensics. I say forensics in the loosest terms here as all I really did was play around with a few commands that I always run when I find files I know nothing about.
Before we get started, let’s imagine for a second that I am Joe Bloggs in the street with a rudementary knowledge of computers. That basically means I know how to turn it on, “use” iTunes, connect my iPhone and sync that bad boy…I know nothing about encryption save for the fact that “My bank uses it to protect me from evil hackers…”
Let’s get started.
The backups are located in ~/Library/Application Support/MobileSync/Backup/xxxx… where xxxx…is the unique identifier for your current mobile device. How this ID is made up I couldn’t say. It’s not based on the EMEI number or anything like that, although at a glance it does certainly look like a SHA1 hash of something…
Moving on. In the root directory you will see many, many files, mostly made up of the following files:
xxxx.mddata
xxxx.mdinfo
These files seems to be SHA1 hashed file names to perhaps mask the original file name, although I can’t say for sure as I no longer have a jail broken iPhone.
There are also three plist files:
Info.plist
Manifest.plist
Status.plist
We will take a look at these files later on. But first, let’s take a look at those “mddata” and “mdinfo” files. There is just far too much “noise” coming from them to ignore.
Within my backup directory there are 957 .mddata files and 956 .mdinfo files. Purely out of habit I ran a simple “file *.mddata” and “file *.mdinfo” on the directory and lo and behold we had something interesting. Very interesting in fact….
All the .mdinfo files are in fact Apple “binary property list” files (or plist files) . These files seem to point to data files on the actual phone itself. Running the “strings” command on some of them gives some pretty interesting (although probably boring in the long run) results.
Not really a dead end, but the “.mddata” files are FAR more interesting….
Lots of different files to pick through
A quick scan with the “file” command comes up with the following file types for all the 957 samples I have in my backup directory:
ASCII text
ASCII text, with no line terminators
Apple binary property list
DOS executable (device driver)
GIF image data, version 89a, 596 x 542
HTML document text
JPEG image data, EXIF standard
JPEG image data, EXIF standard 2.21
JPEG image data, JFIF standard 1.01
JPEG image data, JFIF standard 1.01, comment
PDF document, version 1.3
PDF document, version 1.4
PNG image, 310 x 400, 8-bit/color RGBA, non-interlaced
PNG image, 320 x 460, 8-bit/color RGBA, non-interlaced
PNG image, 320 x 480, 8-bit/color RGB, non-interlaced
PNG image, 320 x 480, 8-bit/color RGBA, non-interlaced
PNG image, 480 x 320, 8-bit colormap, non-interlaced
PNG image, 805314566 x 396263525, 0-bit grayscale,
SQLite 3.x database
SQLite 3.x database, user version 3
SQLite 3.x database, user version 327686
XML document text
data
Out of this list, the SQLite databases were probably the most fun. Most of the images in the samples were from my photos library, either the originals that I took with the iPhones’ camera, images that I had taken and added to my iPhoto database or they were the thumbnails that the iPhone or iTunes generated for display.
Databases, it’s always about the databases
Let’s take a look at the SQLite databases. There were 37 different databases on my phone. Going through each of them manually was a little tiresome but more than that a little scary.
Some of the more “entertaining” things stored in these _unencrypted_ databases include the following:
Calls (incoming, outgoing and missed)
Contact List
SMS messages
Getting the data
All of this information could be gathered using the built in sqlite3 command and either running ”.dump” or using SQL “select” statements if you wanted a more specific data set.
There is more than enough reason here to encrypt your backups. I don’t really have anything to hide in terms of state secrets or such like, but the thoughts of having personal information and messages hanging “out in the wind” like they are in these databases is a very scary though.
But wait, we have forgotten something
What about those three .plist files in amongst all those other juicy files ?
Before we go into that it’s useful to mention that 90% of the time you can simply read these files with a text editor of some sort or the more common less/most/more option on the CLI. The are simply XML formatted files with all the goodies in there for the world to see.
Info.plist
The Info.plist file contains a whole bunch of useful information about the phone including:
Device name
IMEI Number
Last Backup Date
Phone Number of the device
Serial Number
Build Version
Calendars
Contact Groups
Itunes Version
As well as a bunch of other references to what look like Base64 encoded files within the XML file.
Lots of useful information here.
Manifest.plist
The Manifest.pl file isn’t very interesting at first glance. It is again an XML file with two rather interesting looking keys, namely AuthSignature and AuthVersion. Both of which are base64 encoded files of what looks like garbage, although I am sure on closer inspection they won’t be…If anyone can find me 3 more hours in a day for me to mess around with fun stuff like this, please contact me at godiwishihadmorefreetime@gmail.com
Status.plist
The final “normal” .plist file in the backup root directory is a file called (very imaginatively) Status.plist. It contains a rather cryptic key “Backup Success“. No points for guessing what this file is about.
The Kicker
There is always one kicker isn’t there ? That one little piece of the pie that makes you go “Dammit” or “Oh hell yes” depending on which side of the fence you park your rear…
So I use 1password to store my plethora of passwords that I use for various sites, servers etc. I like it because it works very well and most of all syncs between my MacBook and my iPhone. We know how much we love to sync stuff.
So yes, naturally when I backup my iPhone to my Mac it backups up the current state of my 1password database. It does this into a very neat little SQLite database with my 1password data right there in neat little columns. Ok, so it’s not in plain site, the entries for username and password etc. are hashed, presumably with something like SHA1. I am not a cryptanalyst so at a glance I couldn’t say for certain what the algorithm is. Gun to my head I would say SHA1.
At this point I would like to point out the work being done on SHA1 collisions but I am unable to find anything decent to link to. Perhaps next time…