Agreed, legitimate copies should be supported. I've changed the patch accordingly.
X-Men patch is also available now, so both can run now in DOSBox 0.72.
This one was very interesting - the protection is quite patch-resistant. I ended up just decrypting the last layer manually in xmen.com, and skipped the protection layer completely. I also intercept the attempt to run cop.frm, which was also protected but which simply ran startup.com. Now it just runs startup.com, which isn't protected.
Their code is doing funny things with the CPU. One loop relies on the prefetch caching bug, one loop requires that it doesn't occur, or that somehow the queue is flushed. I don't know how it ever worked.
In any case, the rep movs behaviour is incorrect in DOSBox.

one loop requires that it doesn't occur, or that somehow the queue is flushed. I don't know how it ever worked.

I don't remember any problem with the prefetch-abusing games, when the
queue is used they work. Flusing of the queue happens on codeflow changing
instructions of course, but the exact details are unknown.

In any case, the rep movs behaviour is incorrect in DOSBox.

No it isn't, that's what the cputype selection in the cvs is for. It is RARELY
needed and causes slowdowns, that's why it is optional.

The rep movs behaviour exists in real _current_ CPUs (and all before it).
Try it yourself and you will see. The example that I posted earlier came from my x64 system.
It's not a prefetch bug, so DOSBox is incorrect in its current behaviour.
However, the only apps that I've seen abusing this are some Windows runtime packers.

I didn't test rep movsX eplicitly so i don't know how it'd behave,
though it sounds unlikely that an interruptable instruction would
be implemented as atomic operation on current cpus.
On pre-pentium the effect surely is due to the instruction being
loaded into the prefetch queue.

Yes, it's certainly strange that it behaves as it does, but it is a fact on current CPUs, for both rep movs and rep stos. For those two instructions, the CPU still caches them and continues to execute them even when the instruction sequence has been overwritten in memory.

Separately, those instructions are no longer interruptible in the right conditions on modern CPUs. It depends on the values of edi (and esi for movs) and ecx. If they are aligned properly, then it is uninterruptible for the size of an entire cache line. This is known as the "fast string" operation, and existed since the Pentium Pro. That's also documented in my paper.