As I have said before in earlier posts, these are the two limitations to the data obfuscation :
1) All objects must be new rather than modified ones, as it just renames everything by default. An user can manually provide a list of object names not be renamed, as the program doesn't have a list of all built-in objects.
2) No implicit references must be used, anywhere. For example, an actor based on the GenericAttack parent assumes that any missile actor will be named ##id##Missile, which means the same name with a "Missile" suffix. If the missile actor is named as such, no explicit reference actually exists in the XML files. The data obfuscation program will not create a new reference, and hence the link will be broken.
Karawasa, sorry it took a while. I put up a package which contains SouLCarveRR's GUI : it saves you from having to edit .bat files but you'll still need to extract the .galaxy script from the map MPQ and put it back.
I'm not sure I'll complete the data obfuscation any time soon : it's rather complex to make it fully reliable, due to SC2 data's tendency to have implied suffixes at the end of object names, without any explicit references. It would require quite a bit of extra parsing.
I wouldn't mind putting the current package "as it is". It certainly works, but we would probably get bug reports from people who don't fully understand that suffix limitation or the format of SC2's XML files...
Well! The command-line is working, and so is the GUI program from SouLCarveRR.
I just thought he would make a small update ( so the GUI program still work even if a backup/ directory doesn't already exist ), but if not, I'll put that shortly as it is.
Oh, obfuscating the data converts all references to that data : triggers, Galaxy code, pre-placed objects. Everything.
The only glitch with the data obfuscation program is that it can't make the difference between new objects and modified existing objects... Renaming modified objects will turn them into new objects, but without the implied fields of the parent default object. Anyhow, I'll fix that one day, perhaps just with a very long list of default object names that must not be renamed.
And the Galaxy script obfuscation works perfectly as far as I know.
The various objects of the data editor must refer to each other to work. The map editor can see the links between the objects just as much as Starcraft 2 can.
So yes, it doesn't protect a map in any sense, it just makes it a hassle to figure things out. Obfuscation of all data and galaxy code is about the best "protection" we can get, until Blizzard adds some real locking one day.
As a side effect, it also shrinks the size of the Galaxy code to about 40% of original size, as well as making all XML data smaller through renaming.
If you are still interested in building a GUI on top of it, do you want to do the MPQ unpacking and repacking? I never used libmpq, though I guess it shouldn't be too complicated.
Names are of course unique ( strictly, it isn't random, more like a non-colliding index rehashing ).
I realize people are far more interested in Galaxy code obfuscation than data! Oh well, that's easy then :). A first version for Galaxy code is ready, just waiting approval for a new asset.
That first version won't do map MPQ unpacking or anything like that. You have to extract the MapScript.galaxy file from the map, run the program, and put the file back using a program like MPQEditor. Data obfuscation will work the same way, I may use libmpq eventually to make things easier.
The program should catch the names of about everything ( except new data types declared with typedef in custom code ), and encode everything given an alphabet and optional prefix. It also strips every space or line break that isn't strictly necessary, etc. Renaming everything with a random combination of the letters i and j, for example, looks pretty nice... :)
@SexLethal:
Quite right, that was just an example of how easy it is to parse MapScript.galaxy. The program is actually a little more clever than that.
Trigger code is really easy to obfuscate in comparison to the data. If you look at MapScript.galaxy, all local variables begin with lv_, all globals begin with gv_, functions with gf_, etc. Scopes are followed by tracking { and }, so writing a parser for that is most straightforward.
Regarding data, to make the tool work with all maps, the difficult part is really going to be how to manage implicit references with suffixes. For example, if you create an actor named FooBar with GenericAttack as parent, the missile is assumed to be FooBarMissile unless specified otherwise. So if your missile really is named FooBarMissile, there's no explicit reference at all in the data files. The obfuscation code would have to know about parent objects working with such suffixes, be able to figure out when implicit references happens, and create new explicit references... This is a bit messy.
By the way, SoulCarveRR said it, the point isn't really to protect anything... It's more like making it so much trouble to figure things out that the person is better off creating from scratch.
All right, I'll at least put some hours into making it able to recognize modified IDs and new IDs, then SoulCarveRR could make it a fancy GUI :).
@OneTwoSC
I'm not saying you would need to duplicate every data entry that you use, like splash damage. I'm just saying that the current code only works if you create new objects instead of modifying existing ones ; these new objects can link to existing unmodified objects just fine ( including splash damage ). Anyway, That limitation could be removed if the code would be made clever enough to differentiate between object IDs referring to modified stock objects and new objects.
Some maps may have hundreds of new objects defined, I can imagine a desire to obfuscate that stuff as much as trigger code. There's still a quick pass on the MapScript.galaxy file, basically just renaming all functions/triggers and variables ( plus basic stuff like removing comments, extra spaces and line breaks ).
In the end, the program presently does everything I need. It would imply some work to fix the current limitations ( recognizing modified/new object IDs, and dealing with suffixes like ##unitname##Build, ##id##Missile or whatever ), so I was just wondering if there's some demand for such a tool before putting more time on it.
Anyway, here's an example of the conversion made by the program, before and after :
I should have mentioned that : it also fixes Galaxy code references to all data objects ( the Galaxy code is what's generated by the GUI-based triggers ). It also fixes references to existing units/doodas placed on the maps, etc. To summarize, it converted flawlessly my map with 550kb of XML data and 5000 lines of Galaxy code.
@EternalWraith:
I certainly could make it configurable and improve the parsing... Still, I don't think I would be bothered into making a graphical user interface, I'm just not that kind of programmer :p. That's why I'm saying perhaps someone else could be interested into building a fancy graphical interface on top of it.
I have lurked around these forums for some time though I never posted before.
As many, I'm slightly annoyed by the complete lack of protection for SC2 "locked" maps. To protect my maps to a certain extend ( still unreleased ), I very quickly wrote a command line program that would parse the files extracted from a map MPQ and obfuscate all references. So for example, an effect that would be previously called "BattlecruiserTornadoDamageSearch" becomes something like "xn9pK2".
There are some limitations :
- It assumes that all the data is new : I mean new units, new abilities, effects, whatever. If you modify existing units instead, the existing code won't work. It would have to compare against lists of detault IDs to figure out what's new and what's not. I personally think it's bad practice to modify existing stuff rather than create new from scratch anyway.
- The code isn't clever enough to manage references by parameters if you append prefixes/suffixes. So, stuff like ##id##Damage or ##unitname##Build wouldn't work without extra parsing.
- It's totally not user-friendly. It very probably requires a programmer to use ( configuring it by editing the source code and recompiling ).
Still, it works pretty well. Resulting maps are also smaller and faster to load.
Is there any interest in that code? I don't think I would be motivated into writing it a friendly and flexible graphical user interface, but perhaps someone else would... It's just some 600 lines of C code, so if there's any programmer who wants to have a look, let me know.
As I have said before in earlier posts, these are the two limitations to the data obfuscation :
1) All objects must be new rather than modified ones, as it just renames everything by default. An user can manually provide a list of object names not be renamed, as the program doesn't have a list of all built-in objects.
2) No implicit references must be used, anywhere. For example, an actor based on the GenericAttack parent assumes that any missile actor will be named ##id##Missile, which means the same name with a "Missile" suffix. If the missile actor is named as such, no explicit reference actually exists in the XML files. The data obfuscation program will not create a new reference, and hence the link will be broken.
Karawasa, sorry it took a while. I put up a package which contains SouLCarveRR's GUI : it saves you from having to edit .bat files but you'll still need to extract the .galaxy script from the map MPQ and put it back.
I'm not sure I'll complete the data obfuscation any time soon : it's rather complex to make it fully reliable, due to SC2 data's tendency to have implied suffixes at the end of object names, without any explicit references. It would require quite a bit of extra parsing.
I wouldn't mind putting the current package "as it is". It certainly works, but we would probably get bug reports from people who don't fully understand that suffix limitation or the format of SC2's XML files...
Well! The command-line is working, and so is the GUI program from SouLCarveRR.
I just thought he would make a small update ( so the GUI program still work even if a backup/ directory doesn't already exist ), but if not, I'll put that shortly as it is.
Oh, obfuscating the data converts all references to that data : triggers, Galaxy code, pre-placed objects. Everything.
The only glitch with the data obfuscation program is that it can't make the difference between new objects and modified existing objects... Renaming modified objects will turn them into new objects, but without the implied fields of the parent default object. Anyhow, I'll fix that one day, perhaps just with a very long list of default object names that must not be renamed.
And the Galaxy script obfuscation works perfectly as far as I know.
@Jinxxx123:
The various objects of the data editor must refer to each other to work. The map editor can see the links between the objects just as much as Starcraft 2 can.
So yes, it doesn't protect a map in any sense, it just makes it a hassle to figure things out. Obfuscation of all data and galaxy code is about the best "protection" we can get, until Blizzard adds some real locking one day.
As a side effect, it also shrinks the size of the Galaxy code to about 40% of original size, as well as making all XML data smaller through renaming.
@SouLCarveRR:
If you are still interested in building a GUI on top of it, do you want to do the MPQ unpacking and repacking? I never used libmpq, though I guess it shouldn't be too complicated.
Names are of course unique ( strictly, it isn't random, more like a non-colliding index rehashing ).
I realize people are far more interested in Galaxy code obfuscation than data! Oh well, that's easy then :). A first version for Galaxy code is ready, just waiting approval for a new asset.
That first version won't do map MPQ unpacking or anything like that. You have to extract the MapScript.galaxy file from the map, run the program, and put the file back using a program like MPQEditor. Data obfuscation will work the same way, I may use libmpq eventually to make things easier.
The program should catch the names of about everything ( except new data types declared with typedef in custom code ), and encode everything given an alphabet and optional prefix. It also strips every space or line break that isn't strictly necessary, etc. Renaming everything with a random combination of the letters i and j, for example, looks pretty nice... :)
@SexLethal: Quite right, that was just an example of how easy it is to parse MapScript.galaxy. The program is actually a little more clever than that.
Trigger code is really easy to obfuscate in comparison to the data. If you look at MapScript.galaxy, all local variables begin with lv_, all globals begin with gv_, functions with gf_, etc. Scopes are followed by tracking { and }, so writing a parser for that is most straightforward.
Regarding data, to make the tool work with all maps, the difficult part is really going to be how to manage implicit references with suffixes. For example, if you create an actor named FooBar with GenericAttack as parent, the missile is assumed to be FooBarMissile unless specified otherwise. So if your missile really is named FooBarMissile, there's no explicit reference at all in the data files. The obfuscation code would have to know about parent objects working with such suffixes, be able to figure out when implicit references happens, and create new explicit references... This is a bit messy.
By the way, SoulCarveRR said it, the point isn't really to protect anything... It's more like making it so much trouble to figure things out that the person is better off creating from scratch.
All right, I'll at least put some hours into making it able to recognize modified IDs and new IDs, then SoulCarveRR could make it a fancy GUI :).
@SouLCarveRR:
I should have mentioned that : it also fixes Galaxy code references to all data objects ( the Galaxy code is what's generated by the GUI-based triggers ). It also fixes references to existing units/doodas placed on the maps, etc. To summarize, it converted flawlessly my map with 550kb of XML data and 5000 lines of Galaxy code.
@EternalWraith:
I certainly could make it configurable and improve the parsing... Still, I don't think I would be bothered into making a graphical user interface, I'm just not that kind of programmer :p. That's why I'm saying perhaps someone else could be interested into building a fancy graphical interface on top of it.
Hi,
I have lurked around these forums for some time though I never posted before.
As many, I'm slightly annoyed by the complete lack of protection for SC2 "locked" maps. To protect my maps to a certain extend ( still unreleased ), I very quickly wrote a command line program that would parse the files extracted from a map MPQ and obfuscate all references. So for example, an effect that would be previously called "BattlecruiserTornadoDamageSearch" becomes something like "xn9pK2".
There are some limitations :
- It assumes that all the data is new : I mean new units, new abilities, effects, whatever. If you modify existing units instead, the existing code won't work. It would have to compare against lists of detault IDs to figure out what's new and what's not. I personally think it's bad practice to modify existing stuff rather than create new from scratch anyway.
- The code isn't clever enough to manage references by parameters if you append prefixes/suffixes. So, stuff like ##id##Damage or ##unitname##Build wouldn't work without extra parsing.
- It's totally not user-friendly. It very probably requires a programmer to use ( configuring it by editing the source code and recompiling ).
Still, it works pretty well. Resulting maps are also smaller and faster to load.
Is there any interest in that code? I don't think I would be motivated into writing it a friendly and flexible graphical user interface, but perhaps someone else would... It's just some 600 lines of C code, so if there's any programmer who wants to have a look, let me know.
Stragus