CryptorBit Malware Analysis, Decompile, and Encryption crack
For the last 6 months the general public who uses the internet has had to either deal with Cryptorbit, or fear that they may be infected with it. There is a lot of information about CryptorBit on the internet but weirdly nothing seems to be consistent. Some sites say that the infection simply scrambles your files header and is unrecoverable. Others say that the file is corrupted and doesn’t use an encryption at all. Neither of these statements are true and you are about to learn why, and a whole lot more.
For the last 5 months I have been battling CryptorBit, and I won’t lie, it started to become personal. I myself have never been infected with this infection, but with the amount of people I was trying to help there were, giving up was not an option.
Before I begin my analysis, I would like to point out how unique CryptorBit is. CryptorBit’s Decrypter used a custom Obfuscation, along with traditional methods which made reversing horribly difficult, so bad that most of the reversers I ask for help said it just wasn’t worth it and to wait for a dropper. Now here is another interesting part, 6 months old and not a single dropper has ever been found, so something had to be done.
My first month into this infection, I collected a large number of victim’s encrypted files. This is always my first step with encrypting infections. The main reason for this is to see what kind of information I can gather from the encryption scheme from the files alone, and even if I get nothing, I have loads of files to test with later.
Looking at my first CryptorBit file I see this:
Knowing that most headers in files can be rebuilt, I decided to create an application to fix files where possible for users to try for now. It wouldn’t fix all files, but it worked great for a lot of users while the wait for a real fix was happening. This application can be found at Anti-Cryptorbit V2
My first step is to eliminate any lower level encryptions, so after going through a encryption schemes, it was found that if you XOR the first plain text byte from a good file with an encrypted byte, it will give you a byte that you can use to decrypt the first byte of all encrypted files with that key. For example:
Reversing CryptorBit’s Decrypter... Kind of
After waiting a couple of weeks it was apparent that a dropper wasn’t going to show its face anytime soon. So I offered a victim to pay for half of his ransom if he would also send me a copy of the decrypter that was sent to him. He accepted, and 0.8 BTC later, I made contact with the author for the first time when a decrypter was sent to an email I made. He is quite cocky by the way.
With a shiny new decrypter, I was ready to start a real analysis of CryptorBit’s methods. I couldn’t open up IDA fast enough, until when it actually did open and I got quite disappointed fast. This exe was the most oddly obfuscated assembly I had ever seen. After seeing this, I asked for help from a few very good reversers, and they also said it was to horribly obfuscated to bother with. Between the endless Sub jumps, Fake returns, corrupt stack, and encryption, it was hard to tell what was real or garbage. The only thing I had found at this point was the DWORD that held the either 8 byte or 20 byte key.
I wasn’t too excited to start the decompiling process of the exe, so instead I decided to do some outside analysis. I had been talking to someone through email who proved to give me a lot of good ideas, (I won’t mention his name as I do not know if I have permission.) These ideas consisted of running the decrypter against a blank file of 00’s and also generating a truth table. So running the decrypter against a blank file showed no patterns, no surprise there, But when changing a single byte changed the bytes after it. This pointed to some type of chaining method in the encryption. Wanting to follow this lead more I needed to record the changed for every byte (0-255) for multiple locations in the file, and build a truth table. Being as how I am lazy I decided to build an application that would assist me in this.
This application helped me save a tremendous amount of time while analyzing the encrypted files. With the ability to run the decrypter on demand, make blank files with a header matching the decrypter, change blank files bytes while decrypting, plain text and encrypted text repositories with compare features, automatic truth table generation based on changed bytes, and a built in hex editor, it allowed me to quickly figure out more about the encryption scheme. It will defiantly go into my tool box for the next unknown encryption infection and was well worth the time building.
So after gathering a lot of information off the application, it was found that the encryption used previous encrypted bytes in the key it was encrypting with like a type of feedback. It was also very apparent at this point that the encryption used XOR, but in a very weird secure way. I found previously in the assembly of the exe that V1 used an 8 byte key, and that V2 used a 20 byte key, but it was quite obvious from the application information that it wasn’t being used directly, but to somehow propagate a larger key, And the bad news was it was becoming more and more apparent that these files were not just encrypted once. At this point I had squeezed out everything the files could tell me, and I had to move on.
Disassembly/Decompiling of Cryptorbit
After taking a break for a few weeks I decided to come back to Cryptorbit’s nasty assembly code and give it another shot. I guess a break does the mind good because it wasn’t long until I found this:
When I stumbled upon this function everything seemed to fall into place in the assembly. I was able to start removing junk and start seeing the structures of a normal application’s assembly. When I had everything cleaned up and the application still ran as it should, it was time to start decompiling it to C# to make things easier. Let’s skip ahead a week to the fully decompiled decrypter.
After a week I had a fully working solution of the decrypter in C#, and I knew exactly how this infection ticked. It turns out that the encrypter and decrypter and actually the same functions reversed (Go figure) and that the virus creator had made his own custom encryption in a way. With the mixture of feedback from the file, encryption chaining, and multiple encryption runs, he had turned a simple XOR into a pretty secure encryption. Let’s break it down:
First the key is broken apart into a 5 count array with 4 byte (8 bits) in each value, and then we specify what file we want to decrypt. After the key is loaded into the array the application calls “TableGenerate” which will then generate 3 tables from the key.
While in “TableGenerate” all values in the key array has their bytes order swapped. Then the first value of the key array (key) is used to make 2 values that is then used to generate Table1, Which is only used to verify the header of an encrypted file and not used at all to encrypt a file. After Table1 is made the next 4 values in the key array (key, key, key, key) is used to generate Table2, which is used to encrypt. When table2 is done, the next table that is generated is Table3, but table3 is only generated from the previous Table2
After the tables are done generating it’s time to start the decryption process. The file is opened are read entirely into an array, which is then immediately checked to see if it is encrypted by reading the first 8 bytes (Which is the first 8 bytes of the garbage header) and comparing it to previously generated Table1. This is the only thing that Table1 is ever used for. I think it is a little silly generating 512 bytes to use 8 of them, but hey, it’s not my infection I guess! If the file is then verified as being encrypted by CryptorBit with this key, then the application then copies the last 512 bytes from the file array to a different array named “Block1”. This is the original file 512 byte header but encrypted, the reason it is at the bottom is because when the file is encrypted the first 512 bytes are encrypted and moved to the bottom of the file, and then the garbage header replaces its original spot. After the header is loaded into “Block1”, the application then copies the 512 bytes right under the garbage header from the file array. This makes an array of an encrypted version of the first 1024 bytes of the file.
Now that the first files first block of encrypted data is loaded into the array (1024 bytes) the application will now run through the process of decrypting the data. First Table3 is copied to a temporary array so that any modifications made to it during the decryption of “Block1” will not apply when decrypting the next block of encrypted data. Then Table2, which is an array of bytes, it converted to a table of unsigned integers which are all at least 8 numbers long in value, and now comes the decryption. The first decryption pass (Decrypt1) takes 2 uint’s, which are 0x10 and 0x11, out of Table2I to decrypt the data. Then the second decryption pass (Decrypt2) uses Table3_ to decrypt the data again from Decrypt1. Finally, the third decryption pass (decrypt1 again) takes 2 uint’s, which are 0x20 and 0x21, out of Table2I to decrypt the data. After this last pass, Block1, or the first 1024 byte of the file, is now completely decrypted.
Now back to the application. After decryption of the first 1024 bytes is complete, it’s time to move onto the next 1024 bytes. The application moves to the bottom of the File array, skips 512 bytes, and then reads 1024 bytes into the “Block2” array. The reason it skips 512 bytes is because, those bytes are the original file header that was decrypted in the last function. After it reads the 1024 bytes, it then resets the Table3_ array with the original Table3 so that any modifications made in the last decrypt functions are no longer there. Finally, the decrypt functions are called. There is no reason to go into detail for these because they are the same as the last decrypt functions, just with different key/uint values.
Now that the last 1024 bytes are decrypted (2048 bytes total for V2), it’s time to write the decrypted data to the file to complete the process. The 2 “Block’s” of decrypted data are used to overwrite the encrypted data in the file array (FbuffC). The array is then trimmed 512 bytes to get rid of the extra space the garbage header caused. With the complete original file now in the array, it is then written to the file, and thus ends the decryption process.
Knowing what I do know after fighting this infection for months, I was able to create a crack for V1 of CryptorBit so far. I cannot share the fix method publicly for a number of reasons, but as you have heard, you can email me at any time at Decryptorbit@outlook.com with an encrypted file sample and the original version of that file, and I will email you an application along with a key file to decrypt your files. Interested in getting a key? Please read these instructions to get started!
Im still currently working on a crack for V2, but i have little time these days, and I always accept help when possible. If you have read this analysis, and believe you have spotted something that would help in this area, please do not hesitate to email me to share your findings if you want to, as I will not stop until it is also cracked!
Disassembly/Decompiling of Cryptorbit
The virus creator has emailed me back and forth from time to time. When V1 was cracked, this was one of those moments. He challenged me to break V3 (really just v2 with a new Personal ID). When I accepted this offer and let him know I wouldn’t stop until it was cracked, he simply replied that if I did, he would just switch CryptorBit to RSA encryption. Yeah, he is quite the party pooper..
End of Analysis
Cr. DecrypterFixer (Nathan Scott)