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. 

 

WhatsApp messages in Non-Rooted Android Devices

Problem

I needed to extract a series of WhatsApp conversations from a Samsung Galaxy S 10+ running Android 9. Since the device was not rooted, I was only able to get logical and file system extractions - I was able to extract the backup databases containing the messages but as expected, they were encrypted and I did not have access to the decryption key (again, because the device was not rooted). 

Some factors to consider:

·       I had consent from the owner to access the information that was stored on the phone, but I did not have the authority to log in with the What’s App account on another device to restore the messages to it and get a full physical extraction. 

·       Many of the key messages in the case were voice messages sent within the WhatsApp chat threads, so taking manual photographs only was not an option. XRY has a program called Photon that takes pictures of WhatsApp chats in an automated way and generates a report. I did not have access to Photon and it would not have worked for the voice messages.

Background 

WhatsApp, like many other mobile apps, uses SQLite databases to store information. However, one of the things that makes WhatsApp so secure is that it uses end-to-end encryption. This very feature that makes the app so attractive to users can be a big headache for us forensicators. 

Messages and related information such as timestamps, information about attached media, etc. are stored in msgstore.db. wa.db stores information about the user’s contacts, such as contact IDs, display names, phone numbers, etc. These databases are located under /data/data/com.whatsapp/databases/ . I was not able to access any of these files as the device was not rooted and I was not able to get a physical extraction.

WhatsApp backups (backups of msgstore.db) are stored in encrypted databases with the filename format msgstore-####-##-##.#.db.crypt**, where the number denoted by ** varies depending on the version of the encryption algorithm used. (In this case, I was dealing with crypt12). These encrypted backups are located in /mnt/sdcard/WhatsApp/Databases if the user has a physical SD card or in /data/media/0/WhatsApp/Databases in case of emulated storage. 

Figure 1 - Sample of encrypted backup databases

The decryption key for these databases is located at data/data/com.whatsapp/files/key. However, to get the decryption key the device would need to be rooted or we would need a physical extraction, which was our problem to begin with. 

Also, since WhatsApp uses a relay service and end-to-end encryption, even with legal process the company wouldn’t be able to provide message content. 

The attachments sent and received through the app are not encrypted and are saved on the device (or micro sd card if there is one), however, retrieving just the attachments without the context of the entire conversation may not make much sense for an investigation. 

If there is no physical micro SD card present:

The voice messages can be found at data/media/0/WhatsApp/Media/WhatsApp Voice Notes. The filename format is PTT-YYYYMMDD-WA####.opus, where YYYYMMDD means the date in Year, Month, and Day format and ## are digits from 0 to 9. 

Pictures can be found at /data/media/0/WhatsApp/Media/WhatsApp Images/  The filename format for the pictures is IMG-YYYYMMDD-WA####.jpg

Videos can be found at /data/media/0/WhatsApp/Media/WhatsApp Video/ The filename format for the videos is VID-YYYYMMDD-WA####.mp4

Methodology 

After following my standard procedures such as photographing the device and documenting all the steps, I obtained file system and logical extractions with CelleBrite’s UFED Touch2.  I also obtained a quick extraction with Magnet’s Axiom.  After verifying that I was not able to obtain the WhatsApp messages with any of these extractions (just like I expected), I proceeded to research other possible alternatives. None of the free tools or scripts that I could find online to extract the decryption key would work, as the phone was non-rooted and was running Android 9. 

Other options suggested in some forensic forums included:

·       If the device’s phone number was the number associated with the WhatsApp account, you should be able to put that SIM card inside a test phone (rooted or one where you could get a physical extraction). You could then get the key file from the test phone and use it to open the encrypted database. NOTE: I did not have permission from the phone’s owner to do this.

·       Downgrading the app appeared to work with older versions of the OS, but not with Android 9 at this moment. 

·       The WhatsApp account on the phone was set up to back up the subject’s Google account - but I was not able to do that unless I connected the phone to the network, which I wasn’t able to do either. 

My next option would be to export each chat thread to my forensic laptop using Bluetooth. Before doing this, I made sure I had the approval to do so from the lead detective, and documented all the steps, as I was interacting directly with the phone content. 

For each conversation (yes, you have to export one thread at a time with this method), click on the three dots (“More options”) on the top right corner of the screen  > More > Export chat. Then, select whether you want to export the media (pictures, videos, voice messages) or just the text. In this case, I needed everything, since I had many voice messages containing what seemed to be relevant information - otherwise I would have just taken pictures of the conversations. When prompted how I wanted to export the conversation, I selected “Bluetooth”.

