Slashdot Mirror
Hiding and Recovering Data on Linux
neuroticia writes "linuxsecurity.com has an interesting article on data hiding and recovery:
"On a 4GB Linux partition, the block size is typically 4K (chosen automatically when the mke2fs utility is run to create a filesystem). Thus one can reliably hide up to 4KB of data per file if using a small file. The data will be invulnerable to disk usage, invisible from the filesystem, and, which is more exciting for some people, undetectable by file integrity checkers using file checksumming algorithms and MAC times. Ext2 floppy (with a block size of 1KB) allows hiding data as well, albeit in smaller chunks.""
Better yet, how about combining the "slack space" concept with that of a steganographic filesystem? In fact, the two concepts fit together very well...
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
They didn't mention...
...in the article. It beats writing /dev/zero to your entire free space. Besides, if you try and overwrite your free space by dd'ing from /dev/zero, won't the outfile top out at 2 gigs on ext2?
shred -u [filename]
not necessarily root, but you have root access, like in the case of a compromised system.
until detection utilities become widespread, this would be a great place to hide your 1337 +001z like DDoS utils, portscanners, passwd crackers, lists of cc's passwds etc etc. set up a redundant distributed system across all your hacked boxen to hide files in executables and the sysadmin will not even realise what his system is housing.
-f
www.blackant.net
Less than a years ago the FBI caught a guy who used various technologies such as this exact trick on a floppy, and ram storage, and other pda things, to help hide and transport stolen military secrets.
This exact trick (hidden portions on tail ends of files) was cited in one news article.
He got caught. Why? Because the forensic tools are designed to work on DELETED files adn totally IGNORE THE FILE STRUCTURES ON MEDIA.
The many commercial forensic tools work on entire blocks of data and ignore the lengths of files when foing a default scan of a hard drive or floppy.
So this type of hiding is silly, even if encrypted.
The FBIs tools they purchase will find it.
Alright, so you could hide data within the trailing unused space of a block, (IIRC, people like Tanenbaum refer to this as internal fragmentation), and the article says you could use a tool like bmap to handily stuff data in this space....but for those who aren't convinced this does much in the way of hiding anything, could a more practical use be put into place for the slack space? Perhaps write support into the filesystem that would start stuffing things in a relatively (user) transparent way...thus finally making a 10GB disk something much closer to holding 10GB (base-2 or 10 calculations of a GB aside)?
Or perhaps some sort of piggyback filesystem that uses the slack space but would be mounted as a separate partition?
I'd imagine this would introduce lots of external fragmentation on anything stored there, but as a separate filesystem, you could suffer those pains and move your "current, but not often accessed" files there, where you really don't care if you suffer a bit of a performance hit because it's still a whole lot better than reading it from backups.
-transiit
The problem is that to hide information that I would think important (such as pictures, blueprints, my new DeCSS2, the plans to bomb a MacDonald for providing the world with bad food for years, ... ) take more than 4K.
It would take more than one of such blank spaces left on the disk, which would make it very difficult to recover as I'd need to start mapping the different blocks. I think hiding data in images, movies or (way better) music would be better than putting files there or am I missing something (too)?
One shall speak only if what one has to say is more beautiful than silence
One of the first things a forensic analyst will do, mostly in search of deleted blocks is `strings /dev/hda1`. More likely off a ro image, but out everything ASCII will pop.
Have a look at The Coroner's Toolkit
And I used to encrypt everything... Hide files, secure my boxes with passwords that were ridiculous!!!!
Then..
I had to stop and wonder why I was doing it. No one was writing e-mail to my using my PGP. Even though I made it available on my web site, and sent as attachments to people could e-mail me back using it. No one did.
I bought secure removable media. A chain to keep it on me. And had it encrypted. Now i just keep it in a bag with my laptop and never bother to use it.
My palm pilot has encrypted media.
No ones ever touched it... I just keep it on my desk hooked up to my Linux box for easy syncing...
What's my point.. Do I have one? MAYBE.
I stopped because I was lazy. I didn't have anything to hide, nothing I do is that important that I have to encrypt it. My code is opensource, and my bank info and passwords, etc are kept on my linux laptop, not on a server.
I guess, I'd like to know Who is using constant encryption and why?
For me, Encryption needs to be strong, standard, and integrated, otherwise it's just a pain.
This of this as an e-mail client. Kinda like PGP but easier.
I write an e-mail. I click "send". My e-mail client checks the "encryption" server. It finds a match for the e-mail recipient I'm sending to and downloads the PGP file and encrypts the e-mail to the recipients specifications. I did not have to do anything. If no PGP key is found then it will be sent unencrypted and let you know that it is doing so.
www.slightlycrewed.com - Because aren't we all?
It depends on what kind of data you are hiding, and how that data compares to the data already there.
the 3996 bytes left over will have a very discernable pattern: it will be machine code of the program, NOT random bytes.
the 100 bytes encrypted file you create will be random data and will (most likely) look very different from the machine code.
It would be like reading this message and finding a bunch of random numbers in the middle of it - you've got to ask yourself why the pattern was broken.
A better option would be to make your encrypted data look like bytecode and not like random data, kind of like how uuencode makes binary data into ascii characters - that way it won't stand out against the other non-data in the file.
-f
www.blackant.net
I wonder if anyone has ever built tiny file system on this concept. In theory, its not too hard. It would look very similar to a modern block-oriented file system, but with very tiny, variable sized blocks organized as inodes.
The chief objection is that the data may go missing if it is defragged or modified. The solution may be a simple as looking at last modification dates. Many of the system files on both Unix and Windows machines (/usr/bin, c:\Windows\System32) are quite small and are very rarely modified. There could be enough space spread among these files to stitch together into space for several dozen KB of compressed information. Plus, good compression should yield data blocks that look quite a bit like noise.
The other problem is hiding the program to run the file system. But that itself could be hidden in the file system if a small enough bootstrap could be written. Alternately, it could live on a floppy, providing a key, of sorts.