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."
...people just think it is because it hides itself very well. ;-)
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'd be interested to know if this is just a BSD thing or if I can run these apps on Linux or Windows.
I used to use this kind of thing to hide certain, ahem, suspect images on the Acorn machines at school.
:o)
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
Beep beep.
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.
...is that no one else knows where to look to find things that might be sensitive. You can literally hide things in plain sight, but with the amount of crud stacked everywhere physically, and the amount of data strewn about with no apparent labelling (except for the porn of course), no one can actually tell what is important and what isn't.
Of course, dates don't seem to understand the logic of living in an apartment that already looks like it's been rifled through.
Do not look into laser with remaining eye.
I use steg sometimes to pass messages i dont want out in plaintext or overtly encrypted, but it has to be passed in such a way that it isnt apparent that a message is there (i.e. email to brother 'See these pics of grandma!'). It is not a foolproof method, but its very useful when you realize you cant trust the encryption itself to hide the message.
BSD is mentioned 3 times in the post, while the utilities that actually do the work are only mentioned once? This is like titling a post "Processing Images with Filters on Mac OS X" and only mentioning once that you use Photoshop.
"And this is my boy, Sherman. Speak, Sherman." "Hello." "Good boy."
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.
Please help metamoderate.
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.First time I read the headline, I thought it was implying that there are secret messages in the icons/images that are part of the freeBSD installation. Which brings me to wonder: what prevents people from putting messages hidden in the KDE or Gnome icons and such?
(Maybe a "If you can read this, you're too paranoid" sort of message in the Redhat splash picture?)
alias uptime="echo '5:33pm up 22342352324 days, 6:28, 2124315623 users, load average: 2432.40, 12312.31, 123123.19'"
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
Why do we get articles about tools that are what? 3 years old?
There is enough new and interesting (and better) stuff around. For example, rubberhose would've been much more interesting to read about.
Assorted stuff I do sometimes: Lemuria.org
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'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.
In some countries you can go to prison for using cryptography, in other more enlightened countries you can go to prison for not handing over the keys when asked by the guys in jack boots or for talking about the fact that you've been raided.
Government of the people, by corporate executives, for corporate profits.
Any discussion of steganography is incomplete without this:
http://www.mcdonald.org.uk/StegFS/
"See these naked pics of grandma!"
Roving Web-Teleoperated Robot
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)
...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
Use reversable compression. Encrypt the cleartext, package it in a container (subcontained if desired), stga that into the BMP or WAV, compress using GIF/PNG/FLAC as required. Ship product to receiver, they uncompress (since the compression is lossless, no bits lost there), de-steg, decrypt, decrypt, viola recipe for brownies.
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!
You can have it fast, accurate, or pretty. Pick any 2.