several weeks ago i found that there are only about 2000 different checksum formulas sent by the server. for some reason, they decided not to make it fully random.

about a week after i found that out, they increased it to about 50k-100k different checksum formulas sent by the server. it is still limited.

If they coulda done this in the first place, could someone whos got a good idea of the lockdown mpqs explain why they originally only stayed with 2000 checksum formulas?

and wouldn't it be more efficient if they made it took advantage of all values possible? (10^20-50s)

what do you think is limiting blizzard's checksum formulas?

My guess is that it has something to do with making sure the values are correct, which might mean they use a database list of values that they check against.

Wouldn't it be most efficient (as in acual work done by the processor) to randomly generate a checksum formula and have the server hash the expected result on-the-spot then compare it with the client? Unless, ofcourse Blizzard is just cycling through a list of checksum formulas which was randomized after being initally created. (which would explain why Ante never got a repeated checksum formula until now)

That's what I thought they did at first, but how does the server hash the results? That's sort of the key, isn't it? If they have a big database, they can get the results from the game. If they have a different function that gets the same results somehow, then there's another way to crack this thing.

[quote author=[RealityRipple] link=topic=16247.msg164015#msg164015 date=1170641145]
That's what I thought they did at first, but how does the server hash the results? That's sort of the key, isn't it? If they have a big database, they can get the results from the game. If they have a different function that gets the same results somehow, then there's another way to crack this thing.
[/quote]

It's already been done. BNLS has been functional right after the release of new hash values by Battle.net, therefore BNLS does not use a large database, but rather has a function to calculate the correct results, or forces lockdown dlls to return the correct results.

I know, bnls will return any request you give it, I've written a program that does that. the question is, is there another way to get values?

If you generate a new one all the time, it all ends up being very processor intensive. Better to just have a massive hashtable to look up every time you want a result

you have to find the happy midpoint.
If you have 1 user connecting every second, then doing it on the fly is fine.
But if the function takes 500MS, and you have 100 people connecting every second.. it would be logical to have 2-4 'seeds' or w/e you wana call it. And have them be newly generated every 500ms or so.
It all depends on how much of a load you have both for the function and useage wise.
~Hdx

hdx is right. the algorithm used by checkrevision skips through the main game files as loaded into the address space, adding segments of data to the SHA1 information. this is a hefty process to do every time a user logs into battlenet. i think ive already told you this - caching this information is nothing new. battlenet has been doing this for a while. you're not onto something, you're just running in circles. but, from a client perspective, it's fine to run through the selective memory hashing routines once every connection, since it's only being performed once.

Final answer: There's no special function to get the values without memory hashes, otherwise the values would be randomly generated and the server wouldn't have a problem checking if the result was correct. It's probably a big cache database. Nothing accomplished!

[quote author=[RealityRipple] link=topic=16247.msg164057#msg164057 date=1170703922]
Final answer: There's no special function to get the values without memory hashes, otherwise the values would be randomly generated and the server wouldn't have a problem checking if the result was correct. It's probably a big cache database. Nothing accomplished!
[/quote]

No, you're completely wrong. There is a function that creates the digest values and returns them. That function is called checkrevision. And, on the server's side, I'm sure there's even a function that grabs their cached values, too! :P

i said there is no function to get it without the memory hashes. checkrevision uses memory values from the client's memory, hashes them, runs them through a function, and returns the result string and checksum

So, where are we? There's still one huge question: is there any signifcance at all to the new so-called checksum "formulas?" Or are they just originally randomly generated seed values put into a hash value with the expected checksum?

[quote author=BreW link=topic=16247.msg164064#msg164064 date=1170710065]
So, where are we? There's still one huge question: is there any signifcance at all to the new so-called checksum "formulas?" Or are they just originally randomly generated seed values put into a hash value with the expected checksum?
[/quote]

the new values are just like the old values...

They are...? How would the checkrevision function parse the values within the checksum formula? I've never really looked into them... Or, better yet. Are the values within the checksum formula used at all for anything besides as a seed to be hashed with the other values of the CR?

ok, now you're confusing me... Are you talking about the new lockdown values and old lockdown values, or the lockdown system and the ver system?

I think his talking about the new lockdown values.

Is it just me or do not all of you understand that the MPQs are sent to the client by random, and Blizzard is able to change anything about it at any time? :-\

There are patterns to it, though. For instance, clients that don't use the SID_AUTH_* system have very easily visible patterns. Each server uses the same MPQ and request for about half an hour. Originally, there were about 2000 used values for SID_AUTH_* connections, but that number has risen to an unknown size. Since there are around 15^256+16^256+17^256 possible requests per MPQ per client, the list could be very large indeed. But they DO have some method to their madness. It's not random (yet).

This all amazes me... the amount of time we put into figuring this all out, is just crazy. But I have a question, probably stupid, but i'm curious, you said BNLS always returns a value for what you send it (duh), but by sending it a value, and checking it's response, with enough before and after values, couldn't you caluclate the method used to generate the values? Thus finding out BNLS's method? Also, I believe we need to start a big DOC site, like BNETDocs, and call it CRevDocs ;) And put all confirmed and unconfirmed information in a clean easy to read setup, so our minds may all converse together.

I've tried looking for a pattern. I don't see one.

lol, if you want to know the method BNLS uses, just ask Skywing. He's not going to take kindly to you bruteforcing his server to find out how it works.

I'm not bruteforcing his server. I just made a program that requests any values you give it. Ended up with a rather large list of values that don't really exist... 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01... etc...

[quote author=Ante link=topic=16247.msg163983#msg163983 date=1170629834]
several weeks ago i found that there are only about 2000 different checksum formulas sent by the server. for some reason, they decided not to make it fully random.

about a week after i found that out, they increased it to about 50k-100k different checksum formulas sent by the server. it is still limited.

If they coulda done this in the first place, could someone whos got a good idea of the lockdown mpqs explain why they originally only stayed with 2000 checksum formulas?

and wouldn't it be more efficient if they made it took advantage of all values possible? (10^20-50s)

what do you think is limiting blizzard's checksum formulas?
[/quote]
Well, the lists were 1000 per client but they upped SC/BW lists to the same size as W3ROC and W3TFT (20k per client)

WAR3 -> 20000
W3XP -> 20000
D2DV -> 1000
D2XP -> 1000
STAR -> 20000
SEXP -> 20000
JSTR -> 1000
SSHR -> 1000
W2BN-> 1000
DSHR -> 1000
DRTL -> 1000

Inorder to make it random, Blizzard would have to do alot of modifications to battle.net.
At the end of the day, its inplace for checking a clients version, little if anything else :)
Hope that helps.

It'd be quicker to just implement your own version of checkrevision. It'd also work 100% of the time.

[quote author=Smarter link=topic=16247.msg164114#msg164114 date=1170744829]
This all amazes me... the amount of time we put into figuring this all out, is just crazy. But I have a question, probably stupid, but i'm curious, you said BNLS always returns a value for what you send it (duh), but by sending it a value, and checking it's response, with enough before and after values, couldn't you caluclate the method used to generate the values? Thus finding out BNLS's method? Also, I believe we need to start a big DOC site, like BNETDocs, and call it CRevDocs ;) And put all confirmed and unconfirmed information in a clean easy to read setup, so our minds may all converse together.
[/quote]
Don't people understand why you shouldn't brute force? Also, since the checksum is acually a message digest it's very doubtful you will find a pattern. See here for example, how one message can vary a great deal by even a single byte being changed.
@Ripple, Sorry for confusing you. I was talking about the new checkrevision formulas. And haha, Joe you gotta understand having the blizzard servers calculating thousands of checkrevision hashes per minute (they would have to create the checksum formula and compare the checksum on the fly) would be processor intensive. And while handling all other BNCS packets, at the same time.

[quote author=Ringo link=topic=16247.msg164142#msg164142 date=1170777348]
[quote author=Ante link=topic=16247.msg163983#msg163983 date=1170629834]
several weeks ago i found that there are only about 2000 different checksum formulas sent by the server. for some reason, they decided not to make it fully random.

about a week after i found that out, they increased it to about 50k-100k different checksum formulas sent by the server. it is still limited.

If they coulda done this in the first place, could someone whos got a good idea of the lockdown mpqs explain why they originally only stayed with 2000 checksum formulas?

and wouldn't it be more efficient if they made it took advantage of all values possible? (10^20-50s)

what do you think is limiting blizzard's checksum formulas?
[/quote]
Well, the lists were 1000 per client but they upped SC/BW lists to the same size as W3ROC and W3TFT (20k per client)

WAR3 -> 20000
W3XP -> 20000
D2DV -> 1000
D2XP -> 1000
STAR -> 20000
SEXP -> 20000
JSTR -> 1000
SSHR -> 1000
W2BN-> 1000
DSHR -> 1000
DRTL -> 1000

Inorder to make it random, Blizzard would have to do alot of modifications to battle.net.
At the end of the day, its inplace for checking a clients version, little if anything else :)
Hope that helps.
[/quote]
why do y ou think bnet didn't make it totally randomly generated when they implemented the lockdown checkrevision? why do you think they limited the values to 1000 or 20000?


[quote author=warz link=topic=16247.msg164056#msg164056 date=1170703710]
hdx is right. the algorithm used by checkrevision skips through the main game files as loaded into the address space, adding segments of data to the SHA1 information. this is a hefty process to do every time a user logs into battlenet. i think ive already told you this - caching this information is nothing new. battlenet has been doing this for a while. you're not onto something, you're just running in circles. but, from a client perspective, it's fine to run through the selective memory hashing routines once every connection, since it's only being performed once.
[/quote]
what does this have to do with caching information?

[quote]why do y ou think bnet didn't make it totally randomly generated when they implemented the lockdown checkrevision? why do you think they limited the values to 1000 or 20000?
[/quote]
Because, like warz said. It's processor intensive and basically a waste of time :/ It's easier to make a hash table, which has everything in the world to do with catching information, and compare the expected checksum to the client's result.

[quote author=Ante link=topic=16247.msg164236#msg164236 date=1170885038]why do y ou think bnet didn't make it totally randomly generated when they implemented the lockdown checkrevision? why do you think they limited the values to 1000 or 20000?


what does this have to do with caching information?
[/quote]

come on man, put two and two together.