Wednesday, September 23, 2020

 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.ownedAlbumsmaxnum.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. 

 









Saturday, January 25, 2020

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:


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



Peeking at User Notification Events in iOS 15

Summary iOS Notifications allow users to peek at content that could be important to them without having to access the app. For us forensic e...