Slashdot Mirror
Hiding Secrets With Steganography On FreeBSD
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."
Makes you wonder what the demon is hiding
Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose.
I've been using it for years, posting messages like "allah is great" on Fark photoshop contests.
Just raising the background chatter to a dull roar.
my problem wrt steganography is that it 'feels' more like security through obscurity than an actual cryptographic regime (ala gpg encrypted attachments, etc). Other than that, neat stuff.
Sometimes people just have to learn and adapt to change, it is one of the requirements of being a living thing.
This was my first exposure to a steganopraphy demo....Written by the author of a bunch of books on Computer Networks and Operating Systems... http://www.cs.vu.nl/~ast/books/mos2/zebras.html
All the BAD GUYS hide their safes behind pictures? Is the metaphor you're trying to paint that BAD GUYS use steganography? The government propaganda wars are working. Newspeak is ingrained.
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.
fifth sigma, inc.
- jsteg,
- jphide (unix and windows),
- invisible secrets,
- outguess 01.3b,
- F5 (header analysis),
- appendX and camouflage.
Stegbreak is used to launch dictionary attacks against JSteg-Shell, JPHide and OutGuess 0.13b.Win, Linux
Wow, I should not post when knackered.
What happens if you edit the file in a graphic utility? Does it alter the hidden info? Destroy it? Do different actions (hue shift, paining-on-top) affect the outcomes?
harmonious design
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.
I just compiled the source on Linux and it appears to work just fine.
I've been staring at this pictures of Jenny McCarthy for years now, trying to discover the steganographically hidden messages.
That's what I told my girlfriend.
The analogy isn't security through obscurity, it's finding a better place than behind the painting to hide the safe. Or, perhaps more accurately, securing one's valuables in something that is not recognizable as a safe. If the burglar had to look at a thousand books to determine if even one of them had a secret compartment, it would be a much more effective security measure than a safe behind a painting.
If you are using stegged files (they do not have to be images) to communicate with others, then you are hiding the channel. This is a potentially very useful mechanism against automated monitoring tools, particularly if the data is first encrypted. Isolated information in high-volume channels can be very hard to detect. Another use would be to help defeat traffic analysis.
This is not to say that steganography is a magic means of information hiding. But it is one of the useful tools.
Floating face-down in a river of regret...and thoughts of you...
Keep in mind that the article said that hiding messages in images is NOT a great way to hide important stuff by itself, but that it could be used as a second layer of security. Lets have four people, shall we? They all run servers, and they all have an important file on there they don't want other people to find. Johnny keeps his file unencrypted and unhidden. Billy keeps his encrypted, but unhidden. Mike hides his in an mp3, but unencrypted. Joe hides his in a jpeg after encrypting it. Johnny's most likely to have his stolen, obviously. But Billy's file is more likely to be found than either Mike or Joe's, even though Mike's has no encryption on the file itself. Even though the person who took Billy's file doesn't have the information in it, finding it it one step closer to stealing it. Now, Mike and Joe are both considerably less likely to have this file found, unless the data theif expects them to hide it in a media file like this. On the off chance that the hacker DOES find the file, though, Mike's is as good as stolen, just like Johnny's. However, Joe is the most secure of the bunch. Not only is his file encrypted, but it's also hidden, meaning it's unlikely that the hacker will even get the encrypted version. They can't crack what they can't find. Even after what Johnny did, he can go furthur. Encrypt his password, hide the text in an image, rename the image to a .dll or .o and hide it in a system directory. Sure, it's not 100% secure, but it's better than leaving even the most secure file laying around.
...ironically, the better algorithms we get for compressing stuff, the more difficult it is to hide something. It gets really obvious if you start sending around BMPs or WAVs.
Steganography detection is doing rather well - it simply realizes when the compression is "wrong", that is, if it would have been compressed better if there wasn't hidden info in the image.
By the way, for legal purposes it might be just as efficient to use something like Bestcrypt's hidden container - it's a very smart, yet "dumb" form of steganography. You create an encrypted container, which has a key. Then you create a hidden container inside the encrypted container, with a different key. There's no way to detect the presence of a hidden container - it looks like random data in a container full of random data.
If required by law to provide a key, provide the key to the outer container. When asked about a hidden container, go "What hidden container?" Even if it is very likely that there is one, there's no proof of that. Even the wackiest RIP bill doesn't require you to provide decryption keys to things that doesn't provably exist.
Kjella
Live today, because you never know what tomorrow brings
One facet of data security is deniability. Which would you rather the Department of Homeland Security find on your hard drive:
/documents/plan_for_world_domination.pgp
/wallpaper/cute_puppies.png?
or
A securely encrypted message, hidden in a file with ostensibly another purpose, such that there is no way to prove the existence of the hidden message would keep anyone from telling you: "Reveal the secret key to this obviously encrypted file, or face contempt of court and an automatic prison sentence."