Readme.txt.monkey blocks file encryption

[VakarisZ]

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:

1. Create a directory and add some files
2. Enter a the directory as a ransomware target dir into the configuration
3. Run monkey 3 times in a row (or create a README.txt.m0nk3y file)
4. On the third run, monkey will throw an error and files won't get encrypted

Expected behavior

Monkey shouldn't encrypt README.txt and README.txt.m0nk3y files

Machine version (please complete the following information):

• OS: Windows

Tasks

• Check hash of README.txt file. If it's ours, skip it. (0d) @mssalvatore
  • Experiment to see under what conditions Windows will change the README file's line endings.

[mssalvatore]

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.