Even if you’ve never used one, you probably know what a VCR is (or was).
Short for video cassette recorder, it was how we recorded and watched back videos at home in the days when digital video stored on hard disks was the absurdly expensive privilege of huge companies, typically TV stations.
The cassettes were small plastic containers that held two reels and a long strip of magnetic recording tape – kind of like an old-school hard disk, but with the magnetic surface arranged in a long strip of…
…well, of plastic tape, 12.7mm wide (that’s 1/2″ exactly) and about 100m long for every hour of recording.
(Tapes were sold with identifiers such as E-120, meaning PAL or SECAM recording, as used in most of the world, 120 minutes long, or T-180, for three hours of NTSC-format recording, the TV standard used in North America and Japan).
Image thanks to Toby Hudson on Wikimedia under CC BY-SA 2.5 AU.
Leftover data revealed at the end
Few TV shows were exactly the length of a tape, so when you recorded a show, you’d usually have at least a bit of tape left at the end of the reel, which would be blank.
When you watched back, say, a 45-minute show recorded on an E-60 tape, you’d get 15 minutes of video fuzz (commonly known as “static”) if you left the tape running when the show had finished, until the VCR detected the end of the reel and obligingly rewound the cassette for next time.
Unless, of course, you (or the friend who’d lent you the tape) had used it before, and recorded something longer than 45 minutes…
…in which case you’d end up watching the last part of whatever was left over from the time before, and when that ended, what was recorded the time before that, or the time before that, and so on.
You get the picture.
The cut-over was never very clean, because the VCR would typically lose track of the video signal when the first recording ended, and play back a mish-mash of slanting lines, partial frames that jumped around on the screen, blurry washes of colour, and a weird, garbled mix of different audio soundtracks.
For a while, anyway.
Typically, however, the VCR would “realign” itself with the leftover data from the previous recording, resynchronise with the old video stream, and the messed-up, unintelligible nonsense on the screen would vanish.
You’d be cast into the tail-end of an unknown TV show, watching a vacation recording, or viewing some other sort of home video, most (but not all!) of which had been lost when it was recorded over.
In truth, unless you erased the entire tape first, before recording over it, you’d almost always leave some unexpected, and perhaps unwanted, previous content at the end.
The “aCropalypse” bug
Well, a UK cybersecurity researcher called David Buchanan has just published an article about a bug of this sort…
…in the image editing tool on Google’s Pixel phones.
The offending software is apparently known as Markup, and it lets you take photos or screenshots that are already on your phone, and crop or otherwise edit them to remove unwanted details before sending them on to your friends or uploading them to online services.
For instance, you might want to crop someone out of the picture to oblige their request not to have their face shared, or to block out a username or account ID in a software screenshot, or to obscure someone’s house number so as not to give away their address.
As you can imagine, especially when you crop a picture to reduce its size, the resulting image file often ends up smaller than the one you’re replacing.
Markup, apparently, would deal with smaller-than-before images by writing the new image over the old one (like your Dad or your Grandfather recording this week’s football match over the game on last week’s VCR tape), and then truncating the image file to its new, shorter size.
The old data – the tail-end of last week’s football game, in our VCR analogy – would remain behind on the storage device, but it would no longer be part of the digital file containing the new image.
In other words, when you opened the new file, you wouldn’t have the VCR problem of leftover image content being included in it, because the operating system knew to stop reading (or copying) the file at the right point.
The leftover data therefore couldn’t accidentally be leaked if you sent the new file to someone else, or uploaded it to a cloud service.
An attacker would typically need physical access to your phone, need to know how to unlock it and get root privileges, and be able to do a low-level forensic image of the unused data to recover any previously-deleted stuff.
Except for the bug.
To truncate or not to truncate?
As Buchanan discovered, the Java programming function that Markup used to “open the existing file in truncate mode” (meaning that unused data left over after you’d finished rewriting it would be chopped off from the end of the file)…
…was changed, apparently about two years ago, to “open in rewrite mode with no truncation when finished”.
In other words, if you opened the old file and wrote just one solitary byte at the start before closing it, the new file would not be one byte long with the rest chopped off, as you might expect, but would be the old file, in its entirety, with only the first byte changed.
The rest would be intact – not at all what was intended!
As Buchanan found, even though the leftover data from the previous version of the image was incomplete, and would be left alone if the file were opened with a regular image viewer (which would read as much as it needed and ignore the extra stuff at the end)…
…you could nevertheless extract that leftover image data and often make some sense out of it, even though you might end up with a stream of compressed data that started part-way through a compressed block.
Like those VCR tapes, where the VCR player might not be able to synch with the leftover recording immediately, a specially-written PNG file decompressing program might not be able to make sense of the first few chunks of the leftover data, but could often reconstruct blocks of the previous image that followed later on.
Like those VCR tapes, where the leftover part might not be worth much all on its own, you could never be quite sure what had been left behind, and anyone digging into your files might sometimes get lucky with the chunks they managed to reconstruct.
That means they might uncover image fragments from the end of the previous version that were exactly what you had intended to remove.
Loosely speaking, the more you’d cropped and shrunk the original file, the more leftover data would remain behind, and the greater the chance that some of it was just what you didn’t want to share.
What to do?
- Patch now. Google has apparently patched the Markup program in the March 2023 security update of Android. You can track this bug-fix with the identifier CVE-2023-20136.
- Revisit images you’ve already shared. Images you’ve cropped and shared already are too late to fix. But you may want to consider removing them anyway, or replacing them with re-edited images created with the patched version of Markup.
- Consider editing security-critical images conservatively on your laptop. File formats such as PNG can also include comments and so-called metadata (e.g. location information or camera details) that you never intended to share, let alone inadvertently retaining leftover pixels from before.
Command-line image manipulation tools such as ImageMagick or GraphicsMagick, and open-source tools such as GNU Image Manipulation Progam, allow you to convert edited images into formats where you control the content precisely.
For example, raw RGB files include only the colour values of each pixel in the image, with no headers, metadata, comment fields. or other extraneous information or pixels.
RGB files can be huge, because there’s no compression to save space, but that means you don’t lose any image quality in the conversion, even though you do lose any and all data that is not directly part of the image you’re interested in.
So, transcoding an image into RGB format and then back, say, to PNG, is one way of ensuring that you create a totally new file that “knows” nothing about where or how the original image was created, or what now-deleted data it might previously have contained.
