Hi ho! I had a little idea today and I wonder whether there is any existing application for this. I thought of hiding data using a innocent file and a bitmap. The concept is: You take 2 files, a source file and a destination file (that you want to hide). These files are "layed on top of each other". You then create a bitmap file. For every bit where the source and destination match, the bitmap gets a 0, for every bit where the source and dest don't match you get a 1. You can then remove the destination. The original file can be recovered by laying the bitmap on top of the source file. Everywhere the bitmap has a 0 you take the bit from the source, otherwise you take the opposite of the source. Because only you know which file is the source file, you're the only one that can recover the data using the bitmap. I came with the idea because of certain governments are trying to make encryption illegal or forcing you to tell them your encryption keys. This is an alternative that, although you end up with 2 times the disk usage, is just as safe. So is there an app like this? Otherwise I'm going to write one in the future. Possible vulnerabilities 1. File size of bitmap The bitmap file is the same size as the destination file, so you know that the destination has the same size of the bitmap. Possible solution: The bitmap can be made larger, padded with random bytes. You must than either remember the exact size of the destination so you can cut the randomness back of, or you can use the first part of the file to store the length. The first bytes of the source file overlayed with the length will than give you the bitmapped size of the dest file. This is likely to be be implemented. File size of source file The source file must be at least as large as the destination file. Possible solution: Restart from the beginning of the source again. -> new possible vulnerability: you repeat parts of the source so it may be possible to find some kind of pattern. Implemented if found safe -> requires intensive research I guess? Common file types If someone knows the type of the sourcefile you used they know what the header of the source looks like and actually have part of the beginning of the source. The attacker can use that to retrieve the first bytes of the destination and get to know what type the dest is. Possible solution: Don't use the first part of the source file. Start at an offset behind where you know the headers of the most common file types end and where you know the data is pretty random/not derivable from the file type. Alternative An alternative to this whole concept could be to use xdelta. We must then remove all info xdelta knows about the source file (xdelta stores some info to check you really picked the correct source, this is a weakness in our case). These data must then be reinserted before patching, based on the source you picked. The disadvantage is that xdelta is also partly vulnerable to 1 (xdelta will never be larger than source) and 3. It is also likely that the delta file contains 1 to 1 portions of the destination -> BAD, VERY BAD! Apparently this is just XOR and should be fairly safe if the key (source) is not smaller than the dest.