I remember a time when disassembly was rampant, and software protection needed to go to some fairly extreme measures to obfuscate itself. I'm not sure if these sorts of things still occur, but the tactics I read about have stuck with me for some time:
The principal revolved around making the code a lot more complicated than it needed to be. Since they were assuming that someone would disassemble their code, the purpose was to make it as hard to follow as possible. Sure, an encryption routine can be housed in a single function, but it's a lot hard to follow if it's broken up (arbitrarily) into four functions, and the physical locations of those functions is purposefully seperate. Instead of a constant encryption key, the encryption key could be "built", across several functions. Another common tactic was to introduce code that does nothing, which surrounded the meaningful code. It all just goes to make the hackers job more difficult. Perhaps a branch that never happens, a function that's never called, all create the illusion of complexity that simply isn't there. Illusion or not, the hacker still has to wade through it all in order to sort it out. Lastly, you can remove the symoblic information - the function and variable names. Fortunately, the map designer lets you change a variable or function's name, and all references to it are changed automatically. Sure, the hacker can do the same in reverse, but their faced with the burden of figuring out what the variable or function is used for in the first place. If the variable or function isn't actually used, that job gets harder. Say you have variables named Variable001 through Variable008, and only 2,5, and 7 are used, it can be hard to figure out. The other variables should be referenced, but in code that doesn't really do anything.
The down side is that you now need a map of your encryption routines in order to maintain it. You need to know what to switch your variables back to, and what is and isn't actually used inside the functions. It's a burden to be sure. Security and usability are, unfortunately, polar opposites.
You also want to be sure that your players aren't modifying their RAM, and not their banks. If they're using a hacked client, they can jsut modify their RAM directly and bypass all your encryption. If that's the case, they're little you can do. You've done your due dilligence, and all you can do is wait for Blizz to ban them.
0
I remember a time when disassembly was rampant, and software protection needed to go to some fairly extreme measures to obfuscate itself. I'm not sure if these sorts of things still occur, but the tactics I read about have stuck with me for some time:
The principal revolved around making the code a lot more complicated than it needed to be. Since they were assuming that someone would disassemble their code, the purpose was to make it as hard to follow as possible. Sure, an encryption routine can be housed in a single function, but it's a lot hard to follow if it's broken up (arbitrarily) into four functions, and the physical locations of those functions is purposefully seperate. Instead of a constant encryption key, the encryption key could be "built", across several functions. Another common tactic was to introduce code that does nothing, which surrounded the meaningful code. It all just goes to make the hackers job more difficult. Perhaps a branch that never happens, a function that's never called, all create the illusion of complexity that simply isn't there. Illusion or not, the hacker still has to wade through it all in order to sort it out. Lastly, you can remove the symoblic information - the function and variable names. Fortunately, the map designer lets you change a variable or function's name, and all references to it are changed automatically. Sure, the hacker can do the same in reverse, but their faced with the burden of figuring out what the variable or function is used for in the first place. If the variable or function isn't actually used, that job gets harder. Say you have variables named Variable001 through Variable008, and only 2,5, and 7 are used, it can be hard to figure out. The other variables should be referenced, but in code that doesn't really do anything.
The down side is that you now need a map of your encryption routines in order to maintain it. You need to know what to switch your variables back to, and what is and isn't actually used inside the functions. It's a burden to be sure. Security and usability are, unfortunately, polar opposites.
You also want to be sure that your players aren't modifying their RAM, and not their banks. If they're using a hacked client, they can jsut modify their RAM directly and bypass all your encryption. If that's the case, they're little you can do. You've done your due dilligence, and all you can do is wait for Blizz to ban them.