Jump to content

Demonslay335

Emsisoft Employee
  • Posts

    132
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by Demonslay335

  1. The file was encrypted by an online key. Impossible to decrypt.
  2. From what I can look up, the .ts extension seems to be part of the MPEG format; which does not have a standard set of bytes at the beginning past the first 0x47. There's nothing else we can do at the moment in that case, if you cannot find a good original file to match one of those encrypted files that is skipped. The decryptor will tell you what the first 5 bytes of the skipped file are.
  3. The decryptor and the FAQ already tell you; decryption is impossible because it is an online ID. Only the criminals have your key.
  4. Those files have the same first 5 bytes as the first pair (4740001100). Thus, it will not help decrypt any other files that were skipped. The files that were skipped must have a different sequence of the first 5 bytes. The decryptor would tell you this as it skips them. You will need a good filepair with that same first 5 bytes in order to generate a keystream us to be able to decrypt the other files.
  5. Ok, filestream for that first 5 bytes sequence has been added to the server. [+] ID: 0aZtkyoY1nTxvQd50TNprSNj7jVZPwwCjh6KwJxo [+] Created keystream for files starting with: 4740001100 As for the "some vs all", that is answered in the FAQ. Applies for any file format that doesn't have a 100% static 5 bytes at the start.
  6. Ok, that was a good pair. You should be able to decrypt most of your MKV files now. [+] ID: 0aZtkyoY1nTxvQd50TNprSNj7jVZPwwCjh6KwJxo [+] Created keystream for files starting with: 1A45DFA301
  7. The encrypted file would be exactly 78 bytes larger than the original if it is truly the same file before and after the encryption. The MKV files you posted links to were the exact same file. Meaning the "original" was also encrypted. Per the FAQ on the submission page, if the files are too large to submit (generally >10MB), then you need to supply the filepairs for us to manually add to the server. I can see you have submitted valid filepairs for files starting with the following byte sequences so far: 0000001866 7B5C727466
  8. No need for the Visual C++ Redistributables for the decryptor. It isn't written in C++ using those libraries.
  9. @enzi The files you submitted are both the exact same file. You just copied the file and removed the .djvuq extension from one of them... that will not work. It has to be the same file before the encryption.
  10. Moreover it's actually just a scam... The "decryptor" he received was just a batch file that does absolutely nothing (the lab team got a good laugh, as did I), and the second one is an infected Mozilla Firefox installer that drops more malware. Do not run the "FireHunter" file.
  11. The encrypted files themselves are not malicious and cannot infect another system. However, STOP Djvu comes with several other malware that could have dropped themselves to the flash drive theoretically. They would still have to be some sort of executables that you actually run on another computer in order to infect them.
  12. @cheunghome Read the FAQ. If encrypted by an online key, only the criminals have your key. It is impossible to break.
  13. @Deepstate That is the offline ID for .npsg / .btos, but we do not have the key for it. @SalasKafa I'm not sure how you'd get that error in the middle of the decryption process. The decryptor reaches out to the server upon the first file it encounters, and never has to call out again unless it finds a file with a different ID. I still have to look into why a 403 would even occur. Are you sure the system is clean from malware? Perhaps something is interfering with the connection.
  14. Per the FAQ: Your .NET Framework is either outdated or corrupted most likely.
  15. @akin @thegambler Try running the decryptor again with an internet connection; we may have recently received the offline key matching that ID. 😉
  16. @SalasKafa Try running the decryptor again; we may have just received a key for that ID recently. 😉
  17. @Yosef Inmannuel You can DM me a zip of whatever they sent you to look at. I can guarantee either they paid the criminals, or are the criminals.
  18. As the FAQ clearly states, you have an online ID, and it is not decryptable. Only the criminals have your key.
  19. I've reviewed the logs, and am not really seeing anything to do with ChernoLocker. Lots of PUPs and adware, and pirated software that likely landed you in this situation. The "Ransom.FPL.Gandcrab.v1" detection seems to be an erroneous name from what I can tell - it is malware, but it's more of a backdoor Trojan and doesn't encrypt files. I'm afraid I don't have any ideas at the moment as to why the files were corrupted - as far as I can tell, the decryptor is restoring the files exactly to the state the malware encrypted it from. I would recommend holding onto the encrypted files in case something changes in the future though.
  20. It's something new, note does not look familiar. We need the malware executable to analyze any further. DANTE-INFO.txt ! ATTENTION ! -------------------------------------------------------------------------------------------- STRICTLY FORBIDDEN TO USE THIRD-PARTY DECRYPTION SOFTWARE - FILES WILL BE LOST -------------------------------------------------------------------------------------------- [email protected] ID KEY: [redacted 128 bytes base64] ~ L2 Protection ~ [redacted 16 bytes base64]
  21. You are still not following the instructions. Look at the filenames; they are clearly not the same file, the filenames don't even match up at all. promocion NOGHE.jpg.heroset promocionNOCHE.jpg It has to be the exact same file before and after the encryption. Check this quote by Fabian Wosar.
  22. I've done extraneous testing with the malware and our decryptor, and cannot reproduce any issues with decrypting files of any size or contents; they always decrypt to the exact match of the original file I let it encrypt. I can tell the files you provided are corrupted in some minor way, but it does not appear to be from the decryptor or the malware. I do not know the file formats enough to know exactly "where" the corruption is, but I can definitely tell the file that is output by the decryptor, is the exact file that was encrypted by the malware. The padding and size matches up. The only corruption I can tell myself is with 20170914_135554.jpg - the file was truncated or had something appended to it. The very last 2 bytes would normally be 0xFFD9, but there are 98 bytes after it (removing these does not remove the corruption). The malware stores the "original" filesize at the beginning of the file, and that matches up with the decrypted size - so the file had already been truncated/appended by time the malware got to encrypting it. The only thing I can think of at this point is that perhaps the exact malware that encrypted your files is altered from the sample I have. We would need the GridinSoft logs to confirm that, as @GT500 asked for earlier.
  23. I'd need you to send me the actual encrypted files (before decryption) that are having issues for me to look at that any further. I cannot reproduce any issues with decryption using sample data I let the malware encrypt. I don't see any bugs in the malware that would cause data corruption either from what I can tell.
  24. I've fixed the decryptor to no longer give the false-positive when it is really a New Variant (which .topi is). @akin Please read the FAQ. Everything there still applies to you since .topi is New Djvu. We can only get offline keys after a victim has paid and provided it to us. There's no "work" to really be done on our part. I'd recommend running the decryptor on some of your files maybe once every week or so; unfortunately we cannot announce to everyone as soon as we receive new offline keys.
  25. I don't quite understand what you are describing. Can you provide a screenshot of the main Decryptor tab after you've selected what to decrypt?
×
×
  • Create New...