Do you have a Full-Sized Asset…or just a Thumbnail? Did Optimized iPhone Storage process occur?

Hello everyone! During previous research, I’ve mentioned a few times that my test devices were using the Apple Photos application setting Optimize iPhone Storage in lieu of Download and Keep Originals setting. I’ve used this setting in the past because most devices I’ve encountered are using this setting. I’ve always had a curiosity about the forensic impact this might have on my examinations but have never had enough time to research it, yet.

Here is what is listed in the settings menu for Optimize iPhone Storage:

“If your iPhone is low on space, full-resolution photos and videos are automatically replaced with smaller, device-sized versions. Full-resolution versions can be downloaded from iCloud anytime.”

I recently noticed a few questions being posted on the listservs and DFIR Discord about examiners locating assets in file system (fs) locations like /private/var/mobile/Media/PhotoData/Metadata/DCIM/100APPLE/* and then not being able to find the corresponding original full-sized asset in the /private/var/mobile/Media/DCIM/100APPLE/* fs location. In one instance, the examiner believed the original full-sized asset was deleted but left behind the */Metadata/DCIM/100APPLE/ asset and the original assets entry in Photos.sqlite.  

Another examiner asked if I could think of any reason why a device might only be containing a thumbnail asset at /private/var/mobile/Media/PhotoData/Thumbnails/V2/DCIM/100APPLE/* but would not have an original full-sized asset saved at /private/var/mobile/Media/DCIM/100APPLE/*?

I really didn’t have an answer to these questions. My initial thought was these assets were related to the device using iCloud Photos and the Optimize iPhone Storage, but research and testing was required.

I went to the all-knowing Google and started reading up on what I could find. I located this thread written by Léonie, which discussed “Things to consider before using Optimize Storage on the iPhone or iPad for Photos.”

Another article noted: “If you turn on Optimize Storage, iCloud Photos automatically manages the size of your library on your device. Your original photos and videos are stored in iCloud and space-saving versions are kept on your device. Your library is optimized only when you need space, starting with the photos and videos you access least. You can download the original photos and videos over Wi-Fi or cellular when you need them.”

After reading these and other publications, my imagination went wild! I started thinking about all those exams where I marked thumbnails as non-relevant artifacts. I also started thinking it might be possible for a device to contain primarily thumbnails or reduced sized assets. I started considering how big of a forensic impact this might have during a forensic examination. There could be a chance we might only have thumbnails or reduced sized assets being stored on the device internal storages and one of those assets (photos and videos) could be a critical piece of evidence or could be depicting an illegal image…aka the smoking gun! What can we do and articulate with just a thumbnail or reduced sized asset?

Forensic Questions

Do these statements about Optimize iPhone Storage process mean we might be missing original full-sized assets during our examinations if we only acquire the physical device? Answer: Yes

Is there a way to determine which original full-sized asset has been optimized or is missing from our physical device acquisition? Answer: Yes

After we review some material, I will remind you of these forensic questions in Section #6:

What would you do if you only had an optimized asset or thumbnail asset as critical media evidence or illegal media?

Is there a way to analyze the optimized or thumbnail asset and link it to a live photo or original full-sized asset?

Will this provide us with enough information to articulate a legal request for cloud data acquisitions?

If we cannot locate the original full-sized asset during your analysis of the physical device acquisition, are we going to take steps to acquire the original full-sized asset from iCloud Photos?

Tools Used

ArtEx 2.5.3.0

3uTools 2.63

DB Browser 3.12.2

Forensic Browser 3.3.0

Cellebrite UFED 4PC 7.60.0.128

Cellebrite Physical Analyzer 7.58.0.66, 7.59.1.16 and 8.2.1.547

Cellebrite Cloud Analyzer 7.58.0.66 and 7.59.1.16

Magnet AXIOM 6.8.0.33717

Oxygen Detective 15.0.0.126 & 15.1.0.69

Elcomsoft Phone Breaker 10.12 build 38809

Elcomsoft Phone Viewer 5.33 build 37389

Test Devices

Bandit’s iPhone 6s Plus [iPhone8,2] A1687

• iOS 15.3.1 (19B74)

Dexter’s iPhone SE (1^st Gen) [iPhone8,4] A1662 MP8L2LL/A

• iOS 15.6 (19G71)
• 32 GB device storage capacity

Dexter’s iPhone 7 [iPhone9,1] A1660 MNAJ2LL/A

• iOS 15.1 (19B74)
• 128 GB device storage capacity

Scooter’s iPhone X [iPhone10,3] A1864 NQCP2LL/A

• iOS 14.7 (18G69)
• 128 GB device storage capacity

John Scooter Wick’s iPhone 12 Pro [iPhone13,3] A2341 MGK43LL/A

• iOS 16.0.2 (20A380)
• 128 GB device storage capacity

NOTE: The iPhone SE and the iPhone 7 both belong to Dexter. Dexter’s Apple ID is being used on both devices and sharing iCloud Storage. You will see some of the impacts this had during the video documentation.

Getting iOS Optimize iPhone Storage process to occur and optimize assets

The first challenge I encountered was attempting to get the device and iOS to initiate the Optimize iPhone Storage process. I had a loose understanding of what might occur if this process took place, but I couldn’t find a lot of documentation about the exact process, what files, or artifacts would be affected when the process occurs. As many of you are aware, I have been working on Photos.sqlite for some time now and I believed there might be some data within it that could help with the analysis of these optimized or thumbnail assets.

None of the test devices I have been using were close to having full internal device storage. One of my initial assumptions was that it might be easier to see the asset changes if the device internal storage was full, thus forcing iOS to optimize some of the assets. After reviewing my available devices and their internal storage sizes I had available for testing, I decided I would attempt to fill Dexter’s iPhone SE which had iOS 15.6. The settings UI indicated this device only had 32 GB of maximum allowable internal storage. I thought this would be an easy task, but I was wrong! I used several different methods of loading data onto Dexter’s devices:

• 3uTools version 2.63 via Import Photo and PicTools application
• AirDrop
• iCloud Shared Link (aka Cloud Master Moment Asset)
• Capturing new assets
• Saved Message attachments
• SnapChat saved assets

SECTION #1

Device Settings

In this section I will review some of the device and application settings we should verify before we begin analyzing the assets and data found within Photos.sqlite.

iCloud Photos Indicator ON or OFF

The iCloud Photos indicator is in the settings menu at:

Settings > Apple ID > iCloud > Photos On/Off

This is an indicate if a iCloud Photos, in any part, is being used by the device. If either iCloud Photo or Shared Albums switch, detailed in the next section, is ON this indicator will display ON.

If iCloud Photos is OFF but Shared Albums is ON, then this indicator will still show ON, as displayed in figure #33.

For this indicator to display OFF both iCloud Photos and Shared Albums must be turned OFF.

Just because this indicator is displaying OFF it does not indicate that iCloud Photos has never been used for this Apple ID.

This property list is associated with the iCloud Photos setting switch located in the settings menu at:

Settings > Apple ID > iCloud > Photos > iCloud Photos & Shared Albums On/Off switches

It should be noted the setting switches at the above location also control the switches located at:

Settings > Photos > iCloud Photos & Shared Albums On/Off switches

We can use cloudServiceEnableLog.plist to determine if iCloud Photos setting was ON or OFF at the time of a device acquisition.

This property list (plist) can be found at the following file system location:

/private/var/mobile/Media/PhotoData/private/com.apple.accountsd/cloudServiceEnableLog.plist

Within the plist, there will be an enabled key/node and an associated type key/node which will indicate the following:

Again, just because these settings are turned OFF it does not indicate they have never been used for this Apple ID. If this setting has been turned ON and OFF, there will be a history of the setting changes with associated timestamps for the analyzed device only.

Optimize iPhone Storage or Download and Keep Originals Setting

This property list is associated with the Photos Application and will indicate if Optimize iPhone Storage or Download and Keep Originals setting is being used. This settings menu is located at:

Settings > Photos (app) > Optimize iPhone Storage or Download and Keep Originals

The option being used will be checked.

It should be noted the setting switches at the above location also control the switches located at:

Settings > Apple ID > iCloud > Photos > Optimize iPhone Storage or Download and Keep Originals

We can use com.apple.mobileslideshow.plist to determine which setting is being used.

This property list (plist) can be found at the following file system location:

/private/var/mobile/Library/Preferences/com.apple.mobileslideshow.plist

Within the plist there will be a downloadAndKeepOriginals key/node. The sub-key/node will indicate a true or false value to indicate if Download and Keep Originals setting is being used:

This was tested on iOS 14.7. The plist and key/node were found on test devices using iOS versions 14.7, 15.6, 16.0.2. There doesn’t appear to be any changes and appears to be valid in all versions.

Device and Photos Application storage usage

Most of our forensic tools will provide us with device storage measurements. They provide us with acquisition sizes, device maximum storage sizes, user data sizes and available storage space. During this research, I wanted to verify the device storage measurements that could be viewed from: Settings > General > iPhone Storage and started looking for a plist. Luckily, I quickly learned Oxygen Forensic Detective provided the file and decoded data. I didn’t need to search too hard for the data.

The data I was looking for is stored in the com.apple.atc.plist which can be found at the following location:

• /private/var/mobile/Library/Preferences/com.apple.atc.plist

The plist contains a key/node titled DiskUsage. This key/node has several sub-keys/nodes some of which are the following:

• _PhysicalSize
• _PurgeableSize
• _FreeSize

The integer values listed for these keys/nodes are the number of bytes associated with the key/node. There are other keys/nodes in this plist that should be reviewed and tested if you have questions about the amount of data being stored within the device internal storage.

We can see in figure #3.4, this plist also contains a key/node titled CameraRoll and the following sub-keys/nodes:

• _PhysicalSize – This matched the data being displayed within the iPhone Storage setting UI
• _Count – This appeared to hold the number of assets/files that are using the storage space. I attempted to decipher what assets are being counted to produce a matching count, but I was unsuccessful
• _PurgeableSize – I observed this value change throughout the research. I was not able to narrow down exactly what data was being grouped/labeled as purgeable. I have an idea that it’s related to the temporary cache files that are created when assets are being synced with iCloud Photos but was not able to prove that theory. The reason I am making that correlation is because when this value was 0 there were no assets being stored at /private/var/mobile/Media/PhotoData/CPL/storage/filecache.

Photos Application Low Disk Space indicator

The value being stored in this property list is associated with data that can be viewed on the iPhone storage bar chart located at:

Settings > General > iPhone Storage

We can use com.apple.mobileslideshow.plist to determine which setting is being used.

This property list (plist) can be found at the following file system location:

/private/var/mobile/Library/Preferences/com.apple.mobileslideshow.plist

Within the plist there will be a DiskSpaceWasLow key/node that indicates the following:

• True – Device internal disk space was low at the time of acquisition

False – Device internal disk space was not low at the time of acquisition

Cloud Photo Library Asset Counts and Low Disk Space indicators

Another plist that I would like to remind you about is the syncstatus.plist. This plist will keep track of some of the iCloud and iCloud Photos information.

This property list (plist) can be found at the following file system location:

/private/var/mobile/Media/PhotoData/CPL/syncstatus.plist

The plist holds a key/node titled cloudAssetCountPerType. This key/node has two sub-keys/nodes:

• public.image – will indicate the number of images/photos that have been synced with the device’s active Apple ID iCloud Photos account
• public.movie – will indicate the number of movies/videos that have been synced with the device’s active Apple ID iCloud Photos account

I have not tested the new iOS 16 Shared Cloud Photo Library and how this might impact the number of assets

The plist also holds a key/node titled iCloudLibraryExists. This key/node will indicate if iCloud Photo Library exists indicated as True or False.

• True – iCloud Photo Library Exists
• False – iCloud Photo Library does not exist

After the device has been using iCloud Photos and iCloud Photos is turned OFF via the device settings the cloudAssetCountPerType and iCloudLibraryExists keys/nodes are no longer listed in the property list. See Section 13 for a video example.  

The plist holds a key/node titled lastSyncDate, which is a timestamp (UTC-0) that indicates the last time the device and iCloud Photos had a successful sync.

If iCloud Photos was being used and is then turned OFF lastSyncDate timestamp will update and indicate when iCloud Photos was turned OFF. See cloudServiceEnableLog.plist for additional timestamps. See Section 13 for a video example.

Within the plist there will be a lowDiskSpace key/node that indicates the following:

• True – if local device internal storage is low
• False – if local device internal storage is not low

Live Photo JPG-MOV versus HEIC

While I was conducting this research, I was curious why the live photo asset was a JPG and MOV file and not a HEIC file. I conducted a few quick tests and figured it out easily.  

The setting that controls the type of files that are captured with a Live Photo can be found at:

Settings > Camera > Formats > High Efficiency or Most Compatible

We can use com.apple.camera.plist to determine which setting is being used.

This property list (plist) can be found at the following file system location:

/private/var/mobile/Library/Preferences/com.apple.camera.plist

Within the plist there will be a CAMUserPreferenceCaptureEncodingBehavior key/node that indicates the following:

• 0 – indicates the camera will capture High Efficiency files when a live photo is captured
  • HEIC for live photos
• 1 – indicates the camera will capture Most Compatible files when a live photo is captured
  • JPG and MOV for live photos

SECTION #2

Research Documentation

Media Artifacts Acquired from Dexter’s iPhone SE on 9/11/2022 at 5:00 PM  

During this section, I will review the some of the media artifacts that were acquired after a full file system (FFS) acquisition. The assets we will review in this section have not been affected by the Optimize iPhone Storage process yet. The original full-sized assets we will review are still being stored within the device internal storage.

While I am discussing and articulating if it is an original full-sized asset, a thumbnail asset, or an optimized asset, please consider all example assets I use as assets that depict illegal media or a piece of media that is critical for your analysis and investigation.

During the entire testing and research for this write-up, several different forensic tools were used to acquire the device data. In some instances, when it is important to show the chain of events, I will mention the date and time the acquisition was made to demonstrate a timeline of events.

At this point during testing, Dexter’s iPhone SE was not being synced with iCloud Photos. The assets being captured were being saved to the device’s internal storage. It should be noted that iCloud Photos was used previously for this device, so you might notice Cloud Photo Library assets, but for testing purposes, iCloud Photos is now off.

Figure #10 is a screenshot of the assets found within the acquisition within the */mobile/Media/DCIM/100APPLE/* file system location. You will notice there are other media assets being stored in other file system locations. I will discuss some of those other file system locations, but not all of them.

In figure #10, you will notice I’ve highlighted one of the assets (IMG_0043.MOV) that I was able to acquire and analyze after the acquisition. We will review this asset again after Optimize iPhone Storage process occurs. This asset is a Live Photo that was captured with Dexter’s iPhone SE during previous research.

IMG_0043.MOV, seen in figure #10, will not be listed in Photos.sqlite because this asset is related to a Live Photo. The asset listed in the Photos.sqlite database will be IMG_0043.JPG, which we can see to the immediate left of the MOV asset.

In figure #10, please take note of the following items about IMG_0043.MOV:

• It was captured with an Apple iPhone SE (1^st generation)
• The creation timestamp indicates it was created on 2022-08-21 at 15:55:26 (UTC -7)
• The file size is listed in the two different tools, Oxygen 2.56 MB and ArtEx 2685135 bytes

I have already answered this question, but will one or both live photo assets be listed as an original full-sized asset? If so, will the original full-sized asset be the e photo or the video?

In figure #10, we can review the file system location */mobile/Media/DCIM/100APPLE/* and observe it is storing 85 assets:

3 HEIC assets                           17 JPG assets                           17 MOV assets

15 MP4 assets                           33 PNG assets

In figure #11, we can review the following file system location */mobile/Media/PhotoData/CPLAssets/* which is storing 118 folders and 11 assets:

10 JPG assets                           1 PNG asset

At this time there are not that many assets are being stored in the CPLAssets file system location.  

Other locations of interest:

• /private/var/mobile/Media/PhotoData/Metadata/DCIM/100APPLE/
  • 56 assets
• /private/var/mobile/Media/PhotoData/Metadata/PhotoData/CPLAssets/
  • 112 folders – 0 assets
• /private/var/mobile/Media/PhotoData/Thumbnails/V2/DCIM/100APPLE/
  • 75 folders – 75 assets
• /private/var/mobile/Media/PhotoData/Thumbnails/V2/PhotoData/CPLAssets/
  • 118 folders – 11 assets

In figure #12 you will notice the file system location contains multiple folders. Observe the difference in the number of folders being shown within our forensic tools. Oxygen Forensic Detective is showing only 11 folders that contain assets. ArtEx is showing 118 folders, which includes folders that contain assets (11 folders) and the remaining 107 folders that are empty. Oxygen Detective’s default setting was to hide empty folders. This was discovered later and turned off. Just another example of why it’s important to know and understand how your tool works and knowing is half the battle!

We will come back to re-analyze these file system locations after Optimize iPhone Storage process has taken place to see if there are any changes.

IMG_0043.JPG/IMG_0043.MOV Photos.sqlite analysis before Optimize iPhone Storage process

Again please, use your imagination and consider this IMG_0043 asset as one that is depicting illegal material. If this asset, IMG_0043, was an artifact of interest we might use different tools and techniques to learn additional details about the asset. Sometimes forensic tools could be parsing some of this information and others might not. One technique I routinely use is to analyze the Photos.sqlite database. I do this by manually reviewing the database using different SQLite tools and queries I’ve made. 

Figure #13 is a video of the analysis technique I would use to determine if the asset was captured with the analyzed device and if it’s been synced with the Apple ID iCloud Photos account.

NOTE: As with most of my other research, some of the screenshots and videos used in the blog may have been made prior to the complete decoding of Photos.sqlite values. Some of the decoding in the videos might be different than what appears in the final release of this blog and SQLite queries.

In ArtEx, we can see there are two assets, IMG_0043.JPG and IMG_0043.MOV, being stored in the */Media/DCIM/100APPLE/ location for the one asset that was captured. As discussed earlier, this was due to the assets belonging to a Live Photo.

