What does the response byte 0x02 mean for the "status" in this packet? I feel like the documentation of this packet found on Bnetdocs is somewhat incomplete.
(DWORD) Cookie
(BYTE) Result
(STRINGLIST) Failed account names
I don't see any "status", and Result only returns 0, 4, or 5 as far as I've seen.
OH SO SORRY. I ment result not status.
And trust me, there is an 0x02 response. Here, I believe the same applies to the 0x70: Try sending one on THIS Warcraft 3 cdkey, with a clan tag you know has been taken (try dm for example), on any europe server.
M8Z9JYFXVH6XCED4REBBHBWGHT
edit* spelling
BNCS: Account requires upgrade for that key.
Hmm I noticed this while use an older War3 name maker. The server would respond with the same message. Even when I tried to logon using client.
Greetings to vl forum kalya :-p
And yeah, it has to do with "Clanned cdkeys". What's interesting is that you only get that response from a voided cdkey when you send a clan tag which is already in use, and a response of 0 when it's avaliable. (the response is always 2 when using a non voided cdkey) but when not clanned returns the normal response of 1. Well, my real question was what does it mean with the 0x71 packet response and if it returns a list of the failed usernames as with the 0x04 and 0x05 response. If it did this would make clan creators much easier to use, etc. Why isn't this at all in bnetdocs anyways?
Eh, speaking of bnetdocs not being inaccurate, i figured today i would make an SSHR connection, and lo and behold, in the S > C 0x07 packet I get this response:
FF 07 0A 00 00 00 00 00 00 00
where bnetdocs says
Quote
(DWORD) Result
(STRING) Patch path
:p....
FF 07 0A 00 '4 byte packet hearder
00 00 00 00 'response dword (failed version here)
00 'Patch path - is a null string
00 'wtf? either some loose byte or another null string
Err...
Blizzard only started using bytes in their packets around the warcraft 3 clan packets era, before that they were literally ALL dwords or strings.
So it's more likely (possibly even safe to assume) that the extra null character is the null terminator for a second, null terminated string that was somewhere along the line dropped from this packet. any ideas what this could be?
disassemble the file and look at the parser.
0 is a failed version check (unable to authenticate, not outdated)
1 is old game version (this will give you the patch info)
2 is valid game version (you then send your response/key depending on client)
3 is corrupted hash files
Quote from: Andy on June 23, 2007, 02:01 PM
0 is a failed version check (unable to authenticate, not outdated)
1 is old game version (this will give you the patch info)
2 is valid game version (you then send your response/key depending on client)
3 is corrupted hash files
ok, thanks for the info reality.
(even though it was kind of random...)
No, it wasn't random. You were asking why it responded with null data. The reason is because it was supposed to respond with null data.
Quote from: Andy on June 23, 2007, 05:05 PM
No, it wasn't random. You were asking why it responded with null data. The reason is because it was supposed to respond with null data.
uh...
I asked why there's 2 strings in the packet instead of one, which is what bnetdocs says. ::)
Hey, uhh... anyone have any spare PMAC SSHR hashes laying around? :-P It'd be great if I could use them.
EDIT*** And/or the following hash files (all IX86 versions):
JSTR
DRTL
DSHR
that'd be the shizzle if anyone can get those for me.
Quote from: brew on June 23, 2007, 05:44 PM
Quote from: Andy on June 23, 2007, 05:05 PM
No, it wasn't random. You were asking why it responded with null data. The reason is because it was supposed to respond with null data.
uh...
I asked why there's 2 strings in the packet instead of one, which is what bnetdocs says. ::)
Hey, uhh... anyone have any spare PMAC SSHR hashes laying around? :-P It'd be great if I could use them.
EDIT*** And/or the following hash files (all IX86 versions):
JSTR
DRTL
DSHR
that'd be the shizzle if anyone can get those for me.
in PMAC SSHR login, it sends you a hash string which doesn't contain any operation, which means that they don't check if that login is authentic.. which means you can send 0 for checksum and null string for exe file information.
Quote from: l2k-Shadow on June 23, 2007, 06:38 PM
in PMAC SSHR login, it sends you a hash string which doesn't contain any operation, which means that they don't check if that login is authentic.. which means you can send 0 for checksum and null string for exe file information.
Uhm... I just tried that. It gave me an invalid version response, so then I tried to send the 0x29 anyways. Gave me an ipban. Oh well... did you mean when connecting with the X-SHA connection sequence? (0x50, 0x51, 0x3a, 0x0a) I'm trying to log in using the legacy connection sequence (0x05, 0x06, 0x28, 0x29, 0x0a)
Also does anyone have those hash files? by any chance?
Quote from: brew on June 23, 2007, 08:28 PM
Quote from: l2k-Shadow on June 23, 2007, 06:38 PM
in PMAC SSHR login, it sends you a hash string which doesn't contain any operation, which means that they don't check if that login is authentic.. which means you can send 0 for checksum and null string for exe file information.
Uhm... I just tried that. It gave me an invalid version response, so then I tried to send the 0x29 anyways. Gave me an ipban. Oh well... did you mean when connecting with the X-SHA connection sequence? (0x50, 0x51, 0x3a, 0x0a) I'm trying to log in using the legacy connection sequence (0x05, 0x06, 0x28, 0x29, 0x0a)
Also does anyone have those hash files? by any chance?
i use 0x05, 0x06, 0x07 works fine, i suggest checking your code.
Oh snap. You're right, it was my code. (i gave up on sshr and started working on JSTR, so i hard coded jstr to be the client ....ewpps, but i still don't have the hashes for that.... -.-)
If only bnls had support for these odd clients....
BNLS does support JSTR.... 0x06
Indeed it does. Thanks for catching that, RealityRipple.
Although.... in theory it should work just like PMAC SSHR, there is no checksum formula, it's just a null string. so it would expect just any old response, right? nope. some reason it requires a valid response. eek :(
And bnls still doesn't support DRTL or DSHR, so how are we supposed to connect to these clients?
My Cache DB and logon server works for them (but I just got my IP switched and the DNS is taking forever.) Try 72.173.96.196:9367 for 0x1A if you want. And I'm fairly certain JSTR does not work like SSHR.
Quote from: Andy on June 23, 2007, 09:43 PM
My Cache DB and logon server works for them (but I just got my IP switched and the DNS is taking forever.) Try 72.173.96.196:9364 for 0x1A if you want. And I'm fairly certain JSTR does not work like SSHR.
Does your logon server work with 0x09 and 0x18 packets too? I have what bnls packet to use an option in my bot.
Just 1A currently, sorry.
Edit: Also, my ISP is a dirty wh0re, and only lets incoming packets through every few tries usually. It's really odd.
Quote from: brew on June 23, 2007, 09:40 PM
Indeed it does. Thanks for catching that, RealityRipple.
Although.... in theory it should work just like PMAC SSHR, there is no checksum formula, it's just a null string. so it would expect just any old response, right? nope. some reason it requires a valid response. eek :(
And bnls still doesn't support DRTL or DSHR, so how are we supposed to connect to these clients?
Is there even a mac version for sc japanese? lol
Quote from: brew on June 23, 2007, 12:19 PM
Eh, speaking of bnetdocs not being inaccurate, i figured today i would make an SSHR connection, and lo and behold, in the S > C 0x07 packet I get this response:
Sorry to nitpick, but the phrase "not being inaccurate" isn't accurate per se. That basically is saying the BNETDocs is accurate. The 'in' part of the inaccurate word is a prefix meaning "not", so you basically just said "not being not accurate".
Okay. Done nitpicking. :)
Quote from: brew on June 23, 2007, 05:44 PM
Quote from: Andy on June 23, 2007, 05:05 PM
No, it wasn't random. You were asking why it responded with null data. The reason is because it was supposed to respond with null data.
uh...
I asked why there's 2 strings in the packet instead of one, which is what bnetdocs says. ::)
Clicky (http://forum.valhallalegends.com/index.php?topic=16166.msg162941#msg162941), Skywing says the officual useage of the 2nd string.
This is partly why its best to packet log the client (if possible) then compare the packet log with the documentation on bnetdocs :)
Quote from: Kyro on June 24, 2007, 02:59 AM
Sorry to nitpick, but the phrase "not being inaccurate" isn't accurate per se. That basically is saying the BNETDocs is accurate. The 'in' part of the inaccurate word is a prefix meaning "not", so you basically just said "not being not accurate".
Okay. Done nitpicking. :)
oops.... typo. i would have never said that consciencously
Same thing goes for people who ask "Didn't he come to work?" and people would respond "No", but that's backwards too. Saying the negative of "someone did not come to work" means he did come to work, right? I mean... its like saying ~(~asdf). The correct response would be "yes", but nobody seems to know what you're talking about when you respond that way. It's quite confusing, and I tend not to use bad grammar so I usually respond with the entire sentence back. :-/
Thanks for the feedback, Kyro.
@Ringo, thanks for linking me to that topic. even though, it's improperly labeled in bnetdocs as a STRING, where it really should be either two STRINGS or a STRINGLIST type. (which is defined somewhere else in bnetdocs) Hey uh... any idea on when bnetdocs is coming back up? and when people will be able to register?
Saying "No, he didn't come to work" is correct. "No" would imply you add no to the beginning of the question rephrased as an answer ("Didn't he?" "He didn't"), not a falseness of the question. That'd be "No, he did", and that's not what the question asked.
Quote from: Andy on June 24, 2007, 11:11 AM
Saying "No, he didn't come to work" is correct. "No" would imply you add no to the beginning of the question rephrased as an answer ("Didn't he?" "He didn't"), not a falseness of the question. That'd be "No, he did", and that's not what the question asked.
I'm talking about when people give those one-word answers like "yes" or "no", not an entire sentence. It's kind-of confusing. I assume you're talking about the response-prefix before the people give their actual explination, like "No, blahlbahlbalh" or "Yea, blah blah blah"
I'm saying "No" implies "No, he didn't come to work", not "No, he did come to work" because the question was "Didn't he come to work?" which means "Did he not come to work?". The correct response is "No, he did not come to work", not "Yes, he did not come to work". Even though both make grammatical sense, it's a matter of syntax and common language use. No and Yes are shortened versions of an entire response. Negative questions are answered with negative answers if the question was correct.
Quote from: Andy on June 24, 2007, 11:44 AM
it's a matter of syntax and common language use. No and Yes are shortened versions of an entire response.
The decay of western culture *sigh*
EDIT** uhm, why not use 9367 for your bnls port? also what are the client id numbers for DRTL and DSHR.... lol
No, that's just the decay of the English Language. The decay of western culture is the lack of common courtesy... But I'm not going to get into that on here.
yah
So i got the hashes for JSTR and i was able to make a connection without bnls, using rob's checkrevision function, and SEXP's dx buffer dump, and it worked. Woot. Dammit, bnls is just about always down. Y?
btw, i have the DRTL and DSHR hashes too, so i dont need it anymore. by the way, does anyone know how to and/or have a diablo 1 directx buffer file? (rob's format)
Sorry, that was a typo. it does use 9367... Also, I think Blake said rob's dll doesn't work for d1.
Quote from: Andy on June 24, 2007, 09:20 PM
Sorry, that was a typo. it does use 9367... Also, I think Blake said rob's dll doesn't work for d1.
Jeez, no wonder why it never responded.
And it most likely does. He probably has the directx buffer dump file in the wrong format. Also do you know where I can get the version that works with W2BN?
And for your bnls server, what are the client id numbers for DRTL and DSHR? You know... for regular bnls it's like
Public Function GetClient(Client As String) As Long
Select Case Client
Case "STAR": GetClient = 1
Case "SEXP": GetClient = 2
Case "W2BN": GetClient = 3
Case "D2DV": GetClient = 4
Case "D2XP": GetClient = 5
Case "JSTR": GetClient = 6
Case "WAR3": GetClient = 7
Case "W3XP": GetClient = 8
End Select
End Function
? :-P
They're the same as JBLS:
DRTL 9
DSHR A
SSHR B
Thx