Executable PNGs

https://djharper.dev/post/2020/12/26/executable-pngs/

by todsacerdoti • 6 years ago

236 39 6 years ago

Hackbraten2• 6 years ago

I don’t have a link to back it up but I recall that yes, PICO-8 in fact uses the two least significant bits of each color channel, respectively.

mjbrusso• 6 years ago

I don’t have a link to back it up but I recall that yes, PICO-8 in fact uses the two least significant bits of each color channel, respectively.

"The cart data is stored using a steganographic process. Each PICO-8 byte is stored as the two least significant bits of each of the four color channels"

https://pico-8.fandom.com/wiki/P8PNGFileFormat

petee• 6 years ago

I would think PICO-8 would just use png's ability to add chunks of data that are ignored if not recognized by a regular decoder, why bother with steno?

Separately, this is pretty nifty

edit: well i stand corrected by the comment below[1] that pico does in fact use a steno technique, but i am curious why they took such a route considering nothing in the cart is intended to be secret or copy proof

[1]https://news.ycombinator.com/item?id=25543336

Hackbraten2• 6 years ago

One core concept of PICO-8 is the artificial limit to 32 KiB per cartridge.

While that would certainly also be enforceable with PNG data chunks, I think the 32K restriction lends itself to the steganographic solution more naturally than using a chunk would.

kmm• 6 years ago

I'd expect a not insignificant amount of image hosting sites to throw away unrecognized chunks, especially if they contain a few dozen kilobytes of data. It might even make sense for privacy or security reasons, just like EXIF data is usually stripped.

skrebbel2• 6 years ago

"why bother" isn't a very relevant question about anything PICO-8. The entire thing is about artificial limits for "because we can" reasons.

Basically, the answer would be something akin to "because that would feel like cheating"

kroltan• 6 years ago

As other posters mentioned, using extra chunks might make it incompatible with hosting sites that remove them.

Plus consider that they can be removed even perhaps unintentionally, if the upload process manipulates the image, it might convert the PNG file into a format-independent "Image" structure while in memory, which possibly discards this extra information.

Steganography is a bit more resillient since it will survive basically everything but scaling or lossy compression, as the information is in the image itself (and thus a format-independent program doesn't need to take into account that data).

Naturally, it is still liable to websites that assume images are photos and thus can be scaled and otherwise tampered with much less consequence.

egypturnash• 6 years ago

“Because Zep thought it was more fun that way” is always a good guess at the reason anything in Pico-8 works the way it does, tbh.

afavour2• 6 years ago

This is really cool but I doubt this is now PICO8 works, since PNG lets you create arbitrary chunks of data that standard decoders will ignore:

All ancillary chunks are optional, in the sense that encoders need not write them and decoders can ignore them.

http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html

skrebbel2• 6 years ago

You don't need to doubt, you can just check:

https://pico-8.fandom.com/wiki/P8PNGFileFormat

The cart data is stored using a steganographic process. Each PICO-8 byte is stored as the two least significant bits of each of the four color channels, ordered ARGB

afavour2• 6 years ago

I stand corrected! I maintain it’s an odd choice given the availability of alternatives, but I suppose it’s all in good fun.

MontagFTB• 6 years ago

They could have created their own chunk type and set the safe-to-copy but to 1, permitting apps to round-trip the chunk without knowing exactly what was in it. From the spec:

If a chunk's safe-to-copy bit is 1, the chunk may be copied to a modified PNG file whether or not the software recognizes the chunk type, and regardless of the extent of the file modifications.

dmje• 6 years ago

This is cool. I've always loved pico8 and been in some level of awe about the idea of distributing games as pngs, so it's really interesting to read more about it, even if "pointless" :-)

lucasvr_br• 6 years ago

I liked the integration with binfmt_misc! There are several different approaches to bundle data files with a single executable, as the author probably knows it. My favorite one is AppImage. Even though, I've also looked into using alternative approaches to software distribution in the recent past, and ended up creating an extra section in the ELF file to store ancillary data. `objcopy --add-section <params> --set-section-flags <params>` appends the payload to the executable, and libelf can be used at some later point to retrieve the data back. Works like a charm, as long as you don't let `strip` remove unneeded sections from that executable file.

donohoe• 6 years ago

This is a bit old but I used to write my JavaScript to PNG and load that instead. I don’t recommend it, it’s just for fun.

I think the encoder still works:

https://donohoe.dev/project/jspng-encoder/

djhworld3• 6 years ago

Author here, hello.

The post glosses over some aspects of the implementation, for example to fit some executables into an image you can optionally compress the data with gzip and encode that instead

It also supports encoding at two-bit and four-bit levels but obviously the grain starts becoming apparent in the output images

Also it puts a 40 byte or so "header" in the encoded output so the decoder can see how many bytes to read up to, validate a hash and check a magic. It's a bit basic but it's enough to get it to work.

