Hiding Secrets With Steganography On FreeBSD 424
BSD Forums writes "Bad guys in the movies all keep their wall safes hidden behind paintings. Is there a metaphor in there for your sensitive files? OnLamp's Dru Lavigne explores steganography, or hiding secret messages in images or sounds, with the outguess and steghide utilities on FreeBSD."
Is this limited to FreeBSD only? (Score:4, Interesting)
Hiding pr0n? (Score:5, Interesting)
Of course being an adult now it's not as required, but I suppose it might be able to hide offensive pr0n images inside more innocent ones - so that anyone looking finds pretty mild things and stops there, without being able to find things that would get you looked at oddly in church
Good stuff, but... (Score:5, Interesting)
How come ... (Score:5, Interesting)
No... (Score:5, Interesting)
No, bad guys in movies walk into the Rich Dude's house, immediately realize where the safe is, pull the painting away and get whatever's in the safe. How many times have we said that security through obscurity isn't security, and now we're all clamoring about obscuring data to make it safer.
Data-wise, it seems like you'd need to be hiding a relatively small amount of data. Otherwise, you're like an elephant trying to blend in at an LA cocktail party.
Really cool demo... (Score:5, Interesting)
Bad Guys? (Score:5, Interesting)
Every citizen of these modern times is a criminal, and because everyone is a criminal, everyone should use steganography. Most criminals are not BAD GUYS, but instead, good loving parents, patriots, and friends to society. It no longer makes sense to equate criminal to BAD.
Re:Good stuff, but... (Score:5, Interesting)
Security through obscurity is fine _as an additional layer_ - can't even begin to decrypt something you can't find.
Are there secrets in the opensource images? (Score:5, Interesting)
(Maybe a "If you can read this, you're too paranoid" sort of message in the Redhat splash picture?)
Does this mean ... (Score:2, Interesting)
I can hide my entire pr0n collection in a single gigpixel [slashdot.org] image?
Seriously, though, I read a news article some time ago describing how the FBI are onto such data hiding techniques after discovering terrorists (ok, "Arabs") had been posting stego encrypted messages in images posted to various popular terrorist (there I go again!) websites.
Don't know to what extent they're "onto" it (they never say, do they?), but I imagine looking for secret clues [abeautifulmind.com] can be a full-time job.
I wonder . . . (Score:5, Interesting)
why the old stuff? (Score:5, Interesting)
There is enough new and interesting (and better) stuff around. For example, rubberhose [rubberhose.org] would've been much more interesting to read about.
Re:Good stuff, but... (Score:5, Interesting)
When I Steg an image I encrypt the text first then plant it into the picture.
Even if you figure out that the image has been Stegged you won't know if you get the
Method I used to put it in because you can't read it. But all the receiver needs to do is use the correct decoding in Steg and then un encrypt the images. You may be able to tell there is something in the picture but reading it is another matter.
Re:Good stuff, but... (Score:5, Interesting)
The results of my wardialing from payphones or my list of machines/users/passwords was always only on removeable media, encrypted, and then simply hidden in gif files.
Back then the Feds and the other goons that you heard harassing others or trying to jail them were not savvy/smart enough to dig very deep. Hell we use to openly trade information in Gif files on a national BBS, although we did get sloppy. The more naked the chick in the picture, the better the info was inside it with one exception... targets we were after were in the "ugly" files.
Examples of good steno-encryption (Score:5, Interesting)
It is a good read.
Lies, Deceipt, and Trickery
The rest of the hack does everything it can to hide itself. There are two major components to the disguise: the "fake" hack, and the JPEG image of Tux.
Firstly the fake hack. The fake hack begins at offset 0xD00 in the game save. If you disassemble the game save, you are likely to notice that some interesting stuff begins there. It appears to be getting it's own address, turning off write protection in memory, patching the kernel, and calling XLaunchNewImage. There is some branching logic which seems to imply that it is patching the kernel in different ways, depending on the value of location 0x8001FFFF in memory. The patches even resemble those that certain modchips perform, some are even at the same offsets. The path to the linux xbe is noticeable as well, at offset 0xFD5.
Upon initial inspection this code seems very plausible. When you look at it closer, there are a lot of inconsistencies. Firstly, the value being tested at 0x8001FFFF does not match up to any known kernels that I know of anyway. Secondly, a lot of the patches to the kernel are junk code and don't make any sense. Thirdly, there is no call to IoCreateSymbolicLink in order for the call to XLaunchNewImage to work. XLaunchNewImage checks to make sure that the path to the executable resides on the 'D:' drive to prevent applications being launched from the hard drive, and therefore only from the DVDROM drive. Without remapping \Device\Harddisk0\Partition1 to 'D:' using IoCreateSymbolicLink, there is no way for the kernel to find the default.xbe as specified.
Secondly there is the Tux JPEG. Starting at offset 0x1080 in the game save is a JPEG image. This is obvious from the text JFIF which is present in all JPEG headers. If you extract out this block, you get a nice little picture of Tux. Seems like a harmless little addition by a linux fanatic. It is typical of linuxheads to stick stuff like this everywhere. In reality, the real hack is encrypted and stored in this image. The practice of storing data in images is known as steganography. Perhaps this doesn't count, as it stores the data in the header and not in the actual image data. It's still rather devious. We'll come back to the contents of the hidden data in a moment.
Re:I wonder . . . (Score:3, Interesting)
Hmm. If it does, you could use it to your advantage. Encrypt your message. Use steg to hide it in an image. For that added level of (ob)s(e)curity you could hue shift the image whatever values you wanted before hiding your message in it. Adjust the values to "normal" before sending it.
To completely decrypt it, you would have to be able to set the R,G, and B values to the correct ones, then de-steg it to get the message, then unencrypt it.
Seriously, do any of you have information that is THAT secret? :-)
Re:No... (Score:3, Interesting)
So myBankAccountNumbers.jpg becomes mban.o and myMistressesAddressAndPhone.jpg becomes maap.o.
Then drop em in with your system files. Done.
On Window$, rename them to
OR, drop them into your MySQL data folder, and rename to pictures to match what's in there. This might work for you if you use MySQL and do regular backups.
So it's kinda like changing the paintings on the walls to look like sheetrock or bricks.
I don't guarantee that this would keep forensics guys from finding stuff, but I don't think the first place they're going to look for stuff is in system or development files.
The only problem here is to keep track of what is what. After a couple of files, it's going to be a pain to remember which file has your pr0n site passwords in it, versus Gramma's cookie recipe.
wbs.
Re:Good stuff, but... (Score:5, Interesting)
It leaves a telltale header "-----BEGIN PGP MESSAGE-----"
This makes it very easy to find encrypted messages as you can apply a simple filter.
One of the benefits of steganography is that is looks like a JPG file being emailed or a JPG(PNG) sitting there on a website. Without very special software there is no easy way of even knowing that the picture of grandpa on the tractor is anything but a picture of grandpa on the tractor.
When I was playing with it, I would encrypt the text using PGP then embed it in a image using JSteg. It was fun but not particularly useful since nothing I had to say or email was worth anything to anyone important. Having said that, should (when) the revolution comes it will not be televised [gilscottheron.com], it will be stegged so I'm keeping those skills.
Re:I wonder . . . (Score:2, Interesting)
Not me, but I can imagine various scenarios where steg would be useful. e.g. espionage -- where you use a one time pad to encrypt the info, then steg to insert it in a jpeg which you could transport through airports, etc. on a memory card in your digital camera. Much less incriminating than carrying a floppy or cd...
I can imagine that a similar "stealth" technique could be employed using mp3s and an iPod.
Re:Hiding pr0n? (Score:4, Interesting)
Re:Good stuff, but... (Score:5, Interesting)
Basically, encryption is hiding a needle in a very large haystack, and stego is hiding a carefully disguised strand of hay in a not-so-big haystack. The end result is that similar attacks are required to break either scheme (theoretically), so from a conceptual point of view neither should be preferred over the other.
Why put the data in comment blocks? (Score:2, Interesting)
Why not make the data truly hidden by using the least significant bit within each of the RGB values for a 24 bit color image? 8 bytes of image data can hide 1 byte of data.
If you can repeat the hidden message enough times you might even be able to use this within a jpeg image and have the message survive recompression of the image or slight image manipulation. When reconstructing the message collect the bits of the repeated message and select the bits that repeat the most.
I'll have to try to write something quick and dirty up in Python to test this out.
Featured on Navy:NCIS (Score:2, Interesting)
How? (Score:5, Interesting)
Now I take the encrypted bits of the message (which already look a lot like random noise) and hide them inside the least significant bits of a bitmap file. Lets assume that I'm using a half-decent steganography tool here, and it distributes the bits of the message throughout the image in a psueudo-random fashion.
So now we've got a stream of encrypted bits, which more or less resembles a stream of psueodo-random numbers. And we've sprinkled these bits all over the place inside the image, so they don't even appear together or in order.
How does one go about detecting that there's a message in there, reliably? What distinguishes the [pseudo]randomly-distributed [psuedo]random-bits of the encrypted message from the background noise of the image?
(I am assuming, of course, that the message we're trying to hide is relatively small - at most, 1 bit per byte in the image is modified. Much more than that is like trying to hide a tractor trailer behind a go-kart)
Steganography Filesystem (Score:4, Interesting)
Ideally the software would only need to be pointed to a directory or a wildcard, given a passphrase and be able to just "mount" those files. I.E.
Some Steganography can be detected (Score:3, Interesting)
Really, what do you guys need to hide? (Score:3, Interesting)
Of course, if I lived in China and was plotting a demonstration, I'd need to hide that info. Or bank heist details.
Currently, encryption is used freestanding by people with something to hide - and is viewed by 'the masses' as a terrorist/theft/dishonest tool. Why isn't encryption used in *everything*? I appreciate the need for encryption, but until it is everywhere and easy to use, it will have a black cloud hanging over it. Which makes it much easier for those who would like to abuse their powers (cough *Ash*cough) to pass laws restricting the use. Thereby reinforcing its reputation as a tool for people who have something (bad, ohohoh very bad) to hide.
Re:Is this limited to FreeBSD only? (Score:5, Interesting)
Please, please, please, avoid steganography and use standard cryptography if you want to protect data. Steganography's security lies in the idea that if you conceal the method with which data is obscured, you conceal the data. This is a very bad way to assume security. In any data protection scheme, you should always assume your enemy has the algorithm used to obscure the data, but that only you have the secret (key).
I do realize that steganographic techniques now will encrypt data then insert the encrypted bytes into the image, but if it is so easy to extract the steganographically encoded information, what's the point of encoding it in the first place? Differential steganalysis seems to be an easy enough method of finding steganographically encoded data, so recovering the information encoded into an image or whathaveyou is somewhat of a trivial problem, and if there is a trivial step in your data protection scheme, it should just be removed, because it's pointless.
Kerkhoff must be rolling in his grave.
Hiding secret messages in gzip data (Score:2, Interesting)
Obvious solution... (Score:5, Interesting)
Also tends to confuse the detectors, as they are not trying all (n) possible ways the file could have been compressed to look for steg data in the raw file, only looking at the compression errors in the current format.
For every scheme, a crack, for every crack, a new scheme. What fun the merry go round is!
steganography isn't secure at all (Score:3, Interesting)
Its a twofold problem as I see it.
1. The hiding of encrypted data/images/text/whatever inside of an image file is based on the notion that security through obscurity raises the bar. Anyone who studies security knows that this is just not true. Since suspicious images are simple to detect, this layer of obscurity offers no real data protection than just encrypting the file and naming it "this-is-secure-data.blowfish". Its just a matter of what encryption method is used to secure the contents. Which brings me to my second point.
2. Since the basis of steganography is to hide information inside an image without disturbing the visual image, the size of the data contained within, from my understanding, is severely constrained. Thereby limiting the effectiveness of this technique in all but very large, suspicious, and still easily scanned images.
SO, by hiding one's data inside an image with this technique, one is left with a picture of a table that is just screaming to be scanned for its suspicious content.
Re:The great thing about being disorganized... (Score:2, Interesting)
Re:Hiding pr0n? (Score:2, Interesting)
2000/xp fixed that.
Re:Stego is so old news (Score:1, Interesting)
Go read a little bit, Ariel Sharon himself said terrorism is a good tool for freedom fighters back in the day when the isreali's were fighting the british.
so dont lable shit as troll just cuz you dont like what the man is saying.
In BSD (Score:3, Interesting)
Re:How? (Score:3, Interesting)
Mimic Functions (Score:1, Interesting)
Re:Is this limited to FreeBSD only? (Score:3, Interesting)
However, if the Department of Homeland Security suspected that you were hiding data within your own obscure files, they could search the files themselves for "extra" data. They can prove such a message exists, even if they can't discover what the message is.
This is true, but finding well-encrypted data is much harder than finding plaintext data. Plaintext data has certain statistical properties, i.e. in ordinary English ascii-text some characters are used more often than others. Cipher text usually resembles a random stream of data. This means that a discovered "disturbance" in image data produced by information encoded in the low order bits might just as well have been produced by inaccuracies in a scanner or digital camera. I am not claiming it is impossible to show that data is hidden in an image, but I assume it will be much harder to prove this in court if the data is encoded using a "statistically sound" encryption algorithm.
Re:Is this limited to FreeBSD only? (Score:2, Interesting)
Reveal the secret key to this obviously encrypted file, or face contempt of court and an automatic prison sentence.
You can encrypt two (or more generally N) messages with different keys into the same encrypted file. If confronted with the above ultimatum, reveal just one key and keep the very important information secret just as before.
Of course, many messages encrypted into the same file would draw suspition from cryptanalysts, but those experts are in rare supply and regular police would generally stop bothering you if they can see one mildly incriminating decrypted message (surely, it has to be a a nice bait).
Steganography comes into play if you want to hide the secondary secret messages in the multi-message encrypted file...