Synopsis

Forensics Question: To determine the manner (process) by which a particular photo in the Photos app was created on the iOS device
OS Versions: iOS 12 - 16
Tools: XRY 10.4 and previous versions XAMN 7.4.0 and previous versions Sanderson Forensic Browser for SQLite V3.3.0

Deep Dive Into The iOS “Photos.sqlite” database: Part 1

Usually the content of a photo, its EXIF information (if available), and/or its timestamp are generally adequate in most inquiries and the how any media file came to be on the device is self-evident, i.e. sent as a WhatsApp attachment, an MMS, taken by the host device camera, etc. There are times, however, when a media file is important to a case and the “how it got there” is of importance, but is not obvious or often quite puzzling. Most of us have seen such a media file. It is simply among the media files taken by the host device’s camera, but lacks EXIF information or even has conflicting EXIF information, meaning it was taken by another device. But the question remains, how did it get there?

Fortunately, the question has an answer, one that can be found in the Photos.sqlite database. However, the answer does require a deep dive and some research to bring the answer to the surface. Fortunately, XAMN now does some of the work for you.

Let’s consider an actual case that occurred, the accusations and questions that arose, and the forensic answer. In this case, XAMN was displaying the ‘answer’, but its meaning was anything but obvious.

The case:

A rather well-to-do couple were divorcing and were the parents of an autistic child. Naturally, a custody battle ensued in which accusations are made by each party against the other in the hopes of winning favor with the court and being awarded custody. No surprises there.

During this process, it was discovered that their autistic child’s iPhone contained a batch of pictures in the photo gallery that were sexually explicit, not illegal, but for this child and his age, inappropriate. The presence of these photos and their apparent timestamps were being used by one party to demonstrate the inability of the other party to properly supervise and parent the child. So, the question to be answered was how those media files came to

be on that particular iPhone. To answer that question, the parties turned to digital forensics to assist in uncovering the facts.

The Forensics:

The author’s forensic firm was hired to determine how the media files came to be present on the child’s iPhone. On initial observation, there was no obvious connection to any app or messaging service. The media files were simply sitting among the regular photos taken by the camera on this iPhone. They lacked any useful EXIF information, aside from “EXIFUSERCOMMENT” being “Screenshot” and they weren’t screenshots from this particular iPhone. They were just there. In fact, except for these few explicit media files, it’s one of the cleanest phones in terms of content I’ve ever examined, squeaky clean.

The metadata, as I viewed at the time and with the knowledge I had then, was unremarkable. I had been recently researching artifacts in the Photos.sqlite database and thought it a good time to see if anything about the ‘source’ of the photos in question could be derived from that database. The Photos.sqlite database, in a nutshell, tracks all the photos that are contained and viewed in the Photos.app. As the photos in question were present in this app, it stood to reason that the database may reveal more information than that revealed by XAMN or any other forensic tool for that matter. This database is massive in terms of the detail and amount of metadata present, much more so than most forensic tools actually parse from this data source.

While perusing the data therein, one field in particular came into focus, one named “ZCREATORBUNDLEID”, which was located, at the time of this inquiry, in the table “ZADDITIONALASSETATTRIBUTES”. It was remarkable that the values in this field were the same values as I had seen in the XAMN but under a different field name or heading, which was named in XAMN at the time (before XRY 10.4 and before XAMN 7.4.0) as “Package Name”. The “Package Name” field values for all media files in question were all: “com.apple.sharingd”. Seeing this value with its actual field name, not an interpreted name assigned by a developer, provided greater meaning, particularly the word: “CREATOR”.

Figure 1 - Photos.sqlite database "ZCREATORBUNDLEID" Shows "com.apple.sharingd" for file IMG_0894.JPG – The data displayed in this screenshot was created using Forensic Browser for SQLite Version 3.3.0 by Sanderson Forensics, LTD

Figure 2 XAMN Shows same value "com.apple.sharingd" as "Package Name" for same file

Thus if “sharingd” is the name of the package or bundle that “Created” this media file, then determining what “sharingd” is should reveal how these media files came to be on this particular iDevice. A quick search reveals that “sharingd” is the “Sharing Daemon” that enables AirDrop, Shared Computers, and Remote Disc in “Finder” and first appeared in OSX

