Background

Background

A couple weeks ago, my grandfather emailed me saying that many of his personal files had been corrupted and he could no longer open them. He happens to live on the other side of the country, but he sent along a few files as a sample and asked if there was anything I could do to fix them.

Investigation

The files all had the form [OriginalFileName].[OriginalExtension].crypted. My first (overly hopeful) thought was that something had simply changed the extension so that Windows would not know how to open the file. It turned out that this was not the case and something had definitely scrambled the internals of the files.

I opened a couple of the files in a hex editor and was surprised to notice some plaintext floating around. The files were not totally corrupted after all.

After fruitlessly trying to compare the sample encrypted files to valid .xlsx and .pdf documents I created, I decided to work with my grandfather to locate backup files of some of the encrypted ones. He succeeded in tracking down two backups and sent them to me along with their encrypted counterparts. Comparing the valid and encrypted files in the hex editor, I figured out that the virus had only corrupted the first 2048 bytes of each file.

I'm no cryptography expert, but I knew that XOR encryption was a thing. Just as a test, I XOR'd the first few bytes of a valid file with its encrypted counterpart by hand and then tried to use the result to decrypt first few bytes of a different encrypted file. Somehow I messed this up, got an invalid result, and assumed that the files were not encrypted with XOR encryption (they actually were, but more on that later).

Initially I assumed that the encrypted/corrupted portions of the files were lost for good. But two kilobytes is a small percentage of most files, so I began trying to salvage the remaining good parts of each file.

My first thought was to create a valid file of each type (.xlsx, .docx, .pdf, etc.), and then programmatically merge the first 2048 bytes of the valid file into the encrypted file. I hoped that this would correct any file headers or other definitions that may have been corrupted. Unfortunately, this strategy failed because the first two kilobytes of a file may contain important structural information and often the valid bytes did not line up correctly in the merged file.

Instead, I decided to try merging the files by hand and thought that I might be able to salvage some of my grandfather's most important files this way. After a weekend's of struggling and learning about the internal structures of .pdf's and .xlsx's, I had only managed to fix one file.

Now getting a little frustrated at the lack of progress, I turned my attention once again to decrypting the encrypted portion of the files. I thought that maybe I could buy some cloud computing time and try to brute force a solution.

This lead me to searching for more information on the virus, where I eventually came across this technical analysis. The analysis told me that the virus did indeed use XOR encryption to encrypt the first one or two kilobytes of the files, depending on the version of the virus.

Solution

Armed with technical knowledge of the virus, I wrote a quick proof of concept application that XOR'd the first two kilobytes of a valid backup file with the first two kilobytes of its encrypted counterpart to produce a decryption key. Then I used that decryption key on a different encrypted file to produce the original, unencrypted version.

With a successful proof of concept, I quickly wrote a simple Windows Forms application that performed the same logic. The tool worked on all of the sample encrypted files I had, so I sent it to my grandfather with instructions on how to use it. He got back to me the next day saying that the tool worked and had decrypted all of his files successfully.

Mission accomplished.