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.""
Sorry, I fail to see how this is news (block sizes and slack space have been well known for years) or a useful technique - you'd need to have a large number of known unchanging files to store any sensible quantity of data. The obvious source would be binary executables. If you are able to store data in the slack space of binary executables, you're presumably root, in which case why not secure your data in a more sensible way.
This trick is more useful on other OSs that copy using entire blocks.
for example data hidden in the tail portion of 512 bytes on a mac will be copied from one floppy to another on the Mac OS for the last 18 years.
Using modern network protocols or file compression will lose these tail end bytes.
A way of hiding data in a Mc file that survives network and file compression is to store data in the 12 byte undefined section of a resource fork header.
Some people write 12 byte hole scanners to search for passwords and credit card numbers and somwtimes find them according to legend.
But the mac has a concept of a physical file length and a logical file length, and the two values do not have to equal each other, and the physical file length has to be modulo 512 minimum.
But hiding data can get easily lost, its better to hide such data in node cluster control areas rather than file tail ends.
Just make sure you don't use a smart filesystem like ReiserFS, which can use the slack space for storage. If you try to put something in its slack space you might find yourself a bit lost...
I did not see it mentioned that ReiserFS is able to "pack tails", which means that the ending parts of files that do not fill an entire disk block (typically 4KB) are not stored in their own block. Thereby, it does not waste (on average) 2KB per file.
Actually using the disk blocks seems, to me, more appropriate than hiding stuff in them. There is even work in progress of an ext2 version of this technique.
This technique is really *old*. I once had a DOS game that used this to prevent casual copying - the installer was writing additional data into the slack space at the end of it's main executable. There was something similar on the floppy too. I think what it was doing was hashing the data on the floppy with whatever was generated on the HDD, but since I just NOP'ed over the subroutine call, I really didn't need to look too closely. Or require my diskette to play the game for that matter. ;)
UNIX? They're not even circumcised! Savages!
Hrm... may not work with a lot of setups. From "shred --help":
CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective:
* log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, etc.)
* filesystems that write redundant data and carry on even if some writes fail, such as RAID-based filesystems
* filesystems that make snapshots, such as Network Appliance's NFS server
* filesystems that cache in temporary locations, such as NFS version 3 clients
* compressed filesystems
Note as well that, unless you specify the -x option, it *will* attempt to shred the final block completely, beyond the end of the file (thus killing the hidden data).
I'll go back to lurking now.