10.9. So it appears that “com.apple.sharingd” is an underlying process that enables the AirDrop feature. Airdrop is an Apple feature allowing users of Apple devices (Mac, iPads, iPhones, etc) to share files wirelessly. To send or receive, the device must have Airdrop enabled. One can opt to share with Everyone or just one’s Contacts. In addition, Bluetooth must be enabled, as it scans for other Airdrop users and initiates contact. Finally, Wi-Fi must be enabled, as the file transfer occurs over a peer-to-peer Wi-Fi connection.

To verify this conclusion, several iPhones were used to transfer files via Airdrop between them. In all cases, on the receiving devices, all “Airdropped’ media files showed the “ZCREATORBUNDLEID” as ‘com.apple.sharingd’. While this is pretty solid evidence that ‘sharingd’ is the process underlying Airdrop, one more check was conducted, which was to examine the Apple Unified logs of the receiving iPhone to observe the log entries for the Airdrop transfer. Thus, an Airdrop transfer was made to the recipient phone and a ‘sysdiagnose’ was triggered. The massive array of logs was collected from the recipient device using “Airdrop.” One of the sets of logs in this collection is the “system_logs.logarchive, which are the Apple Unified Logs. They were collected and examined on a Mac laptop using command lines searches in Terminal. Clearly, ‘sharingd’ is the process underlying Airdrop, as seen in the log snippet below in Figure 3.

Figure 3 - Apple Unified Logs queried in Terminal show 'sharingd' is process used by AirDrop

As an aside, each Airdrop transfer is assigned a GUID (See Above Screenshot in Red Rectangle - SFAirDropTransfer: identifier: “GUID String”) and the same GUID can be seen on the sending phone, however that GUID is a one-time use GUID and has a short shelf life in the logs. One can also find other information in these logs that can be used for attribution. So for those getting excited about using these logs to assign attribution for an Airdrop, understand that, one, these logs are not part of the iTunes backup and thus you will need elevated privileges to gain access to these logs (alternatively you can initiate “sysdiagnose” and use AirDrop to retrieve these logs ^{see note2 below} ), plus, two, you’d need both the sending and receiving phones, and, three, you’d need them very soon after the transfer (short shelf- life of logs). Obviously this would be a challenging investigative task, but doable with a sting-type operation.

Thus, we now have established that these media files were created by Airdrop, based on our analysis thus far. There are eleven media files in this investigation that are being questioned as to their source. They were all added to this device on 24 Aug 2019 as the same exact time to the second, thus indicating a batch-type action. If we select the media file shown in the screenshot (Figure 2 above), IMG_0894.jpg, and right-click on the Package Name “com.apple.sharingd”, we can see that we have the option to create a dynamic filter based on this value, as shown in the screenshot below (Figure 4).

Figure 4 -Right Click on Package Name: com.apple.sharingd and create a dynamic filter

In this manner the examiner can create a filter that will isolate and display, in the current tab or a new tab, all media files created by the “Package Name” value name, which, in this case, all media files created via AirDrop (com.apple.sharingd), as shown in Figure 5 below. As there were other Airdrop media files on this device, we applied an additional date / time filter to focus on the media files in question.

Figure 5 - Dynamic filter created for Package Name "com.apple.sharingd"

Conclusion:

In the case at hand, we have established that the eleven questioned media files were added to the iPhone device on 24 August 2019 at the same exact time and via Airdrop.

Additionally, a timeline analysis showed that ten minutes before the Airdrop occurred, the user sent a text message saying he would be arriving at Penn Station (NYC) in just a couple of minutes. Given that Wi-Fi and Bluetooth were enabled, and Airdrop was enabled for “Everyone” (see Figure 6 below), it seems most likely the child was the victim of Cyberflashing via Airdrop, which is a major problem in the NYC transit system, as well as most other major metropolitan transit systems.

Figure 6 - PList settings for "sharingd" reveal Airdrop is available for "Everyone", which is not the default setting

.

Digging a little deeper and wider:

As we all know, once we start down the road of discovery, many other incidental discoveries are made along the journey. During the examination of the Photos.sqlite database, in addition to the “ZCREATORBUNDLEID” field, in the same table there is a somewhat related field, named “ZEDITORBUNDLEID”. We’ll talk more about this related field later. We’ve discussed that “ZCREATORBUNDLEID” contains the value of the process or bundle that created any particular media file. In doing so, however, we have only discussed one particular package or bundle, namely com.apple.sharingd. In all of my tests and observations “sharingd” has only been associated with Airdrop on iOS devices. If anyone establishes another feature on iOS that uses sharingd as its creator bundle, I’d certainly appreciate if you’d let me know.