Anyway this was fun, thanks for reading!

codetrotter• 6 years ago

It also supports encoding at two-bit [...] levels

Excellent! That was going to be my question after having just read the blog post and comments. Nice work!

app4soft• 6 years ago

to fit some executables into an image you can optionally compress the data with gzip and encode that instead

We already know such solution as "Rarjpeg"[0]: "letter file" + "letterbox file"[1]

Supported "letter files" (which could make box files selfexecutable):

- archives (selfexecutable): .rar/.7z

- other (not selfexecutable): any other files

Actually, supported "letterbox files" are:

- audio: .wav/.mp3/.aac/.amr

- image: .jpg/.png/.gif/.webp

- other: .torrent , .html

So, there are nothing new in your solution.

[0] http://lurkmore.to/Rarjpeg

[1] https://news.ycombinator.com/item?id=25329600

djhworld3• 6 years ago

Thanks, I didn't go into this expecting it to be new, or a production ready thing, I did it because it was dumb and I learned a few things along the way

hootbootscoot2• 6 years ago

I can't believe someone flagged a citation-laden dry-as-a-bone statement with no insults, rude words, etc.

I do think that that the author addressed this comment by saying that they don't CLAIM original work, but I find such use of the "flag post" tool to be disturbingly motivated and illogical.

NiceWayToDoIT• 6 years ago

Vehicle for viruses/malware?

sloshnmosh• 6 years ago

I’ve seen Android malware that imports and exfilterates compressed data disguised as GIF’s

nicoty• 6 years ago

This might be of interest - https://github.com/chinarulezzz/pixload

cryptoquick• 6 years ago

Well, at least it's intentional, unlike the Windows Metafile exploit, or 4chan.jse. (Intentional by the user, at least; the developer's intention is assumed)

est• 6 years ago

PNG could be modified into 16-bit executables on Windows. The extension is .con and could start with any header bytes.

You can even access some 32bit APIs I assume?

wheybags2• 6 years ago

I suspect the clang issue is because it expects argv[0] to be a path to a real binary, and internally reruns itself as a subprocess. It might start working if instead of using /proc/self, you fetched your pid and used it explicitly in the path, so the subprocess could run it too.

djhworld3• 6 years ago

Hmm good suggestion thanks, I just tried this but it exhibits the same behaviour.

I think it's running into this problem https://stackoverflow.com/questions/27494866/llvm-cannot-fin... - it looks like it looks at /proc/self/exe which I'm guessing returns a bad value? Not sure.

wheybags2• 6 years ago

Ah, maybe it's using readlink on /proc/self/exe to get the actual path to the binary, which would obviously fail if it's not a real file. If it's something along those lines then I guess it's probably not fixable. Oh well, still a bit of fun anyway :p

tyingq• 6 years ago

My poor man's version from this HN discussion[1]:

  curl -s https://pbs.twimg.com/media/Dq2sPGNU0AEKyyC.jpg | dd status=none bs=1 skip=599 count=40

[1] https://news.ycombinator.com/item?id=18342042

RodgerTheGreat• 6 years ago

In my own system, Octo[0], I encode programs and their metadata in a similar steganographic fashion in GIF files[1]. As others have noted here, both GIF and PNG offer extension mechanisms and ways to embed "comments", but popular image-sharing sites universally re-encode images and discard this data. The advantage of GIF over PNG (for my purposes) is that I store an arbitrary payload in a fixed-looking image by creating additional frames of animation.

In the past, I've also used a different technique- if you simply concatenate a PNG onto a JAR (which is really just a ZIP archive) you end up with a file that acts like a PNG unless you change the extension to JAR, in which case it acts like a Java executable. This works because the PNG header is at the beginning of the file, while the ZIP header is at the end. Nowadays, though, desktop Java is pretty much dead, so it's a less exciting party trick.

[0] https://github.com/JohnEarnest/Octo

[1] https://github.com/JohnEarnest/Octo/blob/gh-pages/js/sharing...

masklinn2• 6 years ago

In the past, I've also used a different technique- if you simply concatenate a PNG onto a JAR (which is really just a ZIP archive) you end up with a file that acts like a PNG unless you change the extension to JAR, in which case it acts like a Java executable. This works because the PNG header is at the beginning of the file, while the ZIP header is at the end. Nowadays, though, desktop Java is pretty much dead, so it's a less exciting party trick.

It was a common party trick for the reasons you outlined on image boards: you could smuggle small-ish zip files as long as the board made the original file available as-is somehow by concatenating the image (usually jpeg) and zip.

gcc_programmer• 6 years ago

any file is executable on linux, if you are brave enough

evilotto• 6 years ago

Makecode Arcade also saves your code in a downloadable png.

https://arcade.makecode.com/

Executable PNGs

Related Stories