Thread: Steganography

  1. #1
    Registered User
    Join Date
    Nov 2001



    I've been searching Google, along with a couple other search engines, for examples on steganography in C. I've also came across, it's a great site with information and articles on steganography; unfortunately, I was unable to find any tutorials or links. If anyone may be able to point me out to something, that would be great.


  2. #2
    Registered User
    Join Date
    Nov 2001
    Thanks alot, I found what I was looking for through some links on that page.


  3. #3
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Waterloo, Texas
    My Great Grandfather was a great steganographist of his time.

    A true innovator. But he's dead now, so I really can't help, can I?
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
        return std::pow
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;

  4. #4

    Once I programmed QBasic, I wrote a program that hides secret information in the space-characters of textfiles. The stenographic principle is as following:

    There is under the DOS/Windows-ASCII-charset a character
    that looks also like space. So you have " " and " " (at least on your screen).
    If you have for example the secret ASCII character number 64 (a "@") that is binary a 1000000 you can hide this character in seven of the two space-characters, because you can see every space-character as a bit.

    This is a very easy stenographic method and simple to implement.
    Try it!

    I hope I could help you!


  5. #5
    Registered User
    Join Date
    Nov 2001

    Sounds pretty neat, did you know him well?


    QBasic, hehe, I've done some VB...The method you are talking about sounds interesting! What I'm going to be working on will be for multiple platforms.

    Thanks for your replys.


  6. #6
    Registered User
    Join Date
    Sep 2001
    In attempting to larn something about data compression, I noticed something interesting about JPEGs...
    They're based on the principle that you can completely transofm any image into a two dimensional array of the same size, however the farther down the array you go, the less important the information in it is as far as the image looks, so you can just clip off the last say, 90% of the array.

    Of course, you could also just slap any old information in there, and end up with a larger array, but since the information you added is all incidental, it shouldn't have much effect on the image.

    Still don't know all the details of JPEG storage, but it seems pretty simple to do, just need an image to tack info on to.
    Callou collei we'll code the way
    Of prime numbers and pings!

  7. #7
    Registered User
    Join Date
    Nov 2001

    That sounds like the right way to do it. In theory it seems easy, but in practice it will be alot harder for me. I will try to come up with something. Thanks for information.


  8. #8
    Back when I was writing JPEG code for commercial products, I saw the same thing you did, except slightly differently-- Actually, that is why JPEG is called 'lossy'.

    It is because the least significant bits have no serious impact on the image quality and may be discarded-- hence the compression.


    For example, as in JPEG, if you look at a given pixel, it is represented by an RGB triplet. For sake of example, lets look at it this way:

    1010 1101 R
    1110 0010 G
    0011 0110 B

    MSB is on the left, LSB is on the right. Each of these values puts you on a specific point on the color wheel. We will ignore the HSV (Hue Saturation Value) model in this discussion.

    If, above, you were to eliminate the 4 MSBs (most significant bit) in just the red component, for example, your value for Red would change from 173 to 13. Red would significantly be modified on the color wheel and would be noticably different than intended.

    If, on the other hand, you were to eliminate the 4 LSBs (least significant bit), your value would change from 173 to 160-- hardly any change at all, relatively speaking.

    That is essentially how JPEG works. It's a 'quantization' process to determine how many bits from each RGB triplet can be eliminated without sacrificing too much image quality. Other things are done during this phase as well, such as looking at 'square blocks' of pixels, rathern than single pixels. Sort of a 'fat pixel' approach. If you could get away with dealing with a graphic image by breaking it into 10x10 (or some other "ideal" size) mosaic pixel blocks and then quantizing each of those blocks, compression would be significant.


Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 5
    Last Post: 07-31-2006, 12:13 PM