|
Recovery of deleted files in iDevices since iOS 4 has been impractical to impossible because of the use of an encrypted file system. This does not mean that deleted data cannot be retrieved, however. Deleted records can be recovered from allocated SQLite databases because of the of the construct of the database file: dropped records are not always overwritten. This article will demonstrate how the interaction between the iOS Photo Streams service and the Camera Roll application can help examiners identify and "recover" deleted photographs. |
The dawning of Apple iCloud in 2011, a new service was born: the iCloud Photo Stream. Photo Stream syncs photos taken with an iDevice with other devices registered by the user. The user must have an iCloud account and enable Photo Stream through the Settings | iCloud | Photo Stream menu for the service to work.
Photo Stream comes in two flavors, if you will: the basic Photo Stream and Shared Photo Stream. Basic Photo Stream syncs photos only between the users devices, but Shared Photo Stream alows the user to share photos with other people through a public website or directly on their Photo Stream enabled devices.
You might be getting ahead of me already and thinking, "Excellent! If a user takes a photograph on his iPhone and it gets synced with with other Photo Stream enabled devices, I can find deleted photos from the iPhone on the other devices!" To that I say, "whoa there big fella," and I pull firmly back on your reins. It’s not quite that simple, and while that’s a possibility if the photograph is moved out of Photo Stream storage and into a long term storage location, there are a few things you need to know…
Pictures in the Sky
When a user takes a photograph using a Photo Stream enabled iDevice, like an iPhone, it is sent to iCloud storage and held there for 30 days to give all the users registered devices a chance to sync. The data is only transfered from the iPhone when connected to WiFi, it doesn’t transmit photographs over cellular networks. iDevices hold the last 1000 photos (JPG, TIFF, PNG, and RAW) in the stream, so a user must move photographs to a long term storage location like the Camera Roll if they want to keep them longer. Macs and PCs don’t have the 1000 photo limitation because of their larger storage capacities. Videos are not synced through Photo Stream.
If another Photo Stream enabled device in the user’s network takes a photograph, or a photograph is loaded into Photo Stream on a Mac or PC from another source like a digital camera, it is synced with the iPhone, as you’ve probably guessed. If an image is deleted from Photo Stream on any one of the networked devices, it is deleted from all the devices on the network. As our friend Mork for Ork used to say, "Shazbot!" It’s not going to be that easy. And besides, how often do we get our hands on all the devices when performing forensics, anyway?
So, Why the Post?
While performing an examination on an iPhone 4s with iOS 6.1.3 recently, I noted lots of duplicate photographs with different filenames. The filename differences were not from a user renaming them (if that’s even possible in a non-jail broken device), but images with the same apparent image content and the same created time existed in two distinct paths, had distinct names (like "IMG_1027.JPG" and "IMG_1098.JPG") and existed in different domains. Intrigued, I investigated.
Through study and a little experimentation with a colleagues iPhone, I discovered that when a user takes a photograph, it is simultaneously stored in the Camera Roll Domain in /Media/DCIM/ subdirectories and the Media Domain in the /Media/PhotoStreamsData/ subdirectories. The filename is incremental: if the last photograph was "IMG_1027.JPG", the next is "IMG_1028.JPG". This is true even if "IMG_1027.JPG" is deleted before the next image is taken—filenames are not reused.
Likewise, the photograph that is written to the Photo Stream is given an incremental filename. But, it is not based on the Camera Roll Domain filenames, but instead on the Photo Stream image filenames stored in the Media Domain. Recall that images in Photo Stream can come from any networked device and it will make sense that they need to have unique filenames created on the local device to avoid overwriting. With that knowledge, you begin to understand why two files with the same image content exist in different locations and have different filenames.
But, there’s more. I mentioned that videos were not synced in Photo Stream. They are, however, stored in the Camera Roll domain of the iDevice in which they were created, and they are given an incremental filename that mixes them into the photographs though they have a different extension. I’ve printed a sample listing to illustrate.
CameraRollDomain/Media/DCIM/105APPLE/IMG_5316.JPG CameraRollDomain/Media/DCIM/105APPLE/IMG_5317.JPG CameraRollDomain/Media/DCIM/105APPLE/IMG_5318.JPG CameraRollDomain/Media/DCIM/105APPLE/IMG_5319.MOV CameraRollDomain/Media/DCIM/105APPLE/IMG_5320.MOV CameraRollDomain/Media/DCIM/105APPLE/IMG_5321.JPG CameraRollDomain/Media/DCIM/105APPLE/IMG_5322.JPG
Thus, video are included in the Camera Roll Domain incrementing filename schema, but since they are not written to the Media Domain, the filenames there unaffected, i.e, not incremented.
Another factor to consider is that the Camera Roll domain can be used to save videos and images not made with the device being examined. The user has the option to save image and videos from Internet browsers, applications like Facebook, and MMS messages by pressing and holding them. Whatever the source of the files, they are saved to Camera Roll with sequential filenames.
CameraRollDomain/Media/DCIM/105APPLE/IMG_5198.JPG CameraRollDomain/Media/DCIM/105APPLE/IMG_5199.JPG CameraRollDomain/Media/DCIM/105APPLE/IMG_5200.JPG CameraRollDomain/Media/DCIM/105APPLE/IMG_5201.JPG CameraRollDomain/Media/DCIM/105APPLE/IMG_5202.MOV CameraRollDomain/Media/DCIM/105APPLE/IMG_5203.MOV CameraRollDomain/Media/DCIM/105APPLE/IMG_5204.MOV CameraRollDomain/Media/DCIM/105APPLE/IMG_5205.mp4 CameraRollDomain/Media/DCIM/105APPLE/IMG_5206.mp4 CameraRollDomain/Media/DCIM/105APPLE/IMG_5207.mp4 CameraRollDomain/Media/DCIM/105APPLE/IMG_5208.mp4 CameraRollDomain/Media/DCIM/105APPLE/IMG_5209.mp4 CameraRollDomain/Media/DCIM/105APPLE/IMG_5210.PNG
Again, the JPEG, TIFF, PNG, and RAW images are automatically added to the Photo Stream when the service is enabled. If only there were some data source to help us figure out how to match the Camera Roll image filenames to those in the Photo Streams directories. Cryptographic hashing (e.g., MD5) won’t help because the EXIF data is different in .jpg images, and besides, the point of this article was to "recover" deleted images, which means you are missing one half of the comparison! Once again, enter SQLite…
Recovering images deleted from the Camera Roll
The /CameraRollDomain/Media/PhotoData/Photos.sqlite database contains data about images in the Camera Roll Domain and the Media Domain. Incidentally, it also tracks the videos in the Camera Roll Domain. The ZGENERICASSET asset table is the table of interest and contains file dates, paths, and names.
$ sqlite3 -header CameraRollDomain/Media/PhotoData/Photos.sqlite \ ".schema zgenericasset" CREATE TABLE ZGENERICASSET ( Z_PK INTEGER PRIMARY KEY, Z_ENT INTEGER, Z_OPT INTEGER, ZCLOUDHASCOMMENTSBYME INTEGER, ZCLOUDHASCOMMENTSCONVERSATION INTEGER, ZCLOUDHASUNSEENCOMMENTS INTEGER, ZCLOUDPLACEHOLDERKIND INTEGER, ZCOMPLETE INTEGER, ZFLAGGED INTEGER, ZHEIGHT INTEGER, ZKIND INTEGER, ZORIENTATION INTEGER, ZSAVEDASSETTYPE INTEGER, ZTHUMBNAILINDEX INTEGER, ZWIDTH INTEGER, ZADDITIONALATTRIBUTES INTEGER, ZCLOUDBATCHPUBLISHDATE TIMESTAMP, ZCLOUDLASTVIEWEDCOMMENTDATE TIMESTAMP, ZDATECREATED TIMESTAMP, ZMODIFICATIONDATE TIMESTAMP, ZSORTTOKEN FLOAT, ZCLOUDASSETGUID VARCHAR, ZCLOUDASSETKIND VARCHAR, ZCLOUDBATCHID VARCHAR, ZCLOUDCOLLECTIONGUID VARCHAR, ZDIRECTORY VARCHAR, ZFILENAME VARCHAR, ZTITLE VARCHAR, ZUNIFORMTYPEIDENTIFIER VARCHAR, ZCLOUDMETADATA BLOB, FACERECTANGLES BLOB, ZUUID BLOB, ZLOCATIONDATA BLOB, ZIMAGEURLDATA BLOB, ZTHUMBNAILURLDATA BLOB );
A lot of the information in the table is inconsequential to our analysis. Some is of passing interest, and might be relevant to another type of examination. But lets hone in on our quarry: file dates, names, and paths. To make SQLite work for you, you must learn its Structured Query Language.
First off, lets get an overview of the files that this table tracks. It would be nice to see just the unique paths in the ZDIRECTORY field. Fortunately, SQLite gives us the Distinct function for just this purpose.
$ sqlite3 -header CameraRollDomain/Media/PhotoData/Photos.sqlite \ 'SELECT DISTINCT(zdirectory) FROM zgenericasset ORDER BY zdirectory ASC' ZDIRECTORY DCIM/100APPLE DCIM/101APPLE DCIM/102APPLE DCIM/103APPLE DCIM/104APPLE DCIM/105APPLE PhotoData/Sync/100SYNCD PhotoStreamsData/97527241/103APPLE PhotoStreamsData/97527241/104APPLE
So, we see from the output that the DCIM and PhotoData directories, which are in the Camera Roll Domain, and the PhotoStreamData directory, which is located in the Media Domain, are the source root directories for the data tracked by this table. How would I know that if I wasn’t familiar with the iPhone file structure? Hunt and peck? No!
$ find -type d | grep -E '(DCIM|Photo(Streams)?Data)$' ./MediaDomain/Media/PhotoStreamsData ./CameraRollDomain/Media/DCIM ./CameraRollDomain/Media/PhotoData ./CameraRollDomain/Media/PhotoData/Metadata/DCIM
Here, we tell the find command to return only directories with the -type d option and we filter the results with a regular expression. The regular expression looks for lines ending with DCIM, PhotoData, or PhotoStreamsData. That saves alot of hunting and pecking!
Now, we’ll get export the files from the database sorted by creation date. From this, maybe we can draw some conclusions, or at least have a list of files on which to focus for further analysis.
$ sqlite3 -header -list CameraRollDomain/Media/PhotoData/Photos.sqlite "SELECT \ z_pk, DATETIME(zdatecreated + 978307200, 'unixepoch', 'localtime') AS \ zdatecreated, zdirectory, zfilename FROM zgenericasset ZDATECREATED|ZDIRECTORY|ZFILENAME ... 9598|2013-04-27 20:53:44|DCIM/105APPLE|IMG_5303.JPG 9628|2013-04-27 20:53:44|PhotoStreamsData/97527241/104APPLE|IMG_4245.JPG 9599|2013-04-27 20:53:49|DCIM/105APPLE|IMG_5304.JPG 9629|2013-04-27 20:53:49|PhotoStreamsData/97527241/104APPLE|IMG_4246.JPG 9600|2013-04-27 21:16:41|DCIM/105APPLE|IMG_5305.JPG 9630|2013-04-27 21:16:41|PhotoStreamsData/97527241/104APPLE|IMG_4247.JPG 9601|2013-04-27 21:16:49|DCIM/105APPLE|IMG_5306.JPG 9631|2013-04-27 21:16:49|PhotoStreamsData/97527241/104APPLE|IMG_4248.JPG ...
|
|
Time stamps in the database were in Mac Absolute Time and had to be converted to unixepoch by adding 978307200 seconds for the SQLite DATETIME() function to perform the conversion to local time. |
Here we see a pattern developing. Look at the lines in pairs: the created dates match in each pair. The DCIM filenames increment by one as do the PhotoStreamsData filenames. This leads us to believe that image in the DCIM directory is related to the image in the PhotoStreamsData directory. If we viewed the images, we would in fact see that the image content appears to be the same. However, some image optimizations occur in the creation of the Photo Stream image and we will not match by MD5, and not just because the embedded metadata is slightly different (original filename, for example, but the image data is different.
On your Mac or PC, your photos are downloaded and stored in full resolution. On your iPhone, iPad, iPod touch, and Apple TV, your Photo Stream photos are delivered in a device-optimized resolution that speeds downloads and saves storage space. While actual dimensions will vary, an optimized version of a photo taken by a standard point-and-shoot camera will have a 2048 x 1536 pixel resolution when pushed to your devices. Panoramic photos can be up to 5400 pixels wide.
— Apple Inc.
But does this make a claim that they are the same image invalid. Not at all! The similarities are overwhelming: embedded modified and created time stamps are identical (in the database and in the file system), gps data is identical, device information is identical, and image content appears identical, and so on. In the purest sense, they are not the same any more than a film negative is the same as a print from the negative, yet we would argue they are the same because one is a reproduction of the other. Such is the argument here.
Finally, lets extend this analysis to deleted files. What if we were presented with the following file list?
9623|2013-04-27 21:56:27|DCIM/105APPLE|IMG_5328.JPG 9648|2013-04-27 21:56:27|PhotoStreamsData/97527241/104APPLE|IMG_4265.JPG 9624|2013-04-27 21:56:48|DCIM/105APPLE|IMG_5329.JPG 9649|2013-04-27 21:56:48|PhotoStreamsData/97527241/104APPLE|IMG_4266.JPG 9625|2013-04-27 21:56:59|DCIM/105APPLE|IMG_5330.JPG 9650|2013-04-27 21:56:59|PhotoStreamsData/97527241/104APPLE|IMG_4267.JPG 9656|2013-04-29 01:34:10|PhotoStreamsData/97527241/104APPLE|IMG_4268.JPG 9657|2013-04-29 01:34:23|PhotoStreamsData/97527241/104APPLE|IMG_4269.JPG 9658|2013-04-29 01:38:19|PhotoStreamsData/97527241/104APPLE|IMG_4270.JPG 9654|2013-04-29 01:38:28|DCIM/105APPLE|IMG_5334.JPG 9659|2013-04-29 01:38:28|PhotoStreamsData/97527241/104APPLE|IMG_4271.JPG
We see the expected DCIM/Photostreams created date and filename pattern through the first three pairs. Then we have three Photo Stream images, IMG_4268.JPG, IMG_4269.JPG, IMG_4270.JPG, that are missing their DCIM counter parts. The next DCIM image is IMG_5334.JPG, which is three images removed from the previous DCIM image, IMG_5330.JPG. This is probably better understood in a table:
| Created Date | DCIM (Camera Roll) | PhotoStreamsData |
|---|---|---|
2013-04-27 21:56:27 |
IMG_5328.JPG |
IMG_4265.JPG |
2013-04-27 21:56:48 |
IMG_5329.JPG |
IMG_4266.JPG |
2013-04-27 21:56:59 |
IMG_5330.JPG |
IMG_4267.JPG |
2013-04-29 01:34:10 |
IMG_4268.JPG |
|
2013-04-29 01:34:23 |
IMG_4269.JPG |
|
2013-04-29 01:38:28 |
IMG_4270.JPG |
|
2013-04-29 01:38:28 |
IMG_5334.JPG |
IMG_4271.JPG |
Is it reasonable to conclude that IMG_4268.JPG, IMG_4269.JPG, and IMG_4270.JPG are facsimiles of the missing IMG_5331.JPG, IMG_5332.JPG, and IMG_5333.JPG?
| Created Date | DCIM (Camera Roll) | PhotoStreamsData |
|---|---|---|
2013-04-27 21:56:27 |
IMG_5328.JPG |
IMG_4265.JPG |
2013-04-27 21:56:48 |
IMG_5329.JPG |
IMG_4266.JPG |
2013-04-27 21:56:59 |
IMG_5330.JPG |
IMG_4267.JPG |
2013-04-29 01:34:10 |
IMG_5331.JPG |
IMG_4268.JPG |
2013-04-29 01:34:23 |
IMG_5332.JPG |
IMG_4269.JPG |
2013-04-29 01:38:28 |
IMG_5333.JPG |
IMG_4270.JPG |
2013-04-29 01:38:28 |
IMG_5334.JPG |
IMG_4271.JPG |
I believe that it is. We know that:
-
The Photo Stream service creates a file with the same content at the same time it is created in the Camera Roll
-
Filenames are sequentially created relative to the directory contents
-
Video files in the Camera Roll Domain are not created in the Photo Stream Domain
-
Facsimile images are not cryptographically identical, but the image content is arguably the same.
With this information and the observable file pattern: the unbroken filename sequence of Photo Stream images and an equivalent number of missing Camera Roll images as unpaired Photo Stream images, the conclusion is reasonable.
Caveats
This analysis is not complete. Recovery of deleted SQLite records can be used to confirm or refute this analysis, and I’ll begin working on that next. Also, there are circumstances in which the interpretation is ambiguous (absent recovered SQLite records). Take the following as an example:
9616|2013-04-27 21:51:57|DCIM/105APPLE|IMG_5321.JPG 9643|2013-04-27 21:51:57|PhotoStreamsData/97527241/104APPLE|IMG_4260.JPG 9617|2013-04-27 21:52:01|DCIM/105APPLE|IMG_5322.JPG 9644|2013-04-27 21:52:01|PhotoStreamsData/97527241/104APPLE|IMG_4261.JPG 9618|2013-04-27 21:53:10|DCIM/105APPLE|IMG_5323.MOV 9619|2013-04-27 21:55:22|DCIM/105APPLE|IMG_5324.JPG 9645|2013-04-27 21:55:22|PhotoStreamsData/97527241/104APPLE|IMG_4262.JPG 9646|2013-04-27 21:56:14|PhotoStreamsData/97527241/104APPLE|IMG_4263.JPG 9622|2013-04-27 21:56:19|DCIM/105APPLE|IMG_5327.JPG 9647|2013-04-27 21:56:19|PhotoStreamsData/97527241/104APPLE|IMG_4264.JPG
Rendered into a table
| Created Date | DCIM (Camera Roll) | PhotoStreamsData |
|---|---|---|
2013-04-27 21:51:57 |
IMG_5321.JPG |
IMG_4260.JPG |
2013-04-27 21:52:01 |
IMG_5322.JPG |
IMG_4261.JPG |
2013-04-27 21:53:10 |
IMG_5323.MOV |
|
2013-04-27 21:55:22 |
IMG_5324.JPG |
IMG_4262.JPG |
2013-04-27 21:56:14 |
IMG_4263.JPG |
|
2013-04-27 21:56:19 |
IMG_5327.JPG |
IMG_4264.JPG |
Above, we see that IMG_5323.MOV, a video, does not have a PhotoStreamsData pairing, and that is expected. The next Camera Roll image is paired with the next Photo Streams image in sequence… again, expected behavior. But there is a gap of two filenames in the Camera Roll and only one pairing file in the PhotoStreams Data. The implication is that one of the missing files is a video, but which one? Does IMG_5325.JPG or IMG_5326.JPG pair with IMG_4263?
|
|
Neither IMG_5325 nor IMG_5326 were in the database, even as deleted records, so the data was overwritten or vacuumed. |
Thus, you can see, this will not solve all deleted file mysteries, but you might very well be able to "recover" a file deleted from the Camera Roll by sifting the Photos.sqlite database and finding the Photo Streams equivalent!
No comments:
Post a Comment