Jump to content

Demonslay335

Emsisoft Employee
  • Posts

    131
  • Joined

  • Last visited

  • Days Won

    10

Posts posted by Demonslay335

  1. 9 hours ago, cybermetric said:

    It also looks like @daemon3642 has removed the .drume extension from the encrypted files, which he/she should not have done. 

    No, he simply has "File name extensions" hidden in Explorer (it is highly recommended to change that...). You can see the "Type" shows as "DRUME File".

    As for the 404 error, it's an anomaly based on the files that were listed there. When the decryptor sees the STOP Djvu filemarker ("{36A698B9-D67C-4E07-BE82-0EC5B14B4DF5}") in a file, it takes the extension and asks the server "hey, is this Old or New Djvu?" (if it hasn't already asked for that extension). Apparently, those files had the filemarker, but no appended extension. There seems to be a security thing with the server engine that instantly rejects image extensions such as ".gif" for that parameter instead of letting my code handle it. I'll look into it, but it may be out of my control for the time being. Either way, it doesn't affect you much since those files were just in your Recycle Bin.

    As the decryptor told you for your .drume files, it is Old Djvu, and you need to follow the instructions for uploading file pairs as Amigo-A said. You specifically need to upload an encrypted/original file pair for either a DOCX/XLSX/PPTX, or ZIP file, as those all start with the same first 5 bytes (which is why it is telling you what they are).

     

    Edit: the 404 error has been fixed.

    • Thanks 1
  2. The FAQ already explains this...

    Quote

    What is a file pair? This refers to a pair of files that are identical (as in they are the exact same file), except one copy is encrypted and the other is not. Our decryption service can analyze the differences between an encrypted file and an original unencrypted copy of the same file, allowing it to determine how to decrypt that type of file. For most victims with an older variant of STOP/Djvu, submitting file pairs will be the only way they will get their files back.

    File pairs only work for one type of file. Due to the way encryption works in STOP/Djvu, file pairs can only help the decryption service figure out how to decrypt one type of file. For instance, if you submit a file pair for an MP3 file, then the decrypter will be able to decrypt all of your other MP3 files, however it won't be able to decrypt any other type of file. There are some exceptions to this, such as certain newer Microsoft Office documents (such as DOCX and XLSX) since those files are technically ZIP archives.

    The decrypter can't decrypt all of my pictures even though I submitted file pairs for them? JPEG/JPG images have a format oddity that causes file pairs to be specific to each source of pictures, rather than the file format in general. As an example, if you have pictures from two different cameras, and submit a file pair from the group of pictures from one of the cameras, then the decrypter will only be able to decrypt files from the camera that the file pair came from. In order to decrypt all JPEG/JPG images, you will need to submit file pairs from every source you've obtained those pictures from.

     

  3. On 3/29/2020 at 6:39 AM, Van said:

    I don't understand why this apparently "basic" issue look unsolvable: those 2 ransomware are pretty close, I can barely think that even they've not been made by the same guys, one is currently a copy of the other. if it's not the case, why keep suggesting that you have a decryptor for Megalocker whereas it can only work with the NamPoHyu? Change the name please, because you create more disappointment than something else.

    They are the exact same malware, just different names; the only thing that changed was the extension. The reason we are able to decrypt MegaLocker at all is because we acquired keys from the criminal's servers. Period. They then changed servers and locked it down better, and continued attacking victims. We do not have keys for victims encrypted after that date, as only the criminals have those keys.

    The crypto itself is otherwise secure and cannot be broken any other way without the keys.

  4. The encrypted files themselves are not infectious or anything.

    It's always recommended to archive encrypted files in that case in hopes of something changing in the future; unfortunately with STOP Djvu and the new variants with online keys, your only chance will be if the criminals are caught and their private RSA keys seized by law enforcement.

  5. The files that were decrypted would have been encrypted by the offline ID... as explained in the FAQ, the malware sometimes encrypts some files with an online key, and others with an offline key. Those 3 files just got lucky.

    The decryptor would not show the ID if it decrypted them; only if it could not decrypt the files.

    • Thanks 1
  6. Are you sure the file pair you are providing is good? It has to be the exact same file before and after the encryption. Any modifications between that and when it was encrypted would result in a bad pair.

    You can zip the files together and post them here if the forum allows (use a third-party sharing site if it doesn't), and I can take a look.

  7. Perfect. Confirmed that is the ransomware. Good news is we should be able to break it. :) It may take awhile though.

    Can you provide me with an encrypted file and it's original? Specifically an ".encryptedS" file please.

    Also, fun fact: the ransomware uses extension ".encryptedL" for files larger than 50,000,000 bytes, and extension ".encryptedS" for files smaller. Must stand for "Large" and "Small" respectively.

    image.png.ef1b0439893e8ad56244c6db24d443e5.png

×
×
  • Create New...