Figure 2 - Select "More options" (three dots)

Figure 3 - Options to export the chat

The messages and attachments were then exported to a folder on my forensic laptop. I chose to name each folder with the same name listed in the WhatsApp (whether this was the contact name or group name).

For each thread, a .txt file is created containing the text conversation. Any media attachments are also exported to that folder with the following format (see Figure 4 below):

Pictures

IMG-YYYYMMDD-WA####.jpg

Videos

VID-YYYYMMDD-WA####.mp4

Voice messages

PTT-YYYYMMDD-WA####.opus

NOTE: The WhatsApp FAQ page mentions there is a limit to the number of messages that can be exported via email. “When exporting with media, you can send up to 10,000 latest messages. Without media, you can send 40,000 messages. These constraints are due to maximum email sizes.” I could not find any information as to whether there was a limit on the number of messages that could be exported using Bluetooth, but I did notice it was approximately 16-18 mb worth of media (starting with the newest attachments).

This is not a problem, as I still have these files from the CelleBrite extraction, so if an older media file that had not been exported was needed we could still find it, but keep this in mind if you are skipping that step.

It can be good practice to hash the exported files and create an L01 image to keep a copy of them with your case data.

My next problem was how to present all this information to the lead detective. I asked my friend and mentor Alexis Brignoni (@AlexisBrignoni) for suggestions and he quickly wrote a script that processes all the extracted folders and generates HTML reports for each message thread. 

You can find the awesome script here:

https://github.com/abrignoni/Whatsapp-ManualBUP-Parser

NOTE:

A few things about this awesome script:

- The script runs in Python3… you may need to install a dependency such as PySimpleGUI (pip3 install PySimpleGUI).

- Make sure you make a folder for each of the conversations you export. (I just exported one conversation in the example shown below – JavaVonMutt). Place all the folders with the different conversations within another folder (in this case, the WhatsApp2 folder), and place this folder in the same folder that has the Python script and the logo.

Figure 4 - Sample directory structure

-       Make sure you point the script to the main folder where you have all your chats (in this case, WhatsApp2)

Figure 5 - WhatsApp Manual Extractor Report Generator GUI

-       At this time, the reports do not open correctly in Safari. I used Chrome and it looks beautiful!

Figure 6 – Report for the Java Von Mutt chat thread

Figure 7- Image hyperlinked within the report

 

Note: This post is focused on WhatsApp on regular Android devices. The types of artifacts generated by WhatsApp in other operating systems may vary. According to my research, in iOS, WhatsApp data can be found on iTunes backups without any further encryption (you just need the iTunes backup password - or reset it if you don’t have it… but that’s a topic for another day.)

As always:

Double check your work. Don’t just rely on one tool. Whenever possible, test your tools and test your results. 

Document, document, document. 

The fact that your tool of choice can’t parse an artifact at the moment doesn’t mean it is the end of the world. We are examiners, not robots. Think outside the box!

Share your findings with the community. This is how we grow. 

Until next time!

G.

References

Katalov, V. (2018, Dec. 20). A New Method for Decrypting WhatsApp Backups. Retrieved from https://blog.elcomsoft.com/2018/12/a-new-method-for-decrypting-whatsapp-backups/

Mikhailov, I. (2019, July 19). WhatsApp in Plain Sight: Where and How You Can Collect Forensic Artifacts. Retrieved from https://www.group-ib.com/blog/whatsapp_forensic_artifacts

A "Quick Look" into iOS Snapshots

I can’t believe I am finally publishing a blog. I have started writing about at least 5 or 6 different subjects, but I often get distracted and move on to research something else, and forget to go back and finish what I was doing. ***SQUIRREL!!!***



Oftentimes**, when a user swipes up on the screen while using an application in an iOS device, or presses the home button (on those devices that still have one), or if they receive a call while using an application, the active application is sent to the background. A “snapshot” of the current screen is taken in order to provide a smooth visual transition while changing screens.  



** Developers can choose to disable this, to use an overlay image, or to hide certain fields, for security reasons, for example.



From iOS 10 on, these snapshots have been stored as KTX files. KTX is a Khronos Group compression format that provides a container for multiples textures or images. This format usually requires less memory and is faster and more efficient than other types, presenting an advantage for mobile devices.  A more detailed review of the KTX format is beyond the scope of this post, but the specs can be found on the Khronos Group website.