I will start by reviewing the assets in ArtEx and the Local Photo Library Photos.sqlite database. I will be using a new query that has been made to allow for easier analysis of assets to determine which assets are being stored on the device internal storage or which assets have been moved to iCloud Photos as the result of Optimize iPhone Storage process. The new query will be listed with the other queries for each iOS version. The new query will have zIntResou and iCloud Photos in the query name. Here is an example of the iOS 16 version query name: iOS16_LPL_Phsql_IntResou-iCldPhotos.txt

• What if we didn’t know that?
• How can we use the data stored in Photos.sqlite to determine if these assets are a part of a Live Photo?

In figure #13, we can see I have highlighted two rows of data belonging to the live photo, IMG_0043. The rows of data indicate they belong to an asset with a zAsset-Filename of IMG_0043.JPG, but you will notice they have different file sizes. One row of data belongs to the IMG_0043.JPG from the live photo and the other row of data belongs to IMG_0043.MOV from the live photo. 

Notice in the Photos.sqlite database, the two rows of data have the same zAsset-zPK (227) and the same zAsset-UUID (E1D7737A-028C-45A8-8BD4-F81F1AD69246). As discussed previously in other blogs and research, if you use small queries that only include one row of data per primary key or asset file name, you will be overlooking important data for your analysis.

Notice these rows of data do not have a zCldMast-zPK listed. This is because this asset has not been synced with iCloud Photos.

Even though the two rows of data have the same zAsset-UUID, they have different zIntResou-Fingerprint identifiers. This indicates each row of data is related to unique internal resource asset:

• AR0xwcy090kAG2gO0IYVrRjsqkkp
• AQH9EJZqDfQDfx5D7Q3KHuvxojzR

In the video, you will notice I am highlighting that the acquisition was made on 9/11/2022 at approximately 5:00 PM, and at that time, iCloud Photos was OFF. I am pointing out that the data in zAsset-Bundle Scope can have two different interpretations, one if iCloud Photos is turned ON and a different interpretation if iCloud Photos is turned OFF. In this case, it’s turned OFF and the value (0) indicates the asset is being stored on the local device. The zAsset-Cloud Local State can also have two different interpretations, in this case, it’s turned OFF and the value (0) indicates the asset has not been synced with iCloud Photos.

The zAsset-Visibility State data indicates these assets are visible within the Local Photo Library. The extended attributes table contains data indicating the asset was captured with an iPhone SE, which was Dexter’s iPhone that is being examined. It was captured with the back camera as indicated by the zAddAssetAttr-Imported By data. This is typical of an asset that was captured with the Native Camera Application (com.apple.camera). We can validate this by analyzing the knowledgeC.db, current.Powerlog.PLSQL, biome data, sysdiagnose logs, and other system files to learn which application might have been in focus and if the camera was using power at the time this asset was captured/digitized with the analyzed device.

