In today's Stormcast, Johannes discussed a privacy issue with Windows 11's snipping tool.

The issue is the following: if you use Windows 11's snipping tool to open an existing image, then modify the image to make it smaller (cropping for example), and then save the image again under the same name, then the file will not be truncated. The file will keep its original data after the beginning of the file has been overwritten with the new image.

I tested this with a PNG file on Windows 11, and could indeed reproduce the issue. The reason why this doesn't work on Windows 10, is that as far as I know, Windows 10's snipping tool can not open an existing file.

This data that wasn't truncated, can be easily detected with my pngdump.py tool:

A PNG file should end with an IEND chunk, and in this case, we see that my tool detects and reports data found after this chunk (remainder). This is the data from the original file, that is being leaked (it should have been removed).

I just added a new option to my pngdump.py tool, to search for known PNG chunks. In normal mode, my pngdump.py tool expects to parse a compliant PNG file.

But with this new option, -f (--find), pngdump.py will scan any file you give it, for known PNG chunks, and report them:

This time, pngdump.py also finds unexpected data after the IEND chunk, but then it also finds known chunks (IDAT chunks and another IEND chunk). The unexpected data is another IDAT chunk whose header has been overwritten, and can thus no longer be recognized. But after that corrupt chunk, pngdump finds intact chunks with its -f option:

At the end, pngdump also produces a small statistical overview. One can clearly see that there are 2 IEND chunks, and that is abnormal.

IDAT chunks contain the bitmap image compressed with ZLIB. With a bit of luck, one can decompress these extra IDAT chunks and reconstitute a partial image, as demonstrated by David Buchanan here.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com