[quote=94820:@Christian Schmitz]there
http://www.mbsplugins.de/archive/2014-06-03/MBS_Xojo__Real_Studio_Plugins_[/quote]
Great. Thank you. 
Stenography only works with lossless compression techniques, whether audio or images. Lossy compression works by removing data, that once is removed can not be fully recovered. I made something similar for WAV audio file formats in VB6 once. The porting over should be fairly easy. WAV files are easy to work with, as just a few bytes are header informationā¦ then samples are all the data following (either in 16-bit or 8-bit segments per channel, usually).
I didnāt try encoding into JPEG, but my original image was JPEG and I encoded into PNG. I was able to reopened that image and read the message.
I just tried it with JPEG and could not read the message, even with max quality, so thatās not an option.
I did research into this, 10 years ago and I never found a succesful routine with JPEG. The closest I got was embedding a graphic in the blue channel, which was only clearly visible when viewing the blue channel only. It also wasnāt perfect either.
[quote=94822:@Michel Bujardet]Christian Schmitz there
http://www.mbsplugins.de/archive/2014-06-03/MBS_Xojo__Real_Studio_Plugins_ [/quote]
It works. Thank you.
It is interesting but unencrypted text is rather easy to find. Using this technique would probably require encrypting the text.
You can try various things to make it harder to find. For instance, donāt use every LSB as a placeholder for your āhiddenā data. Donāt use ANY bytes that would normally be a solid color. You can check the leading bits and if theyāre all the sameā¦ ignore the last value. If somebody goes searching through an imageā¦ and thereās an area of solid black pixels, but a few of those have the LSB fluctuating, then they can safely assume thereās data contained in other LSBs. Hope you understand what Iām sayingā¦
Keep in mind, doing the above works similar to compression. You can only do something forward, that can be reproduced using a formula to recreate it in reverseā¦ without entropy; otherwise, it wonāt work.
You have to use lossless formats - I think that was mentioned
Sorry I havent responded, for some reason this forum decides to stop giving me notifications on posts so I only just realised people had responded. It would be fine for what I need to have the images saved out as a PNG so long as the incoming image is a JPG. I need to make sure that the information is very well hidden in the image and not easy to spot as others have demonstrated how (above).
Okay, I can look into it.
The best way would be to encrypt it, then embed it into the image. Then even if someone suspected steganography by the look of the color signal, he would simply encounter encrypted data instead of clear text. Of course the set and get methods would manage encryption transparently.
Nathan, the technique I outlined above is pretty easy to implement. (I may even turn it into a class.) You can get a public key from the target user, use it to encrypt the message, turn it into Base64, then embed that. Terminate it with a null, and the ādecoderā for the other side is pretty easy to implement.
In an 800 X 600 image, you can store a message up to 180k if you use the last bit of all three colors of every pixel.
(Um, youāre not planning on using this to send messages to Al-Qaeda or something, are you?)
Wow, you have the same client 
No it is nothing like that, My client travels all over the world with financial reports on high net worth people but some of these people live in places where the governments are not friendly and he has to travel as a tourist to avoid suspicion. Even carrying a USB stick is too much for him so he always has his digital camera with him as he is into photography so he is going to download some photos before he leaves to his PC, add the reports (PDFs) in encrypted form to the images and put them back on the card and then they go back into the camera. He also has an MP3 player where we have already stored a compiled / wrapped Xojo app that is encrypted etc which he then uses to view the data on the camera card when he is with his clients.
Nice.
How big is the typical PDF? He may have to use plain text instead, or perhaps encode a file across several images.
The other option to save space is to use the first 24 bits to encode the length of the upcoming data and skip Base64 encoding.
Is your client 007? 
if you do Kem, I would be interested.
I envision that it would take, as properties, the message or file to encode, a public key for encryption, and an array of images to use in order. The size of the images must accommodate the message or an exception will be raised. If no public key is supplied, encryption would be skipped.
An optional destination FolderItem, if supplied, would be used to output the images. The array of images could also be an array of FolderItem of images. In other words, it need not be done all in RAM.
The first 32 bits (not 24 as I posted above) would be used to encode the length of the message, then the message would be encoded across the images. Just the images used would be returned either in the result array or in the supplied folder.
First the Blue channel across the images would be used, then the Green channel, and finally the Red channel. Why? No reason, I just picked that order arbitrarily.
Have I forgotten anything?
Well Kem, I think you think too much in detail.
I added for Nathan a couple of plugin functions.
I wish He is an accountant so does like spending much of his won money!!!
[quote=95301:@Kem Tekinay]How big is the typical PDF? He may have to use plain text instead, or perhaps encode a file across several images.
The other option to save space is to use the first 24 bits to encode the length of the upcoming data and skip Base64 encoding.[/quote]
The files are normally about 100k but we have the option of just using formatted text which compressed down to about 3-5k plus the advantage of this is that he then can read the files directly in the Xojo app an leave no possible trace from the PDF viewer on the PC being used. This is most likely the way we will go. In addition to the encryption using the password we will also be using part of the image as part of the addition encryption so that each image has a different password etc. Obviously we will remove client specific information from the text file and have already built a routine that pulls out country names like āHouse in Spainā and replaces with different descriptions etc.
Rather than always use the same channels why not read a byte from the first image and based on a simple rule make it decide which sequence to use. Also how about using another byte to decide a sequence to write the data in so rather than writing bytes 1,2,3,4,5 ā¦ 200,201, 202 would be written in a different order and if you really wanted to be slick you would read another byte an use it as a seed to offset the way you change the bits so that if someone starts to look at the channel data they wont see big blocks which would scream hidden data.
I like to think. In fact, thinking about things I think is what I think I do best, donāt you think?