maps protected by vexorian

[xxx_]

....

 

[Binsu]

Actually, this is the problem now. Even protection is not enough because the people or should we say the pros now can open them. With using various tools, and I hear its MPQ Master, I think.

 

[Daffa]

Actually, main purpose of Vexorian is not protection, Vexorian state that protection actually never exist, people call protection because Vexorian optimizer destroy WE data and corrupt the WE data rendering them not openable in WE but still readable in game, but some tools used by pros can unlock them and use them.

 

[-SmaSHeR-]

actaully when protected map with this tool normally they cant open in world editor an error will pop out but us others mentioned it can be easly opened if you know how to

 

[Binsu]

But Ralle has posted a tutorial on another way on protecting maps by messing somethings in binary data files. Here >>>> Top Ten Questions

One of the questions is about protecting and Ralle has provided an alternate way other than using Optimizers.

 

[Imp Midna]

To come back to the main question, yes. You will need so much time and a lot of knowledge to open a map that was "protected" with the optimizer. And in order to reach the skills required to open the map despite the protection, one has to have a mind developed far enough to understand that stealing a map is a pointless endeavor that is not worth taking the time. So, you can feel pretty save.

 

[Binsu]

To come back to the main question, yes. You will need so much time and a lot of knowledge to open a map that was "protected" with the optimizer. And in order to reach the skills required to open the map despite the protection, one has to have a mind developed far enough to understand that stealing a map is a pointless endeavor that is not worth taking the time. So, you can feel pretty save.

You are so genius! =D

 

[Kitabatake]

so vexorian changes part of triggers, so lets say someone wants to "steal" your map and save it (with changes or not, doesnt matter), a lot of errors pop up

my point is, we use vexorian on our map so we should stay calm because 99% of people wont be able to "steal" our map unless they are super pros?

Nobody wants to steal your map.

Pretty much the only reason why people would want to mess with a map is to slap in a cheat pack, which they can then abuse in multiplayer.
Doing this requires no skill and regular map protection is completely useless against it.

 

[WaterKnight]

Pretty much the only reason why people would want to mess with a map is to slap in a cheat pack, which they can then abuse in multiplayer.
Doing this requires no skill and regular map protection is completely useless against it.

Depends on the map if this requires skill, more so without breaking the map.

Even if you see through the protection, obfuscating practices like Vexorian's optimizer applies, destroy meaningful information how the map was created, therefore make it a pain.

 

[Kitabatake]

Depends on the map if this requires skill, more so without breaking the map.

Hell no, children can do that.

Even if you see through the protection, obfuscating practices like Vexorian's optimizer applies, destroy meaningful information how the map was created, therefore make it a pain.

...
How exactly does obfuscation make it a pain for you to copypaste a premade cheat pack into a map?

 

[Dr Super Good]

The best way to protect a map from being modified (this does not stop opening in World Edit) is by destroying the (listfile) in the archive and then turning on both "encryption" and "modify key by file offset" option. Without the (listfile) file, it is impossible to know what files the archive contains (you can still search for them if you know their paths). Nothing stops a person from modifying a single file but if the file is larger (eg a cheat pack is added) it will not fit in its current position. It is also not possible to move existing files to compact the archive as you do not have the decryption key and any movement would invalidate the decryption.

The end result is either 1 of the following.
- The person tries to detect all files in the archive and rebuild a complete (listfile). This results in him having to trace every single path referenced by the game data and check if that path is contained in the archive. Script computed file paths may never be detectable. If he succeeds he then has full control over the map, otherwise he will be forced to lose files or manually fix them.
- He tags the modified script file onto the end of the archive, leaving all other files intact. This is very easy to do but will make the map considerably larger (as there is a hole in the file where the old script was). Could possibly push map over then 8 MB limit.
- He deletes part of the script so it can fit in the hole of the original script, basically breaking the map.

If you do not delete the (listfile) then he has access to all file paths and so can do what he wants with the archive.

 

[WaterKnight]

