I've found multiple copies like that to be very common. Usually the text goes through a series of tests each time it is copied, and variables like names are filled in etc. If you keep going, you should get to the original 'compressed' text as loaded from the CD. You might get lucky and find some simple compression or encryption routine that can be bypassed all together.
I think I was wrong with what I said, but I did find the part in memory where the compressed text loaded from the CD is, and it's getting it from there. I've yet to figure out how it's decompressed, but I did see it changing the register that points to the current byte to load from the compressed section to an address that was several bytes before what the current byte should be, similar to what I read about LZ storing bytes that were previously used as to not reuse them in memory.
The concrete example was something like this:
00 01 02 03 04 05 06 07 08 09 0A
Decompressed bytes that end up being stored:
30 E6 02 80 68 DD 02 80 84 DD
30 E6 02 80 68 DD 02 80 82 84 FC
When it's time to write to 0x09, it should load 0x0A, and somehow in the process,
the address ends up being 0x05, loading that DD then storing it in 0x09.
Don't see how this is compressing anything at all but maybe it works out in the long run?
And I don't think there's anything I can bypass, it does need to decompress/decrypt the text in the CD after all, and I need to be able to insert text compressed/encrypted like this into the image.
I'm guessing if it's encryption I could technically rewrite it to bypass the decryption and load non-encrypted text I would write into the image, though judging from what Vehek posted, it looks like it really is compression.
Edit: I've been digging some more. There's apparently something like 3 routes through which it can go. It either loads bytes directly from the "compressed" zone and stores them into the other zone, loops loading bytes from the compressed zone until it finds the appropriate byte to load and store, or it uses a loaded byte to calculate (with some ANDs and ORs and shifts and values in other registers) an address pointing to the byte that must be stored. I've seen this address end up pointing to the uncompressed zone, way before the position where it would store the new byte. It might also have ended up pointing to a posterior position in the compressed zone, but I might've confused that for the second case I described where it skips over some bytes.
I've also seen it use 2 registers to compare them, where one is a set value and the other keeps incrementing during a loop, and depending whether the incrementing one is < than the set one, it branches off to somewhere or not. I think this loop determines a certain amount of bytes to either directly load from the compressed zone, to get from a previously written part of memory, or to skip through in the compressed zone, I don't remember right now exactly.