Stop hand-rolling crypto, people! Ransomware needs security too. :(

The author probably wanted to be able to somewhat quickly encrypt/decrypt a full disk on potentially slow hardware.

It would have been smarter to bundle the ransomware with a 32-bit DOS extender so the known-good Salsa implementation could be used unchanged.

That is, the closer the bits in the hash result for the candidate are to the target hash result, the better it considers the candidate (in particular, cardinality of symmetric difference for a bitset is the count of the number of one bits in the symmetric difference. It then sets the fitness to mean lower is better, so the smaller the number of different bits, the better it considers the candidate)

This means it just tweak input key bits through mutation until the result comes out right. Now, in theory, there should be no correlation, so this should be no better than random search, but ...

I'm not sure if there aren't clever ways to undo it, but at least it would resist such a simple method like that.

  return int(bitset.From(c.qwords()).SymmetricDifferenceCardinality(target_bitset))

* They used 16 bit math instead of 32 bit math (with, I'm assuming, a 32 bit output size rather than the recommended 64 bit output). Which has the effect of looking like 10 rounds, but it's a rather more serious security failure.

* They generated keys in the alphanumeric range (instead of the full byte range) significantly reducing entropy.

All which seems to have weakened it substantially (understatement).

Looks like it used a [1-9a-xA-X]{8} key. Even with a CSPRNG that's only 46 bits of entropy. You can brute force that in 2-3 hours with adequate hardware.