In this example, the "encrypted data" is xored with the key 4 bytes at a time. The first 4 bytes in the data are the same as the key. For the next 4 and you get the constant I posted above. Plug into Google, find where it is often found, decide rest of table, see it matches.
I've learned programmers either invent their own hashes, random number generators, and crypto, in which case I usually break them, or they reuse existing algos, in which any code constants are searchable.
Plus I've written and reversed enough of all that I recognized the loop as a CRC polynomial remainder loop.
All Crc-n algos are trivially crackable/reversible/collideable. They're a remainder on division of polynomials (learn the math on how they work), so use the polynomial equivalent of extended euclidean algo and you get one answer. Now all sufficient multiples of that mod class give all possible answers, one at a time.
The polynomial is not present in the binary. The table was obfuscated so this approach will not work here (and it's pretty common to do this specifically to stop such a simply look at the bytes in a binary).
I've learned programmers either invent their own hashes, random number generators, and crypto, in which case I usually break them, or they reuse existing algos, in which any code constants are searchable.
Plus I've written and reversed enough of all that I recognized the loop as a CRC polynomial remainder loop.
All Crc-n algos are trivially crackable/reversible/collideable. They're a remainder on division of polynomials (learn the math on how they work), so use the polynomial equivalent of extended euclidean algo and you get one answer. Now all sufficient multiples of that mod class give all possible answers, one at a time.
That should give you plenty to chase through