Forgot your password?
typodupeerror
Linux Software

Hiding and Recovering Data on Linux 151

Posted by CmdrTaco
from the hah-its-in-the-other-hand dept.
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.""
This discussion has been archived. No new comments can be posted.

Hiding and Recovering Data on Linux

Comments Filter:
  • Some questions... (Score:3, Insightful)

    by Saib0t (204692) <(gro.dum-airepseh) (ta) (tobias)> on Thursday March 14, 2002 @09:05AM (#3161939)
    The article, while explaining rather well that there IS such a thing, fails to explain some things:


    - 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...

    • by redhog (15207) on Thursday March 14, 2002 @09:13AM (#3161957) Homepage
      This is a question of security by obscurity. If everyone used exactly this technic to hide their data, everyone and their dog will be able to recover it. But if everyone hides their data at different places (I hide mine in the most insinificant bits in a picture, you hide yours in teh filesystem, etc), we'l increase the workd needed to find any given information.

      If you think that "if you are innocent, you have nothing to hide", then certainly, this has no uses. Otherwise, it has lots of uses :)

      Hiding dirty pictures of you and your SO from parents perheaps?

      No, just _moving_ it does not free the block. You must either move it to another disk, or copy it and remove all had links to it.
      • This is a question of security by obscurity. If everyone used exactly this technic to hide their data, everyone and their dog will be able to recover it.

        Let's assume that if you want to hide something, you'll be clever enough to at least encrypt it before storing it (or even ROT13 it). How can one determine the different between that and random bits left over from old programs, pictures?

        • How can one determine the different between that and random bits left over from old programs, pictures?

          your programs won't leave random bits behind, they leave program-droppings - maybe pointers, strings of data, etc. as with hiding data in image files, you have to be careful that the signature of your hidden data matches what one would expect in that area.

          do a google search for steganography to learn more about it, like into Neil Provos's stegdetect work at citi.umich.edu.

          • your programs won't leave random bits behind, they leave program-droppings
            I think you misunderstood my question (or I misunderstood your reply). I was talking about this: you have a program on the HDD, it's on a given block, you delete the program, create a 100 bytes file on that block, the remaining 3996 bytes would be filled with part of the code of the program. Now, how would a malicious person be able to figure out that the files you hide in the blank space are not leftovers from programs you deleted?

            Thanks for your advice on steganography, I bookmarked it for later reading.

            • Re:Some questions... (Score:3, Interesting)

              by friscolr (124774)
              you delete the program, create a 100 bytes file on that block, the remaining 3996 bytes would be filled with part of the code of the program. Now, how would a malicious person be able to figure out that the files you hide in the blank space are not leftovers from programs you deleted?

              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.

    • - what are the potential uses for such a thing?
      Fun mostly! But really, it's useful for anyone who wants to hide information from governme^wuntrustworthy people.

      - Is there any legitimate use for that?
      See above.

      - Does moving the file to another location suffices to prevent any use of such a thing?

      AFAIK, no. Not with ext2 at least if you're moving the file from one place on a filesystem to another on the same filesystem. The data doesn't actually get moved. All that changes is the link to the inode. (can somebody correct me / elaborate)

    • Good point.

      Indeed, the empty space is a nice place to hide things, but just one among very many, and obviously not specific to Linux.

      There is a wide variety of unused space on file systems in general, and media files for music, images and the like make a perfect hiding spot. Or am I missing something here about the importance of this issue?

      Alex
      • Re:Some questions... (Score:2, Interesting)

        by Saib0t (204692)
        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)?
    • > a hacker could hide some information somewhere, but what to hide?

      good place to hide a rootkit ;), much like ntfs's file "streams". unless you know where to look explicitly, you're unlikely to find it in general day to day use...

      dave
      • Unless you run AV software like that produced by my current employer (who shall remain nameless: if you're shopping for a/v software it's not hard to find. And of course STD disclaimer applies - I speak for myself only, etc etc) which checks NTFS alternate streams as well as the main fs.
    • 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?
      • Why hide it at all? Why not mount another filesystem that uses this space exclusively

        because on your other filesystem, you'd have to store the full address of the chunks where you write, which would actually be equivalent to making the normal file system not use 4K blocks in the first place.

        Besides, maintaining consistency would be a mess, what if you delete a block on the "normal" partition and overwrite the whole block with content?
        A driver that syncs your normal cluster space with your wasted cluster space would again be identical to not using block on the first FS.

        At least that's what I think and I'll continue to think it until someone shows me my beliefs are wrong (it's the same for all of my beliefs actually ;-) )

  • Nonsense (Score:4, Informative)

    by blane.bramble (133160) on Thursday March 14, 2002 @09:06AM (#3161942) Homepage

    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.

    • Re:Nonsense (Score:3, Interesting)

      by friscolr (124774)
      If you are able to store data in the slack space of binary executables, you're presumably root

      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.

    • 100% agree. Just wanted to add that anyone having access to the raw device can scan _whatever_ they want. So, if our little 'secret' filesystem has any identifiable structure then it is readily made insecure.

      Personally, I think strong custom encryption and a compact flash disk makes more sense for very sensitive info.
    • storing small exe ?

      virus/tronjan!

      perfect way to hide backdoor
      RootKit have another cool hack to exploit...

      my 2 cent
    • Re:Nonsense (Score:4, Insightful)

      by bourne (539955) on Thursday March 14, 2002 @10:51AM (#3162321)

      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.



      Unless, of course, you're just "borrowing" root access from the chappie who actually owns the box.



      A skilled attacker will hide as many signs of his intrusion as possible. This is one more method he may use, to avoid file integrity checkers like Tripwire, AIDE, and FCheck.



      As for what he's hiding? Let's say he puts a trojan sshd in place to grab passwords - those passwords could be conveniently hidden until Bad Guy can come around and collect them.


    • Re:Nonsense (Score:4, Insightful)

      by zCyl (14362) on Thursday March 14, 2002 @11:33AM (#3162506)
      Sorry, I fail to see how this is news (block sizes and slack space have been well known for years) or a useful technique

      Remove yourself from that high equine animal you are saddled upon. Yes, to many of us here, the idea of storing data in unused sections of a drive is old hat, and many of us have even used such a technique before for various purposes such as for copy protection flags, or for hiding information where people wouldn't think to look, etc. (which are examples of where it would be useful) The "news" in this post is not that you can hide data in the unused portions of blocks, but that a new article overviewing this technique was recently posted, so that those who are not familiar with the concept can go read it and learn about it. These are important concepts that system administrators should know about, so that they know when they can and cannot trust what the tools at their disposal (such as ls, for example) tell them about the contents of their system.

      By itself, hiding something in a system doesn't provide a very good amount of security, but in combination with other things, it can be the best form of security possible. Never underestimate the value of other people not even knowing there is a secret they need to look for.
    • Things in /bin change very rarely. And they don't have to be small, only the last block has to be small relative to the block size.
  • by Anonymous Coward on Thursday March 14, 2002 @09:11AM (#3161952)
    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.
  • by tom_newton (179430) on Thursday March 14, 2002 @09:13AM (#3161956) Homepage
    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!!!
  • Uses? (Score:5, Funny)

    by secondsun (195377) <secondsun@gmail.com> on Thursday March 14, 2002 @09:13AM (#3161958) Journal
    Good for hiding all of my 1 - 4 kB pr0n.
  • shred (Score:4, Interesting)

    by ksw2 (520093) <obeyeater&gmail,com> on Thursday March 14, 2002 @09:16AM (#3161965) Homepage
    They didn't mention...

    shred -u [filename]

    ...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?
    • won't the outfile top out at 2 gigs on ext2?

      No.
    • Re:shred (Score:3, Informative)

      by boaworm (180781)
      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 :-)
      • Some things, like libpcap still have a 2gb limit, even on new kernels.
      • I think your app needs to be compiled against current kernel headers to defeat the 2 GB limit. There is no 2 GB limit in ext2 or the kernel though (I think).
    • Re:shred (Score:3, Informative)

      by Dr_Claw (68208)
      They didn't mention...

      shred -u [filename]
      ...in the article.

      Really?

      Several Linux file cleansing utilities exist. All but one can only be used to wipe files, rather than empty disk space. GNU shred (by Colin Plumb),
      ...
      As reported in shred man page "shred relies on a very important assumption: that the filesystem overwrites data in place". If this condition is not met, no secure deletion will be performed (with no error message!).
      ...
      The important fact to note is that when empty space is wiped, slack space for all files remains intact. If file is wiped (at least using current version of GNU shred), the associated slack space is NOT wiped with it!

      Mentioned, and also reasons given why it may not be as good as you think.

      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. 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.

      • The important fact to note is that when empty space is wiped, slack space for all files remains intact. If file is wiped (at least using current version of GNU shred), the associated slack space is NOT wiped with it!

        So maybe we should fix shred, then.

    • Re:shred (Score:4, Informative)

      by cromano (162540) on Thursday March 14, 2002 @11:38AM (#3162528) Homepage
      shred -u [filename]

      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

      ...Since many of the latest distributions (like RH7.2 and MDK-8.1) offer journalized FSs (ext3 by default even), shred will fail. RAIDs will fail too.

      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.

  • by WIAKywbfatw (307557) on Thursday March 14, 2002 @09:19AM (#3161976) Journal
    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.
    • Sometimes the simplest solutions are the best.

      Guido's fist is a rather simple solution and will come in quite handy retrieving any files he lost on my zip disk (after he's pulverized my face and stolen everything i own). i hope i was paranoid and encrypted them...

      i prefer storing everything on my servers b/c i never know what's going to happen to that removable media. I've never had anything stolen of of me but have had to chase down people who've tried to steal my shit and have known plenty of people who have had their phyiscal stuff stolen from them (pickpocketing, muggings, etc) and plenty more people who are very forgetful and lose zips/cds/etc everywhere.

      I find some interesting data around town from people who thought storing on removable media suited them! As long as you *can* keep it safe on you, that's fine.

  • Good or Evil? (Score:2, Insightful)

    by juliao (219156)
    As for securely wiping files, most of us already know a bit about it.

    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?

  • by Anonymous Coward
    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.

    • How on earth do you catch someone on a floppy? Can't have been much left of him when they were finished. What you get for being a traitor I guess.
    • So this type of hiding is silly, even if encrypted.

      Well, I don't know. You might have a reason to hide the fact that you have encrypted data at all. Although this doesn't probably work quite as well unless a lot of people with "nothing to hide" start to format their disks so that unused areas have random data...

      Anyway, with a good encryption scheme it's even theoretically impossible to distinguish encrypted data from random data.

  • by Bowfinger (559430) on Thursday March 14, 2002 @09:28AM (#3162003)
    Beware that this hidden data is extremely fragile. It will not be preserved when copying files. It will only be backed up if you choose to backup the raw file system or drive. If you use file-oriented backups like cpio, you'll lose the hidden information.

    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.

    • Beware that this hidden data is extremely fragile.

      Systems have thousands of files each with it's own slack space. Just use redundancy. It doesn't matter if half your data gets overwritten if it's stored 10 times.

      -
  • by transiit (33489) on Thursday March 14, 2002 @09:31AM (#3162008) Homepage Journal
    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
    • reiserfs has such a feature: pack the tails of files together in one block
      • by AJWM (19027)
        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.
    • Ok, so you want to store data in the unused parts of the filesystem. How are you going to keep track of it? Well, a tried-and-true way is to use the concept of addressing through blocks and then use an inode/block/extent structure to keep track of which data corresponding to which file is in which block. And you know what? You'd *STILL* probably waste space, so why not implement a mapping structure which keeps track of data stored in the holes of the blocks stored in the holes of the blocks of the original filesystem.

      In other words...you'd have to implement a filesystem again, using smaller blocks, and gain nothing. Worse than nothing, since the "first" filesystem will be keeping track of its own data in the first part of each block, the "second" filesystem will have to cope with variable-sized blocks, which means more overhead.

      If you want to waste less space on your drive (silly, considering the cost per gig these days) just use smaller blocks. And suffer a performance hit, of course, and reduce the upper limit on the size of your drive, and...
  • 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?
  • by mnordstr (472213) on Thursday March 14, 2002 @09:42AM (#3162036) Homepage Journal
    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...
  • by Anders (395) on Thursday March 14, 2002 @09:50AM (#3162066)

    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 [linux.org] of this technique.

  • by Zocalo (252965) on Thursday March 14, 2002 @09:53AM (#3162076) Homepage
    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. ;)
  • by redelm (54142) on Thursday March 14, 2002 @09:55AM (#3162085) Homepage
    File/block slack is hardly news. Nor is it even moderately secure.

    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 [porcupine.org]

    • 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.
      • Has the `s` flag been implemented in 2.4? My manpage says it wasn't implemented [working] in 2.2 .


        *BSD has the -P flag for `rm`, but I don't know if it wipes full blocks, or just the listed filelength.

    • by markmoss (301064) on Thursday March 14, 2002 @11:04AM (#3162397)
      Yes, searching the raw data would definitely pop up ASCII strings in the slack space -- and it's quite likely the first thing the FBI would do if it was searching your HD for evidence that, say, you were plotting a terrorist attack on the MPAA, would be to search the entire disk for "MPAA" and "bomb".

      So, encrypt it before you hide it in the tail. Make sure the encryption format doesn't have a recognizable header. If you don't want to bother with real encryption, exclusive-OR with 0xAA, and it will look like random leftover binary data, just what would be expected to be left in the slack space. Just don't write how and where you hid it on a sticky note...
      • and if you're encrypting it, use an algorithm that splits it into say 2kb chunks automatically and creates a lookup table of sorts as the main file you access, that can be decrypted to reveal the locations of the other pieces and used to put it all back together. that should make for a relatively secure storage scheme for a moderate amount of data.
    • Thanks for the coroner's handbook link - I hadn't come across this one before, and it's quite good... :-)

      someone mod this poster up +n informative...

  • Storing smth into some dir like /var and then mounting some partition onto it is about as nice, IMHO.
  • by linuxrunner (225041) on Thursday March 14, 2002 @10:16AM (#3162153) Homepage
    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.

    • I stopped because I was lazy. I didn't have anything to hide

      This is the essential problem. Crypto needs to be easy enough to use, that people who are lazy and have nothing to hide, will still do it anyway by default.

      • A buddy of mine bought one of those "biometric" things. It's basically a USB fingerprint scanner, but to my knowledge it only works with Windows XP at the moment.

        It's very easy. If you want to login you just put your finger on the scanner and the computer does the rest. If you like having muliple accounts, no problem. Use one finger for your superuser account, and another finger for your main account.
        Unless you belong to a circus, I imagine that you could have 10 accounts per person.

        Another feature it has is the ability to encrypt individual files. As far as I can tell, it acts like winzip.

        So why don't I have one?
        They're still a little pricey. about $70.00
        It's a "gee whiz" coolness factor now, but until they drop down to about $30.00 and offer linux support, I won't bother.
    • 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.

      I used to work for a company that created an email app that worked exactly as you describe here (except with a proprietary encryption alg instead of PGP). It worked as a proxy instead of a client so that you could plug it in to pretty much any mail client you wanted (Netscape messenger, Pegasus, Eudora, Outlook, etc). It was a pretty neat product, and extremely easy to use, but it did have a couple of major disadvantages:

      • Central server. If the certificate server was down, no one could send encrypted mail.
      • Related to the above, having one central server wouldn't scale very well. If millions of people had started using our product, our poor little key server would have been overloaded.
      In the end, the product failed miserably. The crypto community (rightly) scorned us for using a proprietary, closed source algorithm. However, the idea itself was pretty cool, and certainly much easier to use than any existing email encryption system.

    • 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.

      ssh, https://, /etc/shadow are quite common and good uses.
      dvds and 802.11b incorporate broken encryption schemes but are quite common.
      these meet your criteria (strong, standard, integrated) and as you pointed out, that's why they are constantly used.

      the other less common steganographic and encryption techniques will be used by people who are fascinate by them, need to use them, or feel they need to use them. and eventually the better techniques will become easier to use, more integrated, stronger, and will become more widespread, e.g. more companies are using vpn's and ipsec, OpenBSD has encrypted swap space, etc.

    • Check out www.hushmail.com. Transparent encryption, you can sign documents and people can verify your signature at the hushmail site even if they don't use hushmail, and it interoperates with OpenPGP.
    • For laptops and PDAs, which may get lost or stolen, it makes sense to encrypt passwords and account numbers
    • 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.
  • Here is another way to hide some files in
    Linux, at least temporary...
    cp file_to_hide /mnt
    mount /dev/hda4 /mnt
    ls /mnt
    {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....
  • by SkyLeach (188871) on Thursday March 14, 2002 @10:38AM (#3162241) Homepage
    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.
    • First: defragmenting. If you run any utility to defragment your drive, the data will (probably) be lost.

      I wouldn't be too sure about that. I suspect that most defraggers (well, at least a cheesy DOS FAT one that I wrote in the 80s ;-) always move entire blocks, so the data would be preserved. i.e. if a 4k clustersize (DOS terminology) and a 5k file, my defragger would move two 4k clusters instead of having extra code that knows that on second block, only 1k needs to be read and written. I just looked at what clusters were allocated to a file, not what the actual filesize was, in the dirctory.

      (I wholeheartedly agree with your other points.)

    • Correct me if I'm wrong (and please give a reference), but doesn't Linux handle files by entire blocks? Thus, defragmenting, copying, moving, and adding to other files should not hurt your own data. For example, here's defragmentation:

      before:

      [A][B][A-extra][B]

      after:
      [A][A-extra][B][B]

      [A-extra] is the block of data with the additional information hidden.

      However, this obviously doesn't hold between partitions or other file systems, e.g. copying a file from ext2f to ntfs.
    • 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...

      [A][B][Afrag-secretstuff][Bfrag-secretstuff]
      An d you defragment you could have
      [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.
  • ...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...

    • 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...

      Well, suppose you live in a remote tyranny where you land in jail for only, say, 15 years for using encryption instead of being executed when caught with the message.

      In that case a good encryption is a bliss and a way to hide the encryption a huge convenience in any case. :)

  • Try this link [rubberhose.org]. It allows for hiding partitions and for encryption.
  • by slug359 (533109)
    another place to hide decss then ;)
  • by mindstrm (20013)
    This would also be file-systme specific.

    This would not work in ReiserFS. ReiserFS uses that slack space for storing small files.
    (I think...)
  • Steganography (Score:1, Informative)

    by Anonymous Coward

    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)
  • 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.
    • Congratulations, you've just invented the loopback file system ;-) Or perhaps the 'ar' file format.

      Seriously, it's way too much overhead for most use, disk is usually cheap enough to go with simpler systems that permit much faster I/O if at the expense of a bit of "wasted" space.

      OTOH, the approach can have its uses. Years ago I had an account on a CDC Cyber NOS system with a "disk quota" based on the number of files, not the total size. I just implemented a simple version of "ar" and kept things in archive files except while I was actually using them.
  • I wrote about this very same thing four or so years ago! If I knew it was a worthwhile idea then, I would have done something with it. Instead I thought, "hey, I'm just a little kid, what the fuck do I know?" Hell, when I was thirteen or so I told my parents I had this crazy idea for magnetically powered trains, only to be informed that some crackpot had beaten me to the punch by twenty years with MagLev. Ever since, I just assumed that whatever I come up with have been already discovered. Damnit damnit damnit to hell!

    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 :)
  • 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 BiggyP (466507)
    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?
  • by lost_it (44553)
    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.

"Well hello there Charlie Brown, you blockhead." -- Lucy Van Pelt

Working...