Variation on the ECB Penguin problem So this is an age-old example of why encrypting images with ECB is a terrible idea, since the underlying pattern of the image remains the same. Referenced from: If you encrypt an image (AES), is it still an image and can you view it?

In this question, the answerer shows that is is easy to reconstruct an image (in the ppm format) with:

# First convert the Tux to PPM with Gimp
# Then take the header apart
head -n 4 Tux.ppm &gt; header.txt  
tail -n +5 Tux.ppm &gt; body.bin  
# Then encrypt with ECB (experiment with some different keys)
openssl enc -aes-128-ecb -nosalt -pass pass:"ANNA" -in body.bin -out body.ecb.bin  
# And finally put the result together and convert to some better format with Gimp
cat header.txt body.ecb.bin &gt; Tux.ecb.ppm


The variation in this particular question is that, 1. I do not know what the header is, and 2. The header is not separated from the image. 

To elaborate, let's say that I have a file called Tux.ppm which I encrypt as follows:

admin@ubuntu32:~/Documents$ openssl enc -aes-128-ecb -nosalt -in Tux.ppm -out image.bin
enter aes-128-ecb encryption password:
Verifying - enter aes-128-ecb encryption password:


Though it is not relevant to the question, for the sake of completeness, the encryption password used was foo.

Now, if I know what the header initially looked like, reconstructing the image is simple. Say, if I know that the header for Tux.ppm was:

P6
265 314
255


Then, if I simply create a new file, call it header.txt, add the above content to it, and execute:

cat header.txt image.bin &gt; sampleTux.ppm


Then sampleTux.ppm is still entirely recognizable:



Nevertheless, the illustrate a certain point, if I mess the header up just a little bit (e.g. modify the width to 275 and the height to 324), the image screws up beyond recognition.



Say that I've now been given a file called image2.bin. I know that this image was initially a PPM image which was encrypted like above (i.e. it was encrypted with its header). I know that it is a P6 type image which uses the 255 color-encoding format. What I don't know is the width and the height of the initial image, so I cannot construct a new header for it.

How can I create such an "ECB Pengiun" for image2.bin? How can I get information about its initial width and height without guessing it (if that is at all possible)? As illustrated above, that width and height has to be quite exact, otherwise the image completely distorted.

EDIT: In the interest of making better guesses. Assuming that the image not compressed and was created from a standard A-series (A4, A5, etc.) paper, I know that is has a ratio of length-in-millimeters = sqrt(2) * height-in-millimeters. Furthermore, it has a possible DPI of 72, 150, 300 or 600... which still leaves a lot of possibilities.

Maybe I could narrow down the possibilities further if I knew the amount of pixels in the initial file? Could I just get this information from the size of image2.bin or would I have to do something infeasible such as reverse-engineer the process which AES encrypted the file in the first place?
You cannot, at least not if that's the only encrypted image. ECB leaks information because repeated plaintext blocks lead to repeated ciphertext blocks. But it doesn't leak the information within those blocks directly.

So you could find the original size by finding another encrypted picture with the same header of which you already know the size. In that case the encrypted header should be identical.

Otherwise, smart guessing might be the best way forward. If you look at the vertical lines then there should be a high amount of repetition between one horizontal line and the next. Just shifting the image and selecting the one with the most vertical repetition should do the trick.