The following are some important areas to review when analyzing the data for original full-sized assets or if the assets are thumbnails or optimized assets.

zAsset-Saved Asset Type indicates the assets are a part of the Local Photo Library and are being stored in the DCIM/100APPLE location.

zAsset-Filename and zAddAssetAttr-Original Filename, as stated previously, have matching file names. Both rows of data are listing a file name of IMG_0043.JPG. As we have already discussed, one of the assets being stored on the device is a MOV file but isn’t being listed in Photos.sqlite because the primary asset is the photo asset because it was a live photo.

How can we determine which row of data belongs to the JPG and which data belongs to the MOV?

When we compare the timestamps, we can see they either match or are very close with very little time differential. This, along with the other data we have reviewed, indicates there is a high probability the asset we are analyzing was captured with the examined device.

You might notice this recently added column, zAddAssetAttr-Date Created Source and its decoding. Based on my testing and research, the following is a list of values I was able to interpret:

• Integer/Value 0 = Indicates the source of the date created data is a cloud asset
• Integer/Value 1 = Indicates the source of the date created data is a local asset with EXIF timestamp
• Integer/Value 3 = Indicates the source if the date created data is a local asset without an EXIF timestamp

As a reminder, most of the timestamps in Photos.sqlite are stored in UTC-0, but the EXIF timestamp is not. Photos.sqlite zAddAssetAttr-EXIF string timestamps are based on the capturing device date and time setting and the capturing device time zone setting. If the capturing device date and time is not set correctly, this timestamp might not be accurate. The same goes with the capturing device time zone setting, if it is not set correctly, the EXIF timestamp might not be accurate. In most cases, we can use the timestamps and time zone offsets listed in the Photos.sqlite query outputs to recognize possible timestamp inaccuracies. It’s also important to analyze any location data you might find within EXIF or Photos.sqlite because it might provide you with some insight into the proper time zone.

Reviewing these timestamps and time zone offsets should provide you with additional confidence that the asset was captured with the analyzed device. In most cases, if an asset is captured with the analyzed device, the zAsset-Date Created, zAddAssetAttr-EXIF Timestamp String, and the zAsset-Add Date will match or will be off by only a few seconds. The few seconds difference is normally related to syncing and analysis being completed by iOS. As we will see later in this blog, if iCloud Photos was ON, the zCldMast-Creation Date will also match or be very close to the other timestamps.

We can see additional examples of data that is missing which indicates iCloud Photos is OFF:

• zCldMast-Creation Date – blank
• zIntResou-Cloud Master Date Created – blank
• zCldMast-Cloud Local State – blank

The ZINTERNALRESOURCE Photos.sqlite table is the primary table that will be discussed in this blog. The data stored in the ZINTERNALRESOURCE table can be linked to the data stored Photos.sqlite tables. The data can be used to determine if the original full-sized assets are being stored within the device internal storage or if they have been optimized for iPhone storage.

I created a reference guide for the ZINTERNALRESOURCE table data that I’ve been able to interpret. The reference guide can be found as a separate blog on theforensicscooter.com.

When analyzing the rows of data related to the live photo asset, IMG_0043.JPG, we can use several columns to determine the type of asset being stored on the device. Some of these columns have been discussed in other blogs and research, but I will cover them again to highlight how they can be used for this type of analysis.

zAsset-Kind Sub-Type indicates the assets are a part of a Live Photo.

zIntResou-Datastore Class ID – in this video example, the decoding is incorrect. The query was updated after this video was made. The correct interpretation of the value indicates both rows of data are related to local photo library or cloud photo library assets.

zIntResou-Remote Availability indicates not available remotely, which is because these assets have not been synced with iCloud Photos.

zAddAssetAttr-Original File Size indicates the Original File Size for the primary original full-sized asset. In this example the primary original full-sized asset has a file size of 2084608 bytes. All rows will indicate the same original file size.

zIntResou-File ID the rows have a value of -1 which means these assets do not have a file ID. Assets/rows of data will be assigned an internal resource file ID when the asset is being stored on the device internal storage. The exemption to that would be all 5003 and 5005 thumbnails. During my testing they never received an internal resource file ID.

zIntResou-Resource Type indicates the row of data resource type is a Photo or a video. In this example the top row asset is related to a Photo, IMG_0043.JPG and the bottom row is related to a Live Photo, IMG.0043.MOV.

zIntResou-Datastore Sub-Type will indicate general information about the row of data and a possible file size estimate. In this example the top row indicates it belongs to the main/primary asset and it’s the original full-sized asset. This row of data belongs to the IMG_0043.JPG, is the Main Asset and its original size is 2084608. The bottom row indicates it belongs to a Live Photo Video and it’s the original full-sized asset. This row of data belongs to the IMG_0043.MOV and its original size is 2685135.

zIntResou-Data Length indicates the data length for the internal resource asset being stored on the device. We can see, as discussed above, the two different assets have different data length values.

zIntResou-Recipe ID will indicate information about the internal resource asset that could help us locate it within the device. In this example both rows have a value of zero (0) and it indicates the asset is the original size.

• The decoding of this value has been updated since the making of this video and a value of zero indicates the assets original file size matches the internal resource data length or the original full-sized asset has been optimized for iPhone storage and it’s on the device. So, we can see in this example, these two assets, original file size matches the internal resource data length and are both being stored on the local device internal storage.

Notice there aren’t any thumbnails or other assets currently listed in Photos.sqlite for either of these assets. This does not mean that there aren’t any thumbnails, for example 5005.JPG.

REMINDER: At this time during the research, I was still in the preliminary phases of decoding the Recipe ID column. Do not pay attention to the other values and decoding observed in this video. 

zAsset-Playback Style is a great indication of the type of asset you are analyzing. In this case, we can see both assets are indicating the playback style should be Live Photo. This is a great column of data to use when you have access to a physical device. Using the data from this column and the physical device you can hand scroll and locate the asset within the Photo Library and click on the asset to see the type of playback you observe on the device. If the device is isolated from networks, the asset on the physical device may appear to be a still image. If you review Photos.sqlite data, it may indicate the asset should be a Live Photo or Video. This would be an early indication that the original full-sized asset is not stored on the device internal storage. If the asset was stored on the internal storage, the asset would not require a network connection to view the live photo or video.   

SECTION#3

Part B Filling a device internal storage for Optimize iPhone Storage testing

To shorten this long write-up, I’ve created a Part-B for you to reference how I was able to fill a devices internal storage so that Optimize iPhone Storage would occur. Part-B is comprised of long videos and written descriptions of the actions taken to import assets onto the device internal storage and through iCloud Photos. In the example videos, you will be able to see the storage progress via the internal storage bar chart within settings.    

Use this link to review Part -B in its entirety.

Figure #14 is just a portion of an example video from Part-B that demonstrates what it would look like if we were able to see the device’s internal storage at the time Optimize iPhone Storage process occurs.

In this video Dexter’s iPhone SE is connected to a network, iCloud Photos is ON and Optimize iPhone Storage is being used.

Keep in mind, in this example I intentionally filled the internal storage, so I knew exactly when Optimize iPhone Storage process occurred. I believe, if this setting is being used, this process could occur at any time, regardless of how much free space is available.

During this example video, watch the device on the right. While I am filling the storage, the device is connected to a WIFI network, thus things will happen automatically. 

At the beginning of figure #14, you will see the device internal storage is using 30.6 GB of 32 GB. A notification is received on the device informing the user that the storage is full. Note, the date and time in the lower right corner of the video, is 10/9/2022 at 9:20 AM. Notice an asset was uploading/syncing with iCloud Photos and then completes. We can immediately see that asset in iCloud Photos, then its synced with the iPhone 7 on the left side of the screen.

That video was an hour-long video and within less than a few seconds that video finished uploading to iCloud Photos, then it immediately appeared on the iPhone 7. I might have fast internet, but it isn’t that fast. It would take a lot longer for that iPhone 7 to download an hour-long full-sized video. This is just another example of Optimized iPhone Storage that allows for the creation of smaller sized assets and thumbnails to access assets being stored in iCloud Photos.  

At 9:54 AM, I checked the iPhone storage bar chart, we can see that Optimize iPhone Storage process has occurred. The allocated storage has gone from 30.6 GB to 24.1 GB. We can see the yellow Photos section of the bar chart and the Photos Application is accounting for 6.53 GB of allocated storage. Watching closely, we will see the yellow color almost disappear from the bar chat and it will be replaced by system data and the Photos Application storage indicator is no longer visible on the screen. This is because the application is no longer accounting for the largest amount of storage. Based on what I observed, this new system data is related to cache files that have been created on the device as a part of the iCloud Photos syncing process.

SECTION #4

