For each byte we wish to reconstruct, we read the next eight bytes of stegged data, taking the lowest order bit out of each one and ORing it back into our reconstructed byte. We then add the reconstructed byte to an array of rebuilt secret message data.

You may wonder how we know when the end of the secret message data is reached... this is where things get a bit complicated. During your steg process, you probably want to write out some kind of stegged header along with the stegged data so that you know when to stop reading during the de-stegging process.

You may also wonder how much the code changes if we want to be able to consume a variable number of bits per byte, instead of a fixed number of 1. This is where things get a lot complicated. Read on for the grisly details.


If you've gotten this far and are still reading, I'll assume you are interested in learning more about how steganography works. If so, I invite you to check out my StegPng project (this is not an advertisement - I don't make any money off of StegPng or anything else on my website... I'm literally doing this for the fun of it).

StegPng includes variable data compaction (this is the number of bits per byte to "consume" in the container data), and comes complete with full source code so you can take it apart and tinker with it if you please.

Personally, my interest in steganography is academic, not practical, and this is reflected in the design of StegPng - simple statistical analysis of the container image would probably reveal the presence of a secret message within a stegged PNG image. So let me preemptively defend myself against anyone who might accuse me of helping out the terrorists - StegPng is a neat idea, but without some serious modifications it is probably useless for serious covert communication.