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 > header.txt tail -n +5 Tux.ppm > 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 > 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
Now, if I know what the header initially looked like, reconstructing the image is simple. Say, if I know that the header for
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 > sampleTux.ppm
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?