[VB][Solved] Winsock Buffer Overflow - suggestions requested

[Don Cullen]

Before I start off, here's the souce of my bot:

DMBot.zip

Please check it out, if you're willing. Once you set up the login/cdkey vars, and execute the program, click connect, you'll see it connects, logins and goes to a channel fine. Even can chat/whisper with people. Looks good so far, right? Now click Disconnect.

It disconnects. So far, good, right?

Click connect. BAM, runtime error #6, overflow, apparently at winsock buffer. Do not, I repeat, DO NOT, attempt to reconnect. This results in ipban.

Strange, right? Well, exit VB. Then go back into VB, and run the program again. Strangely, it connects, logins, and enters channel without ANY problems.

Apparently as long as VB is restarted after a disconnection, the bot works fine. This is fine for a temporary solution, but it's starting to get aggravating...

I've been poring over my code, trying to find possible errors, but I keep coming up with nothing- it all seems good. So it is with this note, that I now plead with you guys to take a gander at it. Thanks to all of you guys teaching me about botmaking, I've been able to code enough to get the bot this far, so I'd like to take this chance to thank you guys for being very informative, helpful, and as well as especially patient, what with it being my first time coding a binary bot!

Thank you all very much for your help not only in the past, but also in advance!

[MyndFyre]

Before you ask us to fix your code, which I might be able to do from work without VB6 installed, I want to ask you -- have you tried to debug it?

Step through your code from where the connection sequence begins.  After which packets (if any) does the RTE occur?  Does it occur during a receive or send operation?  I mean, really, there are a couple dozen things you can check that it doesn't sound like you're checking.

[Don Cullen]

http://forum.valhallalegends.com/phpbbs/index.php?topic=12790.0

As you can see from that thread, I definitely have been trying to debug it.

And I *DID* step through the code. The only time the RTE occurs is when I use the SendPacket sub, and the line:

sck.SendData Chr(&HFF)

is highlighted. The RTE error only occurs when data is sent (or at least attempted to be sent). It seems to mainly only happen with the 0x0A, 0x51, and rarely, 0x29 when they are sent. Most of the time, the error occurs with 0x51, less often with 0x0A, and rarely 0x29. All of the other packets appear to be sent without a problem.

I modified my code to NOT disconnect upon RTE-- and watched bot without interacting with it. BNET sent my bot a ping, and my bot automatically replied to the ping with 0x25 without a problem. BNET sent a 0X00, and the bot automatically responded with a null packet. In both automatic response cases, the packet went through without an error. I then set up code for the bot to send specific packets upon request, and typed in the bot after 0x0A errored out:

/send 0x0a

The packet still errored out with an overflow. So to answer your implication, yes, I've been trying like heck to debug it, and I've been doing nothing but that for the past few days.

Thanks for the suggestion to step through the code step by step though-- while an excellent idea, I've already done that. Any more suggestions?

[l2k-Shadow]

Never errors for me... Your SendPacket sub is fucked up that's the problem.

Code Select Expand


Public Function SendPacket(sck As Winsock, PacketID As Long, Optional PacketFormat As pPacketFormat = pBNET) As Boolean
    On Error GoTo DumpHex
    'Returns TRUE if packet was successfully sent. FALSE if not.
    'If BNETSendComplete = False Then
    '    AddC vbRed, "Winsocket not available to send yet, please wait a moment..."
    '    Do
    '        DoEvents
    '    Loop Until BNETSendComplete = True
    '    AddC vbGreen, "Alright, it's open. Sending packet..."
    'End If
    'YOU DON'T NEED THE ABOVE CRAP!!!
    If sck.State = sckConnected Then
        'sck.SendData Chr(&HFF) & Chr(PacketID) & MakeMemory(Len(Buffer) + 4, pWORD) & Buffer
        sck.SendData Chr(&HFF) & Chr(PacketID) & MakeWORD(Len(Buffer) + 4) & Buffer
        SendPacket = True
    End If
    Clear
    On Error GoTo 0
'    BNETSendComplete = False <~ YOU DO NOT NEED THIS
    Exit Function
DumpHex:
    DMBot.BNET.Close
    AddC vbRed, " -- Error " & Err.Number & " (" & Err.Description & ") in procedure SendPacket in PacketBuffer class."
    Call DMBot.BNET_Close
    DumpPacket (Chr$(&HFF) & Chr$(PacketID) & MakeMemory(Len(Buffer) + 4, pWORD) & Buffer)
    Clear