Assets being stored at /private/var/mobile/Media/PhotoData/CPL/storage/filecache/*

After additional testing, I believe the system data/other data being listed in the UI we can see in figure #14 after assets are optimized is related to the processing of assets to prepare them for syncing with iCloud Photos and Cloud Photo Library.

During my research and testing, I have noticed prior to assets being removed/optimized for iCloud Photos syncing, the system/OS will make copies and create cache files for the assets being prepared for syncing. Those copies will be stored within the following file system location:

• /private/var/mobile/Media/PhotoData/CPL/storage/filecache/*

These assets are stored in folders. These folders are named based on the first three characters of the assets Cloud Master GUID.

These cache files stored in this location will have unique file names:

• Example of a cache filename: cplAZU9jNuHXi265ciMYlCGYpnkVAJg.jpeg
• All filenames start with “cpl” which stands for Cloud Photo Library
• Followed by the assets zCldMast-Cloud Master GUID from Photos.sqlite

Things that I noticed about these cache files:

• It’s possible these cache files might still have their original full-sized counterpart asset being stored on the device. I found this was an area where duplicate detection was useful
• These cache files will be the same file size as the original full-sized asset
• These cache files do not stay on the device long. They are only stored until the asset(s) have been fully synced with iCloud Photos

There is a database being stored at the following file system location that contains related data:

• /filesystem1/private/var/mobile/Media/PhotoData/CPL/storage/store.cloudphotodb

I have discussed this database in other write-ups and believe it contains important data related to assets and other items being synced with iCloud Photos. I am not going to cover this in detail right now because I believe it should be researched again and detailed in a separate write-up.

Figure #15 is a short video providing an example of this file system location, the cache files and how they are removed after the asset is synced with iCloud Photos. In figure #15, you will see that I am using Dexter’s iPhone SE with 15.6, which is now jailbroken with PaleRa1n. This makes conducting these tests very easy. The device was not connected to a network and several assets were captured and are pending to be synced with iCloud Photos. We can see the assets that were captured while the device was isolated from the networks are listed in Photos.sqlite, they have cloud master data and cloud master created dates, but these assets have not been synced with iCloud Photos yet. They are pending upload as we can see in the following columns: zCldMast-Cloud Local State and zIntResou-Cloud Local State.

After the device is connected to a network and the assets are completely synced with iCloud Photos the case files are no longer listed within /private/var/mobile/Media/PhotoData/CPL/storage/filecache/*

SECTION #5

Reviewing assets after Optimize iPhone Storage Process was completed

While I was importing assets into the devices internal storage, several OS processes occurred. After the assets were imported onto the device, they would be synced with iCloud Photos. At the same time, the OS was evaluating how much device internal storage was available and deciding which assets should be optimized to free up additional internal storage. These processes occurred several times while I was attempting to fill the internal storage.

Prior to isolating the device from network connections, Optimize iPhone Storage process occurred a few times. The asset with illegal material we are analyzing, IMG_0043.JPG, was optimized during testing and the original full-sized asset was uploaded to iCloud Photos. I was not able to catch that exact optimization process, but based on the continued research and testing, I that didn’t matter. When the optimization process occurs, optimized assets and different thumbnails are created on the device internal storage to replace the original full-sized asset that allows users to view the assets on their device.

During this research and testing, several device data acquisitions were collected over an extended period using different forensic tools. Within the next few sections I will use those different acquisitions to demonstrate what I’ve discovered because of this research.

Review of IMG_0043 asset before and after Optimize iPhone Storage 

During this section, I will review some file system locations from before and after Optimize iPhone Storage process occurred. Analyzing these file system locations should provide you with some insight in determining if assets have been optimized. If optimization has occurred, it appears the primary file system locations we typically find assets */mobile/Media/DCIM/100APPLE/* and */mobile/Media/PhotoData/CPLAssets/* will have far less assets then the other metadata and thumbnail file system locations. 

Figure #16 is a screenshot of the assets found within the */mobile/Media/DCIM/100APPLE/* file system location. You will notice I’ve highlighted our illegal/critical evidence asset, IMG_0043.MOV, we have been analyzing.

9-11-2022 Before-optimization acquisition contained 85 media assets stored in */mobile/Media/DCIM/100APPLE/* file system location:

3 HEIC assets                           17 JPG assets                           17 MOV assets

15 MP4 assets                          33 PNG assets

10-9-2022 After-optimization acquisition contained 7 media assets:

3 MOV assets                           4 MP4 assets

None of these assets were related to IMG_0043.JPG that was previously stored here

Figure #17 is screenshot of the */mobile/Media/PhotoData/CPLAssets/* file system location.

9-11-2022 Before-optimization acquisition contained 118 folders and 11 assets:

10 JPG assets                           1 PNG asset

10-9-2022 After-optimization acquisition contained 160 folders and 0 assets:

160 folders – 0 assets

None of these were related to the IMG_0043 asset we previously observed in DCIM/100APPLE This is evidence that both file system locations (*/DCIM/100APPLE/* & */Media/PhotoData/CPLAssets/*) and assets are impacted by the Optimize iPhone Storage process. If the Optimize iPhone Storage process occurs lots of full-sized assets might be removed from the physical device storage and stored in iCloud Photos.

Other locations of interest after Optimize iPhone Storage process occurred:

• /private/var/mobile/Media/PhotoData/Metadata/DCIM/100APPLE/
  • 142 assets, compared to 56 assets prior to optimization
  • None of these were related to the IMG_0043 asset we previously analyzed
  • This is a primary file system location where optimized assets can be found

• /private/var/mobile/Media/PhotoData/Metadata/PhotoData/CPLAssets/
  • 156 folders – 33 assets, compared to 112 folders – 0 assets prior to optimization
  • None of these were related to the IMG_0043 asset we previously analyzed
  • This file system location is one of the primary locations where optimized assets can be found; there are others, but this location will store most of them

• /private/var/mobile/Media/PhotoData/Thumbnails/V2/DCIM/100APPLE/
  • 214 folders – 214 assets, compared to 75 folders – 75 assets prior to optimization
  • An asset related to IMG_0043 was found in this location

• /private/var/mobile/Media/PhotoData/Thumbnails/V2/PhotoData/CPLAssets/
  • 160 folders – 185 assets, compared to 118 folders – 11 assets prior to optimization
  • None of these were related to the IMG_0043 asset we previously analyzed

SECTION #6

Forensic Examiner Thoughts

What would you do if you only had an optimized asset or thumbnail asset as critical media evidence or illegal media?

Is there a way to analyze the optimized or thumbnail asset and link it to a live photo or original full-sized asset?

Will this provide us with enough information to articulate a legal request for cloud data acquisitions?

If we cannot locate the original full-sized asset during your analysis of the physical device acquisition, are we going to take steps to acquire the original full-sized asset from iCloud Photos?

SECTION #7

Comparing acquisition data & Photos.sqlite before & after Optimize iPhone Storage

In figure #22 and in this next section we will review the data for our illegal material asset (IMG_0043) before and after Optimize iPhone Storage process has occurred. During this section I will be using Cellebrite (CB) Physical Analyzer (PA) (7.58.0.66).

Dexter’s iPhone SE iOS 15.6 FFS acquired 11/12/2022 at 1:12 PM (UTC-8)

In this section we will use a full file system acquisition that was made using Oxygen Detective. This acquisition was made after the Optimize iPhone Storage process occurred.

Using Cellebrite PA 7.58.0.66, I used the term “DCIM” to filter the assets. Notice we are now viewing 511 of 6806 photos assets.

I then cleared the filter and switched views from Thumbnail view to Folder view and navigated to the DCIM file location. Notice when within the “Media – Images” analyzed data section, /private/var/mobile/Media/DCIM/* folder indicates its containing 22 image assets.

• What about the 511 hits that we got when we used the filter in the thumbnail view?
• How many assets are being displayed on the device for the Local Photo Library?

Notice that while we are reviewing the images being stored in /private/var/mobile/Media/DCIM/* folder we again do not see any assets related to IMG_0043.JPG.

When we are looking at all images filtered using “DCIM” we can see an asset related to IMG_0043.JPG, which is a 5005.JPG thumbnail asset.

We can see the device is connected to a Wi-Fi network. When I navigated to the asset (IMG_0043.JPG) within the Local Photo Library, then clicked on that asset, it displays the asset on the device in the individual asset view. If you pay close attention, you should notice that the live photo was played. You might have to look closely, but if you watch the screen saver you should notice the short video clip.

I also navigate back and forth between the assets in the individual asset view. These were not clicked on from within the Photo Library multiple asset view (aka Camera Roll).

In figure #22, we can see I use the device to locate the asset (IMG_0043.JPG) we have been analyzing. If we have the device to manually verify artifacts we encounter during our forensic exam, we might be able to find and verify the following information:

• We can see the Original File name listed is IMG_0043
• We can see the asset has been synced with iCloud Photos because of the Cloud Logo with a checkmark
• The asset type is a JPEG
• The flash was used
• The asset is a Live Photo

Now let’s see if we can find the asset (IMG_0043.JPG) in the acquisition (11/12/2022 at 1:12 PM) made after Optimize iPhone Storage process was completed. Using Cellebrite PA filters, I searched for image/photo assets related to “IMG_0043.”

Using the search, we were able to locate several assets related to a file name IMG_0043. Some of those were not related to the asset we want to analyze. Two of the hits are in fact assets related to our illegal asset IMG_0043.JPG. One of the assets is a message attachment and the other is a 5005.JPG thumbnail.

Using the “Media – Images” section of PA, we can use the specific search and see three results. One of the results is the asset we want to analyze. Cellebrite PA does not provide us with a lot of information about a 5005.JPG asset. By reviewing the available information within Cellebrite PA we can learn the following about the thumbnail asset:

• The file path */Media/PhotoData/Thumbnails/V2/DCIM/100APPLE/IMG_0043.JPG/5005.JPG indicates its related to an asset with the file name IMG_0043.JPG
• The folder file name matches the original file name for our illegal asset
• It’s a 5005.JPG thumbnail asset
• It’s file size is 58311

Does any of this tell us the asset was captured with the analyzed device?

Where is all the asset metadata and EXIF data we can view on the device?

I’m hoping someone said Photos.sqlite?

But wait, there’s thumbnail metadata data in Photos.sqlite?

Let’s review the 9/11/2022 BEFORE Optimize iPhone Storage acquisition.

Notice in the BEFORE Optimize iPhone Storage acquisition, there are several more assets found in the “Media – Images” section of PA than there is in the AFTER Optimize iPhone Storage acquisition. We can see in the BEFORE acquisition the illegal asset (IMG_0043.JPG) has a lot more information like, location indicators, event indicators, and attachment indicators. Using the “File Info” tab we can see a lot of the metadata and EXIF data for the original asset that was being stored on the device.

Then we can use the “Media – Images” section of PA to view the related image assets. We can see there are seven assets that were found related to our search for IMG_0043 and four of those assets are related to our illegal media asset.   

Then we can use the “Media – Videos” section of PA to view the related video assets. We can see there are five assets that were found related to our search for IMG_0043 and three of those assets are related to our illegal media asset.

Then, we can go back to “Media – Images” tab and notice the same 5005.JPG has also been found in the before optimization acquisition.

Let’s go back and review AFTER Optimize iPhone Storage acquisition and review the file size of the 5005.JPG asset to see if they match, and they do.

Using Photos.sqlite to review 5005.JPG thumbnail

Let’s use Photos.sqlite to see if we can find more metadata or EXIF data about the IMG_0043 5005.JPG thumbnail asset that contains illegal material.

