HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

Game cache is not secure

03-18-2009, 03:54 PM#1
Strilanc
You may have seen the patch notes for the beta wc3 patch. They include a notice about detected modified maps. Right now it is relatively easy to modify the files in a map and still have it be authenticated by wc3 as the "same" map. This allows you to, for example, modify the script file to periodically tell you the position of enemies. As long as you use only GetLocalPlayer-safe-actions, you can make essentially any changes you want. This will be a problem for the rest of .22.

Which brings us to game cache. If you store a value in game cache, the SyncStored functions can be used to maliciously change the cached values. For example an ability which stores damage to apply in one second could have that damage value changed from 100 to a million.

If you're map is not competitive or not popular, then most likely no one will bother making a hacked version. But it's definitely something to consider. Dota has a couple of these issues and don't think they aren't being exploited.
03-18-2009, 04:28 PM#2
Captain Griffen
Ooo, very good point. Never thought of that (despite being aware that you can do the thing with maps being "the same"). Yet more reason to not use GC.
03-18-2009, 04:49 PM#3
Anitarf
This would have been important news three years ago.

Wait, SyncStored is GetLocalPlayer-safe?
03-18-2009, 05:36 PM#4
Strilanc
Quote:
Originally Posted by Anitarf
This would have been important news three years ago.

Wait, SyncStored is GetLocalPlayer-safe?

Yes. It's often used to put meta-data in replays (eg. name of hero selected), and maps only send it from one player to avoid repetition.
03-18-2009, 08:08 PM#5
akolyt0r
SyncStored will most likely change the value to the value the player with the lowest ping has ??

If thats true, hosting a hacked version would be pretty efficient for the host.

MAYBE this thread should be deleted before guys of wc3edit (etc..) get knowledge of this (if they dont have yet)
03-18-2009, 08:18 PM#6
Strilanc
Quote:
Originally Posted by akolyt0r
SyncStored will most likely change the value to the value the player with the lowest ping has ??

If thats true, hosting a hacked version would be pretty efficient for the host.

MAYBE this thread should be deleted before guys of wc3edit (etc..) get knowledge of this (if they dont have yet)

Only the player with the modified version sends the sync value; ping has nothing to do with it.

Blizzard mentioned it in the patch notes. I think that counts as well known. Trying to stop hacks by hiding information is a poor strategy, anyways.
03-18-2009, 09:39 PM#7
Ammorth
Using vJass and storing the ID of the struct to the GC would be a lot safer then, seeing as how the "hacking" player can't sync array values. You could try change the struct that will be used for the data, but couldn't locally change the data within any struct.
03-18-2009, 10:06 PM#8
Captain Griffen
And using an array based hash would be safer still.
03-18-2009, 10:42 PM#9
Strilanc
Quote:
Originally Posted by Ammorth
Using vJass and storing the ID of the struct to the GC would be a lot safer then, seeing as how the "hacking" player can't sync array values. You could try change the struct that will be used for the data, but couldn't locally change the data within any struct.

You could still do stuff like swap units' attached properties, not to mention sending a -1 to guarantee all the future reads return 0 [eg. for a cooldown_time_left count or something].
03-19-2009, 04:06 AM#10
Vexorian
Quote:
You may have seen the patch notes for the beta wc3 patch
what?
--

So, let me understand this, does this only apply when you are storing information such as spell config in gc?

Another thing is, wouldn't this cause a desync? You are using SyncStored but wouldn't it desync once there's actually an effect in gameplay? Or does SyncStored allow a LocalPlayer to modify all gamecaches of the rest of the people? I don't think so.

I am far more worried of the instant map-hack, btw wouldn't this work for melee maps as well? Or do they have a different way for authentification?

--
Edit: I am fairly sure the guy with the hacked script will desync at the very second he does something that modifies gameplay. You can certainly store extra damage in the gamecache without desyncing, but by the time the damage will be applied, you'll desync.
03-19-2009, 12:08 PM#11
DioD
Game cache is secure, there is no way to pass different data over gamecache to other players.
03-19-2009, 01:17 PM#12
Captain Griffen
I'm not so sure that's true, DioD. At least I'm fairly sure I've seen scripts that claim differently.
03-19-2009, 01:24 PM#13
Vexorian
I think SyncStoredInteger will desync if it is not called by everyone in the map.

Though I invite anyone to test it.
03-19-2009, 03:07 PM#14
Strilanc
Quote:
Originally Posted by Vexorian
I think SyncStoredInteger will desync if it is not called by everyone in the map.

Though I invite anyone to test it.

Dota places meta-data in the replay by using SyncStoredInteger from only one player. Otherwise it would repeat the data 10 times. It makes intuitive sense for SyncStoredInteger not to cause desyncs, because its purpose is to resolve sync issues.

The reason it won't desync when the 'damage is applied' is because the damage is read from game cache. the hacked version will desync itself only if the ability fires between the time the sync is used and other players receive it [250ms to 500ms usually].
03-19-2009, 03:17 PM#15
Vexorian
Quote:
Dota places meta-data in the replay by using SyncStoredInteger from only one player. Otherwise it would repeat the data 10 times. It makes intuitive sense for SyncStoredInteger not to cause desyncs, because its purpose is to resolve sync issues.
It makes sense for SyncStoredInteger to cause desyncs if it is not called by all computers, else it is a vulnerability and bug should be reported to blizz, it would be a huge screw up.

My suggestion is, don't assume, test it. Can a script set gamecache for every player if the legit script never calls SyncStoredInteger? I am sure it won't.