edit2: I wrote an sfs linker in jwm_tools that will mount link and autorun an sfs file ... new squash has xz support, so perhaps this would be a better way to go. Click on screenshot, get corresponding screen in ~0.2s (similar to magicermine which is currently proprietary)

Last edited by technosaurus on Mon 11 Jan 2016, 18:09; edited 2 times in total

This is a very generic implementation that can also be used as a poor man's steganography using only busybox applets (shell, stat, head and tail)
the first file should be something containerized (so it knows where the end of its data is) and preferably known to have varying sizes jpeg is fine if the second file is small, but avi, mov or mpg if the second file is large

The second file could be anything from text to a heavily encrypted file.

I think I have it broken down into the simplest form for further modification
you may not need to fuss with recovering the container file - if so you can remove the code related to it ... name1 size1 and head portions
if you are trying to hide a file, you may not want to even have the file name included and just have the output defined by the user - also a fairly easy mod_________________Web Programming - Pet Packaging 100 & 101

Probably I found another way, without any additional tools.
cat archive.tar.xz >>image.jpg
xzcat image.jpg > archive.tar
Seems xzcat successfully finds a signature (FD377A58h) at the end of "garbage" (mean jpeg's body) and decompresses an archive._________________SUUM CUIQUE.

And zip files can be password protected, but I may take a look at patching busybox zip first.
Other possibilities: use it to add sfs file to kernel image_________________Web Programming - Pet Packaging 100 & 101

As long as such file has .zip extension, it behaves like zip - "decoy" part can be listed/extracted (only full 'unzip' or 7zip; busybox's fails in this case, too) without any warnings and 'file somearch.zip' reports an ordinary zip file.
Fooling the 'file' utility and lack of warnings is achieved by appending a part of original zip header to the beginning of the file (head -c 30 ...) and adjusting its internal structure (zip -A ...).
After changing the extension to .7z we're gaining access to the "hidden" 7zip part and, suprisingly, 7zip has nothing against those 30 leading, extra bytes.

BTW, to avoid unnecessary suspicions, the size of uncompressed "decoy" part should be greater than the size of concatenated zip+7z, what could be achieved by using high compression level and by including some "sparse" files into it.

It's kind of off topic, but when Flickr came out with their free 1TB my first thought was about how neat it would be to use it as a backup filesystem by zipping files and appending to jpegs. But then I saw that almost as soon as it came out someone had implemented the same idea but hiding the files in pngs instead: https://github.com/Rotten194/flickr-fuse_________________Classic Puppy quotes
-
root: n. the superuser or administrator account that has complete control over everything in the machine. Running as root is a taonga of Puppy Linux users.

I wouldn't count on that except to share files short term, it is quite possible that they would decide to run image optimizers (optipng, jpegtran,...) or some other craziness on the images that would remove embedded data_________________Web Programming - Pet Packaging 100 & 101

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum