Sharing is Caring – An Overview of Shared Albums in iOS
This blog post is based on research conducted in collaboration with Daniel Ogden and Alexis Brignoni.
Post written by Geraldine Blay
In these times of quarantine and isolation, we may only be sharing virtually. One of the ways we can share memories in iOS/MacOS platforms is through Shared Albums (previously named iCloud Photo Sharing). Shared albums allow users to share photos and videos with people you choose, and subscribers can add their own pictures and videos, as well as comment on them.
To enable shared albums in iOS, a user can go to Settings – click on their Apple ID – iCloud – Photos – Shared Albums. Shared Albums can also be enabled on Windows, macOS, and Apple TV. For more information, visit https://support.apple.com/en-us/HT202786
Methodology
An iPhone 7 Plus running iOS 13.5.1 was used for these tests.
The following shared albums were created in the device:
1. A Shared Album from a test phone - shared with two users, using the email associated with their Apple ID.
2. A Shared Album from another iOS device - shared to the test phone.
3. A shared album created while the device was on airplane mode (and disconnected from any networks). Therefore, the recipients could not receive/accept the request before the phone extraction was completed.
Note: Something interesting happened with this particular part of the test. The phone was taken off airplane mode after roughly 8-10 hours and the album was nowhere to be found. The user we had shared the album with received the notification but it disappeared from his phone.
4. A shared album created from the test phone – shared with two users, one of them had already accepted the invitation to the first album mentioned on item 1 above.
5. A shared album created from macOS. The invitation was sent to the test phone and it was accepted, we could see the album title displayed on the phone but before the photos could transfer, the phone was placed in airplane mode. ** Another extraction was also done once the phone was taken off airplane mode and the photos had transferred to check for differences. **
6. A shared album was created from the test phone, an invite was shared to another iOS user, and the phone was placed in airplane mode. We were curious about repeating part 3 of the test, this time the phone was only left in airplane mode for a short period of time, as opposed to the 8-10 hrs. it was left before.
7. A Shared Album was created from the test phone - shared with a user, using the phone number associated with his Apple ID.
A full file system checkm8 extraction (using UFED 4 PC) was obtained as a baseline before any of the albums were created. Also, full file system checkm8 extractions were obtained after each of the albums mentioned above were created. Physical Analyzer 7.35 and iLEAPP v 1.6 were used to process the extractions.
Results
The screenshot below shows the default structure of the PhotoCloudSharingData directory when the baseline image was taken – at this point, no shared albums had been received or added. It contained Caches and INFLIGHT_JOBS subdirectories and a serverconfiguration file.
The Caches subdirectory is empty, except for a diskcacherepository.plist file.
Once the shared albums had been created on the test device, the directory private/var/mobile/Media/PhotoData/PhotoCloudSharingData/ contained several items:
Within the subdirectory named by the DsID* (private/var/mobile/Media/PhotoData/PhotoCloudSharingData/<DsID>) we find our shared albums.
*Note: According to the iPhone Wiki, DsID stands for Directory Services Identifier and “is a method of identifying AppleID accounts” (think of it as if Apple customers had serial numbers :-p).
Each of these shared albums (regardless if it was shared from the device owner’s Apple ID or shared with the device owner’s APPLE ID) is listed as a separate GUID in the
private/var/mobile/Media/PhotoData/PhotoCloudSharingData/<DsID>/ directory
For example, in the screenshot below, we can see 2 shared albums:
Within each of these shared album directories, there is:
- a DCIM_CLOUD.PLIST: This plist contains:
· DCIMLastDirectoryNumber (in case there is more than one DCIM directory in that album)
· DCIMLastFileNumber: Indicates the number of photos in the DCIM directory. We also verified that adding pictures or videos to a shared album that already exists increases the DCIMLastFileNumber field of the DCIM_CLOUD.plist by the number of items added.
Further testing is required to find out what happens in case there is more than one DCIM directory within a shared album.
- an Info.plist containing the album title, CloudOwnerHashedPersonID, Cloud Owner Email, First and Last Name, whether a public URL is enabled for that album, subscription date (if the album has been shared with the person), and Cloud Relationship State**.
The CloudOwnerHashedPersonID also appears in the cloudSharedPersonInfos.plist discussed below.
**Note: More research is needed for the CloudRelationshipState field. In our testing, we were only able to locate values of “0” and “2”. The albums that had “0” as “Cloud Relationship State” also happened to be the albums the test user had created, and the ones that had a Relationship State of “2” were the ones shared with her. However, this could have been a total coincidence and more testing is needed.
- a subfolder containing the photos/videos from that album. The naming convention for that directory appears to be 100CLOUD***.
***Note: It may be possible that a shared album has more than one of these directories. We haven’t created an album with enough pictures/videos yet – it is on our list of things to test but we didn’t want to keep delaying this blog post. We believe the field DCIMLastDirectoryNumber referenced above relates to this.
The main PhotoCloudSharingData directory also contains a subdirectory titled Caches, which contains diskcacherepository.plist and sharedAssetsPrefetchCount.plist
Other files that could contain important data also found in the PhotoCloudSharingData directory are:
- serverconfiguration: contains configuration settings, such as maxnum.ownedAlbums, maxnum.photosPerAlbum, and maxnum.commentsPerPhoto.
- cloudSharedEmails.plist: contains e-mails associated with the Apple IDs that have shared albums with this device (including the AppleID used in the test device, since albums have been shared from it).
- cloudSharedPersonInfos.plist: In our testing, as soon as an album is shared, this plist will populate a GUID with the format ********-****-****-************, which contains the APPLE ID email (and/or phone number if that was what was used for the invite) of the user that the album was shared with. However, if/when this user accepts the shared album invitation, another entry is created using the CloudOwnerHashedPersonID, which contains the first name, last name and full name associated with their APPLE ID .
While we can look at these plists natively (using a Mac for example) or your favorite forensic suite, Alexis Brignoni was kind enough to add support to some of these plists in iLEAPP. By the way, go follow Alexis on Twitter (@AlexisBrignoni) and check out his blog at https://abrignoni.blogspot.com.
Here are some of the edited screenshots from running iLEAPP on one of the test images.
cloudSharedEmails.plist:
cloudSharedPersonInfos.plist:
Data from the DCIM_CLOUD.plists from every shared album in the test phone (under the iCloud Shared Album Data section of iLEAPP)
Data from the Info.plists from every album (under the iCloud Shared Owner Info section of iLEAPP – file path column omitted from screenshot)
Notice how the previously mentioned missing album (marked with red on the screenshot below) still appeared in the file system but it was not visible on the physical device and none of the other data related to it was populated.
As usual, research is just designed to guide you, always double and triple check everything - trust but verify!
This concludes Part 1 of this blog post… Stay tuned for part 2 for additional artifacts related to Shared Albums in iOS and MacOS.