In figure #23, I’ve previously exported Photos.sqlite database from the data acquisition. I am using ArtEx SQLite tool to review the database and the query output. Using the query output, I will use the zAsset-Filename and zAddAssetAttr-Original Filename columns to locate the data for our illegal material asset IMG_0043.JPG, which if we only had the 5005.JPG thumbnail we can derive the original file name using the thumbnail file path: */IMG_0043.JPG/5005.JPG.  

The first asset we locate in Photos.sqlite with a filename of IMG_0043 has 6 rows of data. These rows of data contain the following information that we can use to validate the data in each row is associated with the same primary asset:

• zAsset-Filename: IMG_0043.JPG
• zAddAssetAttr-Original File Name: IMG_0043.JPG
• zCldMast-Original Filename: IMG_0043.JPG
• zAsset-ZPK: 227
• zAsset-UUID: E1D7737A-028C-45A8-8BD4-F81F1AD69246
• zCldMast-Cloud Master GUID: AR0xwcy090kAG2gO0IYVrRjsqkkp
• zAddAssetAttr-Master Fingerprint: AR0xwcy090kAG2gO0IYVrRjsqkkp
• zIntResou-Fingerprint: Notice each row of data has a unique fingerprint:
  • AR0xwcy090kAG2gO0IYVrRjsqkkp
    • Primary Fingerprint: It matches the zAddAssetAttr-Master fingerprint and zCldMast-Cloud Master GUID
  • AcPSDEGfJknUr2GqnwQRpA4rCWvW
  • AWy3IwVZDWITU95VkUlizbfbdEDD
  • AQH9EJZqDfQDfx5D7Q3KHuvxojzRARY8KZlWCCwXLzIBl8bY0g5CtZbL
  • AaeMgmkY4TSzAYvc31TljBvxmAL7
• zAsset-Cloud Local State: Asset can or was synced with iCloud
• Extended attributes: Apple iPhone SE (1^st generation) back camera 4.15 mm – indicates the same make and model device that is being analyzed and was used to capture the original illegal media asset
• zExtAttr-Flash Fired: Indicates flash was fired
• zAddAssetAttr-Imported by: Native Back Camera
• zAsset-Saved Asset Type: Local Photo Library Asset
• zAsset-Directory: DCIM/100APPLE
• zAsset-Add Date: 2022-08-21 22:55:28 (UTC)
• zAsset-Date Created: 2022-08-21 22:55:28 (UTC)
• zCldMast-Creation Date: 2022-08-21 22:55:28 (UTC)
• zIntResou-CldMast Date Created: 2022-08-21 22:55:28 (UTC)
• zAddAssetAttr-EXIF string: 2022:08:21 15:55:28 (UTC -7)
• zCldMast-Cloud Local State: Synced with Cloud
• zCldMast-Import Date: 2022-08-21 22:55:28 (UTC)
• zCldMastMedData-Data: Contains EXIF and Metadata for the Original Full-Sized asset 
• zAsset-Kind: Photo
• zAsset-Kind Sub-Type: Live Photo
• zAddAssetAttr-Cloud Kind Sub-Type: Still Photo
• zAsset-Playback Style: Live Photo

There are several other columns of data that match for all 6 rows of data, but the above listed rows are ones I analyze to see if I was working with related asset data and if it was captured with analyzed device.

We can then review the zCloudMasterMediaMetadata table zData column data and review the EXIF data that has been saved in Photos.sqlite for this asset.

I would like to highlight the zCldMast-Import Date column timestamp. I recently learned that I’ve previously misinterpreted the timestamp in this column in past research and blogs.

zCldMast-Import Date: This timestamp (UTC-0), will be populated when an asset is recognized as an asset that can be imported into iCloud Photos. This occurs when an asset is imported into the Local Photo Library AND the iCloud Photos setting is ON. If iCloud Photos setting is OFF, the cloud master table and other iCloud Photos related data will not be populated in Photos.sqlite.

If iCloud Photos setting is ON, regardless of whether the device is connected to a network or not, the OS will prepare the device and assets to be synced to iCloud Photos. The zCldMast-Import Date, zAsset-Add Date, zAsset-Date Created, and if the asset was captured with the device, the EXIF timestamp string, will all be very similar. These and other cloud master related timestamps become populated almost simultaneously. These timestamps might only be off by a few seconds. This allows the assets to start syncing with iCloud Photos as soon as the device is reconnected to a network.  

Most important thing to note about this zCldMast-Import Date, is that this timestamp has very little to do with when the asset was synced over the network with iCloud Photos but has to do with when the device prepared the asset to be synced. Be sure that you are checking the zCldMast-Cloud Local State to determine if the asset is Pending Upload or if it has been synced with iCloud Photos.

In figure #24, we will go back and start to analyze the illegal asset IMG_0043, but this time we will review the data from the ZINTERNALRESOURCE table. Additional information about the internal resource table can be found by reviewing the Reference Guide for Photos.sqlite zInternalResource table.

zIntResou-Local Availability: Indicates if each internal resource asset is available within the local device internal storage. Within the Internal Resource Reference Guide, I detail that during my testing, thumbnail assets (5003 or 5005) will not be listed as having local availability, nor will they be listed to have a zIntResou-File ID, but they will be stored on the device internal storage.  

zIntResou-Cloud Local State: indicates the asset has been synced with iCloud

zIntResou-Remote Availability: indicates the asset is available remotely via iCloud Photos

zIntResou-File ID: none of the assets currently have an internal resource file ID. This is consistent with an optimized asset that the OS doesn’t consider recent and has had very little user/device interactions within Photo Library/Camera Roll

zAddAssetAttr-Original File Size: this indicates the file size for the original full-sized asset, which was 2084608

Now we will start to see some differences.

The ZINTERNALRESOURCE table will track the different associated assets using the zIntResou-Fingerprint. The following column data is listed in conjunction with its zIntResou-Fingerprint/internal resource asset. We can see just by reviewing this data the original full-sized asset was a Live Photo. The primary fingerprint is listed in bold which is associated with the original full-sized asset, IMG_0043.JPG.

zIntResou-Resource Type:

• AR0xwcy090kAG2gO0IYVrRjsqkkp: Photo
• AcPSDEGfJknUr2GqnwQRpA4rCWvW: Photo
• AWy3IwVZDWITU95VkUlizbfbdEDD: Photo
• AQH9EJZqDfQDfx5D7Q3KHuvxojzR: Live Photo
• ARY8KZlWCCwXLzIBl8bY0g5CtZbL: Live Photo
• AaeMgmkY4TSzAYvc31TljBvxmAL7: Live Photo

zIntResou-Datastore Sub-Type:

• AR0xwcy090kAG2gO0IYVrRjsqkkp: Main Asset Original Size
• AcPSDEGfJknUr2GqnwQRpA4rCWvW: JPG Med Thumb
• AWy3IwVZDWITU95VkUlizbfbdEDD: JPG Small Thumb
• AQH9EJZqDfQDfx5D7Q3KHuvxojzR: Live Photo Video Optimized CPL Asset
• ARY8KZlWCCwXLzIBl8bY0g5CtZbL: Video Med Data
• AaeMgmkY4TSzAYvc31TljBvxmAL7: Video Small Data

zIntResou-Data Length:

• AR0xwcy090kAG2gO0IYVrRjsqkkp: 2084608
• AcPSDEGfJknUr2GqnwQRpA4rCWvW: 650110
• AWy3IwVZDWITU95VkUlizbfbdEDD: 50275
• AQH9EJZqDfQDfx5D7Q3KHuvxojzR: 2685135
• ARY8KZlWCCwXLzIBl8bY0g5CtZbL: 1366576
• AaeMgmkY4TSzAYvc31TljBvxmAL7: 385678

zIntResou-Recipe ID:

• AR0xwcy090kAG2gO0IYVrRjsqkkp: Original File Size matches Data Length or this is an asset that has been optimized for iPhone storage
• AcPSDEGfJknUr2GqnwQRpA4rCWvW: Various Asset Types or Thumbs
• AWy3IwVZDWITU95VkUlizbfbdEDD: Resource Type is a Photo asset will be 5003 or 5005 JPG thumb
• AQH9EJZqDfQDfx5D7Q3KHuvxojzR: Original File Size matches Data Length or this is an asset that has been optimized for iPhone storage
• ARY8KZlWCCwXLzIBl8bY0g5CtZbL: medium MOV file associated with Live Photo
• AaeMgmkY4TSzAYvc31TljBvxmAL7: No IR Asset Live Photo iCloud Sync Asset

We can then take this data and reanalyze the “File Info” for the 5005.JPG asset within CB PA. We can review the file size and see that it does not match but is very close to the “Data Length” listed in the Photos.sqlite for the zInternal Resource fingerprint, AWy3IwVZDWITU95VkUlizbfbdEDD.

Because of the above information, based on this analysis, and previous testing, I believe this data provides us with a high probability the original asset was captured with analyzed device. I believe we could state with confidence the 5005.JPG thumbnail stored at */Thumbnails/V2/DCIM/100APPLE/IMG_0043.JPG/5005.JPG is a very similar representation of the original full-sized asset that was once stored on the local device and might still be stored in the users iCloud Photos.

Based on the research and what we’ve learned about iCloud Photos synchronization, if we encounter an optimized asset or a thumbnail asset within the physical device acquisition and we do not have the original full-sized asset, do you think we should attempt to acquire the original full-sized asset from iCloud Photos?

If during our analysis we’ve determined that we only have an optimized asset or a thumbnail asset, how long would it take to acquire the proper legal authority and make a legal request for iCloud Photos sync data? How long would it take to use a commercial forensic cloud acquisition tool to acquire the iCloud Photos sync data? Regardless of which method the data might be acquired, we can anticipate that it will take at least a few days before we can get the proper legal authority? Is this a situation where we might want to consult with legal advisers and articulate exigent circumstances because anyone who has access to the iCloud account could access the iCloud Photos data which contains the original full-sized asset and might permanently delete it before they could be acquired through legal process?

SECTION #9

After an asset is Optimized & assets are Downloaded from iCloud Photos back onto the device

 Dexter’s iPhone SE iOS 15.6 FFS acquired 11/19/2022 at 3:48 PM (UTC-8)

As noted previously, I have viewed the illegal material asset, IMG_0043, on the device while it was connected to a network. By viewing the illegal material asset on the device as I describe below and can be seen at 0:50 in figure #22, impacted the number and type of related assets that are now being stored on the device internal storage and what is being listed in the Photos.sqlite database.

