Results 1 to 4 of 4
  1. #1
    Join Date
    Aug 2003

    Common methods for stegano decryption

    ok, I did a search of the forums, and didn't see any information on common methods used to detect steganography.

    I'm pretty interested in the subject, after finding out it existed from a challenge on http://www.hackquest.de Does anyone know of any info on the web, or in a book, that details these methods. So far, I've used image manipulation programs to decrypt one or two simple files, but ones like the one I've attached to this post still elude me as to how to decrypt them.

    Thanks for any help

  2. #2
    Senior Member
    Join Date
    Jul 2003
    when messgaes are hiden in pictures/ files, most common steg programs leave a common signature that steg searchers use to identify a hiden message in file,

    Im not sure if there is a list of these availiable, If anyone knows of one can they show me?

    you could download common ones and play about and create a program that looks for certain things, thats what ive been doing, (havent worked on it for ages cos been building a robot arm) in python, mine was going to use common things in the english lang to search for them, this would only work for plain text and not for encrypted files


  3. #3
    Senior Member
    Join Date
    Oct 2001

    Post Steganography and Images

    Good Stenganography is made to not be detected. So a steganography detector would be a border line oxymoryon. Luckily many steganography programs do several things that make it easy for a steganography detector to find the message. One is that it has to store the message somewhere, so something is not going to be what it appears. Usually the changes are very minimal and unnoticable, but there are changes.

    To prove this, I've taken your message and added a few effects to it to bring out where the message could be hidden. Mainly I was playing with brightness and contrast until stuff jumped out at me. What appears to be a white background acturally seems to not be quite so white. There is a big block of something that was very close to white, but not quite. It could have been an artifact from compression however small those chances were, so it might be legitimate. If the background was completely white, the entire thing would have changed color together, but obviously there was a small color distortion caused from *something.*

    So this method of hiding a message in an image is pretty easy to detect on a non-noisey source. This image had very little random noise, as it was probably computer generated. If you take a webcam and snap a pic, chances are there is a bit of noise there. Steganography programs do all sorts of elaborate things to make message recovery difficult if you have the wrong program, but most of the time if you try different programs chances should be good that you can recover the message, so good luck.

    As for how these programs acturally hide data in an image, it is my understanding that the lowest bit usually plays a key role in steganography with images. This means that for each pixel's three colors, RGB, the lowest bit of each of these colors' intensity is changed to be a bit of the message. This causes color distortion that is not readily apparent, and you can see its effects in the attachment after lots of contrast and brightness changes. There may be more complex ways that the data is hidden, but I only know of using the lowest bit. Hopefully that can give you something to look into if you're interested.


    Edit: Hrm, I accidentally had the image in .bmp format when I originally uploaded it, so I removed the attachment, and uploaded a .png version of it. When I download, I still get the older 300kb .bmp file. Maybe it will sort itself out, or maybe it i a bug. Sorry about the big file size.

  4. #4
    Senior Member
    Join Date
    Jan 2002
    Right - one very obvious attack on steganography, even if it's done perfectly, is comparing the modified image / sound file with the original.

    Therefore to defend against this, it's incredibly important to securely delete the original, assuming you don't use it in place.

    Personally I think that 16-bit .wav files with 4 bits of data used for steganography are ideal. Assuming you record it off an analogue medium (the radio using an analogue tuner card is good), there will be much more than 4 bits of noise in the original.

    The other advantage of 16-bit wav files is that they're large. Large enough that you can have a reasonable length (plausible deniability here) wav file storing a reasonable amount of stuff (even at 25%).

    Even a fairly big JPG can only reasonably store a few kilobytes of stuff.

    "Scramdisk" can do in-place wav steganography in win9x and thus enable you to use the wav file as a container without having to copy it or change it in any other way.

    There is of course no header or signature in steganographically encrypted volumes with Scramdisk (nor is there in normal encrypted volumes, but they are easier to detect because they're full of random bytes) - so detection is very difficult.

    The trick is, when backing up encrypted data, to use a different container each time for the backup (from a different wav file).

    It is tempting to just back up the container file, but that backup can trivially be compared with the original and an attacker could see which sectors had been modified, compare that with a DOS filesystem structure etc, and fairly trivially prove beyond reasonable doubt that you have encrypted stuff in there.

    In order to do regular backups, you need an analogue source of fresh wav files - therefore I suggest you get an analogue radio tuner card. Record your favourite programme each week - that's plausible.

    Oh yes, and forget about a digital tuner card - that is a *REALLY* bad idea - an attacker can simply compare your wav files with the (digital) data broadcast.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.