So, Acropalypse is “people use image snipping and markup tools to redact images, but those tools often allow the unredacted images to be recovered”? Yeah, that’s a pretty big violation of the implicit expectations of users.
To be more specific "acropalypse" refers to any image editor which does not truncate the original file before overwriting it with the edited version, leading to portions of the original being recoverable by an adversary.
It originally referred to a specific vulnerability in the Markup app found on Google Pixel devices (CVE-2023-21036), but apparently now includes other unrelated apps.
Reminds me of the old Underhanded C competition where people deliberately tried to write undetectable but faulty code for image redaction: http://underhanded-c.org/_page_id_17.html
Oh, that’s actually way worse than I thought! It’s not that these apps have some kind of undo feature or are aiming for non-destructive editing, and that’s not what users expect - the apps actually are attempting to perform redaction and they’re poorly implemented.
Kudos on the name by the way, I love a good tight pun name for a vulnerability.
I can't speak for this windows tool, but for the android image editor the editor _was_ doing the correct thing. Then the underlying IO library changed in breaking way (and diverged from other APIs using the same mode strings) to not truncate when opening existing files.
The API was (accidentally?) changed long before the Android tool was written, if I understand correctly. Depending on your point of view, that means it's either a poorly designed and documented API, an incorrect API that doesn't match the documentation, or a testing failure during development of the app.
It would be interesting to see if any popular ZIP libraries have a similar issue. If you add a file that's already in the archive, for example, and the new one is larger, I could see it just sticking the new one at the end of the archive and appending a new central directory structure.
Is the periodic reencoding of the huffman tree part of DEFLATE or in the PNG are they just using a sequence of separate DEFLATE structures appended together that each have their own huffman tree? If it's the former, you might be able to recover part of a ZIP archive entry that was reduced in size and written over the original version.
