πŸ‘€todsacerdotiπŸ•‘5yπŸ”Ό236πŸ—¨οΈ39

(Replying to PARENT post)

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...

πŸ‘€RodgerTheGreatπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

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!

πŸ‘€djhworldπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

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

πŸ‘€peteeπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

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.
πŸ‘€lucasvr_brπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

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/

πŸ‘€donohoeπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

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

πŸ‘€afavourπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

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.
πŸ‘€HackbratenπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

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
πŸ‘€tyingqπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

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" :-)
πŸ‘€dmjeπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

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.
πŸ‘€wheybagsπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

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)
πŸ‘€cryptoquickπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Makecode Arcade also saves your code in a downloadable png.

https://arcade.makecode.com/

πŸ‘€evilottoπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

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?

πŸ‘€estπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

any file is executable on linux, if you are brave enough
πŸ‘€gcc_programmerπŸ•‘5yπŸ”Ό0πŸ—¨οΈ0