After discovering the data and assets discussed within this section, my initial thoughts were if a user viewed an optimized asset on a device, this action would guarantee the original full-sized asset or related assets would be downloaded from iCloud Photos and imported back onto the device. After additional testing and research, this was not correct. Yes, it’s possible the original full-sized asset or related assets could be downloaded from iCloud Photos when an asset is viewed on the device. But I also observed several different instances where I had no interaction with a particular asset on the device and assets were downloaded and imported onto the device. There were other instances where I viewed an optimized asset on the device, and it did not download and import the full-sized asset onto the device.

During this section, we will review the data within the acquisition after the following actions occurred:

• Illegal material asset, IMG_0043.JPG, was captured with Dexter’s iPhone SE

• The illegal material asset was sent to another user via an iMessage

• iOS Optimize iPhone Storage process occurred

• As a part of the Optimize iPhone Storage process, iOS moved the illegal material asset, IMG_0043.JPG, and other related assets, IMG_0043.MOV, from the device internal storage to iCloud Photos. The only asset left behind was the attachment and 5005.JPG

• Device acquisition was made (11/12/2022 at 1:12 PM) – post-Optimize iPhone Storage

• On 11/19/2022 at 1:01 PM (UTC-8), the illegal asset, IMG_0043, was viewed as an individual media asset on the analyzed device, see 00:50 in figure #22, for this user action

• On 11/19/2022 at 4:38 PM (UTC-8) the device was acquired again after the asset was optimized and viewed on the analyzed device

Figure #27 is a video that demonstrates how I reviewed the acquisition data after the optimized asset was viewed on the device and assets are downloaded from iCloud Photos back onto the device. Immediately upon searching within CB PA for our illegal material asset via the file name, IMG_0043, we can see we have more assets. A lot of the asset metadata, EXIF data, and Cellebrite PA tags can now be seen on the new assets.

We can see there are four additional assets related to IMG_0043 asset. Two (2) of them can be found in “Media – Images” and two (2) can be found in “Media – Videos.” These 4 assets were not present in the last acquisition we reviewed. The following assets are within the device internal storage and are located at the following file paths:

• */mobile/Media/PhotoData/Thumbnails/V2/DCIM/100APPLE/IMG_0043.JPG/5005.JPG
  • Present in the last acquisition prior to the asset being viewed on the device
• */mobile/Media/DCIM/100APPLE/IMG_0043.JPG
  • Was NOT present in the last acquisition after optimization occurred
• */mobile/Media/DCIM/100APPLE/IMG_0043.MOV
  • Was NOT present in the last acquisition after optimization occurred
• */mobile/Media/PhotoData/Metadata/DCIM/100APPLE/IMG_0043.JPG
  • Was NOT present in the last acquisition after optimization occurred
• */mobile/Media/PhotoData/Metadata/DCIM/100APPLE/IMG_0043.meduim.MOV
  • Was NOT present in the last acquisition after optimization occurred

Take notice of the modified, accessed, created timestamps being represented in CB PA.

• */mobile/Media/PhotoData/Thumbnails/V2/DCIM/100APPLE/IMG_0043.JPG/5005.JPG
  • 8/21/2022 3:55:28 PM (UTC-7) – has never left the device internal storage
• */mobile/Media/DCIM/100APPLE/IMG_0043.JPG
  • 11/19/2022 1:11:30 PM (UTC-8)
• */mobile/Media/PhotoData/Metadata/DCIM/100APPLE/IMG_0043.JPG
  • 11/19/2022 1:01:37 PM (UTC-8)
• */mobile/Media/DCIM/100APPLE/IMG_0043.MOV
  • 11/19/2022 1:11:30 PM (UTC-8)
• */mobile/Media/PhotoData/Metadata/DCIM/100APPLE/IMG_0043.medium.MOV
  • 11/19/2022 1:01:37 PM (UTC-8)

Review the created timestamp for the thumbnail asset being stored in */V2/DCIM/100APPLE/*. Notice that it matches the date and time the original full-sized asset was originally imported onto the device from the devices back camera.

Review the created timestamps for the assets being stored in */Metadata/DCIM/*. Notice they match the date and time when the asset was clicked on in the Local Photo Library Camera Roll, viewed individually on the device, then downloaded from iCloud Photos back onto the device. As I stated previously this user action may or may not prompt the optimized asset to be imported back onto the device internal storage from iCloud Photos. The viewing of the asset on the device and the user interactions with the device can be seen in figure #22.

The */mobile/Media/DCIM/100APPLE/* asset was created on the device a few seconds later. Based on previous testing and research, I believe the time difference between the metadata files timestamp (1:01:37) and the timestamp for the original full-sized asset (1:11:30) is the result of the time it took for the full-sized asset to completely import onto the device.

These newly created timestamps could have a significant impact when creating artifact timeline reports or if an examiner doesn’t fully understand these timestamps. This is an example of why I believe it is very important for examiners to understand the difference in terms used in forensic tools. 

• File Metadata-Capture Time
• EXIF data-Date Time Digitized
• Photos.sqlite zAddAssetAttr-EXIF String
• Photos.sqlite zAsset-Add Date
• Photos.sqlite zCldMast-Creation Date
• Tool-Created Timestamp
• Photos.sqlite zAsset-Date Created
• File System-Creation Time

During this research, I encountered previously optimized assets that were imported onto the device. Some of those assets were not viewed by a user or interacted with on the device. I don’t know all the parameters that can trigger an asset to be imported back onto the device, but Apple and the OS are making those decisions for the user. We can, however, see that after viewing an optimized asset on the device, it is likely reappear back on the device in the internal storage.

We can review the zIntResou-Cloud Last On-Demand Download Date data to find a timestamp for the last time resources were downloaded for an asset and imported onto the device.

Another behavior that I would like to highlight is this asset was synced with iCloud Photos. When it was imported back onto the device it did not change from a Local Photo Library asset to a Cloud Photo Library asset (CPLAsset). It was imported back onto the device with the same asset type as it was prior to being optimized. It appears if its imported back on the originating device, it would remain a Local Photo Library asset. With limited testing, if that same asset is synced and viewed on a different device that is using the same Apple ID iCloud Photos account, the asset will be a Cloud Photo Library Asset (CPLAsset).

In figure #27 you will see I’ve highlighted the hash and pixel resolution for the assets. I am pointing out that even though these assets are related and are very similar, they are not the same asset.

In figure #27 you will notice there is a difference between the number of assets being stored in */mobile/Media/DCIM/100APPLE/* file system location:

• 11/12/2022 acquisition:
  • */mobile/Media/DCIM/100APPLE/: 65 assets
• 11/19/2022 acquisition:
  • */mobile/Media/DCIM/100APPLE/: 70 assets

As we have observed previously, there are over 200 assets being stored in iCloud Photos, but only 5 additional assets were downloaded to */mobile/Media/DCIM/100APPLE/ file system location. Additional assets might have been downloaded to other file system locations.

In figure #27, we can see the zIntResou-Cloud Last On-Demand Download Date listed in Photos.sqlite for our illegal material asset, IMG_0043, corresponds to the date and time the asset was viewed on the device and subsequently downloaded from iCloud Photos and re-created on the device internal storage. I then highlight a few timestamps being stored in Photos.sqlite that could have significate value for your analysis, but they might not be parsed by your forensic tool. I encourage you to manually analyze Photos.sqlite data when analyzing media assets. It can be reviewed manually or you could use or create queries to make it easier to analyze.

In figure #25 and in figure #27 At 9:43, you will notice that I take some of the Photos.sqlite zInternal Resource table data and compare it to the data being displayed in CB PA. If you pause the video, you should be able to analyze the assets in PA and compare the data to what is found in Photos.sqlite. We can see, based on my research and testing, what I’ve decoded as the original full-sized asset(s) which is now back on the device internal storage. We can confirm this by reviewing the assets zAddAssetAttr-Original File size data and the zIntResou-Data Length data, and in this example we can see the values match. We can also see that there is another asset (IMG_0043.medium.MOV) that is on the device internal storage that is smaller than the original asset.

In figure #25 and #26, we can see some screenshots that contains some of the ZINTERNALRESOURSE table data and the Cellebrite parsed and decoded data. Remember in this case, the asset is a Live Photo. In the screenshots we can use the zIntResou-Fingerprint to identify each unique internal resource asset and link them to assets we have found during our examination.

SECTION #10

IMG_0042 is another asset we viewed on device this this one was not selected

In figure #22 at 0:56, we can see that a few other assets were viewed on the device while we were viewing the illegal asset, IMG_0043.JPG. When we viewed these other assets did any of their original full-sized assets get imported onto the device internal storage?

If the original full-sized asset did not get imported, did any other assets get imported onto the device?

In figure #28, we will review, IMG_0042, but this time I will be using PA 8.2.1.547. We will also review the data in Photos.sqlite zInternal Resource table data to see if we have an original full-sized asset or smaller optimized assets.

After reviewing the “Media – Images” and “Media – Videos” analyzed data sections in PA and filtering the assets using “IMG_0042” we can see the original full-sized asset was not imported onto the device internal storage. We can see that there are some additional assets that were imported onto the device internal storage that we didn’t previously have for analysis.

• */Metadata/DCIM/100APPLE/IMG_0042.JPG
• */Metadata/DCIM/100APPLE/IMG_0042.medium.MOV

When did these assets get “created” on the device internal storage?

Again, if you look back and review figure #22, we can see the MAC timestamps and the zInternal Resource Cloud Last On-Demand Download Date matchup with when the asset was viewed on the device.

SECTION #11

Using cloud acquisition tools to acquire iCloud Photos sync data

One of the main purposes for this research was to determine if we, forensic examiners, might be missing or overlooking original full-sized assets during the analysis of a physical device data acquisition. I believe the research demonstrates if iCloud Photos is ON and Optimized iPhone Storage is being used, and we have only acquired the physical device internal storage, there is a chance we could be missing original full-sized assets from our analysis.

As a part of this research, I wanted to use available forensic tools to acquire and validate iCloud Photos sync data. To do so, I am using Dexter’s test device account and used multiple forensic tools to acquire the iCloud Photos data. Some were successful and others were not.

Out of respect for the forensic tool vendors and the methods they have incorporated into their tools that allows us to acquire the iCloud data, I will not be including the acquisition methods in my example videos.

