Closed VakarisZ closed 3 years ago
This appears to be working as designed. Files ending in .m0nk3y
are already ignored. It attempts to rename the file and fails, giving you an error message as to why. If we don't encrypt existing README.txt files, this could mean we would overwrite a user's data with our README.txt. For example, if the target directory contains source code, it may already contain a README.txt. If we don't encrypt that file and rename it with .m0nk3y
, then we'll potentially overwrite it with our own README, making the original data unrecoverable.
We could check the hash of any README.txt file and skip it if it's ours.
Describe the bug
If a README.txt.monkey file is present in the ransomware target directory the encryption of the files fail with
{'path': 'C:\\w\\Dump\\README.txt', 'success': False, 'error': "[WinError 183] Cannot create a file when that file already exists: 'C:\\\\w\\\\Dump\\\\README.txt' -> 'C:\\\\w\\\\Dump\\\\README.txt.m0nk3y'"}
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Monkey shouldn't encrypt README.txt and README.txt.m0nk3y files
Machine version (please complete the following information):
Tasks