S > C 0x71

[brew]

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.

[Barabajagal]

Code Select Expand

(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.

[brew]

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.

Code Select Expand


M8Z9JYFXVH6XCED4REBBHBWGHT


edit* spelling

[Barabajagal]

BNCS: Account requires upgrade for that key.

[Kayla]

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.

[brew]

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

(DWORD)  Result
(STRING)     Patch path

:p....

Code Select Expand


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?

[l2k-Shadow]

disassemble the file and look at the parser.

[Barabajagal]

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

[brew]

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...)

[Barabajagal]

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.

[brew]

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.

[l2k-Shadow]

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.

[brew]

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?

[l2k-Shadow]

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.

[brew]

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....