New Tool Hides Data In Plain Sight On HDDs 136
Trailrunner7 writes "A group of researchers has developed a new application that can hide sensitive data on a hard drive without encrypting it or leaving any obvious signs that the data is present. The new steganography system relies on the old principle of hiding valuables in plain sight. Developed by a group of academic researchers in the US and Pakistan, the system can be used to embed secret data in existing structures on a given HDD by taking advantage of the way file systems are designed and implemented. The software does this by breaking a file to be hidden into a number of fragments and placing the individual pieces in clusters scattered around the hard drive."
Re: (Score:2)
US and Pakistan.
Together. CIA and ISI?
Here's your backdoor Trojan from hell.
Re: (Score:2)
Do you think there is an "intelligence" organisation in the world, that is no co-opted and part of the secret government operations?
Re: (Score:2)
Re: (Score:3)
fuck religious people in general
Can I start with the cute ones, please?
Re: (Score:2)
Start with the girls of the IDF [damncoolpictures.com] and work your way through the middle east from there.
Re: (Score:2)
Re:Steganography? (Score:5, Insightful)
What sort of thought process leads to a stupid comment like this? Somebody creates a new plastic: "Congratulations, you've reinvented polymerization!" Somebody makes a better and faster computer chip: "Congratulations, you've reinvented computing!"
Everything is built on something else. For most of us, that's obvious. I guess not for some. For you, new ideas must leap fully formed from a different universe accompanied by a huge explosion in order to be interesting, I guess.
Re: (Score:2)
I can certainly see how his comment could come off as sarcastic and acerbic.
However, he does have a point. There is nothing new about the approach. They even claim new, but from reading the article, this is not new.
I see no reason to make a comparison between new and old stenographic methods. At most splitting the chunks against multiple files is a different implementation of the exact same idea. Nothing Earth shattering, and I can see a couple of issues already.
If it is split across multiple files and
Re: (Score:2)
Except this doesn't seem "better" since it's just one fsck away from obliterating everything.
Re: (Score:3)
Re: (Score:2)
Unfortunately it won't remove your comment.
Scandisk hasn't been used since.... February 2000.
Snark aside, yea, this does sound "dangerous" - it might hide it in plain sight, but it also fixes it in a very fragile state.
Re: (Score:1)
The software does this by breaking a file to be hidden into a number of fragments and placing the individual pieces in clusters scattered around the hard drive.
Have they re-invented FAT file system?
Sounds familiar (Score:1)
NTFS has been doing that for years.
Re:Sounds familiar (Score:5, Funny)
yeah, but unlike NTFS, this is supposed to allow you to read that data in the future
20 MB in 160 GB ?! (Score:1)
Wow, isn't that useful.
Re:20 MB in 160 GB ?! (Score:5, Insightful)
I thought the same thing at first, but in all fairness 20 MB of critical data can go a long way.
Hiding stuff doesn't have to mean hiding video. A .pdf file can be all you want to hide in some cases, and you might want to do so without attracting attention with cryptography.
Let's just say this could have its uses.
Especially since I don't know of another steganography FS that is being maintained ? (RubberhoseFS was a nice idea)
Re: (Score:1)
Re: (Score:1)
There are a million ways to do this... You can hide data in photo's.. Videos... MP3's... just about any innocent file can have a hidden payload in it if you know what to look for.. The big key is that you just can't have a hunt/find/decrypt executable on that pc..
Re: (Score:1)
This is probably key really - at the end of the day it can't "look" like you've hidden something, so you'd be just as well off using a hidden partition with something like Truecrypt, since you'll have to keep the decoding program on a portable key of some kind.
Re:20 MB in 160 GB ?! (Score:4, Informative)
Yes. He did actually have a productive life as a white-hat hacker (he was one of the first famous Australian hackers; he was arrested and given a slap on the wrist at age 20 for breaking into telecommunications networks) and FOSS developer before becoming a media celebrity.
Assange has actually contributed many small interesting projects; IIRC he wrote nntpcache & surfraw, as well as rubberhose ...
Re: (Score:3)
Re:20 MB in 160 GB ?! (Score:4, Interesting)
Wow, isn't that useful.
It rather depends on what is in that 20MB. How many diplomatic cables would fit into 20MB? Or 200MB, since 2TB drives are commodities now.
Re:20 MB in 160 GB ?! (Score:4, Informative)
Re:20 MB in 160 GB ?! (Score:4, Funny)
Wow. :)
You took criticism constructively and then admitted you were wrong and moved on with your life?
You do not belong here. Move along.
Re: (Score:1)
Re: (Score:2)
What type of text files do you write that take up 20 MB?
Re: (Score:2)
What type of text files do you write that take up 20 MB?
Directory listing of his porn stash.
Re: (Score:2, Funny)
Re: (Score:2)
It could be the software and key to turn a different block of random data into actual data.
Re: (Score:1)
Re: (Score:2)
As you've later agreed ... 20MB is actually reasonably useful. The problem with this techniques is that you're going to need in the order of 160GB of non-infringing data to hide the 20MB in. And if you're wanting to do this routinely, you're going to need a lot more, otherwise it's going to start to look suspicious. Lots of Jason Bourne lookalikes crossing your borders, all carrying laptops with the same collection of movies on them ... peculiar. Attention-attracting.
Actually ... a r
bollocks (Score:3)
Just because you're encoding the information in the fragmentation patterns of the underlying filesystem it doesn't mean you're not engaging in encryption. The encryption is the key input to the algorithm to identify how to turn that apparently random pattern back into plaintext - otherwise we'd be able to say, "OK, let's check he's not using this method," without any secrets.
tl;dr Steganography is useless without encryption.
Re: (Score:3)
The point of Steganography is not to make it hard to find the information. It's point is to avoid even being looked for. That's what the whole "hide in plain sight" bit means, you know.
Re: (Score:3)
That reasoning has always been specious. It's trivial to compile a list of published steganographic methods and engineer some check for them. The method must involve some form of key and encryption to make the check unlikely to succeed.
Re: (Score:2)
That reasoning has always been specious. It's trivial to compile a list of published steganographic methods and engineer some check for them. The method must involve some form of key and encryption to make the check unlikely to succeed.
The way the check might fail is by finding random weirdness. Right off the top of my head, a graph of file length vs frags is probably going to be distorted by this storage mechanism... Also a graph of filesystem age or filesystem size vs frag level is probably going to show this mechanism as an outlier.
Since fragmentation is not random, hiding anything using it is going to be very tricky... Plenty of room for honest error and/or snake oil and/or back doors.
Re: (Score:2)
Encryption is done beforehand for three reasons:
1: The hidden data is essentially static, with no discernible patterns.
2: If the stegoed data is located, it cannot be used as plain text.
3: Plausible deniability. If a stego detector finds random numbers, that is one thing, versus plaintext as another.
Don't forget -- a lot of encrypted files have a pattern to them, such as PGP, ZIP, etc. One will need to find a utility that does to files what TrueCrypt does to partitions and has a complete unreadable str
Re: (Score:2)
i think the real life analogue of this software is a pair of paper scissors and hiding fragments in unmarked folders. even if you know what the computer is about to do, finding all the 'misplaced' folders is something likely to take several hours per incident. if this technique was used to protect a whole lot of folders it might not be reversible at any level.
Re:bollocks: Not even hidden! (Score:2)
Bollocks indeed:
a) Even with small amounts of hidden data (20 MB in 160 GB was quoted), you will still end up with an _extremely_ fragmented file system:
Each hidden bit requires either a sequential or fragmented block placement, which means that 20 MB needs 160 Mbit or 160 million frag/nofrag chaining decisions.
This works out to one such block per kB of disk space, but since the FAT32 filesystem normally uses 4 KB (or larger) clusters, you would have to decrease the block size to either 1 KB or 512 bytes (t
All sorts of uses (Score:2)
Re: (Score:2)
Except that any router passing your packets might choose to re-fragment or recombine your packets, destroying your message.
Re: (Score:2)
in addition to MacTenchi's comment.. out of order fragments will get dropped by any good router or ips so you can't go that way and duplicate fragments are discarded by every decent firewall. now udp packets echo'd from client to random client until they need to be re-assembled is another story. the greater the ratio of client to packets you have the greater the difficulty for someone to re assemble it.
Purely academic (Score:4, Interesting)
You get very little data to store, but this looks like it will be secure and, for a change, really hard or impossible to detect.
Of course a dead giveaway is the access software needed, so this works only for hiding data that the holder cannot access. That and the low data volume (20MB in 160GB are given as example) limits the usefulness to a nice but very academic idea.
Re: (Score:2)
> Of course a dead giveaway is the access software needed, so this works
> only for hiding data that the holder cannot access.
Lots of use cases for that. You encode a hard drive at your embassy and send it back with an unsuspecting minion. When they get home your people there do a 'routine check' on the laptop and extract the too hot for ordinary channels memo, again with the user totally unsuspecting that he was a courier.
Human rights group in hellhole country wants to get a release out? Find some
Re: (Score:2)
Completely bogus.
Embassies have diplomatic couriers that are explicitly allowed to carry encrypted data and make regular travels. Embassies also typically have very secure encrypted communications.
"Human rights group.": The tourist will likely be an informer or watched and needs to be extremely careful not to be entrapped. This scenario is completely unrealistic. Also, if the "Human rights group" has the software or even the paper, then they already have channels that actually work. If the tourist's laptop
Re: (Score:2)
How would the change in the fragmentation pattern be glaringly obvious? I don't think they're going to create a complete image of every hard driver entering or leaving the country. Or the carrier might just bring a drive bought inside the country, etc etc.
I agree that it's largely artificial, though; with capacities in the sub-gigabyte range, transmitting the data via the internet or a cellular link is going to be much easier than physically carrying around drives. Most places that have tourists going in al
Re: (Score:2)
The change is of course only obvious if they are looking for it. But they do not need the whole disk, just the FAT and that is far, far smaller and there such a change is glaringly obvious.
Anyways, I doubt anybody is really worried about preventing a few megabytes from being smuggled. There are a lot of ways to do that and the threat represented by this is rather small.
Re: (Score:1)
Actually, the real problem is that normal usage of the drive would typically change where some files are stored and how they are fragmented. If you used it on your main system drive (i.e., the filesystem whereupon the OS is installed), merely booting up your operating system would very likely make some of your hidden data irretrievable.
(There's also the small matter of FAT32 no longer being terribly useful on hard drives, but in principle the method would be applicable to other filesystems, though the impl
Re: (Score:2)
Re: (Score:2)
You get very little data to store, but this looks like it will be secure and, for a change, really hard or impossible to detect.
Of course a dead giveaway is the access software needed, so this works only for hiding data that the holder cannot access. That and the low data volume (20MB in 160GB are given as example) limits the usefulness to a nice but very academic idea.
I agree... and this made me think: a good method I saw for steganography uses forums and blogs to embed the data in public site inside other documents.
However, why not do something like store the data in a Fake Antivirus program, or even web cookies forged for various sites? Both give you true plausible deniability, as you can deny you ever wanted the data on your machine in the first place... and with the second, you can make the data expire, and even have a remote website that'll automatically reconstitu
Re: (Score:1)
2nd thought: you can even hide the data on OTHER people's computers using this method, assuming you have access to a few domain names and web servers. You could also initiate a remote expiry/rewrite of key cookies, so the data can be remotely revoked, assuming the person visits somewhere that'll reset the cookie.
You could even overwrite common cookies (store the data in ad cookies, and then usually run ad blocking software). To erase, you disable your ad blocking software, and the ads wipe the data for yo
Re: (Score:2)
If accessing that java app is not suspicious, then store your data in it. Otherwise you are handing probable cause right to the other side. Also, what makes you think the app, if not under your control, is trustworthy? Amateur.
Plausible deniability (Score:5, Insightful)
Doesn't TrueCrypt's plausible deniability get the same effect without depending on a loose file system hack?
Re: (Score:3)
That might be part of it. However, the main aspect of plausible deniability for TrueCrypt is that the blob of encrypted data may hold two volumes, each accessed by a different passphrase. Then, I can have the software installed on my computer, and it is easy to see that I am probably using the software for hiding data. But it is impossible to tell whether I am only using one encrypted volume, or two. I can deny that I have created a passphrase for the second one, and there is no way to tell how much of
Re: (Score:1)
The guys who are only using one will not survive.
So there's no incentive for the latter set to use it at all.
*Everything* about using TrueCrypt says "keep beating me with the rubber hose".
Re: (Score:1)
Re: (Score:2)
Deniability gets less and less plausible every time you get hit with a $5 wrench [xkcd.com].
Re: (Score:2)
Deniability gets less and less plausible every time you get hit with a $5 wrench [xkcd.com].
No, the deniability gets more and more plausible every time you get hit with the wrench and still just keep begging for mercy. It's just that it gets harder and harder too with every impact. But I'm sure that's what you actually meant, so this is just nitpicking.
Then the question becomes: Will they keep hitting you with the wrench until you die just in case, even if they start to believe you're telling the truth?
And then: If you're still alive when they're through with using the wrench, are they going to bu
Re: (Score:2)
You've conflated plausible deniability with flat refusal. The whole point of PLAUSIBLE deniability is that people will most likely BELIEVE you when you say you have nothing to hide. In other words, you're hoping they won't see a reason to use the wrench.
But if the questioners think you've got a truecrypt volume, they'll just keep on destroying parts of you body until either you give them multiple passwords that work and give them the data they're looking for, or you're dead (and buried in an unmarked grave). Using truecrypt is itself suspicious, and anyone dumb enough to think that a technical solution will get you out of this is totally missing what would happen in reality. Or are you one of these idiots that thinks their data is more important than their
Thar be dragons! (Score:3)
Moreover, the channel provides two-fold plausible deniability so that an investigator without the key cannot prove the presence of hidden information,"
So what encryption scheme are they using before storing the data? I didn't find it in the article. Hopefully not something as dumb as XOR using the "key" or using the key as a step size when encoding or something like that.
Unless they encrypt the data before encoding the fragmentation,a glance at the frag pattern will show a distinct and obvious pattern based on the stored data. If the data is UTF-8 text using non-ascii glyphs, its gonna be pretty obvious when every other byte is a UTF-8 shift header thingy. If its plain ole ascii text its going to be pretty obvious the 8th bit is almost always 0. If the data is semi-packetized like video frames, its gonna be pretty obvious. If the data is stored emails with semi-known plaintext headers, its gonna be pretty obvious. Theres only so many ways to encode 1 and 0 into the frag pattern so playing games like encoding it backwards isn't going to help.
I'm guessing its not going to be plausibly deniable at all... The other part of the deniability problem is how to deny the presence of the decryption tools in the filesystem, or in unused blocks of the FS. Hmm. You could delete the tools, and then defrag the hard drive to sorta-wipe it. Oh wait...
How? (Score:2)
Re: (Score:2)
I doubt it will work (Score:4, Funny)
Re: (Score:2)
come on... Maybe Everyone is Exceptionally stupid, Truly... At least Try to Make it less Obvious. Each Secret system has it's own way of passing data... I can think of 8 off the top of my head, but none are that ridiculously easy to spot. Perhaps More effort is needed to create a good example? even this one is pathetic, but it's more realistic than what you are showing, and more accurately to the point (somewhat).
working implementation: (Score:2)
the data isn't even written to sectors marked empty, the data is written to empty air!
http://blog.jitbit.com/2011/04/chinese-magic-drive.html [jitbit.com]
Ephemeral but effective (Score:2)
Re:Intimately Involved (Score:2)
Steganographically encode info in trolls!
Did you exactly document the shades of red in Goatse? How do you know those aren't orange-shifted to encode data?
Talk about in plain sight! Yikes!
Only 20MB (Score:2)
It's easier to put your sensitive data on a micro SD card, and hide that somewhere.
Re: (Score:1)
It's easier to put your sensitive data on a micro SD card, and hide that somewhere.
I once setup a computer on an SD card, but also setup a partition to be used as memory for my digital camera. In this way I could put the memory into my SD camera and the camera would operate in all normal ways if searched. But I could also remove the memory from my camera and put it into a computer. Furthermore, I didn't just put data on the SD card. I put the entire operating system on it. So I could essentially travel anywhere with only my camera in hand and when I arrive at my destination, I could put t
Re: (Score:2)
Would it make more sense to hide the Hard Drive? (Score:2)
For example, place the hard drive in the shell of a real but non functional printer. If it doesn't need to be connected, alternately hollow out a book and hide it in there, etc.
Re: (Score:2)
Or, place it inside a fully functional printer, directly wired to the USB line, hiding in the back of an unused paper tray slot of a multi-slot computer... then, with the printer connected, the Hard Drive can also be connected (or easily disconnected). Add a switch internally if you're paranoid, or set the power such that turning off the printer turns on the hard drive and vice versa.
Re: (Score:1)
This approach fails badly, though: if they do any kind of serious physical search, the gig is up.
Re: (Score:2)
I think we can rely on the police to be lazy in general, and likely the search warrant would be for computer equipment. If you keep your naughty data in a spare small PC in a dusty box in the attic which you access wirelessly, and don't give them any special reason to think you have one up there, they could easily miss it.
If you have an old style rear projection TV you can easily fit an entire PC inside it, and transmit data via the coax cable.
At last a use for the cloud: register under a fake account name
Re: (Score:2)
I think we can rely on the police to be lazy in general, and likely the search warrant would be for computer equipment. If you keep your naughty data in a spare small PC in a dusty box in the attic which you access wirelessly, and don't give them any special reason to think you have one up there, they could easily miss it.
If they seized your computer and did forensics on it, they would see you accessing some wifi box "dirtydatamachine". They walk up to your premise with a wifi scanner, and wonder why there there is an AP without and SSID being broadcast, that happens to respond with "dirtydatamachine".
The only thing that will really work with this is to encrypt the drive with truecrypt and only give up the decoy password, at which point there is no reason to bother with the WiFi box.
Security 101 (Score:1)
Re: (Score:2)
Simon & Garfunkel fans sing with me: (Score:1)
"His bowtie is really a camera..."
Re: (Score:2)
Have you heard the Yes version? Great rendition. :)
Doesn't look undetectable (Score:1)
a cluster is chained with a consecutive cluster if the bit encountered in the message is similar to the previous bit and a cluster is chained with a non-consecutive cluster if the message bit is different from the previous message bit.
Then, even if the data is encrypted with an unknown key, we can expect almost exactly half the clusters to be chained to consecutive ones, and they are distributed a random fashion. By counting the length of consecutive cluster blocks, we should see that 1/2 of them have 1 cluster, 1/4 have 2 clusters, 1/8 have 3 clusters and so on, and they are evenly distributed along the drive.
It's very unlikely that such a distribution would appear spontaneously on a disk by just using it normally, so
Re: (Score:3)
They hide data by splitting it into small pieces, writing it to disk in random order and marking that sector empty. Sounds like a disaster to me, all you need to do is to use the disk, just defrag it and your hidden data is gone.
Yeah that was my thought too. Although you could consider defrag to be a secure destruct mechanism... ;)
Re: (Score:3)
Yeah that was my thought too. Although you could consider defrag to be a secure destruct mechanism... ;)
That's the beauty of this sort of thing. Not for storing your routine Porn^HDocuments, but for really sensitive stuff that can be destroyed quickly and 'innocently'.
"Well, sir, the computer was running a bit slow, so I defragged it yesterday. Is that a problem?"
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes, but it would require the user to know to actually defrag the hard drive.
Also, that's even better than you might think, makes obliterating the data even easier if you suspect it'll be found, or as a way to ensure it's destroyed. As long as you're not writing to the volatile part of the HD, you'll be fine for normal operation.
Re: (Score:2)
Correct me if I'm wrong (I often am about Windows) but aren't there several types of sectors reserved for system uses and not touched by defrag? I know I've seen the defrag graphic when fixing some friends borked up PC and seen something like this.
All that would have to be done is to mark the hidden data as system sectors not to be messed with by defrag. Of course, knowing this, it would make a search for said data much easier.
Re:Defrag and die (Score:4, Informative)
They hide data by splitting it into small pieces, writing it to disk in random order and marking that sector empty. Sounds like a disaster to me, all you need to do is to use the disk, just defrag it and your hidden data is gone.
This is called fragility, and depending on context, is a desired feature.
Re:Defrag and don't read the article (Score:4, Informative)
Know how I know you did not read the article? This method is rearranging existing data so the FAT itself holds the data. This is not including the data at the end of a cluster, or putting it in empty clusters.
If you want to encode a 0, put the first block at an even numbered sector. If you want to encode a 1, put it at an odd numbered sector. There are other ways to do it, but that's just one example.
There is no data on the drive itself to analyze, it's all in the fragmentation of the FAT.
Re: (Score:2)
Re:Defrag and die (Score:5, Informative)
No they do not. You just totally invented that.
I know this is Slashdot and not reading TFA is a rite of passage, but at least don't try to "inform" when you have no idea about something.
None of the secret data is written to disk at all. As the researchers explain clearly (they're quoted in TFA), the data is encoded in the pattern of cluster allocations used for storing the non-hidden files already present on the drive. They even describe the RLE-based algorithm used for cluster-chain encoding. The size of existing files remains the same, the amount of disk space used and unused in the filestore remains the same, and the contents of all the files remain the same after this process.
So your explanation couldn't be more wrong. And the moderators who gave you a +5 Informative failed to understand the method as well.
Re: (Score:2)
It seems like TFA's author might have made the same mistake, or their wording is extremely poor. They say
The software does this by breaking a file to be hidden into a number of fragments and placing the individual pieces in clusters scattered around the hard drive. [...] The method that Khan and his colleagues developed avoids this problem by hiding small pieces of a sensitive file various random places on a hard drive. [...] as the sensitive files are not actually hidden but rather dispersed in pieces.
The file is broken into bits and placed in the arrangement of clusters--these bits are not literally written to the hard drive.
They're hiding in the block-lists, not empty space (Score:2)
They reorder full blocks to encode data in the orderings within the list of blocks for a given file. That's why they "do not require storage of any additional information on the filesystem" and why "a capacity of up to 24 bits/cluster can be achieved on a half-empty disk".
If they wrote to additional blocks they (1) would be adding additional data to the filesystem, (2) would have no limit to the data that could be hidden and (3) would lose it as soon as one started writing additional information to the di