After attempting to use multiple tools and having communications with some of their support staff, it appears that Apple has done it again! It appears Apple has changed the way account authentication occurs, thus breaking most of the commercial iCloud Photos sync data acquisition tools. If there is information indicating that a tool was not successful in acquiring the data, please hold your judgement and give each vendor time to adjust and fix the problem. During the testing, I used the following forensic tools to acquire the iCloud Photos sync data:

Cellebrite Physical Analyzer and Cloud Analyzer 7.58.0.66

• Both token and credential methods were attempted and unsuccessful – support ticket submitted

UPDATE: 12/22/2022: Cellebrite Cloud Analyzer 7.59.1.16

• Cellebrite updated their Cloud Analyzer tool and is now capable of acquiring iCloud Photos sync data to include the recovery of deleted media no longer on the physical device. See update in Section #12 for additional details.

Magnet AXIOM 6.8.0.33717

• Magnet has information posted on their support page indicating they are aware of the issues their tool currently has and they are working on it
• Both token and credential methods were attempted and unsuccessful

After attempting to use the above tools and was unsuccessful in acquiring the iCloud Photos sync data, I used the credentials to login to Dexter’s iCloud Photos account via web browser and manually downloaded all assets available within the “Library.” This process produced a zipped container named iCloud Photos.zip.

Oxygen Forensic Detective 15.1.0.69 and Cloud Extractor 9.1.0.50

• Token method failed to acquire the iCloud Photos sync data – support ticket submitted
• Credential method successfully acquired iCloud Photos sync data

While doing some research on forensic tools that may have the ability to acquire iCloud Photos sync data, I found a recent article published on Elcomsoft’s website written by Oleg Afonin. The article states their tool, Elcomsoft Phone Breaker and Viewer should be able to acquire the data. I requested, and Elcomsoft was happy to provide, a demo of their tools.

Elcomsoft Phone Breaker 10.12 build 38809 and Phone Viewer 5.33 build 37389

• Credential method successfully acquired iCloud Photos sync data – used multiple times
• Token method was not attempted based on information contained in Elcomsoft documentation

Of the tools tested and vendor documentation available, in my opinion, Elcomsoft was by far the easiest tool to use and contained the most detailed documents about how they are acquiring iCloud Photos sync data. All techniques suggested via Elcomsoft documentation were not attempted. As of the date this write-up was published, if you have a need to acquire iCloud sync data, I encourage you to contact Elcomsoft and give their tools a try!    

As others have mentioned, we cannot serve legal process to Apple for our own test data, so I was not able to determine if iCloud Photos sync data is included in the most recent version of Apple warrant returns.

In figure #29, you see the metadata and EXIF data that accompanied the highlighted asset when it was downloaded from iCloud Photos. You might have to zoom in a bit. Here is a list of some the data we can use to match this asset with the data that exits in Photos.sqlite:

• iCloud Photos Information Name: Starts with 68281528529_A9F4ECC6-C85E-4BD5 – This value matches Photos.sqlite zAddAssetAttr-Original Filename data
• iCloud Photos EXIF: Matches the EXIF listed in the Photos.sqlite extended attributes table and zCldMasterMediaMetadata-Data
• iCloud Photos EXIF Digitized Timestamp: Matches Photos.sqlite zAddAssetAttr-EXIF string

Merging a device FFS acquisition and iCloud Photos sync data acquisitions into one forensic tool

For demonstration purposes, in figure #30, I will make a full file system acquisition of Dexter’s iPhone SE, which will include some full-sized assets, optimized assets, and other assets.

Dexter’s iPhone SE (iOS 15.6) is now jailbroken with palera1n and will be acquired with Ian Whiffin’s tool Artifact Examiner. The file system acquisition will then be decoded and parsed using Cellebrite PA.

While that acquisition was taking place, I used Dexter’s iCloud credentials and acquired his iCloud Photos sync data using Elcomsoft Phone Breaker.

I opened the device full file system acquisition using ArtEx and reviewed the plist’s I discussed at the beginning of the blog. Doing so, allowed me to learn that iCloud Photos was ON and Optimize iPhone Storage setting was being used at the time of the full file system acquisition.

I then navigated and checked a few file system locations to analyze if the full file system acquisition contained optimized assets. I quickly located some assets that have been optimized for iPhone storage. These assets are not available in the */Media/DCIM/100APPLE/* location, but they are found in the */Thumbnails/V2/DCIM/100APPLE/* location:

• IMG_0075.JPG  
• IMG_0076.JPG
• IMG_0078.MOV

To validate what I was observing in ArtEx, I loaded the acquisition into Cellebrite PA.

I then analyzed the following file system locations to review the asset counts:

• /private/var/mobile/Media/DCIM/100APPLE/*
  • 76 assets
• /private/var/mobile/Media/PhotoData/CPLAssets/*
  • 161 folders – 3 assets

• /private/var/mobile/Media/PhotoData/Thumbnails/V2/DCIM/100APPLE/
  • 269 folders – 269 assets
• /private/var/mobile/Media/PhotoData/Thumbnails/V2/PhotoData/CPLAssets/
  • 161 folders – 183 assets
• /private/var/mobile/Media/PhotoData/Metadata/DCIM/100APPLE/
  •  214 assets
• /private/var/mobile/Media/PhotoData/Metadata/PhotoData/CPLAssets/
  • 157 folders – 42 assets

In Cellebrite PA I opened the Media-Images section and searched for /Media/DCIM/ and the result was only 27 assets. Based on the thumbnail count I would expect to see more photos stored in this location.

It’s clear to me, based on the device settings and the asset counts, this device contains assets that have been optimized and does not contain every original full-sized asset. This is an example of something you can do to determine if investigators should start working towards getting legal authority for iCloud Photos sync data.   

After acquiring the iCloud Photos sync data, the acquisition was added to Cellebrite PA with the full file system acquisition.

To demonstrate that we have acquired an original full-sized asset that was not contained in our full file system acquisition, I will navigate to */Media/DCIM/100APPLE/ and review the assets. Notice we do not have assets with the following file names:

• IMG_0075.JPG  
• IMG_0076.JPG
• IMG_0078.MOV

Now we can check */Media/PhotoData/Thumbnails/V2/DCIM/100APPLE/* attempt to locate the folders that are labeled with these file names. We have located the thumbnail assets indicating these assets should be stored in the Local Photo Library, but they are not in */Media/DCIM/*. We can check the iCloud Photos sync data acquisition and we have found the original full-sized assets.

How can we confirm that these iCloud Photos sync data assets are the original full-sized assets?

In figure #31, I will review the asset data acquired from the device full file system acquisition, Photos.sqlite data, and the iCloud Photos sync data acquired with Elcomsoft. We can query the Photos.sqlite data and review the output to find the zAddAssetAttr-Original File Size and review the assets acquired from iCloud Photos and the data matches and BOOM! We have the original assets we were missing from the device full file system acquisition. Now that we have conducted a validation, we should have most, if not all the original full-sized assets within our forensic tool. Now when we create a data summary report from a forensic tool for the investigators, they should have the data needed to move forward with their investigation into those illegal media files.

SECTION #12

Deleting an Optimized/Thumbnail asset still deletes Original/Full-Sized Asset

In figure #32, I am demonstrating what might occur if iCloud Photos is ON and Optimize iPhone Storage process occurs and a user deletes an optimized/thumbnail asset on the device. 

If figure #31, we identified a few assets that were optimized, and we were able to download the original full-sized assets from iCloud Photos using Elcomsoft Phone Breaker. Those assets were:

• IMG_0075.JPG  
• IMG_0076.JPG
• IMG_0078.MOV

If figure #32, you can see I have located two of those items (IMG_0075.JPG and IMG_0078.MOV) on the physical device and deleted them. I then permanently deleted them from the recently deleted utility. This action deletes all related assets (thumbnails, optimized assets, and iCloud Photos assets) and removes the data from Photos.sqlite. We can also see in the video that the deleted assets are removed from iCloud Photos when they are deleted via the device.

After the deletion, I used Elcomsoft Phone Breaker to acquire the iCloud Photos Sync data again.

While the iCloud Photos sync data was being acquired, I used the ArtEx live connection and connected to Dexter’s iPhone SE. I reviewed the device data to determine if any of the assets were left behind after the deletion. I conducted a search using the file names. You will notice the Local Photo Library assets are no longer on the device. A message attachment for IMG_0078.MOV was left behind after the deletion. This was a message attachment that was sent to another user during previous testing. This message attachment was not affected when an asset is deleted from the local photo library.

The data was removed from Photos.sqlite as we can see the file names are missing from the database. We can do a quick primary key analysis and observe there are missing primary keys where the asset data should be located. I checked the thumbnail file system location and nothing there either.

Note: Because the deletion just occurred and the data was acquired right after the deletion event, we can review the Photos.sqlite database without the WAL and locate the deleted data. Normally this data is not available during our acquisitions because we aren’t able to make a device acquisition immediately following the deletion event.   

After the iCloud Photos data acquisition was completed and it was opened it in Elcomsoft Phone Viewer, I instantly noticed the “Recovered” tab indicated 2 recovered assets. I viewed them and the assets listed in the Recovered tab were the assets I deleted from the device and from iCloud Photos. There are lots of articles out there that discuss the recovery of iCloud Photos data, but I couldn’t find one that specifically states if or for how long we might be able to recover deleted iCloud Photos sync data. I wanted to make you aware that it is possible, and I observed it during this research. This was a single test, and I am not sure if this would happen again.

UPDATE 12/22/2022: Additional attempts to recover deleted assets via cloud data acquisitions

During some continued research and testing I want to see how long deleted assets might be recoverable via forensic cloud acquisition tools.

During this testing, on 12/14/2022, I deleted several assets (videos and photos) from a physical device via the Recently Deleted utility.

The deleted assets were no longer found in the Recently Deleted utility of the physical device or in the iCloud Photos Recently Deleted web interface. When the assets were deleted from the physical device, the asset data being stored in Photos.sqlite database was also deleted.

On 12/20/2022, I used Elcomsoft Photo breaker to acquire the Dexter’s iCloud account iCloud Photos sync data. When doing so I was able to recover the deleted assets. Not only did Elcomsoft acquire the deleted assets, it was also acquired a Photos.db file that contained metadata and EXIF about all of the iCloud Photos synced assets.

On 12/22/2022, I used a new released version of Cellebrite Physical Analyzer and Cloud Analyzer (7.59.1.16). Using Dexter’s credentials, I was able to acquire Dexter’s iCloud account iCloud Photos sync data. This acquisition was able to acquire the assets that have been synced and recover the deleted assets previously acquired/recovered on 12/20/2022. This data acquisition did not include the Photos.db file that was acquired using Elcomsoft Phone Breaker.

Both forensic cloud acquisition tools were able to acquire and parse upload timestamps and the deleted/expunged timestamps.

Note: When I acquired iCloud Photos sync data using Vendor A tool and loaded and parsed that acquisition using Vendor B tool, the deleted assets were not always given a deleted indicator. Please use caution when using multiple vendor tools to acquire and analyze the data. Manual analysis might be necessary.

Additional research and testing are ongoing.

SECTIOM #13

Turning OFF iCloud Photos after Optimize iPhone Storage process has occurred

The iCloud Photos ON/OFF setting is device specific. If a person is using multiple devices with the same Apple ID and iCloud account, it’s possible for the physical devices to contain different assets in the photo library.

Example: one device has iCloud Photos ON and is using Optimize iPhone Storage and the second device has iCloud Photos OFF. These two devices would have completely different Local Photo Library assets.

If a device is using iCloud Photos and a user decides they no longer want to use iCloud Photos and turns the setting OFF, they are promoted not once, but twice in separate popup notifications, informing the user if they do not allow the original full-sized assets to download from iCloud Photos, the assets that have been Optimized will be removed from the device.

When I was testing this on some of my devices, I received a different notification informing me that my internal storage did not have enough free space to store all original full-sized assets that are being stored in iCloud Photos. If I turned iCloud Photos OFF, the optimized assets would be removed from my device.

For this test, I will be using Scooters iPhone X with iOS 14.7. I believe I won’t get many chances to do this test as it would require me to fill the device storage again.

In figure #33, we can see this device is connected to a network, iCloud Photos ON, and it’s using Optimize iPhone Storage.

When we view the Photo Library the asset count indicates there are 254 Photos and 76 Videos and some are currently being uploaded to iCloud Photos. When reviewing the */Media/DCIM/100APPLE/ there are only 32 assets being stored here. I then reviewed the */Thumbnails/V2/DCIM/100APPLE/ location, and we can see that there are 339 thumbnails being stored in the location. These asset counts within these file system locations can provide us with an indication that more than 200+ assets have been optimized for iPhone storage.

