Hashing (Java)

[Grok]

16000 simultaneous connected useRs?
16000 unique useRs?
16000 totalled uses?
16000 uses per day?

[Yoni]

16000 uses per second?

[Banana fanna fo fanna]

16000 active users, I believe. They probably auth with the server maybe twice a day. It's an HTTP GET afaik.

[Mesiah / haiseM]

ewww, not to mention eww@inaccuracy

[Nova1313]

700-1000 on at any given time. 300 new signups on average per week.

17000 users as of now approved for use. 21000 requests total 4000 some denied for spamming/warring purposes.

Unique logins per day depends. On saturday it peaks around 2000-3000
weekdays if you break 1000 thats lucky...

Alot of the users are 24/7 which has been extremely possible since the last patch I put out and a the new key auth dedicated server I purchased.

[Grok]

700-1000 "on at any given time"?

If it's an auth server, how are they "on" more than a second or two?

If there are 3000 logins max per day, you're saying each user remains connected to your auth server an average of 8 hours.

Says Barbie:  Math is HARD!

[n00blar]

BG3 isn't an auth server (i assume you are referring to something like BNLS?) it is a chat gateway.  They connect chatbots through BG3 to battle.net (like a proxy almost) i'm sure nova can explain in further detail

[Skywing]

BG3 isn't an auth server (i assume you are referring to something like BNLS?) it is a chat gateway.  They connect chatbots through BG3 to battle.net (like a proxy almost) i'm sure nova can explain in further detail

I believe he's referring to BG3's checkin ("BGKey") server.

[c0ol]

I messed with this for a day or so, and i fould that making the version check IN java would be a hack at best.  If you do want to attempt it go for it, heres how it works:
Battle.net sends you an equation like so A=345 B=566 C=123 A=A+B B=B-C C=C^S
what you want to do is read in the file one dword at a time (actually read it in 8k chunks and use it 1 byte at a time, but w/e) and set S as the current dword that you are processing.  Then loop through the equations and execute each one, where again S is the current dword.  do this for all of the files in the correct order, once you are done C will be the checksum dword.  You can do this in a number of ways, the easiest and slowest way to process this would be to have a series of if statements that you execute for every byte.  The other way, and prolly the best is to precompile the equations as machine code, and then run it like a function for each byte.  I hope this helps with your java porting.

[Banana fanna fo fanna]

Ah, thank you for explaining that.

[smoke]

what you want to do is read in the file one dword at a time (actually read it in 8k chunks and use it 1 byte at a time, but w/e) and set S as the current dword that you are processing.

There is a chance that you might need to account for byte order issues (little/big endian) when reading the dwords into memory from the file, I'm not sure what byte ordering Java uses by default when reading/writing to files.  It may be that the java virtual machine automatically rearranges bytes based on the underlying hardware.  Then it is a matter of determining which byte order Java uses.

x86 uses little-endian (low order bytes come first)
PPC uses big-endian (high order bytes come first)

-smoke

[c0ol]

well the operations arent byte order sincitive, + - ^ so i dont think it would matter.

EDIT:
actually you are right, because if u read 00 00 00 02 backwards it would be a totally diffrent number.  In java you would prolly start a byte buffer, and set the byte order to big edian then read all the files into it, and pop the dwords off the  top.

[TyC-Pros]

This is getting more confusing every time I read this. I've been thinking about this and I'm starting to think I might as well reinstall Delphi and start working on a Delphi-Bot...

Is there any documentation available on CD-Key decoding, CD-Key Hashing (and the other hashing things) and CheckRevision?