A JPEG that becomes a PNG after AES encryption and a PDF after 3DES decryption | Hacker News Reader

A JPEG that becomes a PNG after AES encryption and a PDF after 3DES decryption

code.google.com

240 pointssoundsop27 comments

Open articleView on HN

See also The International Journal of Proof-of-Concept Or Get The Fuck Out.

https://archive.org/details/Pocorgtfo00

https://archive.org/details/Pocorgtfo01

https://archive.org/details/Pocorgtfo02

https://archive.org/details/pocorgtfo03

https://archive.org/details/pocorgtfo04

https://archive.org/details/pocorgtfo05

For the uninitiated, some of these files are bootable (on x86), or contain other goodies hidden somehow. These are written (or collated) by Travis Goodspeed - travisgoodspeed.blogspot.com

This blog is amazing! Very motivating. Thanks for sharing.

The file in question: https://corkami.googlecode.com/svn-history/r1906/trunk/src/a... (direct download, 173kb)

Imgur mirror: http://i.imgur.com/jUEAygp.jpg

People are going to be mighty confused if they try to use that, imgur re-encodes all of it's images uploaded.

Even JPEGs? That would explain some of the bad quality images on there. Or do they re-encode without recompressing, à la jpegtran?

They do compression on big images IIRC

Yep, 45KB vs 143KB.

Lol that's funny: I took my math classes exactly in that building. University of Applied Sciences, Darmstadt, Germany. www.h-da.de

How in the hell does one discover that kind of thing? :) I don't really know much about crypto and symmetric ciphers in general, but aren't the odds of discovering something that converts from JPEG to PNG by applying AES extremely small? Let alone something that ALSO goes from JPEG to PDF by applying 3DES.

I presume there is some algorithm based on the nature of ciphers themselves?

Only the file headers need to be valid, and generating a new file is as simple brute forcing encryption with random keys and then checking for a minimal correct file header.

I didn't check this demo in particular, but I have seen this trick before. The first observation needed is that you can insert an arbitrary block of data into the picture without changing how it renders. The second observation is that AES is a symmetric algorithm, meaning decryption is the same operation as encryption. Using this, you can encrypt the PNG, and embed the result in the unencrypted JPEG. Then, when you encrypt the JPEG, you encrypt the embedded PNG.

There are a couple of complications to this. The major one is that both formats require correct data near the begging of the file. The size of this region is small enough that it is feasible to brute force passwords until you find one that works.

AES encryption is not the same as decryption.

You get the definition of "symmetric" wrong. Symmetric encryption refers to using the same key for encryption and decryption, as opposed to asymmetric, aka public-key encryption. By no means AESEncrypt and AESDecrypt are the same functions.

That said, some encryption modes employing AES, like AES in CTR mode, are based on generating a pseudo-random keystream and XORing it with cleartext to get the ciphertext. The inverse of that operation is itself, but that has nothing to do with the term "symmetric encryption". This particular case uses AES in CBC mode, which is not symmetric in that sense.

There is a difference between "symmetric key encryption" and "symmetric encryption".

Is there? The usual term for what you're describing is a "stream cipher" or a "streaming-mode cipher".

I think the objection here comes from not stating that it's AES in CTR mode.

AES is not a symmetric algorithm, AES in CTR mode is.

The other poster was talking about a stream cipher...

However, I'd point out that DES is a block cipher (thought it can be turned in to streaming cipher much like AES), and its decryption is encryption is with the keys in reverse order. This is how triple-DES can work as it does.

The trick is that the encrypted JPEG data is not PNG data. The file is usually crafted in such a way that the container formats are tolerant of the junk data that becomes the second file after encryption. The second file's format is also tolerant of the junk data that used to be a JPEG. Some parts may actually be used on both sides of the transformation, but not most of the bits.

PDF is particularly lenient, so I'm not surprised about that. But the JPEG-to-PNG trick must involve some brute forcing.

The slides in the same repo may help.

https://code.google.com/p/corkami/source/browse/trunk/src/an...

Previous discussion: https://news.ycombinator.com/item?id=7775015

tl:dr I'm a fanboy of Corkami and just wanted to show appreciation.

Ange Albertini does some amazing research and I was orginally introduced to his works after reading POC||GTFO from a Talk Travis Goodspeed gave. Recently Corkami did a giveaway on twitter for a signed mini-poster (Corkami's Posters are amazing as well highly recommended!) Fortunately I have a signed mini-poster en route to my mailbox cannot wait to have that thing framed.

The raw file:

* (JPG) https://corkami.googlecode.com/svn-history/r1906/trunk/src/a...

Does anyone know what block size is needed, IV, cypher mode?

The python file in that commit shows you everything you need: https://code.google.com/p/corkami/source/browse/trunk/src/an...

GOD WHERE IS THE PICTURE IM FREAKING OUT

Reply on news.ycombinator.com