|
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 |
DidierStevens 282 Posts ISC Handler |
| Reply Subscribe |
Oct 8th 2017 1 year ago |
|
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. |
UnknownNick 11 Posts |
| Reply Quote |
Oct 9th 2017 1 year ago |
|
Yeah, this reminded me of good old FTP too.
|
DidierStevens 282 Posts ISC Handler |
| Reply Quote |
Oct 12th 2017 1 year ago |
Sign Up for Free or Log In to start participating in the conversation!
