An iPhone Photo Can Tell You More Than Its File Path

Observed environment

This is what was observed on one device, through one tool. It is not a statement that the same behavior occurs on every iOS version, every application version, or every extraction method.

While examining an iPhone 16 running iOS 26.5, we came across a photo artifact that was a good reminder of something easy to overlook in mobile forensics.

The file path tells you where an image is stored. It does not necessarily tell you how it got there.

The image we were looking at was stored here:

/private/var/mobile/Media/DCIM/100APPLE/IMG_6000.JPG

At first glance that looks completely normal. It is sitting inside the standard iPhone DCIM structure just like any other photo.

But Cellebrite was also showing an album name of AI Image.

That caught our attention, because the words AI Image do not appear anywhere in the actual file path. So the question became: where was Cellebrite getting that additional context from?

The first lesson: don't stop at the DCIM path

It is easy to look at a path like DCIM/100APPLE/IMG_6000.JPG and assume that is basically the end of the story.

It is not.

On iOS, the physical image file is only one part of the artifact. The Photos library maintains additional information about that asset in databases and related records.

That means an image can live in a completely normal DCIM folder while other native iOS records preserve information about things like album associations, asset identifiers, import information, timestamps, application relationships, and other metadata that never appears in the filename or folder path.

That is what led us to dig deeper.

Where we found the answer

The useful record was in the ZADDITIONALASSETATTRIBUTES table.

Once we filtered that table using the image filename, we were able to locate the corresponding record for the asset. From there, two fields became especially important:

• ZIMPORTEDBYBUNDLEIDENTIFIER
• ZIMPORTEDBYDISPLAYNAME

Those fields can provide context about the application associated with importing or saving the image into the Photos library.

That is significant because the image itself may still end up in a completely ordinary location such as /private/var/mobile/Media/DCIM/100APPLE/IMG_6000.JPG.

So we now had two different layers of information. The file path told us where the image was stored. The additional asset attributes told us which application was associated with importing it. Together, that is a much more complete forensic picture than either one alone.

Why this matters

This becomes especially important when examining images that were downloaded, shared, saved from another app, or otherwise did not originate from the device camera.

If you only look at the DCIM folder, a downloaded image may look almost identical to a normal photograph stored in the Photos library. That can make it easy to miss the source context.

The better question is not just where the JPG is located. It is also: what does iOS know about how this image entered the Photos library?

That is where fields such as ZIMPORTEDBYBUNDLEIDENTIFIER and ZIMPORTEDBYDISPLAYNAME can become extremely useful.

A simple workflow for other examiners

If you run into a similar image, this is the process we would recommend.

1. Identify the image filename from the filesystem or the parsed artifact.
2. Document the full physical path — in this case /private/var/mobile/Media/DCIM/100APPLE/IMG_6000.JPG.
3. Locate the Photos database containing ZADDITIONALASSETATTRIBUTES.
4. Filter the table using the image filename.
5. Locate the matching asset record.
6. Review the import-related fields, especially ZIMPORTEDBYBUNDLEIDENTIFIER and ZIMPORTEDBYDISPLAYNAME.
7. Correlate that information with the other evidence on the device.
8. Do not rely on the application name alone to establish a specific user action. Treat it as one more piece of supporting context.

That last point matters. An import-related field can be very useful, but it still needs to be considered alongside timestamps, messages, downloads, application artifacts, browser history, or other relevant evidence.

The big takeaway

The easiest way we can explain this finding is that the DCIM path tells you where the image ended up, and the additional asset attributes may help tell you how it got there.

A normal-looking path like /private/var/mobile/Media/DCIM/100APPLE/IMG_6000.JPG does not mean the image lacks source information. The source context may simply exist somewhere else in the Photos database.

In this case, Cellebrite's presentation of additional information led us to the native iOS record, and the ZADDITIONALASSETATTRIBUTES table provided the deeper context we were looking for.

For us, this was a good reminder that parsed artifacts are often just the starting point. When something in a tool looks interesting, or does not seem to match the filesystem, it is worth asking one more question: what native database record is the tool actually reading to show us this?

That is usually where the better forensic answer is.

What this observation does and does not support

We are describing what we observed on one device, on one operating system version, through one tool. Stated carefully:

• Observed. An image at /private/var/mobile/Media/DCIM/100APPLE/IMG_6000.JPG on an iPhone 16 running iOS 26.5, presented by Cellebrite with an album name of AI Image that appears nowhere in the file path, with a corresponding ZADDITIONALASSETATTRIBUTES record carrying import-related fields.
• Provides context. ZIMPORTEDBYBUNDLEIDENTIFIER and ZIMPORTEDBYDISPLAYNAME can indicate the application associated with importing or saving an asset into the Photos library.
• Not established by this artifact alone. That a particular person deliberately downloaded, viewed, or knowingly retained the image. An import-related field does not carry intent, and it does not identify a user.

Field behavior can differ across iOS versions, application versions, extraction methods, and tool versions. Validate this against your own data before relying on it.