Obviously there are other creator bundles, some of which are, not surprisingly, rather obscure by virtue of their package names. Let’s look at another common creator bundle, “com.apple.springboard.” “Springboard” is basically the desktop or home screen manager of iOS, but that hardly tells us what media files it creates. After considerable testing of various media file types and their creator bundles, without a doubt, any screenshot using the native method of creating a screenshot will have “springboard” as its Creator bundle.

In the below screenshot, Figure 7, we have a Package Name dynamic filter applied for “com.apple.springboard”. One can easily see that the resultant media files are all screenshots. Once you know some of the package names you seek, i.e. “com.apple.sharingd”, “com.apple.springboard”, etc., you can do a text filter for sharingd, springboard, or the like and then filter for pictures. Using a combination of text and media file filtering will provide more accurate results when searching for a specific package name. This approach will reduce the chances of getting potential false positives and in turn increases the likelihood of finding the desired package name.

Figure 7 - Package Name dynamic filter applied

I have compiled a table with some of the more common creator bundle packages names you may encounter.

The descriptions note the observations of bundles involved in the creator / importer roles.

So far we have been talking about a field named “ZCREATORBUNDLEID”, which was the name of the field at the time this case occurred. Leave it to Apple to continually change things. “ZCREATORBUNDLEID” was the name of the field up to and including iOS 14.

Beginning with iOS 15, the field was renamed “ZIMPORTEDBYBUNDLEIDENTIFIER”, so any query starting with iOS 15 and going forward until they change it again, will have to reflect this field name.

As a ‘forensic bonus’, as previously mentioned, Apple includes another important field named “ZEDITORBUNDLEID”, which is just what the name suggests, the package that edited the media file, if any at all. In most cases this field will be blank, but when populated, it indicates the user knew of the media file’s presence and content, as they took the effort to modify it in some fashion. Thus, it becomes another piece of evidence establishing attribution.

Currently, MSAB’s XAMN is the only tool, based on my latest review, that parses out either of these two fields (ZCREATORBUNDLEID / ZIMPORTEDBYBUNDLEIDENTIFIER OR

ZEDITORBUNDLEID) and has been for a few years now. The manner in which the data was displayed in earlier versions, as “Package Name”, was not very descriptive. Further, when a media file had entries for both a “Creator” and an “Editor”, they were both named “Package Name” and one could not distinguish between the two, as shown below in Figure 8. In this case, both packages are named Package Name and no naming differentiation is made despite the data having come from two different locations and having very different meanings to the data in question. In this screenshot, Sanderson’s Forensic Browsers for SQLITE is used to display the two fields in question, thus clarifying that the two “Package Names” are actually “Creator” and “Editor” fields.

Figure 8 - Both "ZImportedByBundleIdentifier" and "ZEditorBundleID" fields are populated and have identical names in XAMN despite having different source fields and different meanings. – A portion of the data displayed in this screenshot was created using Forensic Browser for SQLite Version 3.3.0 by Sanderson Forensics, LTD

The development team at MSAB has rectified this naming convention issue with XRY 10.4.0 and the fields will appear as “Creator package name” and “Editor package name” in future releases, as seen below in Figures 9 and 10, respectively.

Figure 9 –“ Creator package name” is updated naming convention

Figure 10 –“ Editor package name” is updated naming convention

While the new naming conventions will clarify these field names, it is always a best practice to verify “tool reported data” against raw data when that data is crucial to a particular element of the case and/or whenever the data is not clear in its meaning. You can do so directly in XAMN or you can use a third-party tool to do so. The Photos.sqlite database is massive and complex. It will require a “join” to access the data, so you may find it easier to use a third-party tool. A query is referenced in note 1 below and includes the necessary “joins”.

As we have seen in thus far, the creator or importer bundle or package is an important piece of evidence when it comes to determining how a particular media file came to be on an iOS device. Also, if there is an editor bundle or package, such can be used to show that a user had knowledge of that media file’s existence, as they undertook an effort to modify it.

