Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by GeorgeB

  1. My name is GeorgeB and I'm not a cybercriminal. Also I'm not a victim of this ransom virus. I want to help someone that ignored my advice about real backup solution. When he lost all data he wanted to pay ransom. My advice was: "Do not pay for ransom!". While we are debating that is right or not to share knowledbe about how this ransom works autors build new versions, becouse they share their knowledge each others. I think that is nothing wrong to study and share. Great discoveries have come from people who do not know that one thing is impossible.
  2. 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.
  3. Analyzing small files I noticed it encrypts on blocks of 16 bytes. Example:
  4. Please PM to me decryptor an your key. Thanks!
  5. Please send these files. I cannot download from original post. Thanks.
  6. Nice work, Let's name this variant CRY36, Please confirm that this variant crypt files in 32 byte block and only first 320 blocks of 32 bytes(10k). Please share any knowledge about how this variant works. Thanks
  7. Dear Mclaugb, Please share unlocker ,key provided and sample of encrypted files. I want to try to dissasembly unlocker. Thanks!
  8. What is last 35 bytes at the end of encrypted files (in my case is 31 of 00 and EF 52 5E A0)?
  9. Constant to all files encrypted. In my case all files have 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EF 52 5E A0.
  10. I cannot download these files. Please confirm that last bytes in encrypted files is EF 52 5E A0. Thanks!
  11. Mcl Please send infected exe archive to me. I want to let it to encrypt some files in vm.
  12. Same problem here. After a short view files are crypted in blocks of 32 bytes. If file is larger than 320 bloks of 32 bytes (10kb) rest of file remain uncrypted. At end of file 36 bytes is added, first byte differ from file to file and rest of 35 bytes are the same (00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EF 52 5E A0). If file size does not divide exactly to 32 then last block of less than 32 bytes remain uncrypted. samples.rar
  • Create New...