I scrolled through the Photo Library, and we can see all the assets that a user could view and interact with.

When I checked the syncstatus.plist we could see it contains asset counts for the assets currently synced with iCloud Photos. When iCloud Photos is turned OFF, these plist keys/nodes will no longer be visible.

In figure #33 at 4:35, when I turn iCloud Photos OFF, I received a notification that 330 photos and videos will be removed from this iPhone. Please take notice how fast this process takes!! It takes approximately 3 seconds for iOS to remove access and data to more than 200+ media assets that were once stored on the device.

I believe this should cause alarms for any forensic examiner. This is a very quick way for a user to hide hundreds of illegal media files from examiners and investigators. We should all be checking the cloudServiceEnableLog.plist to analyze the iCloud Photo Library log to determine if iCloud Photos is being used.

After turning iCloud Photos OFF, I checked the Photo Library, and we can see there are only 23 assets being listed.

I reviewed the settings plist’s and we can see a timestamp was logged when iCloud Photo Library was turned OFF.

I rechecked those file system locations and most of the assets that were present when iCloud Photos was ON, are now gone.

Towards the end of figure #33, I checked iCloud Photos via a web browser and verified the optimized assets from the device are still being stored in iCloud Photos. Note: I did not conduct any testing about what would happen if a user switched from Optimize iPhone Storage to Download and Keep Originals before turning OFF iCloud Photos. That would take a significant amount of time due to downloading over 200+ assets from iCloud Photos.  

Not depicted in the video, but I checked Photos.sqlite and most of the data related to the removed/hidden assets has been cleared/deleted from Photos.sqlite. There were a few tables that still contained data for the missing assets, but further research is required. Here is a list of the tables that might still have some of the old data:

• ACHANGE
• ATRANSACTION
• ZMEDIAANALYSYSASSETATTRIBUTES – This table contains a zMedAnlyAstAttr-zFingerprint column that I believe might help an examiner with matching records to those now being stored in iCloud Photos.
• ZSCENECLASSIFICATION
• ZSCENEPRINT
• ZPRIMARYKEY table – maintained the Z_MAX count for the table primary keys. Within this table I was able to locate the ZASSET Table Z_MAX count was 525, but there were only 56 primary keys currently listed in the table. This could provide an examiner with some insight if they are missing data.

I believe this illustrates the importance of taking control of an environment and target devices immediately when investigators believe critical evidence is being stored on Apple devices. Just imagine the forensic impact this could have, as investigators arrive/while they are on scene and device users start turning iCloud Photos OFF prior to the device seizure.

This could immediately hide obvious traces of critical evidence or illegal media. Prior to turning iCloud Photos OFF, the device full file system acquisition has contained data and media files for more than 250 media assets. Now, after iCloud Photos was turned OFF, our device full file system acquisition only contains data and media files for 50 or so media assets.

This and the fact that iCloud Photos setting is device specific, are great examples why investigators/examiners should be seizing and acquiring all physical devices available during an investigation. Additionally, we should be making attempts to acquire iCloud Photo data related to those physical devices. I believe this research could act as a warning for us to become more familiar with forensic tools that provide us with the ability to acquire iCloud Photos data via tokens and credentials.            

Acquiring every Apple device that is seized during an investigation, might not be something that we do for every investigation, but think about the forensic and investigation impact this scenario could have:

• At 7:00 AM – Investigators approach a location and make notification
• At 7:15 AM – Investigators perform a manual review/triage of an iPhone
• NO contraband is located
• Decision time – Seize or not to Seize?
• Device is seized, and a forensic analysis is completed on the iPhone
• Examiner indicates in their forensic analysis that cloudServiceEnableLog.plist documented iCloud Photos was turned OFF at 7:01 AM on the date of the seizure…
• Could this be an indicator that someone attempted to destroy or conceal possible evidence?

Note: If any commercial/open-source forensic tool vendors are taking the time to read this, first thank you, and if you haven’t already, please include the data from cloudServiceEnableLog.plist into your forensic triage tools so investigators can get this information fast and make quick decisions.

Update: 12/6/2022

A day after turning iCloud Photos OFF and documenting results, I turned iCloud Photos back ON. When I did so, the Photo Library/Camera Roll was indicating it was updating. I waited a day or so and it was still indicating the same updating message. I had 23 assets that were not synced with iCloud Photos yet. I had a few videos that were more than 30 minuets long and I believed they were holding up the upload process. I deleted those two videos and then the rest of the assets that were pending upload were synced with iCloud Photos.

After the assets uploaded, I started to see previously existing assets reappearing back onto the device in Photo Library/Camera Roll.

When this occurred, I had immediately questioned if the assets originally captured with Scooters iPhone X, would be listed as Local Photo Library assets or Cloud Photo Library Assets (CPLAssets)?

Remember I learned earlier, if an asset was listed as a Local Photo Library asset, it would remain a Local Photo Library Asset, even after it was optimized and the original full-sized asset was downloaded from iCloud Photos. This instance occurred while iCloud Photos remained ON and the original asset data was still listed in Photos.sqlite.

This is a different situation because the original asset data has been removed from Photos.sqlite and there is no significate data indicating the original asset was once stored on this device. I was curious if and how these newly synced assets would be listed in Photos.sqlite.

Here is what I observed after this one isolated test:

• All assets found in Photo Library/Camera Roll are listed in Photos.sqlite again
• All assets that were removed from the device as the result of turning iCloud Photos OFF have been downloaded back onto the device and are now Cloud Photo Library Assets (CPLAssets)
• Not all of the assets had the Original Full-Sized asset downloaded. Most of the assets downloaded were 5003-5005.JPG thumbnail assets or optimized assets.
• The assets zIntResou-Cloud Last Prefetch date or zIntResou-Cloud Last On-Demand Download Date timestamp was updated with the date and time the asset was back onto the device and viewed in the Photo Library. See Reference Guide for additional information
• The assets zAsset-Modification Date was updated for all of the assets downloaded from iCloud Photos
• The following timestamps did not update and matched to when they were previously listed in Photos.sqlite and the original asset:
  • zAsset-Add Date
  • zAsset-Date Created
  • zCldMast-Creation Date
  • zIntResou-Cloud Master Date
  • zCldMast-Import Date

If you cannot get legal authority to use a forensic tool to acquire iCloud Photos sync data or you can’t get the data though an Apple warrant return, this might be a last resort method of collecting data from a synced iCloud Photos account. Document – Document – Document!!!

Conclusion

When I started researching the Optimize iPhone Storage setting and realized there was a connection to the Photos.sqlite ZINTERNALRESOURCE table this research project turned into a long one. I had no idea that our devices were behaving in this manner, nor did I realize that it would be so easy for someone to remove/hide data for hundreds of media assets within three seconds.

After reading through this and the other parts of this research, you should be able to use the data from the ZINTERANALRESOURCE table to determine if an asset within your data acquisition is an Original Full-Sized asset, a thumbnail asset, or an optimized asset. I also hope that you can use this data to show a relation between assets being stored on the device and what assets should be stored in iCloud Photos.

I have demonstrated we can use com.apple.mobileslideshow.plist to determine if Optimize iPhone Storage or Download and Keep Originals setting is being used on the device. I also reminded you that we can check cloudServiceEnableLog.plist to determine if iCloud Photos setting is ON or OFF. I believe these are critical settings to check to ensure that you are not missing any original full-sized assets that are being stored in iCloud Photos.

I believe the research demonstrates if your device acquisition does not have a lot of assets being stored in /private/var/mobile/Media/DCIM/* file system location, it doesn’t necessarily indicate assets have been deleted, they just might have been optimized. You might want to check other file system locations and Photos.sqlite data to analyze the zInternal Resource table information to determine if iCloud Photos sync data should be acquired.

The ultimate hidden asset is one that is being stored in iCloud Photos while the physical device has iCloud Photos turned OFF.

The research into this Photos.sqlite ZINTERNALRESOURCE table and associated data is far from over. There is so much more to be tested and researched.

Thanks for reading and I hope this helps you on your adventure with Photos.sqlite!