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.""
Privacy is always a good thing. But how quickly do you think the FBI or USSS will try to regulate this sort of "uncrackable encryption"?
Would it be possible to break up the encrypted passwd file and hide it in slack space? Perhaps have an ersatz passwd with useless passwds, and hide the real one in several places around the disk. Or am I just being really REALLY paranoid??
why not strong encrypt your document first, when embed the result steganographically into a jpeg before "hiding" it on an ext2 filesystem.
That should do it.
- what are the potential uses for such a thing?
- a hacker could hide some information somewhere, but what to hide?
- Is there any legitimate use for that?
- Does moving the file to another location suffices to prevent any use of such a thing? (after all, if the file is moved, the block is free for reuse).
Just my 0.01 worth questions...
One shall speak only if what one has to say is more beautiful than silence
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.
...until you're free to think something without being forced to tell anyone.
sounds more like something you would use in an easily-defeated copy-protection scheme for software distributed on read-only media.
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.
Of course! Copy the requisite illegal plans to a floppy, jam it in a bag, and bury it in your garden. Of course, if you have a dog, he might dig it up and nark on you to the feds, but that's life I suppose :)
Personally, my data is about as interesting as a box of dry Jacob's cream crackers, so I ain't about to go hiding it, either in my slack space *or* my window box!!!
Tom Newton
Good for hiding all of my 1 - 4 kB pr0n.
There is nothing wrong with being gay. It's getting caught where the trouble lies.
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]
Take your data with you. Keep it with you at all times or put it somewhere more secure or less obvious than an open server.
Yes, it's not a perfect solution but it works 99 per cent of the time. And, if you're paranoid, you can always encrypt the files on your CDR/floppy/zip/Compact Flash card/USB key chain drive for further security.
Sometimes the simplest solutions are the best.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
Regarding slack space, yes, it works as described, you can use slack space to write your data, and hope that it doesn't get overwritten when the file grows.
Using encription and spanning multiple slack zones, namely on binary files, you can, for instance, write a tool that encrypts a file, writes it on a number of slack zones for the files in /usr/bin (since these won't grow much over time, will they?), and then is able to recover the file.
You can even write the tool so that it creates two pipes, one to read, another to write.
But in the end, is this good or bad? Like it is said in the article, it can as easily be used to hide evidence as it can be to plant evidence.
What should we do? Write tools to use this to our advantage, or write tools to automatically wipe clean the slack area and render this inoperant?
Or should we do both?
free the mallocs!
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.
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.
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 file system that comes with the latest releases of Netware allows you to use that extra space. The file system varies the size of the cluster (or block, I forget what it is) to tailer the filesystem to the data. This way if you have a 5k file on 4k filesystem you may only use 6k instead of 8k because the file system gives the file a 4k and a 2k area to store the file.
Why hide the data when you can use that area and reclaim space. On a big drive it can add up pretty quickly. But still is no massive sum.
How many BOFHs do you think will start to threaten to defragment users' workstations (using a tool that doesn't do use direct block copying, of course) just to see if they have hidden data on their disks?
storing small exe ?
virus/tronjan!
perfect way to hide backdoor
RootKit have another cool hack to exploit...
my 2 cent
http://www.rubberhose.org/
Cheers
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!
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
Storing smth into some dir like /var and then mounting some partition onto it is about as nice, IMHO.
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?
How hard would it be to write?
I'm guessing it's not very difficult.
not fragile on a mac.
A mac will faithfully copy a file and round up to 512 bytes if needed under HFS and HFS+ OS's.
Probably on all mountable OSs except over networks on a mac.
Under Linux, who knows, have to sheck the source I guess or try it.
Here is another way to hide some files in /mnt /dev/hda4 /mnt /mnt
Linux, at least temporary...
cp file_to_hide
mount
ls
{stuff from hda4}
Almost the same level of protection as in that article...
The only real use I can see for this is hiding information on someone else's compromised machine...
Great....
There are several practical problems with this.
First: defragmenting. If you run any utility to defragment your drive, the data will (probably) be lost.
Second: Don't move that file! If you don't know what file space your "secret" data is stored in, then moving, adding, deleting, copying or otherwise altering (editing) any file may destroy some part of your hidden information. Remember that you only have 4k to work with at any given time. This isn't a huge amount of space. You start hiding data all over the place and you quickly start running into this risk.
Third: The govm't and spies aren't stupid. They will have thought of this possibility. In order to implement such file-hiding techniques you would almost certainly need to implement some type of disk partition and format management system on top of the existing one in order to avoid the problems mentioned above. It isn't very hard to search for direct-to-disk calls, and checking the kernel source for partion management against current versions to see if it has been altered is easy too. Unless you hide the source code for your (ext3.01?) filesystem somewhere else or in your hidden system area (pretty hard to do) then the person searching for your data has some pretty clear evidence of where to look for your stuff and how to get at it.
My $0.02 will always be worth more than your â0.02, so
yeah, but apparently, some lame moderator with humor up his ass moderated me offtopic.. jeez.. if I had said CowboyNeal instead of my mum-in-law, I'd probably be moderated (+4,funny)
When will I end this grieving ? When will my future begin ?
...And much of this wasted space is available to the *legitimate* filesystem on the volume...
And "Hiding" is an interesting term here. It's not hidden, if it's not encrypted; and if it's encrypted, why bother with such nonsense...
-- Mike Greaves
Try this link. It allows for hiding partitions and for encryption.
Yep, I never spell check.
More incorrect spellings can be found he
where's the etch-o-sketch p0rn??
The reason I said probably in the first post about the defrag operation is because many (not all, and I have NO IDEA about the ext2/3 code) don't actually read the whole block from the disk if only the first 100 bytes are needed. Still others only write out the actual copied data (100 bytes) to the new block. Thus if you have following possibilities...
n d you defragment you could have
[A][B][Afrag-secretstuff][Bfrag-secretstuff]
A
[A][Afrag-gargage][Bbfrag-garbage]
either because the defragmenter read only
[Afrag] or [Bfrag] or wrote only [Afrag] or [Bfrag] to the disk.
Now obviously, a defragger which copies only blocks (like the old Win stuff) would not do this.
My $0.02 will always be worth more than your â0.02, so
viruses have used this trick since the early 80s. tell us something new.
another place to hide decss then ;)
This would also be file-systme specific.
This would not work in ReiserFS. ReiserFS uses that slack space for storing small files.
(I think...)
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)
How to retrieve hidden info from the floppy :
:-)
dd if=/dev/fd0 of=floppy.bin
and search into floppy.bin, that's all
I may just be naive here, but why are files sotred in this way? It seems to be the smart way to implement a filesystem would be to have one monolithif "file" that spanned every block in the whole disk, and have a "virtual" filesystem driver that reads/writes/defragemtns/etc that large file as though it were a physical disk. You would never see loss to block size again, and it would have other benifits too, like making make automagic encryption a breeze.
"Your superior intellect is no match for our puny weapons!"
Just don't fill up your partition...
Oh, and to whoever was asking about the uses for this: data can be hidden with system files, where the information will not be moved. It can be used to conceal anything that needs concealing, preferably in conjuction with encryption. This provides both the benefit of additional security for the data, as well as making it less likely for someone to stumble upon the data and say, "hey, this is valid data!" Encryption is good for that sort of thing sometimes. So if Dear Old Bush's Bastards Enforcing the Right (D.O.B.B.E.R.) come after your essays concerning the effects that Bush's policies are having on our already horrid relationship with the rest of the world, those bungling bumpkins from the Three-Letter-Agencies will hopefully not be able to discover "Anti-American" things. Or you might not want your girlfriend to discover your dirty, dirty porn collection. Or you just might be one paranoid kinda guy. There's a lot of uses, really.
My girlfriend is actually the one with the "dirty, dirty porn collection". She was mad enough when I hid her cigarettes, I'd hate to think what would happen if I hid her porn :)
Build boards not bombs
Many have pointed out, that the technique of hiding data in leftover chunks of blocks isn't very useful in most cases. But that's missing the main point of the article i think. The main point of the article is, that there already is lurking a lot of data in those chunks, and that, unlike free blocks, this data is unlikely to be overwritten unless the associated file (which the block is part of) is altered. I think this is far more interesting, maybe in the enron case or the likes, where computers are scanned for just such evidence which might lurk in thousands of places scattered all over the system and survive longer than anticipated.
--
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
I use ssh (and it's associated utilities) exclusively when logging into remote boxes non-annoymously. A few years ago somone showed me how very easy it was to sniff traffic and I've been more careful ever since.
Why hide it at all? Why not mount another filesystem that uses this space exclusively? Imagine mounting a filesystem, whose total size is equal to all the cluster waste on your hard drive? Then treat it identical to any other drive. When you're finished copying your stuff to it, unmount it. Or better yet, write a driver that syncs your normal cluster space with your wasted cluster space, so as to prevent data loss in some way... Surely there is a use for this! It would be a great place to toss all unused cookies or other cruft that I wouldn't otherwise want to take up space... A temporary drive of sorts? What do you hackers think, would it be hard to write a filesystem that uses this?
it can be quite entertaining to open up a whole filesystem in a hex editor and just poking around to see what you can find, wouldn't it be possible to find this data that way?
Software Freedom Day!.
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).
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.
It seems good, but why not hide the data by controll the allocation of blocks?
"And I used to encrypt everything."
Security has never been an absolute. The value of security has always been judged as a comparison of security costs versus the value of what is being secured.
Do you always lock your car door? Do you always lock your hose door? Do you always use landline phones? Do you always try to pick a decently hard pin for your ATM cards? (No, no, no, yes). How come?
I de-registered my Hushmail because Hushmail v2.0
doesn't work with Mozilla or Linux.
I believe Netscape 4.xx is crippled to that aspect, so I dropped the account.
heck, if you can't "upgrade" your account without having to boot into windows and use IE, what's the point?
fialar
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.
Sounds like Lotus Notes, when configured right - except I don't think it does PGP, just internal public key crypto to other LN users.
Hiding information (that you apparently don't want others to see) is the lowest (and most outdated) form of security known. A few wars - including WW2 - show that the most reliable way to protect your information is a strong encryption. So while it is fun that you can use wasted space (duh) - it does appear to have only academic interest.