Yeah so I'm making a third party gateway for the actual brood war client (which already works great for bots, but most bots dont process UDP packets..) I've got it working good and figuring out every documented packet for BNCS... But I also want to have the gateway forward UDP packets as well... I've been able to obtain the UDP Code ("DWORD tenb"..) from the UDP packet 0x05, and I insert the value into 0x14 and send it directly after the approval from 0x51. I have tested this on my bot, which does not send 0x14, and it works perfectly. My problem is, just sending 0x14 from the actual Brood War client is not enough to convince battle.net that it is processing UDP packets. I'm pretty sure I'm not utilizing my UDP socket correctly, and I'm not sure how I should... Here is what is happening:
Brood war connects to my gateway, my gateway establishes connection to battle.net server.
Gateway forwards all packets to battle.net server.
(Working great up to this point)
Gateway receives UDP Packets 0x05, and 0x09 from the Brood war client, but isn't sending them to battle.net, it is forwarding the returns back to the client instead of to battle.net...
I've got the UDP socket set up like so (so far..):
sckLocalUDP.LocalPort = txtPort.Text
sckLocalUDP.RemotePort = txtPort.Text
sckLocalUDP.Bind
I've tried setting the remote host to the battle.net server as well, but it makes no difference, same results...
On incoming data, this is all my UDP socket is doing for now, since I can't figure this out:
Private Sub sckLocalUDP_DataArrival(ByVal bytesTotal As Long)
Dim strTemp As String
'[UDP PACKET]:
'0000: 05 00 00 00 74 65 6E 62 ...tenb........
'[UDP PACKET]:
'0000: 05 00 00 00 74 65 6E 62 ...tenb........
'[SID_PING] Received.
'[SID_PING] Returned.
'[SID_AUTH_INFO] Received.
'[UDP PACKET]:
'0000: 09 00 00 00 8A E3 E1 A6 8C 69 42 00 ....ŠãᦌiB.....
'[UDP PACKET]:
'0000: 09 00 00 00 8A E3 E1 A6 8C 69 42 00 ....ŠãᦌiB.....
'[UDP PACKET]:
'0000: 09 00 00 00 8A E3 E1 A6 8C 69 42 00 ....ŠãᦌiB.....
sckLocalUDP.GetData strTemp
AddText "[[UDP PACKET]]: " & vbCrLf & DebugOutput(strTemp)
sckLocalUDP.SendData strTemp
End Sub
I've thought about maybe Indexing the socket, But since UDP is connectionless, i don't see how it would matter....
So once again, im receiving udp packets from the client, but don't know how to forward those to the battle.net server... And it's probably some simple one line of code I'm missing, but I just don't know what it is...
Any Ideas? Please?
This will work.
You must set the socket to the destination address when sending, because when you recv, the socket will set its self to the address of the sender. (if that makes sence)
When you call GetData, the remotehostip and remoteport are filled with the senders address and port.
sckLocalUDP.GetData strTemp
AddText "[[UDP PACKET]]: From " & sckLocalUDP.RemoteHostIP & ":" & sckLocalUDP.RemotePort & vbCrLf & DebugOutput(strTemp)
sckLocalUDP.RemoteHost = battle.net
sckLocalUDP.RemotePort = 6112
sckLocalUDP.SendData strTemp
hope this helps
You do not need to send the received UDP data back to the server. You'll need to extract the UDP code from 0x05 and send it in SID_UDPPINGRESPONSE and since you said that you've already done this then you must be sending an incorrect code.
I don't know if you're having the same problem as I had when I first implimeted this, but I assumed that I'd always receive a UDP response before it came time to send it but I was wrong and ended up sending incorrect codes nearly every time. I solved this by halting the connection for up to 30 seconds until a UDP response was received.
I've logged everything. 0x14 is sending 100% fine and correct, as i said before, it works great on bots that dont send 0x14 at all. In the logs, however, its clearly visible that my gateway is receiving udp packets from the brood war client, then simply attempting to send them BACK to the brood war client. So no UDP packets are being send to battle.net... I'm going to try a few things, I'll post my results. Thanks.
Quote from: Mesiah / haiseM on December 27, 2005, 03:35 PM
I've logged everything. 0x14 is sending 100% fine and correct, as i said before, it works great on bots that dont send 0x14 at all. In the logs, however, its clearly visible that my gateway is receiving udp packets from the brood war client, then simply attempting to send them BACK to the brood war client. So no UDP packets are being send to battle.net... I'm going to try a few things, I'll post my results. Thanks.
Read my post, i explained why thats happening :)
I did, and just got finished trying it. No luck... I even tried creating a second UDP socket just for sending the received udp data to battle.net, nothing. I'm going to post a packet log to see if maybe one of u can understand anything out of it. Just keep in mind that this is a gateway, and most packets will appear in there twice or more.
1 127.0.0.1 127.0.0.1 59 Recv
0000 01 FF 50 3A 00 00 00 00 00 36 38 58 49 50 58 45 ..P:.....68XIPXE
0010 53 CD 00 00 00 53 55 6E 65 7F 00 00 01 2C 01 00 S....SUne....,..
0020 00 09 04 00 00 09 04 00 00 55 53 41 00 55 6E 69 .........USA.Uni
0030 74 65 64 20 53 74 61 74 65 73 00 ted States.
2 192.168.0.100 63.241.83.7 59 Send
0000 01 FF 50 3A 00 00 00 00 00 36 38 58 49 50 58 45 ..P:.....68XIPXE
0010 53 CD 00 00 00 53 55 6E 65 7F 00 00 01 2C 01 00 S....SUne....,..
0020 00 09 04 00 00 09 04 00 00 55 53 41 00 55 6E 69 .........USA.Uni
0030 74 65 64 20 53 74 61 74 65 73 00 ted States.
3 0.0.0.0 8 RecvFrom
0000 05 00 00 00 74 65 6E 62 ....tenb
4 0.0.0.0 8 Sendto
0000 05 00 00 00 74 65 6E 62 ....tenb
5 0.0.0.0 8 RecvFrom
0000 05 00 00 00 74 65 6E 62 ....tenb
6 0.0.0.0 8 Sendto
0000 05 00 00 00 74 65 6E 62 ....tenb
7 63.241.83.7 192.168.0.100 106 Recv
0000 FF 25 08 00 1D 28 3F A6 FF 50 62 00 00 00 00 00 .%...(?..Pb.....
0010 83 60 F2 0F 68 B2 36 00 00 AC 41 43 25 0B C5 01 .`..h.6...AC%...
0020 49 58 38 36 76 65 72 35 2E 6D 70 71 00 41 3D 39 IX86ver5.mpq.A=9
0030 35 33 31 33 34 38 30 31 20 42 3D 32 37 38 38 34 53134801 B=27884
0040 31 39 35 35 20 43 3D 38 37 32 38 32 38 32 37 20 1955 C=87282827
0050 34 20 41 3D 41 5E 53 20 42 3D 42 5E 43 20 43 3D 4 A=A^S B=B^C C=
0060 43 2D 41 20 41 3D 41 5E 42 00 C-A A=A^B.
8 192.168.0.100 63.241.83.7 8 Send
0000 FF 25 08 00 1D 28 3F A6 .%...(?.
9 127.0.0.1 127.0.0.1 106 Send
0000 FF 25 08 00 1D 28 3F A6 FF 50 62 00 00 00 00 00 .%...(?..Pb.....
0010 83 60 F2 0F 68 B2 36 00 00 AC 41 43 25 0B C5 01 .`..h.6...AC%...
0020 49 58 38 36 76 65 72 35 2E 6D 70 71 00 41 3D 39 IX86ver5.mpq.A=9
0030 35 33 31 33 34 38 30 31 20 42 3D 32 37 38 38 34 53134801 B=27884
0040 31 39 35 35 20 43 3D 38 37 32 38 32 38 32 37 20 1955 C=87282827
0050 34 20 41 3D 41 5E 53 20 42 3D 42 5E 43 20 43 3D 4 A=A^S B=B^C C=
0060 43 2D 41 20 41 3D 41 5E 42 00 C-A A=A^B.
10 127.0.0.1 127.0.0.1 8 Recv
0000 FF 25 08 00 1D 28 3F A6 .%...(?.
11 0.0.0.0 12 RecvFrom
0000 09 00 00 00 83 60 F2 0F 68 B2 36 00 .....`..h.6.
12 0.0.0.0 12 Sendto
0000 09 00 00 00 83 60 F2 0F 68 B2 36 00 .....`..h.6.
13 192.168.0.100 63.241.83.7 8 Send
0000 FF 25 08 00 1D 28 3F A6 .%...(?.
14 0.0.0.0 12 RecvFrom
0000 09 00 00 00 83 60 F2 0F 68 B2 36 00 .....`..h.6.
15 0.0.0.0 12 Sendto
0000 09 00 00 00 83 60 F2 0F 68 B2 36 00 .....`..h.6.
16 0.0.0.0 12 RecvFrom
0000 09 00 00 00 83 60 F2 0F 68 B2 36 00 .....`..h.6.
17 0.0.0.0 12 Sendto
0000 09 00 00 00 83 60 F2 0F 68 B2 36 00 .....`..h.6.
18 127.0.0.1 127.0.0.1 106 Recv
0000 FF 51 6A 00 05 4D 28 49 09 03 01 01 B7 66 EB 61 .Qj..M(I.....f.a
0010 01 00 00 00 00 00 00 00 0D 00 00 00 01 00 00 00 ................
0020 1D 19 09 00 00 00 00 00 2A 8A B2 D8 BA 47 8C C4 ........*....G..
0030 8E FB D8 0D 25 93 C2 38 12 47 7B D8 73 74 61 72 ....%..8.G{.star
0040 63 72 61 66 74 2E 65 78 65 20 30 39 2F 30 37 2F craft.exe 09/07/
0050 30 35 20 31 39 3A 30 36 3A 34 31 20 31 30 39 33 05 19:06:41 1093
0060 36 33 32 00 68 35 64 77 33 00 632.h5dw3.
19 192.168.0.100 63.241.83.7 106 Send
0000 FF 51 6A 00 05 4D 28 49 09 03 01 01 B7 66 EB 61 .Qj..M(I.....f.a
0010 01 00 00 00 00 00 00 00 0D 00 00 00 01 00 00 00 ................
0020 1D 19 09 00 00 00 00 00 2A 8A B2 D8 BA 47 8C C4 ........*....G..
0030 8E FB D8 0D 25 93 C2 38 12 47 7B D8 73 74 61 72 ....%..8.G{.star
0040 63 72 61 66 74 2E 65 78 65 20 30 39 2F 30 37 2F craft.exe 09/07/
0050 30 35 20 31 39 3A 30 36 3A 34 31 20 31 30 39 33 05 19:06:41 1093
0060 36 33 32 00 68 35 64 77 33 00 632.h5dw3.
20 0.0.0.0 8 RecvFrom
0000 05 00 00 00 74 65 6E 62 ....tenb
21 0.0.0.0 8 Sendto
0000 05 00 00 00 74 65 6E 62 ....tenb
22 0.0.0.0 8 RecvFrom
0000 05 00 00 00 74 65 6E 62 ....tenb
23 0.0.0.0 8 Sendto
0000 05 00 00 00 74 65 6E 62 ....tenb
24 0.0.0.0 8 RecvFrom
0000 05 00 00 00 74 65 6E 62 ....tenb
25 0.0.0.0 8 Sendto
0000 05 00 00 00 74 65 6E 62 ....tenb
26 0.0.0.0 8 RecvFrom
0000 05 00 00 00 74 65 6E 62 ....tenb
27 0.0.0.0 8 Sendto
0000 05 00 00 00 74 65 6E 62 ....tenb
28 0.0.0.0 8 RecvFrom
0000 05 00 00 00 74 65 6E 62 ....tenb
29 0.0.0.0 8 Sendto
0000 05 00 00 00 74 65 6E 62 ....tenb
30 0.0.0.0 8 RecvFrom
0000 05 00 00 00 74 65 6E 62 ....tenb
31 0.0.0.0 8 Sendto
0000 05 00 00 00 74 65 6E 62 ....tenb
32 63.241.83.7 192.168.0.100 9 Recv
0000 FF 51 09 00 00 00 00 00 00 .Q.......
33 192.168.0.100 63.241.83.7 8 Send
0000 FF 14 08 00 74 65 6E 62 ....tenb
34 127.0.0.1 127.0.0.1 9 Send
0000 FF 51 09 00 00 00 00 00 00 .Q.......
35 127.0.0.1 127.0.0.1 31 Recv
0000 FF 2D 04 00 FF 33 1B 00 1D 00 00 00 00 00 00 00 .-...3..........
0010 69 63 6F 6E 73 5F 53 54 41 52 2E 62 6E 69 00 icons_STAR.bni.
36 192.168.0.100 63.241.83.7 31 Send
0000 FF 2D 04 00 FF 33 1B 00 1D 00 00 00 00 00 00 00 .-...3..........
0010 69 63 6F 6E 73 5F 53 54 41 52 2E 62 6E 69 00 icons_STAR.bni.
37 127.0.0.1 127.0.0.1 49 Recv
0000 FF 33 18 00 1A 00 00 00 00 00 00 00 74 6F 73 5F .3..........tos_
0010 55 53 41 2E 74 78 74 00 FF 33 19 00 1B 00 00 00 USA.txt..3......
0020 00 00 00 00 62 6E 73 65 72 76 65 72 2E 69 6E 69 ....bnserver.ini
0030 00 .
As you can see, 0x14 is being sent correctly from my gateway, to the battle.net server. What I am thinking, however, is maybe the UDP socket is fine.... Maybe i have to send 0x14 back to the client too? or something???
Hmm, that looks fine to me.
Was your SC client useing port 6112 for UDP or another?
If it wasnt, its working perfectly, and if it was, i would say it is as well.
of course it is, as i have my udp socket's local port set to 6112, and am receiving data from the client.
Im lost where the problem is then :P
SC sends udp 0x09 to tell bnet what port its useing, then if bnet gets it, which it is, it sends the udp stamp to that port.
Then if SC gets it, which it is, it sends the stamp in the tcp 0x14 as proof.
[EDIT]: or is it your gateway sending 0x14 and not SC?
Ah, if its your gateway sending 0x14 on behalf of SC, and SC isnt getting the 0x05 UDP stamp, then you need to set the remotehost and port to SC's, because the socket will be set up for the last address and port that sent it a udp packet. (bnet)
Bingo. Obviously the SC client is saying "hrm.. no udp..", so its not sending 0x14. So, my gateway sends it. Battle.net definatly receives the 0x14 i sent, as it has been tested and works. But SC is still saying "Ok, No UDP, lets disable the game features", because for all SC knows, it never send 0x14 to begin with.
I've solved the problem of obtaining the user flags of 0x16 from not processing UDP. However, the brood war client still disables the buttons for game features, Which is pretty gay. Expected though. Does anybody have an idea on how to get around the disabling of these buttons? Probably not, but worth a shot :-P
Your gateway can always use FindWindowEx() to find the handles and change the state of the command buttons in Brood War's window class, this may work. Try using Microsoft's Spy++ to find out more information about Brood War's Battle.net chat dialog.
Thanks. Everything is now working perfectly :)