Leaderboard

None of the products tested by AV Comparatives are downright bad. In fact, AV Comparatives requires every participant to be "good" to even be considered for participation. So it is not surprising that there aren't any drastic difference between the products. User dependent detections are all detections where the user is given the theoretical opportunity to pick the wrong option and gets himself infected. They ignore recommendations in those alerts completely. So even if there is a clear recommendation to quarantine, it is counted as user dependent. As a result a lot of AVs adopted a "better to ask for forgiveness than permission" approach to alerts and will blindly quarantine everything first and give the option to restore from quarantine later than to ask the user what he wants to do first like we do. You can configure EAM to use the same approach by adjusting the File Guard settings to "Quarantine with notification" and the Behaviour Blocker to "Use the recommended option" automatically.

I have studied the behavior of the decryption program (unlock.exe) and have noticed some aspects of the decryption key structure. To match ID and KEY: 1) At the beginning of the key is the ID in HEX followed by the character "_" (0x5F) 2) The last byte must be 0x00 3) If any byte is changed in the range between 0x5F and 0x00, the key is accepted. 4) If you delete bytes from this interval (shorten the key) the key is accepted. Considering these I produced a fake key corresponding to Id 1: ID: 1 KEY HEX 315F00 KEY ASCII 1_ (null) When we click on the "Unlock One" button, the error "Access violation at address 005CC02E in module" unlock.exe "is displayed. From here I have concluded that a minimum length is required. Let's extend the key and test it: ID: 1 KEY HEX 315F0000 KEY ASCII 1_(null) (null) When we click the "Unlock One" button, the key is accepted and we are invited to choose the encrypted file (whose original name we modified to match the id 1: testfile.txt.id_1_gebdp3k7bolalnd4.onion._) The content of the file is modified (decrypted with a wrong key), the extension is modified correctly in testfile.txt but the last 36 bytes from the end of the encrypted file are not deleted. The next test is the incremental addition of bytes in the key. From successive increments we reached the following key contents: ID: 1 KEY HEX 315F + 48x (0X00) + 2 * (0X00) 315F 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 0000 KEY ASCII 1_ + 48 x (null) + 2 x (null) This key is accepted and this time in the decrypted file the last 36 bytes are also removed, but obviously with the fake key the decryption is incorrect. I do not know if what I have exposed is helpful but I hope to help and encourage those more experienced than me.

Decryption keys are infection and system specific, they are of no help to anyone other than the victim.

It's been over a month. They can't crack this one. I suggest if you want your files back to try the Proven Data Recovery company as someone mentioned earlier in this thread. Please report back with your experiences with them.