Map Protection

Back to lessons

On Map Protection

This tutorial will look at the pros and cons of map protection vs. open source, as well as what map protectors can do.

First, let's look at what your typical map protector does and what each of these steps mean:

Deleting World Editor Only Files

When you create a map with the World Editor, there are two types of files: game files, and editor-only files. An example of a game file is war3map.j (scripts). These files are required for the game to play. If they are not present, the game will not work. However there are also files created only for the World Editor to read, like war3map.wtg (GUI triggers). These files are totally optional to WC3, and can be safely deleted. This was the earliest level of protection discovered in WC3: if you delete all the WE only files, then the map will not open in World Editor unless they are regenerated.

The issue with this form of protection is that... well, the world editor only files are by definition not needed. Clearly WC3 doesn't need them, and any experienced map editor doesn't either. Keep in mind that the scripts, object, imports, etc. are ALL needed. Basically, deleting these files only restricts opening it in the World Editor and prevents GUI use.

That doesn't matter since anyone experienced enough to edit someone else's map will be able to write JASS. And there are tools that are even better than the world editor for writing JASS. Editing objects is also quite easy. This form of protection only stops the very noobiest of hackers, the type that will go in and change the author to their name or something like that.

It's worth stopping these people, I suppose, but honestly any editing they do is going to be garbage and will never get played over the original anyways.

Another, more important impact of deleting world editor files is that the war3map.doo file is lost. The war3map.doo stores all preplaced units, items, etc. and is an optional file. In place of this file, all preplaced units will be moved to be created on map initialization. This means that if the map is deprotected, there will be no objects placed on the map by default.

Obfuscating the Map Script

Vexorian's Optimizer obfuscates the map script, which means that it will mess up variable and function names to make them meaningless and remove code indentation. Take a VJASS snippet like this:

private function onInit takes nothing returns nothing
    set deathTrigger = CreateTrigger()
    call TriggerRegisterAnyUnitEventBJ(deathTrigger, EVENT_PLAYER_UNIT_DEATH)
    call TriggerAddAction(deathTrigger, function dropItems)
    call TriggerAddCondition(deathTrigger, Condition(function isUnitEnemy))
endfunction

Hopefully it's pretty clear what this trigger's going to do. This is an item drop trigger that fires when an enemy dies. Now if we obfuscate it, it would look something like this:

private function pqjf takes nothing returns nothing
    set ghdn = CreateTrigger()
    call TriggerRegisterAnyUnitEventBJ(ghdn, EVENT_PLAYER_UNIT_DEATH)
    call TriggerAddAction(ghdn, function jkmv)
    call TriggerAddCondition(ghdn, Condition(function Kdms))
endfunction

Now the meaning is entirely lost. Now this level of protection is actually meaningful. Code becomes far harder to read when it is obfuscated. But here's the thing: an experienced map editor will still be able to understand it. The function calls above are enough to figure it out. All you have to do is search for those functions and write down your findings in a notepad, and you will be able to figure out what it's doing.

This may double or triple the time needed to edit a map, but it will not stop anyone who wants to edit it.

(Bonus: can you find the memory leak in the above function?)

Widgetizing the Objects

I only include this for completeness. Very few people do this. Basically it involves obscuring the objects by placing them in spreadsheets instead of the normal .w3u etc. files, which surprisingly, WC3 accepts. But people invented a dewidgetizer, so this doesn't matter anymore. Also it introduces glitches into your map which is the main reason this is rarely used nowdays.

Corrupting the MPQ

MPQ is the file format that .w3x and .w3m files are. Some very clever people found some specific hex addresses you can edit in a MPQ file to make the most common MPQ reading tools fail on it. This will indeed prevent those libraries from opening your map's MPQ. But, WC3 needs to be able to read the map to play it. WC3 uses a library called stormlib which can open any valid MPQ file. And people have found out how to use this library in their tools. What this means is:

Any map that WC3 can open and play, anyone else can also open and read

People have spent years developing these MPQ corrupting tools, only to be foiled by stormlib, which already existed. Doing this method will only slow an editor down for about 10 minutes while they reconstruct the MPQ or repair it in a hex editor. This can result in a loss of imported files (see section: on MPQ format) but if someone is hacking your map, they don't care about losing a couple imports.

So what can we do?

First let me ask this: what do you have to hide? Why does it matter if someone opens your map?

In an RPG this is somewhat understandable: it would make it easy to hack and generate your codes. Though you might argue that all this would do is ruin the hacker's fun, and it's not even much easier than hacking a protected map.

The other concern is that other people might edit your map and publish it as their own. First of all, I have never seen an instance of a map that is actively being made being stolen. Second: if you are an established mapmaker in any forum or discord, people will play your official version over any other. Third: any edit is likely to be crap. Editing someone else's map is not easy and someone who's good enough to do that probably won't be stealing your work. They'll be making their map. Or, perhaps, editing a map that's been dead for years.

The only other reason I can think of is that you don't want people to see your code. I can't understand people who are secretive about their code. You're not making any money off this, and showing others your code will only increase the quality of games over time as people learn from you and get better.

The bottom line is that anyone can, with time and effort, learn to edit any published WC3 map and/or extract any resource from it. Even imports which are harder, can all be discovered with manual effort or tool use. The only way to keep your map truly protected is to never release it.

Open source?

My own personal compromise for maps that I make is this:

I run the Map Optimizer on the public release version. This is to get the performance benefit that the optimizer gives, as well as stopping the bad/lazy hackers.

I release the open source version after deleting the code system (if applicable) from the map, on the main thread and on my maps repository.

If anyone feels that can improve on my maps, they can do so and release them.

On the MPQ format

We all (hopefully) know what a .zip file is. Imagine that an MPQ file is a .zip file that we don't know the contents of. We can see that there are files in it, but we can't see what that file is. That is, unless we know the name of the file. Then we can import a listfile which is a list of hundreds of thousands (or millions) of common file names, which will discover most/all of the files in the map. After we know the name of a file in the MPQ, it can be extracted.

The reason a listfile is required is because of how the MPQ stores files. The MPQ has a hashtable with a low-collision lookup algorithm. What this means is that files are mapped to a hash code based on their filenames. This means it is very easy to discover whether a file exists: hash the name and check the hashtable, and you will discover existence. This hash table (as well as any other info on which files are in the MPQ) are encrypted when added to the archive and so the only way to discover files in it is a "brute force" attack - checking filenames to verify existence.

This is why reconstructing an MPQ can lead to a loss of imports. We don't know every import, so they can't all be extracted, and when the MPQ is remade, it will be missing those. This is the only serious effect of corrupting an MPQ. Although, a corrupt MPQ can be repaired with a hex editor anyways.

Loss of imports can be avoided by analysis of the map script and object editor. For example, searching through all objects in the map and adding their custom models to a listfile. This is a significant amount of work to accomplish.

Back to lessons