SID_AUTH_CHECK (0x51) Ignored

[shadypalm88]

This is probably one of those things where you look for a problem in something for so long you can't see it.  I've been rewriting the core of my bot in another language, and I've been testing it from a Mac (it's cross-platform).  Sending this packet to either real Battle.Net or TestBNCS yields an ACK but no packet in response.

The body of the packet follows (header is OK).  Maybe someone can spot the error.  This is a logon of a StarCraft client using OSX hashes.

Code Select Expand

00000000: 02 56 19 42 01 01 01 02 65 09 B2 C8 01 00 00 00  .V.B....e.......
00000010: 00 00 00 00 0D 00 00 00 01 00 00 00 -- -- -- --  ................
00000020: 00 00 00 00 F9 DB 58 11 39 10 D0 3F 97 F7 B9 68  ......X.9..?...h
00000030: F5 79 6D EC 1B 41 84 7F 53 74 61 72 43 72 61 66  .ym..A..StarCraf
00000040: 74 20 28 43 61 72 62 6F 6E 29 20 30 31 2F 32 32  t (Carbon) 01/22
00000050: 2F 31 30 35 20 31 39 3A 33 34 3A 32 37 20 31 33  /105 19:34:27 13
00000060: 35 38 37 31 32 00 4D 79 72 69 61 64 00           58712.Myriad.

P.S.  Shouldn't the code blocks really use a fixed-width font?

[UserLoser.]

no cdkey owner name

edit: we can use your cdkey now

[shadypalm88]

Whoops, I did the hex dump from the wrong spot.  That wasn't actually the problem.

[UserLoser.]

is 105 a valid year?  are you sure you're using 0x51 as id and not something else like 0x50?

[R.a.B.B.i.T]

This is a logon of a StarCraft client using OSX hashes.

You need to use the Windows hashes, even on a Mac.

[shadypalm88]

UserLoser: Yes, I logged the official client and that's how it sends the date (which differs from Windows versions).  And it's sending the ID 0x51 and the correct length.

Rabbit: Why's that?  My version info function knows how to handle the Mac binaries, and AFAIK, the CheckRevision algorithm is the same.

(Edit: fixed typo.)

[dxoigmn]

Do you set PMAC or XMAC in SID_AUTH_INFO (0x50)?

[shadypalm88]

Do you set PMAC or XMAC in SID_AUTH_INFO (0x50)?

XMAC.

[tA-Kane]

is 105 a valid year? are you sure you're using 0x51 as id and not something else like 0x50?

That's a known problem with the Mac clients. I'm not sure exactly what's the cause, though.

This is a logon of a StarCraft client using OSX hashes.

You need to use the Windows hashes, even on a Mac.

No, you don't. You use Windows hashes if you're reporting your platform as IX86, else you use Mac hashes if you report platform as PMAC or XMAC.


shadypalm, I know you say that the packet header is OK, but it still would be nice if you could show us it nonetheless. The only reason I can think of Battle.net not sending you a response would be an invalid (specifically, too high) packet length in the header. In most other likely cases, Battle.net would either disconnect you (and possibly IP ban you, depending on how badly you broke protocol), or send you a response with various non-success result codes.

[Arta]

Note that TestBNCS does not support non-IX86 version checking correctly. If you report your platform as PMAC or XMAC TestBNCS will only validate your version byte, and will not check anything else.

[shadypalm88]

shadypalm, I know you say that the packet header is OK, but it still would be nice if you could show us it nonetheless.

OK.  I think the 0x51 header looks right, but maybe there's some leftover garbage at the end of another packet or something of the sort.  So, here you go:

Edit Stupid endian issues.  I'm sending the ping packet with a length of 0x0800.  That'd be it.  Thanks for all your help.

[SENT] [RECEIVED]

0000: 01                                       .               

0000: ff50 3a00 0000 0000 4341 4d58 5058 4553  .P:.....CAMXPXES
0010: c900 0000 0000 0000 8401 a8c0 0000 0000  ................
0020: 0000 0000 0000 0000 5553 4100 556e 6974  ........USA.Unit
0030: 6564 2053 7461 7465 7300                 ed States.     

0000: ff25 0800 52e0 fabd                      .%..R...       

0000: ff50 6300 0000 0000 6eb4 1f3a 2b18 1a00  .Pc.....n..:+...
0010: 00a4 e4ae 63e8 c001 584d 4143 7665 7231  ....c...XMACver1
0020: 2e6d 7071 0041 3d36 3031 3732 3733 3638  .mpq.A=601727368
0030: 2042 3d39 3232 3733 3137 3132 2043 3d38   B=922731712 C=8
0040: 3534 3133 3738 3739 2034 2041 3d41 2d53  54137879 4 A=A-S
0050: 2042 3d42 5e43 2043 3d43 5e41 2041 3d41   B=B^C C=C^A A=A
0060: 5e42 00                                  ^B.             

0000: ff25 0008 52e0 fabd                      .%..R...

0000: ff51 7100 8edf 1942 0101 0102 3aec 7529  .Qq....B....:.u)
0010: 0100 0000 0000 0000 0d00 0000 0100 0000  ................
0020: 8e44 5a00 0000 0000 2a66 12e8 b072 f8d6  .DZ.....*f...r..
0030: b4a6 cece 7a81 d966 9ca7 e21d 5374 6172  ....z..f....Star
0040: 4372 6166 7420 2843 6172 626f 6e29 2030  Craft (Carbon) 0
0050: 322f 3231 2f31 3035 2030 343a 3431 3a34  2/21/105 04:41:4
0060: 3720 3133 3538 3731 3200 4d79 7269 6164  7 1358712.Myriad
0070: 00                                       .               

0000: ff00 0400                                ....

[MyndFyre]

Edit Stupid endian issues.  I'm sending the ping packet with a length of 0x0800.  That'd be it.  Thanks for all your help.

When I read this topic, that was my first thought; BNCS hardly if ever ignores a packet -- but it sometimes seems that way when you report a very large packet length.

[tA-Kane]

shadypalm, being that the endianness of your other two packets look correct, I would venture a guess that you're creating each packet manually.

I would highly recommend creating a simple packet creator which handles at least writing most of the common types, as it would end endian issues that you are having, since it would automatically account for endianness. Such common types as writing bytes, shorts, longs, and char arrays. All you do is add the data and tell it what ID to put in the header. Then when you want to actually write the packet, it'll create it for you; it will add 0xFF, the ID, the packet length (corrected for endianness), and then the packet data that you have already written (which would also have been corrected for endianness if you used your Write*() function.

[shadypalm88]

shadypalm, being that the endianness of your other two packets look correct, I would venture a guess that you're creating each packet manually.

Good guess, but it happens to be wrong.  I do have a packet buffer that automatically accounts for endianness depending on the platform it's built on.  (And I overload the shift operators, cout style, instead of using Write* functions, but whatever.)

But the ping packet is handled differently in that, like has been suggested here before, it is simply sent back to the server unprocessed.  However, when my bot receives a packet, it changes the order of the length field to host order directly in place in the received data.  Or, in code:

Code Select Expand

typedef struct {
    unsigned char sanity; // always 0xFF
    unsigned char id;
    uint16_t length;
} bncshead_t;

/* --- snip --- */

head = (bncshead_t*) (buf + position);
head->length = LSB2(head->length);

When this was being sent back to Battle.net, it still had the host endianness.  But thanks for the tip.