Can encryption be reverse engineered from before-and-after files?
December 28, 2017 7:38 PM   Subscribe

I have a large selection of encrypted files along with their original unencrypted versions. Given enough of these pairs, is it possible to derive the process used to transform one into the other? And (preferably) reverse it to decrypt other files encoded the same way?

Last week, I was hit by some ransomware which encrypted a boatload of my files. Fortunately, I have enough redundant copies on various drives that I didn't lose anything major.
But this means I now have a whole lot of files in both their original AND encrypted versions, and a good diversity of sizes and formats (all the way down to 0-byte files which grew to 188 bytes when ciphered). And, since I do have all this data...

I do want to clarify that this question is primarily borne of intellectual curiousity.
Restoring some of my encoded files is a nice-to-have, but none of them were worth paying extortion for -- and I've made my peace with that.
posted by cheshyre to Computers & Internet (9 answers total) 1 user marked this as a favorite
 
If your attacker used best practices, no. If they were incompetent and/or lazy, maybe.
posted by qxntpqbbbqxl at 8:05 PM on December 28, 2017 [1 favorite]


This would be an example of a known-plaintext attack. Modern, well-implemented encryption algorithms should be extremely resistant to such an attempt, especially if you don't have the computing resources of the NSA.

If your files were encrypted with a one-time pad (they certainly were not), getting the key would be as simple as XORing an unencrypted and encrypted file.
posted by dilaudid at 8:06 PM on December 28, 2017 [2 favorites]


It depends on how they are encrypted, but generally no, it's not possible.

Generally speaking, encryption takes your data and transforms it using a secret key. Unless you know that key, you're in essentially the same position as if you didn't have redundant copies. Without redundant copies you could still check 'is this output with this key that I'm testing a valid file format', etc.

A weak cryptographic algorithm might be easier to crack if you have 'before' and 'after' data, but it would likely require an impractically large amount of computing power, or an extremely bad algorithm. Like dilaudid mentioned, this is known as a known-plaintext attack.
posted by so fucking future at 8:08 PM on December 28, 2017


In short, no. This is a known plaintext attack. This is one of the things that all modern cyphers are designed to be resistant to.

If the person writing the ransomware was especially lazy or incompetent, possibly. But it's so easy to do it right, it would be hard to find someone who could even write the ransomware that couldn't do the encryption right. If you were the NSA, you might have a better chance.
posted by mrgoat at 8:11 PM on December 28, 2017 [1 favorite]


Given a theoretically flawless cipher implementation, no, not a chance. In messy reality, maybe? ¯\_(ツ)_/¯

You are describing a known-plaintext attack.

You might derive some inspiration from the Cryptopals Challenges.

There have been a number of blog posts & articles by security researchers attacking the security of the overall ransomware system (recovering keys, discovering a kill switch or other ways into the command & control infrastructure, or other covert or side-channel attacks on less-than-perfectly implemented systems).

In a fiction setting, this is touched on in Cryptonomicon by Neal Stephenson, which has some basis in the real events of WWII cryptanalysis. In a historical setting, known-plaintext attacks were effective on simple or poorly initialized crypto systems. Even some systems which were well constructed for the time were used to transmit fairly redundant data.
posted by books for weapons at 8:19 PM on December 28, 2017 [2 favorites]


Do you have the code for your particular ransomeware stashed away? In principle you could go through the code and reverse engineer the encryption scheme and look for weaknesses.

But as everyone else has said, given a well designed encryption scheme just having plaintext / cyphertext pairs isn’t enough to recover the encryption keys.
posted by pharm at 2:54 AM on December 29, 2017


Some of the encryption methods have been cracked. You can see what version you had and see if there's a reversal available. I'm on my mobile, will look on my regular computer later for the link.
posted by theora55 at 3:57 AM on December 29, 2017


No More Ransom is a good place to start if you are looking for keys for a ransomware variant that has already been cracked.
posted by LightMayo at 5:50 AM on December 29, 2017


Given enough of these pairs, is it possible to derive the process used to transform one into the other?
Yes. It is usually possible to determine the method used to encrypt the files by examining the encrypted files, often even without the plain text. The typical method used in ransomware is to use AES to encrypt the data and then to use a more sophisticated algorithm (typically RSA) to encrypt the AES key and prepend it to each encrypted file. This is likely the case in your example based on the 0 byte file growing to 188 bytes.
And (preferably) reverse it to decrypt other files encoded the same way?
No, not unless they are phenomenally incompetent. You'll need the attackers private RSA key to decrypt the AES key used on your files. There have been a few notable examples of gross incompetence by malware authors. For instance, the CryptoDefense family of ransomware accidentally stored the private key on the victim's system during infection and failed to delete it, so there was a fairly trivial path to restore those files. The very first ransomware only used AES and typically left the key on target computers to make it easy for them to decrypt when paid and were easily defeated. Most recent infections are part of the CryptoLocker family and those encryptions are generally impossible to reverse.
posted by Lame_username at 8:42 AM on December 29, 2017


« Older Secure doormat   |   Sustainability for our corporate overlords Newer »
This thread is closed to new comments.