End Function


You don't need the SendComplete crap... was that the problem? I did get winsocket error due to it, but no overflow error... just remove it and try again.

[Don Cullen]

Did you click disconnect, then click connect to attempt to re-connect to bnet, with the program STILL running? The oncomplete thing was added AFTER the RTE errors were occurring- that was an attempt of mine to try to fix the problem.

[Hdx]

http://hdx.no-ip.org/files/DMBot.zip <~~~modified source
took out the "BNETSendCompleet" If you send more while it's still trying to send info, it'll sjtu sit in queue.
Also, Updatres your unhandeled packet code to desplay the correct ID in hex, and the packet name.
Updated your Flag handeler for joining channels to reflect multiple flags.
also made it desplay hex upon unknow.

updated your dumppacket sub to  be faster. (HexToStr(StrTohex())) was jsut repettitve!
Added a function to get the packet name from the ID.
Also, After 35 mins of using ur bot.. I didnt get any overflow errors..

If you have questions ask.
~-~(HDX)~-~

[Don Cullen]

Unhandled packet code? Where? And the packet name?

http://hdx.no-ip.org/files/DMBot.zip <~~~modified source
took out the "BNETSendCompleet" If you send more while it's still trying to send info, it'll sjtu sit in queue.
Also, Updatres your unhandeled packet code to desplay the correct ID in hex, and the packet name.
Updated your Flag handeler for joining channels to reflect multiple flags.
also made it desplay hex upon unknow.

updated your dumppacket sub to  be faster. (HexToStr(StrTohex())) was jsut repettitve!
Added a function to get the packet name from the ID.
Also, After 35 mins of using ur bot.. I didnt get any overflow errors..

If you have questions ask.
~-~(HDX)~-~

[l2k-Shadow]

Did you click disconnect, then click connect to attempt to re-connect to bnet, with the program STILL running?

yes -.- multiple times

[Hdx]

Unhandled packet code? Where? And the packet name?

you dont handle 0x59 (SID_SETEMAIL)

Code Select Expand

AddC vbRed, "Unrecognized Packet ID: 0x" & IIf(Len(Hex(PacketID)) = 1, "0" & Hex(PacketID), Hex(PacketID)) & " (" & GetPacketName(PacketID) & ")"
Outputs

Unrecognized Packet ID: 0x59 (SID_SETEMAIL)

insted of

Unrecognized Packet ID: 89

~-~(HDX)~-~

[MyndFyre]

Unhandled packet code? Where? And the packet name?

you dont handle 0x59 (SID_SETEMAIL)

Code Select Expand

AddC vbRed, "Unrecognized Packet ID: 0x" & IIf(Len(Hex(PacketID)) = 1, "0" & Hex(PacketID), Hex(PacketID)) & " (" & GetPacketName(PacketID) & ")"
Outputs

Unrecognized Packet ID: 0x59 (SID_SETEMAIL)

insted of

Unrecognized Packet ID: 89

~-~(HDX)~-~

You know, 0x59 and 89 are the same values, right?

[Hdx]

DUA
His code was
AddC vbRed, "Unrecognized Packet ID: " & PacketID
And considering EVERY usually refers to BNCS packets by there IDs in Hex. Having a error that desplays them in hex, along with the designated name makes it A LOT easier to debug.
Insted of having to manually convert it to hex by hand, or read the packet log.
~-~(HDX)~-~

[MyndFyre]

DUA
His code was
AddC vbRed, "Unrecognized Packet ID: " & PacketID
And considering EVERY usually refers to BNCS packets by there IDs in Hex. Having a error that desplays them in hex, along with the designated name makes it A LOT easier to debug.
Insted of having to manually convert it to hex by hand, or read the packet log.
~-~(HDX)~-~

K, just wanted to make sure you knew it wasn't that much more than a cosmetic change.

[Don Cullen]

Overflow still results if I click disconnect, then click connect.

