### 1. Analysis inside Ghidra

#### Main Function

Main function does following things:
- compute `sha256("Ronaldch0nkRivest")`
- create a thread to append files to queue
- create a thread to encrypt files from queue

#### VerySuspiciousFunction

This function is been called for each file, receives key and filename as parameters, it might do the real encryption job. Let's see the code, it first calls `VeryInterestingAsWell`, which then calls `BCryptGenRandom`, for 32 random bytes. Then it calls `FUN_14000b9c0`, which looks like RC4 KSA inside, indicating the beginning of encryption. Several lines below, we could see `DeleteFileW`, it must have created encrypted `*.ch0nk` file, so it can delete the original file.

### 2. Debug in x64dbg

We could type `bp BCryptGenRandom` command to stop inside `VerySuspiciousFunction`. We notice that memory of key from parameters and memory of random bytes are next to each other, and the start address of this block of memory is sent to KSA-like `FUN_14000b9c0`. So the key might be `sha256("Ronaldch0nkRivest") + BCryptGenRandom()`? Let's see the hexadecimal content of `*.ch0nk` file. Wow, the first 32 bytes seem to be exactly the same with the random bytes we just generated? And That's the reason why encrypted file is 32 bytes larger and all the encrypted files are different even if they have identical content.

### 3. Write Code

# split file to random bytes(part of key) and real cipher text
random_bytes = data[:32]
cipher_text = data[32:]

# key is just concatenation of hash and random bytes
key = hashlib.sha256(b"Ronaldch0nkRivest").digest() + random_bytes

# RC4 Decryption
cipher = ARC4.new(key)
decrypted_data = cipher.decrypt(cipher_text)