{"id":38823,"date":"2023-03-21T14:49:24","date_gmt":"2023-03-21T18:49:24","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=38823"},"modified":"2023-03-21T14:51:39","modified_gmt":"2023-03-21T18:51:39","slug":"recovering-cropped-parts-of-google-pixel-screenshots","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/03\/21\/recovering-cropped-parts-of-google-pixel-screenshots\/","title":{"rendered":"Recovering Cropped Parts of Google Pixel Screenshots"},"content":{"rendered":"

Simon Aarons<\/a> (via Hacker News<\/a>):<\/p>\n

Introducing acropalypse: a serious privacy vulnerability in the Google Pixel’s inbuilt screenshot editing tool, Markup, enabling partial recovery of the original, unedited image data of a cropped and\/or redacted screenshot.<\/p><\/blockquote>\n\n

David Buchanan<\/a> (via Hacker News<\/a>):<\/p>\n

\n

Google was passing \"w\"<\/code> to a call to parseMode()<\/code>, when they should've been passing \"wt\"<\/code> (the t stands for truncation). This is an easy mistake, since similar APIs (like POSIX fopen<\/a>) will truncate by default when you simply pass \"w\"<\/code>. Not only that, but previous Android releases had parseMode(\"w\")<\/code> truncate by default too! This change wasn't even documented until some time after the aforementioned bug report<\/a> was made.<\/p>\n

The end result is that the image file is opened without<\/em> the O_TRUNC<\/code> flag, so that when the cropped image is written, the original image is not truncated. If the new image file is smaller, the end of the original is left behind.<\/p><\/blockquote>\n\n

This reminds me of the old Microsoft Word issue where if you had it set to “fast save” it would leave deleted text in the file. Sometimes there even seemed to be chunks of unzeroed content from other apps’ deleted files.<\/p>\n\n

I found that the data was indeed compressed using dynamic Huffman coding, but that the Huffman tree was re-specified every ~16KB or so. This was excellent<\/em> news because it meant I didn’t have to solve the “Huffman coding cryptanalysis” problem, and could instead solve the much simpler-in-practice problem of “find the start of a dynamic-Huffman-coded zlib block”.<\/p>

[…]<\/p>

Although I’m currently an iPhone user, I used to use a Pixel 3XL. I’m also a heavy Discord user, and in the past I’d shared plenty of cropped screenshots through the Discord app.<\/p>

I wrote a script to scrape my own message history to look for vulnerable images. There were lots of them, although most didn’t leak any particularly private information.<\/p><\/blockquote>\n\n

Juerd<\/a>:<\/p>\n

\n

Very simple script<\/a> to check which PNG files have trailing data.<\/p>\n

I hope that people who host forums, image boards, chat applications, etc., will delete or fix potentially vulnerable images before anyone uses them maliciously.<\/p>\n

One way to repair a vulnerable image is to use optipng -fix<\/code>.<\/p>\n<\/blockquote>\n\n

jsjohnst<\/a>:<\/p>\n

These types of issues are exactly why whenever it’s sensitive, I screenshot, crop\/edit, then screenshot the crop’d\/edited screenshot. There’s other possible issues than this bug (like iOS’s non-destructive edits by default), so it’s better to be safe than sorry.<\/p><\/blockquote>\n\n

Nick Heer<\/a>:<\/p>\n

\n

There are some people in the replies to Aarons’ tweet claiming the same is true for cropped iPhone screenshots. In my testing, that is not exactly right: if you crop an iPhone screenshot and then share it with default sharing options, it does not transmit edit history or removed image data, as best as I can tell. When I AirDropped a cropped screenshot to myself, it sent a re-encoded JPG image instead of the HEIF original. In the iOS Share sheet, there is an “Options” button; if you want, you can toggle the switch to “include all photos data” which includes “edit history and metadata”, including image data removed via cropping. This option is off by default.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n