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.
You could rename the file or link to it without losing data. You could rename a parent directory successfully. If you tried to copy the directory, however, you'd lose the data. In short, if you do anything that changes the file's location on the disk, the secret data is lost, or at least disassociated with the original file name and vulnerable to overwriting.
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.
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?
:-)
No, it wont. Unlexx you are writing the zero's to a file which is already larger than 2 gigs. If you write on the device (/dev/hda1 etc) you are not accessing a file or a filesystem, therefor no limitation.
Besides, the 2 GB limitation is not valid any more, unless you use an old kernel. I made a 2.5 GB ascii file last night, and it worked fine
Probable impossibilities are to be preferred to improbable possibilities.
Aristotele
Really?
Mentioned, and also reasons given why it may not be as good as you think.
No. 2Gb is the maximum filesize on 32bit architectures - nothing to do with ext2. This limit can be got around anyway I believe. Besides, in this case you could just keep creating files until the partition was filled.
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!
On Linux, the chattr(1) command will allow you to set the secure deletion attribute of selected files, so that when deleted their allocated block space is wiped with 0x00 values. It would be trivial for a user to set up aliases or cron jobs to ensure that all this flag is set on all her data.
As for searching slack, there are plenty of Perl scripts to cull for interesting data such as IP's, credit card numbers, and other patterned text.
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.
A better way to hide data on a hard disk would be to use steganography, where the data is encrypted using a data-whitening algorithm and files that aren't standard. Anything you hide on a hard disk, even in the slack area, can be read by manually reading every byte of data on the disk, regardless of the OS or the file utilities used. As a note, the CIA knows this, and they grind up the hard drives they use for secret data. (and even then they don't just throw it away)
It's an old technique. IIRC, BSD 4.2's fast filesystem for the VAX had this circa, what, 1984 or so? (Well, a variation of this. Normal block size was 4K but this could be reduced to 1K for the last block of a file, with the last 1K block of several files sharing a real 4K block).
This was actually quite a leap at the time, since blocks were typically only 512b or 1K then. The 4K made it fast, the 1K tail merging made it less wasteful of expensive disk space.
-- Alastair
Check out rubberhose (www.rubberhose.org). It allows you to take a partition, and encrypt different data (and the corresponding parts of the filesystem) on the partition with different passphrases. You can only read the segment(s) that you have the passphrase(s) for. When a file is deleted, it is replaced with random noise. So when someone asks you to hand over the password, you gladly hand them one. They get to see whatever that password encoded, but not the other stuff. And they can never prove (and you can never prove) that you did or didn't hand over all of the passwords.
The disadvantage: because there is no way to tell whether there might be other data on the drive, if you don't have all of the passwords and write to the drive, you may overwrite data encrypted with another password (when data is written, it is scattered on the drive). But it's still a lot better than trying to hide data in the extra room of a block.
According to their website, this is used by civil rights activists who are in hostile nations (where "subpoena" is spelled t-o-r-t-u-r-e).