CLI Magic: ext2hide veils sensitive files

ext2hide is a proof-of-concept program that seeks to magically hide confidential data and files where nobody will look for them. It accomplishes its magic by making use of otherwise abandoned space in the superblocks in ext2/ext3 filesystems. Even though Jason McManus, the author of the code, has been testing and using ext2hide on his own machines without catastrophic results, I urge you to use the utmost caution both in testing and using it. If you don’t grok superblocks and filesystems, you probably should not experiment with ext2hide, at least until it’s out of beta testing.

Grab the latest tarball, decompress it, and enter the resulting ext2hide-version subdirectory. There you will find a number of files you’ll want to read before proceeding: WARNING, README, TESTING, INSTALL, and LICENSE. The WARNING text alerts readers to the fact that if you hide data using ext2hide with a version of e2fsprogs prior to version 1.35, then upgrade e2fsprogs to version 1.35 or later, you run the risk of data corruption in your filesystem. As the text explains, this is because of a change in the the ext2 libraries rather than a bug in ext2hide. It also explains how to check to see what version of e2fsprogs you’re running by entering:


$ dumpe2fs -V
dumpe2fs 1.38 (30-Jun-2005)
Using EXT2FS Library version 1.38


Testing and using ext2hide

The TESTING file contains detailed instructions on how to safely test ext2hide without actually writing anything to your production filesystem. Also included are instructions on how to contact Jason if you uncover any bugs or abnormalities. If you want to do more than simply test with temporary files, read on.

To really use ext2hide, you’ll need to build it first. That requires the header file for e2fsprogs. If there isn’t a devel package available for your distribution — it’s e2fslibs-devel on Ubuntu Dapper — you can download the project source code from its homepage. You’ll also need to have getopts installed, but if you have GLIBC installed, getopts should already be on your system.

Building and installing the program is easy:

$ ./Build
$ su
# ./Build install

But there is a ton of activity and output between those two commands. The ./Build command is interactive and does a lot of testing along the way. At the end of the process, if nothing goes wrong, you’ll see this sequence of messages:

Done with all tests. You had 0 failures. You rock!

Do you wish to delete the temporary working files (114MB)? [y/n] y
Testing complete. Thank you, drive through.

Continuing build script...

Now just do a './Build install' to install the ext2hide program.

Remember to do that second command as root, and note that the executable can only be run by root. By the way, the install process adds man pages, too. Use them.

Let’s play pretend. The RIAA and MPAA have combined to form one super-sized IP blackhole, the effect of which is to suck everything out of the public domain and back into corporate IP pirate chests — including things like your private diary. You don’t want them to have your diary, so you want to hide it from their prying eyes. Assuming that you keep your diary in a file called MyDiary.txt, you can use ext2hide to place the file where the IP pirates can’t find it. Like this (as root):

ext2hide -w MyDiary.txt /dev/hda1
ext2hide v1.0.0rc1 by Jason McManus, Copyleft 2006
Opening '/dev/hda1'...success.
47856 total bytes usable on /dev/hda1.

Write file to filesystem? [y/n] y
47796 bytes remaining in reserved space.
Wrote 36 bytes from MyDiary.txt.

To verify its existence, use the -l option, like this:

ext2hide -l /dev/hda1
ext2hide v1.0.0rc1 by Jason McManus, Copyleft 2006
Opening '/dev/hda1'...success.
47856 total bytes usable on /dev/hda1.
    Volume: /dev/hda1 (/)

    Size      Filename
    36       MyDiary.txt
  1 file found    60 bytes used    47796 bytes free

At this point, MyDiary.txt still exists in its original file as well as in the hidden space on /dev/hda1, so be sure to delete the original file is you want it to be hidden. Other options explain how to extract files from the hidden space, remove them, or even remove all hidden data. See the man pages.

Notes from the author

I asked Jason how he is using the program on his own system. He replied:

I currently use it on private systems, but they are live filesystems, containing essentially several years of my life since I started using Linux in ’94. I use it to store my PasswordSafe key file, tied with the pwsafe Linux utility for manipulating that database, alongside a couple of scripts to automate the extraction and replacement process, so that I can also extract it across the network to various systems (while still encrypted of course). While this is not “production” per se (and one would question someone storing their private keys on a live, production system anyway), I have now done extensive testing on filesystems ranging from 16MB to about 120GB, using 1,024, 2,048, and 4,096 block sizes, and the math has been correct throughout, since 0.99.9.

As far as reliability, there was a bug that I fixed between 0.99.8 and 0.99.9 that would have occurred in certain rare instances with a block size of 4,096 bytes and a filesystem larger than 8TB (2^31 * 4096 – 1). The offset would have looped around to the negative, but this would have been caught by a sanity check before the actual write occurred, so the bugfix was preventative rather than destructive, and it never actually occurred before I noticed and repaired it during testing. In all, I have damaged only one test filesystem during the entire time of testing, and this was actually due to a mistyped dd command on my part, rather than a problem with the tool itself. As far as the ext2/3 filesystem layout goes, a bad offset calculation could theoretically write data anywhere, but an overshoot/overestimation of free space in a superblock would overrun into the filesystem descriptors table, which while obviously not ideal, in the backup blocks it should not actually affect the system, as these would only be referenced during a fsck recovery if the primary superblock and FS descriptors become corrupted. The tool itself relies upon the ext2 libraries themselves to read the superblock information, and does its calculations only after receiving correct and sane responses from the libraries; assuming the library provides correct responses, there is little further potential for problems.

I also asked about others using or expressing interest in the program. He said:

I was actually just pinged last week by a company on the East Coast that expressed interest in having me port or extend the program to UFS, which I am currently researching with a very positive outlook: it appears so far that UFS may allow at least an order of magnitude more of usable reserved space, *and* they write a backup superblock in every block group. I’m still not sure that the port will be successful.

The remainder of the feedback I have gotten has been mostly from end users, who from what I have gathered primarily use it for similar purposes as myself: to store private information such as passwords, etc.

And finally, I mentioned that should I hide something from IP pirates like the mythical combine formed by RIAA and MIAA, the existence of ext2hide on my system would be a sure sign that I was hiding something. McManus said:

In its current form as a userland utility, and having to be run as setuid-root to write to the filesystem, it does indeed suffer from the problem you mention of being visible to the user (though I actually keep mine in my home directory’s ~/bin). The next revision, consisting of a kernel module, should take care of this. I am designing it to operate transparently from kernel space, with user-mountable options and a method to limit it only to certain users.

The idea is to let key people mount and copy files to and from the reserved space transparently, using normal file tools (cp, mv, etc.). This would obviate the need to have the separate and obvious setuid executable in userland. It will also be backward-compatible with the current file storage locations and layout, so it should be a seamless and backward-compatible upgrade. So, the answer is: perhaps if the functionality isn’t suited for your purposes in this version, it’s likely that the modular version will solve those issues and be just what you’re looking for.

ext2hide is one of the more interesting and creative programs I’ve run across recently.
I’ll be starting to use it to hide personal data I want to keep away from
prying eyes.