Cheats only work within the environment. The environment is based on wc3 but may also be altered by the map.

For example, if one of your cheats is increasing the attack damage of the selected units but the map uses a damage system that does not consider the standard damage numbers since it calculates it otherwise, the cheat fizzles out.

If you try to create yourself a level 10 demonhunter but the map has edited slks, no unit will appear. Furthermore, if it does, the unit might be bypassing the system, thereby be created in a disregarded way -> it's not properly registered for the ways of the map.

That's the same issue as with importing any other trigger/feature. You have to consider the conditions it poses to the environment and adapt if required. When this is the case, having to make adjustments, the cheater will have a problem making sense of your creation.

 

[Kitabatake]

The best way to protect a map from being modified (this does not stop opening in World Edit) is by destroying the (listfile) in the archive and then turning on both "encryption" and "modify key by file offset" option.

I don't remember seeing these options in any optimizing programs.
Even google won't give results for "modify key by file offset".
How is this actually done?

Without the (listfile) file, it is impossible to know what files the archive contains (you can still search for them if you know their paths). Nothing stops a person from modifying a single file but if the file is larger (eg a cheat pack is added) it will not fit in its current position. It is also not possible to move existing files to compact the archive as you do not have the decryption key and any movement would invalidate the decryption.

Makes sense.
It reminds me of some people deliberately making their map the maximum multiplayer size so that any added cheat packs would push the size up and make the map unplayable.
That is of course very clumsy compared to what you just described.

Cheats only work within the environment. The environment is based on wc3 but may also be altered by the map.

Yes true, it is possible to develop a map in a way to pre-emptively negate the effects of cheating.
However, that may require more work and time than it's worth.

 

[WaterKnight]

I was not referring to specifically tailor the map in order to prevent intruders. My maps are partly suchlike far away from the standard engine that I do not really fear someone would edit it even without extra protection (or risk total chaos).

What are those you name cheat packs?

 

[Kitabatake]

I was not referring to specifically tailor the map in order to prevent intruders.

What are those you name cheat packs?

Basically triggers that allow certain players to use chat commands to modify resources, unit stats, hero attributes, ability cooldowns, spawn items/units, kick players, etc etc...

 

[WaterKnight]

You could inject another main function, so their triggers won't get initialized. Guess that would already swat most of them. Or mass-trial-destroy triggers before your own init runs.

 

[Kitabatake]

You could inject another main function, so their triggers won't get initialized. Guess that would already swat most of them.

That doesn't sound very convincing.
How would it prevent someone from just adding the triggers' initialization to both main functions?

Or mass-trial-destroy triggers before your own init runs.

Perhaps, but how do you refer to a trigger that is injected into the map later?

 

[Dr Super Good]

I don't remember seeing these options in any optimizing programs.
Even google won't give results for "modify key by file offset".
How is this actually done?

When generating the encryption key for a file you modify it based on where the file is being placed and how big the file is in total before setting the appropriate flag. This prevents one from moving the file without fully decrypting it. The base encryption key is generated from the file path, which is only stored in the (listfile) that is optional. There are brute-force approaches to decrypting files (how MPQEdit allows you to open files without knowing the path) but this relies on content detection to work and so might not detect some types of file.

 

[WaterKnight]

That doesn't sound very convincing.
How would it prevent someone from just adding the triggers' initialization to both main functions?

Well, I do not know their technique but automatically accessing the main function would require at least opening the map archive, parsing for the function within the .j and repacking. In this case, they would not need to edit the //! inject line of vJass i meant (which would not be easier to do by program). When compiling in JNGP, they would have to find the line you can hide anywhere. I mean it would halt the noobs that mostly do not even know about it.

Perhaps, but how do you refer to a trigger that is injected into the map later?

That's why I said trial-destroy. Use the new return bug to try to convert any id between current max and 2^20 (the lowest id a trigger can have). As long as it does not kill wc3, it's fine. Do the same for timers because these could restore the malicious parts.