So I just found out you can easily download a program to read any map file's triggers... Okay, I guess everyone else knew this already but this scares me a lot.
I see that in the editor, there is an option for script obfuscation, but it also says it may cause errors when custom script refers to auto-generated identifiers. Are auto-generated identifiers only those wacky variables in for loops and switch statements, or could i have a problem with variables where I have the script identifier based on name box checked?
Next question, I googled trigger obfuscation quickly and found this Galaxy Obfuscator, which, based on its description, looks like it would do a very good job of making the code an absolute pain in the ass to read. However, it also doesn't work - just gives me an "Error - unexpected [" every time I try to run it (maybe it doesn't know how to handle arrays?!). I'm wondering if there are any other good obfuscators out there that actually work. Or, is the blizzard one robust enough?
Final question - sometimes when I look at map's scripts I see something like "string/external/0123401" and sometimes I just see the literal value. I have several encryption algorithms in my map that rely on keys, so they're pretty much useless if someone can just go into the script and read out the key. How can I make it so these crucial key strings aren't written out literally in my script?
Update: Yeah okay there's no way the Blizzard obfuscator is going to work on my map. It looks like dynamic triggering is highly incompatible with the built-in script obfuscator (unless someone else has managed to find a way to use TriggerCreate("func_name") without getting errors when obfuscating?) What do all you map makers do who don't want people reading your triggers?
If the encryption keys are the only thing that you are worried about, simply put them into a data field somewhere and look them up via catalog functions on initialization. If they can't obtain your data, then they can't obtain your keys.
If the encryption keys are the only thing that you are worried about, simply put them into a data field somewhere and look them up via catalog functions on initialization. If they can't obtain your data, then they can't obtain your keys.
Thanks, will do. But that's not all I'm worried about, that's just one part. I would like all code related to saving and loading bank data to be obfuscated so that no one can reverse engineer the algorithms and then crack the keys via brute force, or bypass the entire system via memory hacking after reading my triggers and understanding how to circumvent the validation.
Also I'm wondering, is the Blizzard "locking" feature actually secure? Can people open up the map with an MPQ editor or maybe some other program that just bypass the lock?
It is not very secure. A map can be unlocked by changing its .s2ma format to .SC2MAP and adding in the components file, though it does not store GUI triggers, only the raw galaxy needed to run the map.
It is not very secure. A map can be unlocked by changing its .s2ma format to .SC2MAP and adding in the components file, though it does not store GUI triggers, only the raw galaxy needed to run the map.
So this means that though I have stored encryption keys in data strings as per MasterWraith's suggestion, someone could still open the map by the process you described and obtain the keys?
yes the values are not changed, just their name. you can still export your keys to a mod or library which makes it a bit harder to access but still possible. in fact it's not possible to protect your script. you can still add lots of unused keys so some1 has to figure out first which one to use.
yes the values are not changed, just their name. you can still export your keys to a mod or library which makes it a bit harder to access but still possible. in fact it's not possible to protect your script. you can still add lots of unused keys so some1 has to figure out first which one to use.
That doesn't address the issue, because TriggerDestroy takes a trigger parameter, whereas TriggerCreate takes the string name of the function as its parameter. Thanks though.
Less effective than my previous suggestion, but you can obfuscate things very easily by saving them in the global DataTable. Then you can break apart the key used to store/retrieve in the DataTable so that it can't simply be searched in your map script.
You could partially encrypt values in one location of the script and then use some trigger magic or function pointers to finish encrypting them elsewhere, retrieving them via the DataTable.
Edit:
And you could simply obfuscate your code by making it excessively complicated, at least in appearance.
I definitely want to stay away from manual obfuscation because the tradeoff of a slight security benefit for a huge increased likelihood of bugs and increased difficulty of debugging is not worth it.
I think I will write my own script obfuscator, could anyone explain to me quickly the process of extracting a map's script, and then re-inserting it after I've run the obfuscation?
Can I ask you question? Why are you so interested in crypting your triggers? I mean, I don't want to make you angry, but it could be more benefit for everybody to have an 'openware' trigger script. Honestly, if someone really wants to see your script, it's sure that he'll find a way to read it (hackers can easily broke government heavy duty firewalls, so a starcraft 2 map could be a joke next to that). I think you should instead add comments like if you're taking information in the script don't forget to add my name in your map.
Can I ask you question? Why are you so interested in crypting your triggers? I mean, I don't want to make you angry, but it could be more benefit for everybody to have an 'openware' trigger script. Honestly, if someone really wants to see your script, it's sure that he'll find a way to read it (hackers can easily broke government heavy duty firewalls, so a starcraft 2 map could be a joke next to that). I think you should instead add comments like if you're taking information in the script don't forget to add my name in your map.
Because reading the script = hacking the bank.
I would love to be able to have my script available for anyone to read who wants to learn a thing or two about how I coded some feature of my map. However, as long as Blizzard insists on storing banks client-side rather than server-side, this cannot be.
So I just found out you can easily download a program to read any map file's triggers... Okay, I guess everyone else knew this already but this scares me a lot.
I see that in the editor, there is an option for script obfuscation, but it also says it may cause errors when custom script refers to auto-generated identifiers. Are auto-generated identifiers only those wacky variables in for loops and switch statements, or could i have a problem with variables where I have the script identifier based on name box checked?
Next question, I googled trigger obfuscation quickly and found this Galaxy Obfuscator, which, based on its description, looks like it would do a very good job of making the code an absolute pain in the ass to read. However, it also doesn't work - just gives me an "Error - unexpected [" every time I try to run it (maybe it doesn't know how to handle arrays?!). I'm wondering if there are any other good obfuscators out there that actually work. Or, is the blizzard one robust enough?
Final question - sometimes when I look at map's scripts I see something like "string/external/0123401" and sometimes I just see the literal value. I have several encryption algorithms in my map that rely on keys, so they're pretty much useless if someone can just go into the script and read out the key. How can I make it so these crucial key strings aren't written out literally in my script?
Update: Yeah okay there's no way the Blizzard obfuscator is going to work on my map. It looks like dynamic triggering is highly incompatible with the built-in script obfuscator (unless someone else has managed to find a way to use TriggerCreate("func_name") without getting errors when obfuscating?) What do all you map makers do who don't want people reading your triggers?
If the encryption keys are the only thing that you are worried about, simply put them into a data field somewhere and look them up via catalog functions on initialization. If they can't obtain your data, then they can't obtain your keys.
Thanks, will do. But that's not all I'm worried about, that's just one part. I would like all code related to saving and loading bank data to be obfuscated so that no one can reverse engineer the algorithms and then crack the keys via brute force, or bypass the entire system via memory hacking after reading my triggers and understanding how to circumvent the validation.
Also I'm wondering, is the Blizzard "locking" feature actually secure? Can people open up the map with an MPQ editor or maybe some other program that just bypass the lock?
@Apollys: Go
It is not very secure. A map can be unlocked by changing its .s2ma format to .SC2MAP and adding in the components file, though it does not store GUI triggers, only the raw galaxy needed to run the map.
So this means that though I have stored encryption keys in data strings as per MasterWraith's suggestion, someone could still open the map by the process you described and obtain the keys?
@Apollys: Go
yes the values are not changed, just their name. you can still export your keys to a mod or library which makes it a bit harder to access but still possible. in fact it's not possible to protect your script. you can still add lots of unused keys so some1 has to figure out first which one to use.
you might consider this useful for your triggerCreate problem. http://www.sc2mapster.com/forums/development/triggers/65013-trigger-destroy-script-obfuscation/
That doesn't address the issue, because TriggerDestroy takes a trigger parameter, whereas TriggerCreate takes the string name of the function as its parameter. Thanks though.
@Apollys: Go
Less effective than my previous suggestion, but you can obfuscate things very easily by saving them in the global DataTable. Then you can break apart the key used to store/retrieve in the DataTable so that it can't simply be searched in your map script.
You could partially encrypt values in one location of the script and then use some trigger magic or function pointers to finish encrypting them elsewhere, retrieving them via the DataTable.
Edit:
And you could simply obfuscate your code by making it excessively complicated, at least in appearance.
@MasterWrath: Go
I definitely want to stay away from manual obfuscation because the tradeoff of a slight security benefit for a huge increased likelihood of bugs and increased difficulty of debugging is not worth it.
I think I will write my own script obfuscator, could anyone explain to me quickly the process of extracting a map's script, and then re-inserting it after I've run the obfuscation?
Can I ask you question? Why are you so interested in crypting your triggers? I mean, I don't want to make you angry, but it could be more benefit for everybody to have an 'openware' trigger script. Honestly, if someone really wants to see your script, it's sure that he'll find a way to read it (hackers can easily broke government heavy duty firewalls, so a starcraft 2 map could be a joke next to that). I think you should instead add comments like if you're taking information in the script don't forget to add my name in your map.
Because reading the script = hacking the bank.
I would love to be able to have my script available for anyone to read who wants to learn a thing or two about how I coded some feature of my map. However, as long as Blizzard insists on storing banks client-side rather than server-side, this cannot be.
The best you can do is make editing your map such a pain in the ass, that anyone would refuse to steal it.
@Apollys: Go
Ok, thanks for the advice.
I'm not really worried about someone stealing it - I wouldn't mind that. I just don't want people hacking the game/banks.