Optimal Save System 0.4

[PipeDream]

Updated, thanks again for the bug report.

[Magentix]

- You'll probably want to mess with the hash and obfuscation functions so that people can't use this stock system map to cheat. One thing that would make things very annoying is to save a random number at map start, then call SetRandomSeed(23), then let your initialization run that doesn't need to vary, then set hash/obfuscation parameters with GetRandomInt. Finally restore the random number you saved. This will force people to figure out those parameters. Remember though that the best you can do is help honest users remain honest.

Could you please elaborate on this?
I'm trying to combine several ways of making a save/load code as hacker-unfriendly as possible.

This method could be one of them if only I understood it fully :/

[Ammorth]

The hash is an algorithm that generates a number based on the "number" being saved. The hash can be any sort of mathematical operations with any numbers you want, but you should incorporate the saving number so that the hash is unique. The hash is also 1-way, so you don't have to worry about going backwards. The hash is calculated on both save and load and is compared. If the hash is the same, the code must be valid (no changes to the characters). More info about hashes can be found at wikipedia.

The reason you would want to make a custom hash is so that player's can't take this version here and use it to decode the save-codes your map generates. Creating a custom hash should change the code significantly that looking at this code won't help.

[Magentix]

Thanks, but I was more referring to (and interested in) SetRandomSeed(23) actually :)

[Ammorth]

The game uses random seeds to generate random numbers. http://en.wikipedia.org/wiki/Random_seed With the same random seed, you can generate the same random numbers every time. So, if you incorporate a random seed and GetRandomInt/Real then you can add complexity to your hash, as the person decoding needs to know the seed being used to receive the same hash.

The reason why you get a random number first is that you will get a random seed after the save-code and players won't find themselves random-ing the same numbers after a save.

[Magentix]

The reason why you get a random number first is that you will get a random seed after the save-code and players won't find themselves random-ing the same numbers after a save.

I like... 50% understand what you're trying to say, but how would this go into coding?

One thing that would make things very annoying is to save a random number at map start, then call SetRandomSeed(23), then let your initialization run that doesn't need to vary, then set hash/obfuscation parameters with GetRandomInt. Finally restore the random number you saved. This will force people to figure out those parameters.

This I understand (I guess...):
- So at map start (0.0 time or init?) I save a GetRandomInt(x,y) with the save/load system itself
- Then I call SetRandomSeed(z) before I initialize the rest of my map
- I use a GetRandomInt/GetRandomReal instead of the numbers in my hash code

This I don't get:
- But why the f.. do I have to save and restore a random number?
- And if I save a number first and then change the hash, won't that make me unable to restore it?
- Why would it "force people to find out those parameters"?


