Re: CRC32 check for IDAT chunks

Cosmin Truta wrote:
>> CRC is always checked. An incorrect CRC causes a benign error for an
>> ancillary chunk, or a severe error for a critical chunk.

On Thu, 31 Jan 2019 at 06:13, Nicolas Badoux wrote:
> From my own test, when IDAT data is corrupted, it results in a zlib error and not in a checksum error.

That's because your corrupt IDAT contains a corrupt zlib stream that
gets diagnosed first. A lot of bad things can happen in a corrupt zlib
stream. Just to name a few: a broken zlib header, a broken Huffman
tree, an out-of-range LZ77 distance, a failed Adler32 checksum, etc.
All of these are diagnosed immediately inside zlib, and then zlib
bails out; and finally, libpng reports the bailout as a zlib error,
and bails out further.

When you already know that the IDAT content is corrupted, and have
already seen a png_error, there's no point in waiting to see if the
CRC is ok or not. Besides, png_error is designed to never return, not
even if a user-defined error handler is in place. Make one critical
error in one critical chunk, and you're out.

If you still want to see what's happening with a mismatched CRC, then
you should alter the IDAT CRC, not the IDAT content, in your test
image. Do whatever you need to do in order to have a valid zlib
stream, so that you do not stumble because of that. Or, if you do
insist on altering a chunk's data, then you should experiment with
something else, like PLTE, which does not have integrity constraints
for their content.

Sincerely,
Cosmin