For example:
> xxd -i tmp.f
unsigned char tmp_f[] = {
0x38, 0x4a, 0x39, 0x6f, 0x61
};
unsigned int tmp_f_len = 5;
On a separate note, a fun fact: PNG uses what is basically a de-facto v3 of the https://en.m.wikipedia.org/wiki/Interchange_File_Format . PNGs can be parsed and generated with generic IFF tools. (Which can also be used to operate on AIFF, TIFF, and—perhaps surprisingly—Erlang .beam files.)
IFF is, IMHO, an incredibly underutilized “metaformat” for how simple it is to work with, how observable/inspectable the results are (for a binary file format), and yet how efficient it is (compared to text-based formats.)
PNG’s (backward-compatible) extensions over IFF are all pretty great ideas as well — e.g. using chunk name capitalization as metadata to mark chunks as optional (plus a few other things); linking chunks with checksums to indicate when derived chunks need to be recalculated; etc. If these extensions were promoted to features of the metaformat itself, that’d make probably the best document-oriented container metaformat around, beating e.g. “a zip file with a META-INF dir inside” by a wide margin. Sadly, AFAIK, nobody has tried to write a formal IFFv3 RFC to formalize these extensions. (Maybe something I’ll do one day myself.)
I remember downloading a lot of albums off 4chan where you would save the image, then rename it to .zip to get a folder of MP3s. Good times!
I do wonder though how "stable" embedding files is. Like do most major hosting services process images to the point it strips that stuff out?
I was surprised to see this was still working 3 years later:
$ curl -s https://pbs.twimg.com/media/Dq2sPGNU0AEKyyC.jpg | dd status=none bs=1 skip=599 count=40| sh
So if you use stego and store data in the image, you have a bigger chance of preserving the data.
I would like to be able to edit everything I store in said Wiki, and this flow breaks when it comes to images. Inspired by draw.io, I created this simple util that lets me (and you) store the diagram's code with the image. Now, as long as you have the final image, you and others can keep editing your diagram!
What is being described will get you on your way to the NSO hack as a service, because their hack was using a decompression algo to build a virtual cpu of sorts and run it, in a single pass of the decompression process.
How hard would it be to embed source code in such a way that you could also build a limited cpu to then run this embedded source code in memory with a single pass of graphic processing or decompression algo?
PNGSource embeds code in ancillary chunks. That's it. No code execution. No steganography (yet).
For example, PNG seems benign, but what it was stored in a zip file of sorts, could the MS windows zip process be exploited, could 7-Zip be exploited or even PKzip for that matter, do you see where I am coming from?
What about if I embedded some icons and image files as a resource in an application exe or dll. You have persistence then, even if its just a beacon or some unique domain name lookup to track the app online. https://docs.microsoft.com/en-us/windows/win32/menurc/enumer...
Likewise, what about compression built into HTML/Web browsers, could that be exploited? https://en.wikipedia.org/wiki/HTTP_compression
Would it be possible to build something into a webpage or imagefile on a popular website where it can exploit the methods NSO have/are using? Maybe we should go back to reading the internet using wget?
FAQ Is this an Electron app?
It's a few MB, which is a two orders of magnitude below Electron size, but still seems rather large for what it does; especially the CLI version.
It's also interesting to me that the spec says that the viewer should give the user a way to look at all the textual parts of a png (there are three), although I've never seen this offered.
2GB like all the other chunks.