DementedBot activated at [9/14/2005 6:03:05 PM] .
Loading configuration...
Username: Kyro[DM]
Password: ********
CDKey: **************
Client: Starcraft: Brood War
Client VerByte: CD
BNET Server: asia.battle.net
BNET Port: 6112
BNET Default Channel: op Kyro[DM]
Config loaded.
Connecting to port 6112 at the asia.battle.net server...
Connected!
Initating packetage...
Notifying server of emulation...
0x01 protocol packet sent.
Server notification done.
Assembling 0x50 Protocol packet...
0x50 SID_AUTH_INFO packet sent.
BNET: Gimme your cdkey.
Assembling 0x51 SID_AUTH_CHECK Packet...
0x51 SID_AUTH_CHECK packet sent.
DMBot: Blah blah. There ya go. Happy?
BNET: Well...
BNET: Fine, I'll accept that...
BNET: But dude, who the heck are you?
Assembling 0x14 SID_UDPPINGRESPONSE Packet...
0x14 SID_UDPPINGRESPONSE packet sent.
Assembling 0x29 SID_LOGONRESPONSE Packet...
0x29 SID_LOGONRESPONSE packet sent.
DMBot: LOL! Well dude, I'm Kyro[DM]...
BNET: Uhhh...
BNET: Oh yea, I know you! Cool, welcome to BNET!
Assembling 0x0A SID_ENTERCHAT Packet...
0x14 SID_ENTERCHAT packet sent.
Assembling 0x0C SID_JOINCHANNEL Packet...
0x0C SID_JOINCHANNEL packet sent.
DMBot: By the way, I know my ABC's!!!
BNET: Cool! So do I! Anyway, welcome to BNET!
Now in Normal Channel op Kyro[DM].
EID_CHANNEL event tripped.
EID_SHOWUSER flag tripped.
Unrecognized Event ID: 0x09
Username: Kyro[DM]
Message:
Disconnected.
Connecting to port 6112 at the asia.battle.net server...
Connected!
Initating packetage...
Notifying server of emulation...
0x01 protocol packet sent.
Server notification done.
Assembling 0x50 Protocol packet...
0x50 SID_AUTH_INFO packet sent.
BNET: Gimme your cdkey.
Assembling 0x51 SID_AUTH_CHECK Packet...
-- Error 6 () in procedure SendPacket in PacketBuffer class.
Local Disconnect Confirmation.
Dumping packet...
StrToHex Dump:
FF 51 68 00 32 51 9B 00 09 03 01 01 E4 53 DA 0F 01 00 00 00 00 00 00 00 0D 00 00 00 01 00 00 00 0A 70 97 00 00 00 00 00 25 DB E8 F0 92 6F A0 F1 2D FA 90 54 4A AF 88 EB 82 CC FD AC 28 6E 75 6C 6C 29 20 30 37 2F 32 34 2F 30 35 20 32 33 3A 35 30 3A 33 31 20 31 30 39 33 36 33 32 00 44 6F 6E 20 43 75 6C 6C 65 6E 00
ASCII Dump:
ÿQh.2Q›.   

äSÚ
...........
....p—.....%Ûèð'o ñ-ú?TJ¯ˆë,Ìý¬(null) 07/24/05 23:50:31 1093632.Don Cullen.
End of packet dump.

But thanks for taking a look at it guys, I seriously appreciate it because I'm at my wit's end... Any more ideas?

[Kp]

One quick suggestion - if you're still getting IP banned for this, stop using bnet and switch to a more forgiving server.  Connect to the test server with a real client, and then connect with yours enough times to overflow.  Have a packetlogger running during all of these connections.  Ideally, save the capture of the real client to one file, and the captures of your client to two other files (one for first pass, one for error pass).  Then you can compare the packet dumps for protocol errors.  Beware that the test server may not even drop you for the violation, so you'll need to rely on other indicators (VB's overflow error, past experience, etc.) to indicate that you've got a "bad" connection captured.

If you need a packet capture program, get Ethereal (free).  Works best on real (non-Microsoft) systems, but you can coax it to work on MS-Windows.

[Don Cullen]

I'm not getting ipbanned, as long as I make sure I switch servers once the RTE occurs if I'm not planning on restarting VB. If I restart VB when the RTE occurs, apparently the program connects without a problem. Weird, no? I'm thinking maybe my winsock is damaged? Because apparently it works for the others, but not for me.

[Edited to avoid double-posting]

I just reinstalled the winsock. Still the same results. I don't understand why you guys have no problem reconnecting with the bot, while I do...