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