Hyd yo kids, hyd yo wives, and hyd errything behind yo images!
I sometimes enjoy messing with files, binary-ly. Many times I end up having chunks of binary files that are meaningless which once were texts, images, and archives. Though last time, I decided to get something out of the act.
I’ll be honest and tell you that at the moment I remembered Antoine Dodson and his advice to humanity “Hyd yo kids, hyd yo wives, and hide yo husbands”. That gave me the idea of hiding files behind other files.
The idea is not securing or locking files, GPG can do that perfectly, the idea is hiding it. Meaning that if one takes the cover off, one will probably see it! Though hiding files might be useful in some cases.
A quick real-life example: One person is refilling his fountain pen in his room and accidentally squirted his wall with the black ink. He brings in an extremely interesting painting/poster and covers the mess. Now, the mess still exists and can be seen once the cover is taken off. This approach is safe and practical whereas locking the room might bring suspicions and curiosity.
Same story, but in Linux.
Some of you might already know that a files in Linux are identified through the first bytes, the file header. Another thing that you might know is that some formats use containers for its data(chunk-based formats), functioning like HTML tags: only that is between the tags is read, anything that comes after the end tag is ignored completely. So theoretically, if we have any sort of file hidden behind a chunk-base file, only the chunk-based file will be loaded when opened with any compatible viewer/editor!
Here’s a chart to simplify the idea:
Obviously, when you stick to files together, the result would have the size of the sum. So onto the practical part. We got multiple tools that could be handy for this, mainly cat.
$cat trollface.jpg pedobear.png > result.jpg
Now, viewing it would show only Trollface(result file; check size) where in fact the file contains the two of them.
This can be done to any file and will not show the second file as long as the first file is of a chunk-based format. This would obviously fail when using non-chunk-based files as the cover, such as plain text files. Not so interesting, I know! But do you know what’s interesting? Using executable files as covers, will the executable execute after the merge?
$ cp `which ls` listFiles $ ./listFiles #just checking if the copy works listFiles pedobear.png result.jpg trollface.jpg $ cat listFiles trollface.jpg pedobear.png > result.exec $ chmod +x result.exec $ ./result.exec listFiles pedobear.png result.exec result.jpg trollface.jpg
It works! But wait, this cannot be applied on all executables! Some executables are scripts and not binary which means that they will be interpreted. In case you didn’t know, interpreted scripts are executed at the time of launch; if it is bundled with another file, the interpreter will err and probably halt. So, yes, it works only with binary executables.
… Now what?
REVERSE IT!! Since you got it hidden for some reason, I’m pretty sure you might one day want to get the hidden file. In my case, I might want to free Pedobear when no children are around! … Logically speaking, preforming this task would require, beside the bundled file, either the original cover file or cover/hide file size.
With the original cover file, you can easily obtain the size. Let’s say the size is x bytes, then all you have to do is skipping the first x bytes and copy what comes after till the end of the file. In case you got the size of the hidden file – let’s call it y, you can do a similar trick: copy the last y bytes.
To preform this practically, you don’t need to write your own program/script, Linux is awesome; comes with all that you need. You can use a lot of tools for this, you can use cut, dd, split, and tail (Yes tail!).
When I first started messing with this, the wondrous tool tail did not cross my mind, I was using split. Using split for this resulted in a mess. Why? Because split has his own way of splitting: Splitting a file of a specified size x would split the file for every x bytes. Meaning that if the file is of size is > 2*x (double the size of the cover file), it will result in many splits of the hidden file until the file ends; leaving you with a mess to cat and clean.
Gladly, tail crossed my mind later. The great
man told me that it can handle not only text, but bytes as well. All I needed to know is the byte which the hidden file begins (size of y).
$tail --bytes [SizeOfHiddenFile] [BundledFile] > [Output]
This gets the hidden file revealed. In our case, Pedobear is of size 7777 bytes (!), Trollface is of size 88820 bytes, and the bundled file is of size 96597.
$tail --bytes 7777 result.jpg > original.png
or in case you don’t have the size of the original, only the cover size was given. You can find the size of the bundled file and use the x-y method!
$tail --bytes $((96597-88820)) result.jpg > original.png
I know inserting manually numbers is prone to err, and that’s why the following is safer, but more complicated:
$tail --bytes $((`du -b result.jpg|cut -f -1`-`du -b trollface.jpg|cut -f -1`)) result.jpg > original.png
`du -b filename` gets the size in bytes appended by the filename. Because filenames should be removed in order to do mathematical operation we add
`|cut -f -1` which gives only the number. Then it subtracts them
`$((BundledFileSize-CoverFileSize))` and puts it where the size of the hidden file size should be.
How could this ever be useful?
I know this is somewhat useless, but hey this can fool a lot of people and you are likely to get away with it! Come on, if you browse a directory on your friends PC and you see images of Linux and penguins, you will never have a second thought that he’s secretly a Mac lover and has a Mac logo behind every image in that directory! He’d fool you, and you can do the same! :P
If you’re not sold by that, here’s another benefit! Let’s say a script kiddie sniffed your email and the attached file which happened to be a secured .zip file containing the things you wish to hide from everybody except for the recipient. Which is more likely to happen, cracking the .zip file (piece of cake) or keeping a Micky Mouse image which you hid your .zip file behind?
Okay, but seriously doesn’t the thought of just attaching files to files blow your mind? … guess not! :/
If you really made it to this point, here’s something interesting and very beneficial, yet very bad-ass. How do you like the sound of: “infinite online storage for free”? Yep, you guessed it. YOU GOTTA PLAY IT RIGHT! Attach your personal files to images, and what? Upload them to free online image hosting services!
I bundled ubuntu-11.04-desktop-amd64.iso (699MB) with a 158KB image. It was uploading, but I canceled it. The internet connection over here was slow so I didn’t wish to worsen it. Though I prepared another pack, a 6.2 MB zip archive full of fonts.
Imgur developers were smart enough, as expected, to do something for files that are large. It seems that they create their own copy with lower quality instead. Other sites have taken the easy way out, reject files > 5MB! Image shack and TinyPic were like that. Though that doesn’t mean we’re doomed, there are still those who haven’t foreseen this humongous hole, right iimmgg? … Be smart.