A strange JPEG file

Published: 2017-10-08
Last Updated: 2017-10-08 23:03:55 UTC
by Didier Stevens (Version: 1)
2 comment(s)

I had a JPEG file to analyze that would not render properly: image viewers would display an error, but no image.

My new jpegdump tool confirmed that it started with the right JPEG markers, but that the data sizes were wrong:

2576 bytes for an APP0 marker is really large...

Taking a look with a hex editor, I saw that the markers were present, but that the size of the data were wrong.

With re-search, I took a closer look at the markers with their data size:

The size of the data following a marker is encoded with two bytes, big endian notation. And for the first markers in the JPEG file, they all looked too large. Then I noticed that the 3rd byte (e.g. the first byte of the size field) was always 0x0A, were I expected it to be 0x00.

Counting all the bytes reveals that in this file, there were no 0x00 bytes but an unusual large amount of 0x0A bytes:

I formed a hypothesis: somehow, all 0x00 values were replaced by 0x0A values. To test this hypothesis, I replaced all 0x0A values by 0x00 values and parsed the result with jpegdump:

This was indeed a JPEG file. But I could not repair it, as I did not know what 0x0A values were original bytes, and which were replacemnt values for 0x00.

At least I new it was most likely not malicious, but corrupted by some unknown process.

 

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Keywords: jpeg
2 comment(s)

Comments

It's been a while since I've seen file corruption like you're describing.
Back then it was due to doing an FTP file transfer in "ASCII mode" to a Unix machine.

You'd be hard pressed to find an FTP server that doesn't default to "Binary mode" these days.

It _might_ be due to someone opening the JPG with a text editor; but they're usually fine too these days.
Yeah, this reminded me of good old FTP too.

Diary Archives