On The Vulnerability Of Save/Load Systems

I played a map which used a save/load system and i thought for myself; "Man there's no real protection against code stealing." Most save/load system use the user name as a protection against code stealing. You can simply go around this by using the favorite tool of kids. Most people would say that you can simply change the chat function to observer. That don't work as you would simply only have to save the replay and watch everyone load their codes.

To prevent this every save/load system could simply include a trigger that stores the name of the player upon loading and every time that player slot use the -save command you would simply check if the name corresponds with the stored name. If they name would not correspond with the stored name you could simply kick that player or do something funny.

I just wanted to point this out since the people who often use this kind of codes tries to prevent code stealing or hacked maps by reseting the code of every user and this is a step of doing this. A small step but a step atleast.

Credits to Owenalacaster for the topic name.

You can't see observer chat in replays (unless the replay owner was an observer in the game). You can't see any chat that you didn't see in-game in a replay.

Also when you talk about "using the favorite tool of kids", do you mean Name Spoofer? If so then I wasn't aware that it could change your name in-game. I don't think I've ever seen one that works that way so that kinda of ruins your solution..

What problem are you trying to address? If a player uses a name spoofer, that doesn't mean their name changes during the game.

All the information the map is given about the player is provided by the player. It's easily manipulable, so you can't rely on it to detect much of anything.


Name spoofing does affect your in-game name (why would wc3 display a spoofable name if it knew the right one?). *edit* Oh, I see that you meant it couldn't be applied in the middle of a game. That's correct.

Any chat which fires a trigger will be present in the replay data (otherwise the replay wouldn't work). You can use my replay explorer tool to see the text, even though it might not be shown in-game. It's stored in the TriggerChatEvent actions.

Everyone keeps saying you can't see observer chat from other players. But i remember that i were able to see player blue's observer chat when he loaded a code in The Black Road 2.0. I did in fact do the thing i warned about up here then. Took hes code and got it for myself. But on the other hand. This was way back when Shadow****** used to make these "tools". I tried to get Griffen or Rao writing something in the observer chat but that failed, but since even Griffen states that you cant see observer chat in replay's without extracting the data i should believe that. But i am pretty sure that you could change name in game with shadow******'s namespoofer without problems. But hey, if there is no real problem with this, great. No need to fix it. :)

There is a problem in that you can still extract it from the replay. The data's there, it needs to be.

I think the non-problem he was referring to was changing your name during the game.

It comes down to this: If someone wants something, there is little you can do to stop him from getting it.

Now i consider myself a normal user. But i don't know how the hell to do this and i don't think i would learn how to extract data from a replay just so i could get someones code. It would be easier just asking for it since that player would not think i could use it.

Or it is that you just open the replay in a program and the chat is clear as a day in there or you can simply just search for -load?

That and the problem that you could steal codes via replays even if a player used the -load via the observer chat. I tested it and you could not change name in game at least not your visible name so here i were wrong. And i believe the save code go by the name you are using in the game when you are saving. But if the code goes by your battle name and the namespoofer actually changes your name but not your visible name althought theres a really slim chance it actually works this way.

So to prevent the extracting codes from the replay one could simply change the load system to one where you use a shop to type in your code with numbers instead. This would probably not be user friendly at all and take a long time. But it would prevent from extracting the chat -load from replays. Unless there's information about what you buy/ability you use.

I would just like to note that i got zero coding knowledge.


You might not be able to fully stop them without touching the actually wc3 engine code. But you can make it harder for them to get the codes. Which will stop lazy or stupid people from even trying. Like my self.

you cant protect your code, there is easy way to use modded map with your favorite set of skills and items to generate code you like and then use in online.

20 mins work for any map, since there is no way to detect code modifications you cant protect from it.

1) Crush MPQ corruption with zezula (if WC3 read map, you also can)

2) Inject your own code (First you will need to write it, not hard, you can load wc* files into editor or SLK into office to get object rawcodes and other valueble data)

3) Disable singleplayer protection (hook GetSlotState, GetPlayerControl)
Replace this functions calls with your own function with proper return
Not needed to check entire code for player counting function, just hook and return values like there is multiple players online
Also you will likely to hook SaveGameCache and few other function that may be used for online detection

4) Hook GetPlayerName (also you can set your name onfly but some maps store such data on init, soo better to hook for predifined return)
If map dont store playernames you can use simple function for setting your name onfly to break playername linking

5) Set level, gold, items or whatever you like

6) Save

7) ???

8) PROFIT

Some maps uses events or time to prevent such actions, this will make process harder, since you will be forced to set event data and time data, in some cases you will be forced to play game (in single player mode and possible with cheats) before can generate genue code.

The only type of security you can implement in save/load codes is security through obscurity. I usually decry all forms of security through obscurity, but in this instance, the data you are attempting to secure is of a low value; thus the reward-to-effort ratio of breaking the "security" is low.

Some of the only real ways to "secure" save/load code systems are:
- Store a user's full name, or preferably, a hash of it, in the save code. Yes, name spoofers and other things can easily circumvent this. There is no way to prevent that.
- Randomize the order and structure of the save code as much as possible
- Include junk data in a hard to decipher way. (Making every 5th character in a generated code a "fake" is an example of doing this so very wrong.)
- Do not align data values (Either real data, or junk data) with glyphs. What this means is that no single character in the save code should represent only one segment of data. (Don't encode a hero's level in the first character of the code, then his first item in the second character... encode his level and his first item in such a way that when one of those values changes, it will change more than a single character in the generated code)
- Don't grab values for what to put in the code at the time of code generation. If a hero gains a level through valid gameplay mechanics, increment a variable. If a hero gains an item through valid gameplay mechanics, store the item type in a variable. This involves some heavy amount of coding, as you have to validate as much as possible at runtime. (eg, someone can just fill the map with uber items then save... so you must attach data to items that are created validly during gameplay (dropped by monsters, bought, crafted, etc.) to help make such cheating more difficult.)
- Use Vex's map optimizer
- Accept the fact that if you do all of the above, and more, flawlessly, people can break the system and cheat.
- Accept the fact that if you do even just most of the above and people break the system and cheat, that you have created a map worthy enough for them to invest a somewhat large sum of time and energy in to cheating in it. Good job! :)



What it really boils down to is making the code generation code split over as much of the map as possible, while making the code generation code itself complex, as well as the codes it outputs. That way, opening the map and adding new (v)JASS code to it to cheat for you becomes much harder, as you must understand a significantly larger portion of the existing (optimized/raped) code to do so effectively. As well, attempting to brute force the code pattern should be extremely difficult if you are randomizing, miss-aligning, and adding good amounts of junk in the right places.

An often overlooked idea is messing around with array indexes. Instead of String[3], use String[9-7+1]. You could also try throwing in a few constants, String[3] becomes String[bj_CAMPAIGN_INDEX_O].

this countered by simple automated scipts that support constant calculations.

just like 256* or hex conversion

You can always add a password which is decided at the creation of the savecode. The password is then saved into the code and is needed to load the code.

yes, great... same problem again.. everyone can steal that password.

yes, but they need to work harder to get (and don't be stupid to have a non-unique password). Ofc, there is the problem with replays.