Lame Way To Protect Against War3Map.j Hacking
Posted: May 28th, 2008, 7:57 pm
This is VERY EASY to reverse once you're aware of it. But it's interesting just the same.
Simply use this code somewhere in your game code (it shouldn't even ever have to be triggered to work):
"REPLACE THIS" should be replaced by a string literal (not a variable). If the length (the number of characters) of this string literal exceeds 1023 (if it's 1024 characters long or longer) WC3 will crash whenever the map is selected (in the "create game" or "custom game" screens). NOTE: Although I have only tested this for the CreateQuestBJ function, it probably works the same way for most (if not all) functions.
(Why 1023 characters? Most likely because "0x00" or "\0" or NULL is appended automatically to any string thus making it 1024 or 2^10 "under the hood".)
The trick here lies in how line breaks can be represented in many different ways and that WC3 reliably understands at the very least two of these representations: CR (carriage return, 0x0D, used most prominently in Mac environments) and CR+LF (carriage return + line feed, 0x0D0A, used most prominently in Windows environments). As you can see, CR occupies only 1 byte (one character) while CR+LF is 2 bytes long (two characters), yet they do the exact same thing (within WC3). So, what does this give?
Since the vast majority of WC3 users and modders use Windows, their line breaks will be saved as CR+LF (per default). But what if we previously, in our war3map.j source file, used CR for our line breaks, what happens then? It depends, but most often the file editor will load the file correctly, but later when saving it CR+LF will be used to encode any line breaks. (JassCraft, for instance, works this way. And I dare say it's the most popular Jass editor out there.) So, how do we exploit this?
All we have to do to exploit the above weakness is to make sure our string literal is less than 1024 characters in length when saved using CR to represent our line breaks (btw Jass has no problem handling line breaks within string literals in the war3map.j source file, so there’s no need to use "\n" or anything like that), yet exceeds 1023 characters in length when CR+LF is used to encode any line breaks. Thus the string literal should contain at the very least one CR, preferably lots of them, and be at least (1024 - [Number of CRs]) characters long. Just try to make the actual text make sense, as to hide its real intent.
You may have to use a hex editor (or an optimizer with this functionality) to assert those line breaks become only CRs and not CR+LFs in the file. If done correctly, when your average cheater/modder tries to hack your map by extracting, modifying and reimporting the war3map.j, even though his code works like a charm, your code will cause the map to crash because he introduced errors in it without even knowing it just by saving your war3map.j.
Easy as pie!
~ Kris
edit: Essentially rewrote the entire thing to improve comprehension.
Simply use this code somewhere in your game code (it shouldn't even ever have to be triggered to work):
Code: Select all
call CreateQuestBJ(0,"Something Here... irrelevant", "REPLACE THIS", "ReplaceableTextures\\CommandButtons\\BTNHolyBolt.blp")"REPLACE THIS" should be replaced by a string literal (not a variable). If the length (the number of characters) of this string literal exceeds 1023 (if it's 1024 characters long or longer) WC3 will crash whenever the map is selected (in the "create game" or "custom game" screens). NOTE: Although I have only tested this for the CreateQuestBJ function, it probably works the same way for most (if not all) functions.
(Why 1023 characters? Most likely because "0x00" or "\0" or NULL is appended automatically to any string thus making it 1024 or 2^10 "under the hood".)
The trick here lies in how line breaks can be represented in many different ways and that WC3 reliably understands at the very least two of these representations: CR (carriage return, 0x0D, used most prominently in Mac environments) and CR+LF (carriage return + line feed, 0x0D0A, used most prominently in Windows environments). As you can see, CR occupies only 1 byte (one character) while CR+LF is 2 bytes long (two characters), yet they do the exact same thing (within WC3). So, what does this give?
Since the vast majority of WC3 users and modders use Windows, their line breaks will be saved as CR+LF (per default). But what if we previously, in our war3map.j source file, used CR for our line breaks, what happens then? It depends, but most often the file editor will load the file correctly, but later when saving it CR+LF will be used to encode any line breaks. (JassCraft, for instance, works this way. And I dare say it's the most popular Jass editor out there.) So, how do we exploit this?
All we have to do to exploit the above weakness is to make sure our string literal is less than 1024 characters in length when saved using CR to represent our line breaks (btw Jass has no problem handling line breaks within string literals in the war3map.j source file, so there’s no need to use "\n" or anything like that), yet exceeds 1023 characters in length when CR+LF is used to encode any line breaks. Thus the string literal should contain at the very least one CR, preferably lots of them, and be at least (1024 - [Number of CRs]) characters long. Just try to make the actual text make sense, as to hide its real intent.
You may have to use a hex editor (or an optimizer with this functionality) to assert those line breaks become only CRs and not CR+LFs in the file. If done correctly, when your average cheater/modder tries to hack your map by extracting, modifying and reimporting the war3map.j, even though his code works like a charm, your code will cause the map to crash because he introduced errors in it without even knowing it just by saving your war3map.j.
Easy as pie!
~ Kris
edit: Essentially rewrote the entire thing to improve comprehension.
)