Jump to content


  • Posts

  • Joined

  • Last visited


0 Neutral
  1. In your 1st post you just posted the link to the pinned topic and that pinned topic says nothing about it only applying to the 'original' version, hence my assumption that the paragraph I highlighted applied in my case. So while you didn't imply it directly, it certainly was possible for a person to reasonably conclude that it was as the pinned post itself did not make that distinction (it should be updated to make that distinction clear). In your 2nd post you then made the distinction between the original variant and subsequent versions, a subsequent version being what had infected my computer. @cybermetric has understood this to also be the case hence his comment which correctly states the current situation.
  2. Hi, thanks a lot for that link. The part that reads "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." Thats what i've been asking about and everyone else here and on the other websites forum is saying can't be done but clearly it can, at least enough times to make it a viable option to try. So is there a URL i can upload the file pairs and have them decrypted please, even if takes a while?
  3. I've noticed that at the very end of my encrypted files there is always this string '9lyMI9DR16ACIMHpqdX5A6dGT7Ez05g7JSKtgFFo{36A698B9-D67C-4E07-BE82-0EC5B14B4DF5}', (my bolding). The 1st part are the majority of the 'online ID' my ransomware readme.txt note told me about, but what is the string in the {}?? Does anyone know?? That string is consistent too across files. Could it be the decrypt key???
  4. Ok, if 2 identical files in different directories are not encrypted the same then that does change things, makes it much harder. Thanks. So, if i know how (&where) i got the virus should i publish that or tell someone?? I also have the downloaded zip file that contains the virus exe.
  5. Its not about calculating the key, its about bypassing it altogether and figuring out the rules the algorithm uses possibly. Let me make it simpler: I file 'A' exists in 2 different directories and they are identical files, so copies or duplicates of each other, name, dates, contents etc. Then when the encryption virus runs through those 2 directories, would those 2 files end up being encrypted in the exact same way, ie would they still be copies of each other, but just encrypted now of course, so that when viewed with a hex editor, the 2 encrypted files would be seen to be identical ie identically encrypted ??
  6. Well just how sophisticated are the algorithms used by the viruses?? I'm thinking that the virus would have to treat each hex character more or less the same assuming its using 1 key. So it takes a hex character (or characters) and puts it thru its algorithm & encryption key to give a result. But if it then comes across that same set of characters again later in the target file then the algorithm + key should give the same result. It can't have a random number seed or time value as otherwise that needs to be recorded for decrypting as well or else decrypting becomes too difficult. Consequently comparing a few good files (from back up) with a few bad files (same files of course) should reveal some aspects of the algorithm rule used which may assist in retrieving data. Incidentally, if i know how (&where) i got the virus should i publish that or tell someone. I also have the downloaded zip file that contains the virus exe.
  7. Hi Amigo-A, thanks for replying. I have both good and bad copies of the same files, can i forget about trying to recreate the key but just focus on figuring out what the encryption algorithm does. Do these algorithms typically follow a few rules that can be derived by comparing files? In principle, if i have a good file with all possible hex values in it and expose it to the virus, then afterwards when comparing the now encrypted file to the decrypted version could i say that for each hex character, it changes it to whatever, so that regardless of rules I know that whenever I see a hex AA then I should change it back to a hex BB as an example. I suppose that if my bait file had every hex character in there at least 3 times and if after, each was changed consistently, then I should be able to change the file back. However if the virus encrypts each instance of a hex character differently then that would make figuring out its rules much harder. regards
  8. I have been infected with ransomware. The PC has been cleaned now, from a backup image, but has encrypted many data files with .tisc extension. For about 60% of the data I have backups so can recover that easily but the other 40% is not backed up. Is it possible to use a good file (from backup) and its encrypted version to deduce what the encryption program did and therefore the key it used by comparing the two files? With a few samples like this can a program be written that decrypts the files? So if i see that every 'E' has become ascii character 'x' (or hex etc) for example then can a program be written to change every 'x' back to an 'E' etc. effectively reverse engineering the key?
  • Create New...