@Danne, @DeafEyeJedi: The XOR operator (usually represented by the ^ symbol) is its own inverse. That is, if X ^ Y = Z, then it is also true that X = Y ^ Z and Y = X ^ Z. If you know any two of the values you can always figure out the third, but if you only have one value you can't determine either of the other two. This property means it can be used as a sort of "poor man's encryption", where e.g. X = unencrypted data, Y = encryption key, Z = encrypted data.

Taking @jkaura's example, we know all of Z (the encrypted file) and some of X (the original data), so we can compute some of Y (the key) using Z ^ X = Y:

580F 2FC2 552F 2E76 D23D ^ 4141 4141 4141 4141 4141 = 194E 6E83 146E 6F37 937C

5B0C 2CC1 562C 2D75 D13E ^ 4242 4242 4242 4242 4242 = 194E 6E83 146E 6F37 937C

Because the results (key fragments) are the same in both cases, it implies the key is a constant. So now the puzzle is to figure out the rest of the key. It might be hard-coded in the encoding/decoding software, or it might be generated using a formula. If it's hard-coded it should be relatively easy to find by scanning the binaries, if it's a formula then some reverse-engineering of the encoding/decoding software (or extracting more fragments of the key using @jkaura's approach) is probably required.