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

23 of 424 comments (clear)

  1. Is this limited to FreeBSD only? by Wigfield · · Score: 4, Interesting

    I'd be interested to know if this is just a BSD thing or if I can run these apps on Linux or Windows.

    1. Re:Is this limited to FreeBSD only? by TedCheshireAcad · · Score: 4, Interesting

      I'm probably gonna get modded down for this, but:

      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.

    2. Re:Is this limited to FreeBSD only? by X-ite · · 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.

  2. Hiding pr0n? by Realistic_Dragon · · Score: 4, Interesting

    I used to use this kind of thing to hide certain, ahem, suspect images on the Acorn machines at school.

    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 :o)

    --
    Beep beep.
    1. Re:Hiding pr0n? by Ayaress · · Score: 4, Interesting

      An interesting technique for hiding "questionable content" on your computer is to zip it up and rename the file something like syskrnl32.dll or winld64.sys or something important-sounding, then putting it in c:\windows\system. Back in the days of windows 3.11, I could go into DOS and do an attrib +d on it, but they seem to have taken the d attribute out since Windows 95.

  3. Good stuff, but... by VargrX · · Score: 5, Interesting

    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.
    1. Re:Good stuff, but... by Realistic_Dragon · · Score: 5, Interesting

      You can always encrypt first then hide later.

      Security through obscurity is fine _as an additional layer_ - can't even begin to decrypt something you can't find.

      --
      Beep beep.
    2. Re:Good stuff, but... by ReTay · · Score: 4, Interesting

      Well again this falls on the user.
      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.

    3. Re:Good stuff, but... by Lumpy · · Score: 4, Interesting

      all of this are nothing more than really old hacker tricks and tips.

      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.

      --
      Do not look at laser with remaining good eye.
    4. Re:Good stuff, but... by jxs2151 · · Score: 4, Interesting
      Here's the deal with encrypting with PGP (GPG, etc.):

      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, it will be stegged so I'm keeping those skills.

    5. Re:Good stuff, but... by dfay · · Score: 4, Interesting

      Cryptography IS security through obscurity... mathematical obscurity. You either choose a secret (a prime or a password) to encrypt something, or you choose a secret (which picture, which algorithm and settings) to hide something using stego.

      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.

  4. How come ... by DogIsMyCoprocessor · · Score: 4, Interesting

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

  5. No... by SuperBanana · · Score: 4, Interesting
    Bad guys in the movies all keep their wall safes hidden behind paintings

    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.

  6. Really cool demo... by veecee_veecee · · Score: 5, Interesting

    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

  7. Bad Guys? by philovivero · · Score: 5, Interesting

    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.

  8. Are there secrets in the opensource images? by ksheka · · Score: 4, Interesting

    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'"
  9. I wonder . . . by lavaface · · Score: 5, Interesting

    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?

  10. why the old stuff? by Tom · · Score: 4, Interesting

    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
  11. Examples of good steno-encryption by MURD3R3R · · Score: 5, Interesting
    The first and probably best steno-encrypted file I ever remember seeing was the first linux no-modchip hack for the XBOX, from http://xbox-linux.sourceforge.net/docs/007analysis .html

    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.

  12. How? by ThePyro · · Score: 4, Interesting
    How could that that work reliably? Lets say I take a text message, then encrypt it (as all hidden messages should be). At this point, the encrypted bits of the message should closely resemble random noise - assuming the encryption scheme we used was good enough.

    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)

    1. Re:How? by quantum+bit · · Score: 3, Interesting

      But JPEG is a lossy compression format. The whole point of the format is to eliminate random noise because such noise would just be a waste of space to store. So if there's a picture with a lot of random noise, it's a pretty good sign that something else is going on. For one thing it will be a lot bigger because 'random' (or encrypted) data is much more difficult to compress.

  13. Steganography Filesystem by commonchaos · · Score: 3, Interesting
    What I would like to be able to see is the ability to use a large directory of files as a stenographic "filesystem" of sorts. For example: Mount the pictures of your roadtrip to Antarctica as a loopback device.

    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.
    mountsteg /home/bob/antarctica_roadtrip_pictures/ /mount/secret/
  14. Obvious solution... by Lemmeoutada+Collecti · · Score: 4, Interesting

    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.