This image looks very different on Apple devices — see for yourself

Take a good look at the image below and the device you are on.

Now view it again on an Apple device. Conversely, if you are using an Apple device, view this page on an Android or Windows device.

‘Think different,’ see different

If you are using an Apple device and viewing this page on Safari, chances are the image appears quite differently from what you’d see on, for example, Chrome or an imaging app on Windows.

Reverse engineer and cryptographer David Buchanan might have left us all puzzled with his latest creation:

The PNG above reads ‘HELLO WORLD’ for most users—except those who see ‘HELLO APPLE,’ that is, in Apple-made software.

But, believe us, it is the same image a.png, interpreted differently by Apple and non-Apple applications.

In tests by BleepingComputer, on macOS Big Sur 11.6, the latest version of Chrome web browser (96.0.4664.110 (x86_64)) rendered the text in the image as ‘HELLO WORLD’. But, viewing this page on Safari, or the image alone in Mac’s ‘Preview’ app shows ‘HELLO APPLE.’

In another test by BleepingComputer on an iPhone, however, both Chrome web browser for iOS and Safari showed ‘HELLO APPLE,’ not ‘HELLO WORLD.’

Here’s one more to leave you startled a tad further—do you see an IBM or a Mac below? Once again, view this page with an Apple and non-Apple device:

Why does this happen?

On his website, Buchanan concisely explains the reason and the concept of ‘parallel-decodable PNGs’ that cause ambiguity among software applications.

Depending on an image renderer’s implementation, the same PNG may be interpreted quite differently.

“I found this while writing my own multi-threaded PNG decoder. While pondering my design, I realised that I had an exploitable implementation bug,” writes the engineer.

“After learning that Apple has their own implementation of parallel-decodable PNGs, I realised that they’d made exactly the same mistake!”

Buchanan discovered that it was possible to craft a PNG file where:

decompress(a + b) != decompress(a) + decompress(b)

“This could happen if a ends midway through a non-compressed block. It is therefore possible for an image to have two possible interpretations, depending on whether a parallel or non-parallel decoder decodes it,” further explains Buchanan.

“This can be mitigated by the decoder, by checking that there is no unprocessed data in each piece of the zlib stream. My implementation does not currently do this!”

To demonstrate the peak of possibilities that could be achieved with this ‘mistake,’ Buchanan shared proof-of-concept (PoC) code:

The 84-line PoC demonstrates how some image rendering libraries can be tricked into showing the alternate version of an image—the one with the ‘SECRET MESSAGE.’

In fact, the reverse engineer has released a handy tool called ‘Ambiguous PNG Packer’ on GitHub that lets just about anyone create PNG images that look completely different in Apple software.

In March this year, Buchanan had also demonstrated how Twitter images could be abused to hide 3-MB-large ZIP and MP3 files within.

Now had the end result of this parallel-decoding business been merely an erroneous or corrupted image that wouldn’t render correctly, it would be easier to classify this as a ‘bug.’

But, we wonder, could this become a security risk in some contexts or an attack vector for malicious actors to abuse? The same file seen differently by two entities is bound to cause trouble.