JPEG APP "JPN"

[Neal Krawetz]

Most jpeg files store c2pa data in a "JP" app segment. (Set of APP11 blocks labeled "JP".)

Microsoft Designer seems to use "JPN".  Otherwise, no difference in the data format.

[Neal Krawetz]

Sample picture:

  https://fotoforensics.com/analysis.php?id=4e81edeb1a6df68733fbc0df705d5ab9ea93c210.835790&fmt=orig

This picture is a C2PA forgery created using Microsoft Designer.
It seems that Microsoft Designer introduces a few bugs.

Bug #1: It uses APP11 "JPN" instead of "JP". ExifTool detects the block (regex "/^JP/" matches), so this is a Microsoft bug and not an ExifTool problem.

Bug #2: ExifTool complains "Invalid JUMBF size or missing JUMBF chunk". c2patool and my own tools don't notice this error. This seems to happen with any JPEG C2PA block created by Microsoft Designer. I think this is an ExifTool bug.

[Phil Harvey]

Sorry for the delay in looking into this.

Thanks.  I'll fix the "C2PA" inconsistency.

The "Invalid JUMBF" problem is because the first APP11 segment is type "jumb", but the rest are type "bmuj".  (Byte order problem?)  I wasted too much time already trying to find the documenation on this, so I can't tell if this is technically allowed, but I doubt it.

- Phil

[Neal Krawetz]

JUMBF and CBOR always use big endian, even if the outer container (JPEG, TIFF) uses little endian.

I viewed the file with hexedit.  There are no "bmuj" bytes. (Well, there is one, but it's coincidentally in the stream and not in the JUMBF structure.)  Everything in the C2PA data uses "jumb".

[Phil Harvey]

The "bmuj" words are in the APP11 header at offsets 0xf3c1 and 0x1e778 in the 4e81...jpg file.

I suggest looking at the file with the ExifTool -v3 option.

- Phil

[Neal Krawetz]

Interesting!

So the APP11 JP has a 16 byte header.
First 4 are the type (JP, JPN, etc.).
Then comes the big endian 4-byte segment number.
Then comes another length, but the endian is dependent on the container.
Then comes the 4-byte type of data, which should be "jumb", but if the length is little endian, then it's "bmuj".

Except, my parsing code ignored the segment number, redundant length, and unnecessary duplicate data type.  And it looks like c2pa-rs skips the same way for anything after the first segment.

And it looks like Microsoft has a bug where, if we didn't skip bytes, it would fail to parse -- just like how exiftool fails to parse.

Okay, exiftool is behaving properly. Microsoft has a bug. And c2pa-rs intentionally skips bytes in order to ignore the bug. That's funny!