(Replying to PARENT post)
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!
(Replying to PARENT post)
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
(Replying to PARENT post)
(Replying to PARENT post)
I think the encoder still works:
(Replying to PARENT post)
> All ancillary chunks are optional, in the sense that encoders need not write them and decoders can ignore them.
(Replying to PARENT post)
(Replying to PARENT post)
  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(Replying to PARENT post)
(Replying to PARENT post)
(Replying to PARENT post)
(Replying to PARENT post)
(Replying to PARENT post)
You can even access some 32bit APIs I assume?
(Replying to PARENT post)
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...