How to hack steganography.r (sorry piotrgapinsk)
[1/1] from: sant4::wanadoo::fr at: 13-Mar-2007 20:09
I tested the script steganography.r (on rebol.org) from piotrgapinsk. I noticed that
it was rather easy to break the code if the image is too uniform or if the encoding key
is too short (less than a length of 15). I added some hack functions in the original
script to prove it. here: http://perso.orange.fr/rebol/steganography.r In the script,
i use a dummy image so it is easy but i tried with real images too and sometimes the
hack works. (depending the nature of the image) (Sorry for the google engrish traduction)
Some proposals, for piotrgapinsk: - The message should be inserted in the middle of the
image to avoid the too uniform areas of the image. Better, its starting position should
vary according to the key. - Each character of the message is encoded using one of the
3 RGB channels of a pixel. Did you notice that your algo almost always puts the most
significant bit to zero (bit 7). It is thus easy to detect the pixels candidates because
the value of the channel used is always lower than 128. Even without that, one can rather
easily detect the pixels candidates by comparing them with the preceding pixel and the
following, to detect suspect variations. What it would be necessary to do, it is to use
only 1 or 2 least significant bits by leaving unchanged the most significant bits. For
example to encode the character "a" with the key "1" you do :"a" xor "1" => 01010000
, that you burst in 4 parts "01" "01" "00" "00" You thus need 4 successive pixels to
code only one character of which you modify only the 2 least significant bits: pixel/1/1:
pixel/1/1 and 1111 1100 or 0000 00 ' 01 ' pixel/2/1: pixel/2/1 and 1111 1100 or 0000
00 ' 01 ' pixel/3/1: pixel/3/1 and 1111 1100 or 0000 00 ' 00 ' pixel/4/1: pixel/4/1 and
1111 1100 or 0000 00 ' 00 ' Thus, the modifications are less easily detectable. They
are it even less, if you modify one bit by pixel. In this case you will need 8 pixels
to encode 1 only character. - Another thing to do is to voluntarily add noise in the
image before to encode your message. For example, if you modify all the least significant
bits of all pixels of the image then your message is not locatable, even if it is encoded
in a area of plain color. I think that, by adding noise on the 2 least significant bits
of each channel, the image remains not very faded. - It is a bad idea to encode the length
of the message in the first pixel of the image. That facilitates the work of the hacker.
It would be better to encode the length of the message in the message himself. For example,
if the message is "Hello, how are you?" , you encode: message: "Hello, how are you ?"
message: join to-char lentgh? message message Then you have to handle the fact that the
first character to be decoded contains the length of the message. But of course, that
has interest only if your message does not always begin at the same place. - Last proposal,
instead of coding a character on 4 or 8 successive pixels as I said previously, you could
use the key to calculate a variable offset between each pixel. With these proposals,
I see nothing than the allied rough force with the use of dictionaries to succeed in
breaking your code.