While we can now determine what bundle created / imported a particular media file, that is only part of the story of how it came to be on a given iOS device. The other part of the story is whether or not the media file was created / imported directly onto the device in question or whether it came from a cloud source. In part two of this series, we’ll examine how the location of a given file, its path, will assist us in determining the rest of the story, i.e. the source from which it came.

Note 1: The information herein came from many sources over time, as well as my own research. As always, research needs verification and most databases also change. If you are going to testify as to how certain evidence came to be and what it means, you should always verify your data and your understanding through your own independent analysis, testing, and verification. If you say what I say, that is hearsay! Always verify before you testify.

I have used a SQLite query in many of the above screenshots that I created, a portion of which originated from ScottKJr3347’s GitHub site, which can be found among the resources below.

This query is geared toward determining the source of a media file. I am sharing that query at this Dropbox link ( https://tinyurl.com/2p8ufxdw ). This query will be modified from time to time and others will be included as well. It will also be referenced in Part II of this series. I believe it to be accurate, which is also true of everything I’ve written above. If you find something in error, please let me know. I’m not flawless. I have a saying that I have use quite frequently, which is “even monkeys fall out of trees”. I can be reached at stephenbunting at mac.com.

Note 2: To initiate “sysdiagnose” on an iDevice, press, simultaneously, Volume Up & Down plus Power Button. Do so for app 1.5 seconds only! You’ll probably get a screen shot; maybe not. Go to Settings > Privacy > Analytics & Improvements > Analytics Data. Scroll down the list to the “I’s” and you should see a couple of entries for “IN_PROGRESS_sysdiagnose_datetime”. Expect compilation to take 10 or 15 minutes. When done, the “IN_Progress” entry goes away and the finished logs can be found in the “S’s” under “sysdiagnose_datetime”. Select the entry and click on the share button to Airdrop it to any iDevice capable and configured for Airdrop. Inside the archive is a forensic goldmine and includes the Apple consolidated logs archive. You can review / query in OSX console or in Terminal. If you can’t dance and chew gum or if your buttons are not working well, you can go to Settings > Accessibility > Touch > Assistance Touch. From there setup a single or double tap for “Analytics”. Then, either a simple tap or double tap will initiate “sysdiagnose”. Once initiated, you can turn it off.

Resources (as of 19 July 2022): https://en.wikipedia.org/wiki/Cyberflashing

https://www.bbc.com/news/technology-33889225

https://www.huffingtonpost.co.uk/entry/cyber-flashing-uk-reports-hidden- problem_uk_5992d291e4b08a24727728fe

https://nypost.com/2017/08/12/airdropping-dick-pics-is-the-latest-horrifying-subway-trend/

https://theforensicscooter.com/2022/02/21/photos-sqlite-update/

https://github.com/ScottKjr3347/iOS_Photos.sqlite_Queries/blob/main/iOS15_Photos.sqlit e_Queries/iOS15_Photos.sqlite_Query

Written by: Steve Bunting (Steve is a contract instructor for MSAB. He has published five textbooks in the field and written numerous articles. He has over 24 years’ experience as a digital forensics examiner, instructor, and mentor).

DFIR Review

The article is easy to follow with plenty of screenshots and references a real case. It would be helpful to include additional details in the case section if possible. The reviewers suggested including the definition of cyberflashing for readers who are not aware of that term.

It was suggested that in addition to the AirDrop section, the author might want to mention the distance limitations that would prevent AirDrop from working.

Reviewers suggested some changes to the organization of the paper. They recommended including the specific version number of the iOS operating systems tested (for example iOS 16.4.1 rather than iOS 16). It would be helpful to include specific dates rather than “at the time of this inquiry” and “as I viewed at the time”.

Some of the reviewers found some differences in the columns that existed in the database, while others were able to reproduce the author’s results. In reference to using Unified Logs, the author wrote “these logs are not part of the iTunes backup and thus you will need elevated privileges to gain access to these logs”, however one of the reviewers indicated that based on their experience you do not need privilege elevation to extract Unified Logs from a device.

Reviewers identified some minor typographical errors and found that one of the URLs did not work and suggested that it should be updated.

Future Work

Reviewers did not suggest any future work related to this research.

Reviewers

Emlyn Butterfield (Methodology Review)

Sharee Dorsey (Methodology Review)

Selena Ley (Methodology Review, Validated Using Reviewer Generated Datasets)

Johann Polewczyk (Methodology Review, Validated Review Using Reviewer Generated Datasets)