High false positive rate with gaming sprites

[notaSWE]

In testing I ran this against a large directory, recursively, and noticed that a substantial number of assets in the following Python/Pygame project show up as vulnerable to Acropalypse:

https://github.com/clear-code-projects/Zelda

Here is a brief list of examples that are showing as vulnerable:

5 - level graphics/graphics/particles/sparkle/0.png
5 - level graphics/graphics/particles/sparkle/1.png
5 - level graphics/graphics/particles/sparkle/2.png
5 - level graphics/graphics/particles/sparkle/3.png
5 - level graphics/graphics/particles/sparkle/4.png
6 - player animations/graphics/particles/smoke_orange/2.png
8 - UI/graphics/monsters/squid/attack/0 - Copy (2).png
8 - UI/graphics/monsters/squid/attack/0 - Copy (3).png
8 - UI/graphics/monsters/squid/attack/0 - Copy.png
8 - UI/graphics/monsters/squid/attack/0.png

I am pretty sure they were created in Tiled, but I am not the creator of the project.

[ogianatiempo]

I have checked the images and they have trailing data after the IEND chunk. This means that there is more information in these files after the end of the png image that you see when you open them. The extra data also contains another IEND chunk at the end, suggesting that it comes from a bigger png file. That is what we also see in Acropalypse affected images... Maybe this program has the same problem when it crops PNGs? I am not familiar with it.

[notaSWE]

Typically a larger image is broken up into smaller square images that can be loaded as sprites in 2D games. That might explain why there is an IEND chunk in the middle of the image, perhaps by design in this case. I was unable to recover any additional data using the python scripts here; feel free to close the issue and thank you for taking a look.

[ogianatiempo]

That makes sense, however it is not compliant with the PNG specification which states that there should be only one IEND chunk at the end (https://www.w3.org/TR/2003/REC-PNG-20031110/#5ChunkOrdering). With Acropalypse affected images sometimes you can't recover the original data too. As far as I understand it depends on being able to locate the starting point of each compressed block to reconstruct the backreferences. For more info on this: https://www.da.vidbuchanan.co.uk/blog/exploiting-acropalypse.html