Like any good software, developers strive to evolve each version to become stronger, better and have more options.
Researchers found Petya would manipulate the Master Boot Record (MBR) to take over the boot process and then encrypt the entire hard disk after a reboot.
Researchers found the reboot was essential to the encryption process and file recovery could occur if the user prevented the reboot.
Now, that weakness does not exist. Petya operators bundled it with another ransomware, called Mischa, which encrypts user files one by one. Thus, in the event Petya was unsuccessful in encrypting the entire disk, Mischa would function as a failsafe.
Right from the start, Petya has been using the Salsa20 stream cipher to encrypt the Master File Table and make the compromised disk inaccessible. However, it also contained a series of implementation bugs that rendered the encryption algorithm weak, making it possible to recover data without paying the ransom.
Petya no longer includes such weaknesses, but instead comes with a proper Salsa20 implementation, security researcher Hasherezade said in a blog post on Malwarebytes Labs’ blog. The ransomware’s behavior hasn’t changed from the previous variants, but bugs spotted before are no longer in the code.
One major bug in the previous version was the result of an invalid implementation of the function s20_littleendian, resulting in only 8 out of 16 characters of the encryption key being meaningful, thus opening the door to brute-force attacks. The current Petya release, however, contains a fixed implementation, meaning that previous decryption tools are no longer usable.
Petya returned to using 32 byte long Salsa key instead of 16 byte long key. The initial release used the longer key but generated it from the 16 byte long key, Hasherezade said. Now, Petya authors went back to using 32 byte long key, but also implemented a more complex pre-processing algorithm compared to the original ransomware release.