As part of my third year studying Digital Security,Forensics & Ethical Hacking at GCU, I took part in a group research project to study the artifacts created when using the notes app on an iPad Mini, and if they could be used as evidence. This post is really just going to explain what I did, what I found and how you can go about doing it too.
Equipment used:
- 2 x Apple iPad Minis (Jailbroken)
- 2 x Wireless Access Points (1 with internet access / 1 without)
- 1 computer with a database manager
I jailbroke the iPads, solely because I wanted to use iFile to view what was happening in real-time, rather than examine the data by backing it up and viewing the file system that way.
I used two wireless access points, so that I could control access to the internet and thus, the ability for each iPad to sync. The computer was used to view the SQLite database that iOS stores the data in, however you can also view the SQLite database in iFile, if you’re lazy.
On the database manager front, I found that when using windows the “SQLite Manager” add-on for Firefox did the trick. On Ubuntu, “SQLite Manager” from the repository was my preferred option.
Overview of the Notes.sqlite file:
The Notes.sqlite file is a sqlite3 file, used by iOS to store all the data regarding each note and the device.
It consists of nine tables :
- ZACCOUNT: This table relates to iTunes account information
- ZNEXTID : This table relates to ID creation
- ZNOTE : This table contains information about the note, such as title, subtitle,author,modification and creation dates as well as foreign key links to ZNOTEBODY
- ZNOTEBODY: Contains the full body of the note, represented in HTML.
- ZNOTECHANGE: Contains information that could be related to syncing although doesn’t appear to have any function.
- ZPROPERTY : Links to the constraints plist file, that contains information about the notes application itself.
- ZSTORE: Contains information relating to icloud stored / local storage
- Z_PRIMARYKEY: Contains the primary keys for each table
- Z_METADATA : Contains metadata
Methodology:
I carried out seven main tests, each test being based on a different action carried out on a note, repeating each one a handful of times in order to verify the results and findings:
- Test 1 : Creation of a note (On iPad 1)
- Test 2: Deletion of a note (From iPad 1)
- Test 3: Modification of a note (From iPad 1)
- Test 4: Modification of a note (From iPad 2)
- Test 5: Accessing a note (From iPad 1)
- Test 6: Accessing a note (From iPad 2)
Test 1:
When a note is created, a record is added to the ZNOTE & ZNOTEBODY tables respectively. The ZNOTE record containing information like the Author, Server ID, date created and date modified. the ZNOTEBODY record containing the actual content of the note, stored in HTML format. Before syncing, each non-synced not has a negative Server ID. After syncing, it has a new Server ID, the value of which is the same across both iPads. It’s also noteworthy to mention that syncing has no effect on the creation and modification date stored on iPad 2.
Test 2:
When a note is deleted from iPad 1, the record is dropped from the tables and that’s all that happens. I was hoping that the server i.d would be used to “mark” the note for deletion, but no, it’s simply dropped from existence. After syncing, the same happens on the second iPad. So apart from a missing private_key, there is no way to know that a note has been deleted and there is no way to recover deleted files using any traditional methods.
Test 3:
When a note is modified from the same device it was created on, the database is changed in two ways. The first is that the modification time stamp is updated to reflect the current time and the second is that the note content in the ZNOTEBODY table is updated to contain the new text.
Unfortunately, this means that there is no way to “roll back” to a previous version of the note.
Test 4:
When a note that was created on iPad 1 is modified from iPad 2, the same changed seen during test 3 were observed, however, what was a interesting, is the value stored in the ZAUTHOR field in the ZNOTE table. Before modification, on iPad 1, this had a value of “NULL” after the modification had synced it had a value of “Stewart Wallace […]” where […] is the iCloud email address the account is registered to.
Test 5:
When a note was accessed (but not edited) by the primary iPad, there was no changes to the database, or the modified time value.
Test 6:
When a note was accessed by the secondary device, there was once again, no changes to the database.
Conclusions
From the analysis of one device and its database, it is possible to determine if a note originated from that device and if it was edited from another secondary device.
If you have more than one device and database, you can cross reference them to deduce what device created the note, if a note has been edited, what device edited it, sadly, it is not possible to see what was edited or at the moment – recover any deleted notes.
Very interesting post Eugene.
I used a similar methodology when analysing iMessage and PhotoStream data and how it interacts with iCloud and other devices, namely an iPhone and iPod touch, and noticed it spreads it’s parameters over an number of SQL database files, both .sqlite and also .db files.
I also found CLI utilities such as TCPDump, which can filter all data from device to another device, and also from device to iCloud back to device, and the olibgatory SQL CLI commands – similarly Cain and Able did this pretty well too – and a hex editor to make sure nothing remains hidden in files, or if said files refuse to open.
I’ll need to have a look into Notes, and possibly iMessage again, because there may be some difference in iOS7.
Keep up the good work!! 🙂
Thanks for reading!
Firstly I’d like to point out that this article was written by one of my friends from my University degree.
Yeah I think iOS7 changes a few mechanisms, still haven’t found the time to look into it 🙂
We use tools such as XRY and recover both live and deleted notes. If databases aren’t supported we write SQL scripts and use Epilog to recover deleted data and reconstruct the database. Determining editing on different devices is interesting and not something we tend to do unless requested.