These snapshots can be located at:



/private/var/mobile/Library/Caches/Snapshots/<bundleID>/<bundleID>/



/private/var/mobile/Containers/Data/Application/<ApplicationUUID>/Library/Caches/Snapshots/<bundleID>



Through research I found that the relationship information for these snapshots was stored in the applicationState.db, located in /private/var/mobile/Library/FrontBoard… but of course, it wasn’t stored in a simple way… it was stored in a blob within the database – you guessed it! In a binary plist within a binary plist.



I could go manually parsing the snapshots information for each of these applications one by one, but I would probably fall asleep halfway through the second one. I needed to find a way to automate this process, so I talked to my good friend and mentor Alexis Brignoni (@AlexisBrignoni), since he is very familiar with bplist inception, Python, and mobile devices in general. Our solution?



Methodology



I have always said that the best way of forensically examining a Mac is by using a Mac. I think this also extends to iOS devices. There are several tools out there that do a fantastic job of parsing iOS extractions, but what do we do when the tool does not support a specific artifact? Or even when the tool does support it, it is our responsibility to understand where the reported values come from, and to make sure they are correct, especially if someone’s freedom depends on it.



So far, my favorite way of viewing KTX files has been to “Quick Look” them with Finder (while being a responsible forensic examiner and making sure they are write protected so I don’t step all over the evidence).



Brigs wrote a Python script (SnapshotImageFinder.py) that would extract all the KTX snapshots from the iOS extraction. I then created an Automator Quick Action that converts KTX files to PNG for usability purposes. Finally, Brigs created SnapshotTriage.py. This script first identifies and extracts the incepted bplists related to our snapshots from within the ApplicationState.db. Then, it makes an HTML report for every application that contains snapshots in our iOS device. This is just a quick summary of the methodology we used - for a detailed explanation please check out Brigs’s blogpost.



By the way, iOS Snapshots remind me of Recent Tasks in Android – If you don’t know what I am talking about, here is a great post by Brigs, you  might be missing out on great evidence for your cases.





Forensic Implications/Case Scenario



Imagine a case where our suspect (John Doe, of course) has recorded a video of himself committing a crime using the native Camera app of his shiny brand new iPhone. In the middle of it, Mr. Doe suspends the application (maybe he received a phone call while he was recording or maybe he got paranoid and decided to get rid of the evidence). Of course, the suspect knows his way around technology and also emptied his “Deleted photos” folder within the native iOS app. We know iOS devices are not too forgiving with deleted data.



While examining the full file system extraction of Mr. Doe’s phone, we recover several KTX snapshots from different applications. These snapshots, along with other awesome files such as KnowledgeC, plists, etc. can help us paint a better picture of what was being done on the phone around the time of the crime.



In particular, we recover the following snapshot from /private/var/mobile/Library/Caches/Snapshots/com.apple.camera/com.apple.camera

While this video may no longer be there, it might prompt us to further investigate… The timestamp associated with the KTX file might give us some perspective. Or maybe it could provide additional clues for our investigation. Maybe he shared this video with someone, uploaded it into social media, or moved it into a secret app. Maybe we could serve a search warrant to Apple for iCloud backups. Maybe, just maybe, we might get lucky and find a video approximately 21 seconds long, recorded around the time indicated in the timestamp. 



“Every contact leaves a trace.”- Professor Edmond Locard



Even though Locard’s Exchange Principle is often applied to tangible evidence such as DNA or blood splatters, it very much applies to digital evidence as well.



It is extremely important that we train our forensic personnel or first responders to limit their interactions with digital evidence to the minimum necessary to preserve it. You don’t want to be explaining to the jury why these snapshots have timestamps dated after the police was on scene, or even worse (in my opinion), have a murderer walk away free because we destroyed a key piece of evidence for not being careful.



Note: Our research has been primarily focused on iOS 11 and 12, but we are planning on expanding it to include other versions. We are also currently doing additional research on the timestamps located within the bplists. As always, please validate, validate, validate! Also please feel free to chime in if you have any additional info, because this is how we grow as a forensic community.

48 65 6c 6c 6f 20 57 6f 72 6c 64

…It wouldn’t be a proper geek blog if it didn’t have that title…


Now that we have that out of the way, thank you for visiting my blog. After so many months of putting it off, I finally gave in and decided to create a blog to share my thoughts and findings with the #DFIR community. Any posts and opinions stated here are mine, unless otherwise specified.


Stay tuned for my first actual post soon!

- G.