Thanks for the help so far, but I really need to understand this fully before I can safely use/adjust it in a map...
(If you could write out a library or something, showing a full example, I'd really apreciate it.)

[Ammorth]

Nothing should be done at map init with the save system. It should all happen during the saving/loading.

The reason why we save a random number before setting the random seed is so that after we are done with the hashing, we can set the number generator back to random numbers. If you were to do SetRandomSeed(GetRandomInt(0, MaxInt)) you would end up having the same random numbers occuring after every save.

For example. Lets say you need 10 numbers between 0 and 100 at random. Lets pretend we use random seed 56. Every time you call SetRandomSeed(56) the next 10 random numbers will be:

Code:

 35 18 72 89 44 06 29 48 92 31

So no matter when you call GetRandomSeed(56), the next 10 numbers after it will be the same. This is true for the next 100, next 1000, basically any amount of numbers you need.

So after the 10 random numbers, the same number would keep coming up for the SetRandomSeed(GetRandomInt(0, MaxInt)) as the 11th random number of seed 56 will always be the same.

Since we know all the numbers will come out the same after setting a seed, we can safely generate the same random numbers, as long as we know the seed from which the numbers were generated from. This is how we can increase the complexity of the hash.

I wrote a save-system similar to PipeDream's system here. Below the the hash part of the code:

JASS:

// This function requires 2 keys to recieve the correct hash.  One key is a version key, and the other is a player hash (convert the player's name into a number)
   private method hash takes integer key, integer key2 returns integer
        local integer hash = 0 // output
        local BigNumList l = .bignum.numList // because warcraft III doesn't support bignums, we have to simulate one with structs.  If you are not sure what this means, just remember this is a "bignum"
        local integer seed = GetRandomInt(0, MAX_INTEGER) // Here we save a random seed to set back later
        call SetRandomSeed(key) // Set our seed to the version key.  This adds complexity to the hash and requires the version to be know.
        loop
            set hash = hash + l.digit*GetRandomInt(0, key2)*key2 + key2*key*113-(key2+l.digit)*37 // the actual hash code; I'm not sure if it's effective.
            set hash = hash - (hash/HashSize)*HashSize // shrink the hash to the proper size
            exitwhen l.next == null // exitwhen we have no digits left
            set l = l.next // get the next digit of the bignum
        endloop
        call SetRandomSeed(seed) // return the random seed to normal by using the random number we generated from before.
        return hash // and return the hash
    endmethod
    
// Hashes the players name (converts it into an integer) which is then used in the hash function
    private method hashName takes player p returns integer
        local integer hash = 0
        local string name = GetPlayerName(p)
        local string temp
        local integer tempint
        local integer i = StringLength(name)
        local integer n = 1
        loop
            exitwhen n > i
            set temp = SubString(name, n-1, n)
            set tempint = GetLetterValue(temp, true)
            set hash = hash + tempint*hash + hash*31 - tempint + 99*tempint
            set hash = hash - (hash/HashSize)*HashSize
            set n = n + 1
        endloop
        return hash
    endmethod

As you can see, we only modify the random seed during the hash, and then revert it back instantly. MAX_INT is the maximum value an integer can be before causing problems (it overflows to a negative number). It is (2^31) - 1 or 2147483647

After a hash is created, it is saved into the save code. When the player loads a code, you can load the hash out and then rehash the save-code. If the hashes are the same, the code must be legit and then it is parsed.

[Magentix]

Thanks, now I understand what the idea is.


So suppose I did this at init:

- I save a random number SeedInt to a global
- I SetRandomSeed(someNumber)
- I set some globals named HASHInt1, HASHInt2, etc with GetRandomInt
- I SetRandomSeed(SeedInt)

Then, in my hash code I wouldn't use numbers, but HASHInt1, HASHInt2, etc.


That would always make my hash the same every time the map loads and yet more difficult for hackers to decode, right?
(Is that what PipeDream meant?)

[Arkan.]

Code:

method Clean takes nothing returns boolean

This function will no longer compile in 1.24 with JassHelpers "return bug fix". Any advice on how to fix it would be really helpfull.

EDIT: nvm solved it, used a local boolean variable fixed it.

[Rising_Dusk]

I think this might possibly have the worst documentation ever of anything I've ever tried to use. It uses a library that isn't approved and has no documentation, it should be using the Log library in the script database, it should have like a billion more comments, it should have an actual example in the testmap...

I mean, really.

[Hodge-Podge]

I play on a server where A-Z, a-z, 1-0, and Chars: ~!@#$%^&*()_+|}{":?></.,';\][=-` are all acceptable. Also haveing all chars acceptable in your save code system, would allow for LANers to save. My bnet name is Hodge-Podge, and my LAN name is }{odge-Podge, so it would be cool to have that capability =P, but anyways. Really nice system its one of the better ones out there

[Fledermaus]

Originally Posted by Documentation

Savecode_player_charset: These are the characters that will be considered in hashing a name. You probably want to add everything that is valid on bnet. It's ok if player has a name which contains a character this string doesn't, but if you later add that character, his codes will break.

[nome]

hi man i just downloaded the savecode.w3x and i got a crash before it can begin to load the map...

any ideaS?
nome

[Joker]

this resource is pretty outdated. Probably doesn't work with new patches.

[exilus4]

acutly how to active the save or load system(srry my english is bad)