[VB2005] Stops in the middle of my Sub

[iNsaNe]

That's C#... it doesn't help me with Visual Basic.

You don't want the literal character ".".  That's what packet capture tools use to represent values that aren't ASCII.

I know. I'm just saying I want that to show up when I'm using Ethereal.

[Sorc.Polgara]

Part of the problem is that you're using the concatenate (&) operator.  When you concatenate a number and a string, the number is converted to string.  That's why you're seeing the 0s there.

That's what I tried to say.  But he didn't seem to understand.

@iNsaNe

The problem you're having is because numerical values are being converted to their string representation.  So, the number 0 is being converted to the string "0".  Similarly, the number 1337 would be converted to the string "1337".  Do you understand what we're saying?

Using the string concatenation operator & with non-strings means that it'll automatically convert the non-string data to a string and concatenate it to the left operand.

[iNsaNe]

Yes, I understand, and have been understanding. The only thing I don't understand is how to keep the numbers and the strings seperate yet sending them together with battle.net.

[MyndFyre]

That's C#... it doesn't help me with Visual Basic.

1.) Even if item (2) didn't apply, if you were using VB6 you could still use the MBNCSUtil library, because MBNCSUtil is exposed to COM.
2.) The entire point of the .NET Framework is so that you can use code written in other languages easily in your project.  All you need to do is download MBNCSUtil.dll, add a reference to it in your project, and you can use all the classes from it you need.  For instance:

Code Select Expand



Imports MBNCSUtil.*

... (in a method somewhere)
Dim pck0x50 As New BncsPacket(&H50)
pck0x50.InsertInt32(0)
pck0x50.InsertDwordString("IX86")
pck0x50.InsertDwordString("STAR")
pck0x50.InsertInt32(&Hcd)
pck0x50.InsertInt32(0)
pck0x50.InsertInt32(0)
pck0x50.InsertInt32(0)
pck0x50.InsertInt32(1033)
pck0x50.InsertDwordString("enUS")
pck0x50.InsertCString("USA")
pck0x50.InsertCString("United States")

sck.Send(pck0x50.GetData())


[Sorc.Polgara]

Not to downplay your suggestion Mynd, even though efficiency-wise and ease-wise it's the better option, but it would probably be more beneficial from an educational point of view for him to at least figure out how to do it without using MBNCSutil FIRST.

[Sorc.Polgara]

iNsaNe, you're better off rewriting the code that builds the packet.  I can't 100% tell if you're using a packet buffer class based on the code you've given, or just stuck a lot of variables, functions, and subs in a module.

I'll try get you started on helping yourself revamp your code by giving you some advice and code snipplets.

First, I suggest you import the System.IO and System.Text namespaces so that you can use the MemoryStream class and Encoding class easily.  Like MyndFyre has pointed out previously, utilizing .NET's MemoryStream class is good.

Importing these goes like this:

Code Select Expand


Imports System.IO
Imports System.Text


Now, you're going to want to scrap the concept of having strSendData as a string, and make it instead a MemoryStream.

So where ever you have declared strSendData, scrap it and replace it with something along the lines of:

Code Select Expand


Private msBuffer As New MemoryStream


Now take a look at this code:

Code Select Expand


Public Sub InsertDWORD(ByVal Data As Integer)
        msBuffer.Write(BitConverter.GetBytes(Data), 0, 4)
End Sub


Notice that unlike your VB6 code and since this is VB.NET, you don't really need that MakeDWORD and MakeWORD function anymore.

Now let's see if you can take it from here.

You will probably need to use the Visual Studio documentation for reference purposes, and I suggest you try and see if you can at least get an idea of what some of the methods in MyndFyre's C# DataBuffer class are doing.  For example, understanding the methods InsertCString() and InsertDwordString() will help with rewriting InsertNTString() and InsertNonNTString() respectively.

I do hope you at least attempt this, since I have spent more than an hour refamiliarizing myself with VB and doing some reading on the .NET framework to attempt to help you.  It's been years since I've touched anything VB.  I rewrote DarkMinion's VB6 PacketBuffer class to adhere to VB.NET... DarkMinion... boy that brought back memories... oh and yeah credit goes to MyndFyre's C# DataBuffer class which I used as a guide.

[MyndFyre]

Not to downplay your suggestion Mynd, even though efficiency-wise and ease-wise it's the better option, but it would probably be more beneficial from an educational point of view for him to at least figure out how to do it without using MBNCSutil FIRST.

You can't imagine the level of frustration I've garnered with people trying to use VB.NET who try to use code they got from another VB6 bot.  Especially now that Microsoft has made VB 2005 freely available in the Express edition.

[l)ragon]

Not to downplay your suggestion Mynd, even though efficiency-wise and ease-wise it's the better option, but it would probably be more beneficial from an educational point of view for him to at least figure out how to do it without using MBNCSutil FIRST.

You can't imagine the level of frustration I've garnered with people trying to use VB.NET who try to use code they got from another VB6 bot.  Especially now that Microsoft has made VB 2005 freely available in the Express edition.

Standerd versions of 2k2 and 2k3 were also downloadable from microsoft.

[brew]

VB 2005 .NET is silly, why do people even bother using it? It took the RAD right out of visual basic. If you want another nice(er) OOP lang, go for C#

[Barabajagal]

Or, if you still like the BASIC series, PowerBasic.

[Sorc.Polgara]

Actually, since using VB.NET a bit the last day I'm pretty satisfied at how it is now compared to VB6, which I'll forever despise for giving me bad programming habits in HS.  .NET improved it a lot in my opinion.  However I agree that you'd be better off learning C#.NET than VB.NET.

[iNsaNe]

Wow. I'm still having problems. It stops after everytime i use msBuffer (Private msBuffer = new MemoryStream)

Code Select Expand

Public Sub Send_SIDAUTHINFO()

        'C -> S 0x50 (SID_AUTH_INFO)

        frmMain.winSock.SendData(&H0)

        InsertDWORD(&H0) 'Protocol ID (0)
        InsertNonNTString("68XI") 'Platorm ID (IX86)
        InsertNonNTString("PX3W") 'Client ID (W3XP)
        InsertDWORD(&H0) 'Version Byte
        InsertDWORD(&H0) 'Product Language
        InsertDWORD(&H0) 'Local IP address
        InsertDWORD(&H0) 'Time zone information
        InsertDWORD(&H0) 'Locale ID
        InsertDWORD(&H0) 'Language ID
        InsertNTString("USA") 'Country Abbreviation
        InsertNTString("United States") 'Country Name

        SendPacket(&H50) 'PacketID = &H50 = 0x50

    End Sub

Private Sub InsertDWORD(ByVal Data As Integer)

        msBuffer.Write(BitConverter.GetBytes(Data), 0, 4)

    End Sub

[Sorc.Polgara]

First off are you using a class for building your packets?  If you aren't then... you're code is probably the epiphany of messiness and disorganization.  Also, based on the code you're given, I can't tell much to help debug the problem.

[iNsaNe]

It's one class named clsPacketBuffer

Code Select Expand

Imports System.IO

Public Class clsPacketBuffer

    Private msBuffer As MemoryStream = New MemoryStream

    Private Sub InsertDWORD(ByVal Data As Integer)

        msBuffer.Write(BitConverter.GetBytes(Data), 0, 4)

    End Sub '<-- Sub doesn't end -.- it's my problem. I inserted breakpoint here and the debug never reaches it.

    Private Sub InsertWORD(ByVal Data As Short)

        msBuffer.Write(BitConverter.GetBytes(Data), 0, 2)

    End Sub

    Private Sub InsertByte(ByVal Data As Byte)

        msBuffer.WriteByte(Data)

    End Sub

    Private Sub InsertNonNTString(ByVal Data As String)

        msBuffer.WriteByte(Data)

    End Sub

    Private Sub InsertNTString(ByVal Data As String)

        msBuffer.WriteByte(Data & Chr(0))

    End Sub

    Public Sub Clear()

        msBuffer.Dispose()

    End Sub


    Private Sub SendPacket(ByVal PacketID As Byte)

        frmMain.winSock.SendData(msBuffer.GetBuffer)
        If PacketID = &H50 Then AddChat(Color.Yellow, "-> Sending 0x50...")

    End Sub

    Private Sub ParseData(ByVal PacketID As Long)

        'Parsing
        Select Case PacketID

            Case &H25
                AddChat(Color.SpringGreen, "< -Received: 0x25!")

            Case &H50
                AddChat(Color.SpringGreen, "<- Received: 0x50!")

        End Select
    End Sub

    Public Sub Send_SIDAUTHINFO()

        'C -> S 0x50 (SID_AUTH_INFO)

        frmMain.winSock.SendData(&H1)

        InsertDWORD(&H0) 'Protocol ID (0)
        InsertNonNTString("68XI") 'Platorm ID (IX86)
        InsertNonNTString("PX3W") 'Client ID (W3XP)
        InsertDWORD(&H0) 'Version Byte
        InsertDWORD(&H0) 'Product Language
        InsertDWORD(&H0) 'Local IP address
        InsertDWORD(&H0) 'Time zone information
        InsertDWORD(&H0) 'Locale ID
        InsertDWORD(&H0) 'Language ID
        InsertNTString("USA") 'Country Abbreviation
        InsertNTString("United States") 'Country Name

        SendPacket(&H50) 'PacketID = &H50 = 0x50
    End Sub

End Class

[MyndFyre]

There are quite a few problems with this code that come to mind, aside from the style issues.

The first is calling Dispose() on the MemoryStream when you call Clear().  Because of the way your buffer is constructed, as you're kind of mixing instance and non-instance style of coding, you won't be able to build more than one packet out of this buffer.  Once you do, you'll generate ObjectDisposedExceptions whenever you try to send a new packet.

The next is calling MemoryStream.GetBuffer() and sending that to the server.  Because MemoryStream doesn't allocate additional memory every time it writes, but rather allocates memory in chunks, sending the results of GetBuffer() directly over the wire will often result in extra null bytes being appended to the end of your data.  If you look at my DataBuffer class, specifically the GetData() method, you'll see:

Code Select Expand


911        public virtual byte[] GetData()
912        {
913            byte[] data = null;
914            lock (this)
915            {
916                data = new byte[m_len];
917                Buffer.BlockCopy(m_ms.GetBuffer(), 0, data, 0, m_len);
918            }
919            return data;
920        }


This can be translated into the following VB.NET code:

Code Select Expand


Public Overridable Function GetData() As Byte()
    Dim data() As Byte
    SyncLock Me
        data = New Byte(Me.Length)
        Buffer.BlockCopy(msBuffer.GetBuffer(), 0, data, 0, Me.Length)
    End SyncLock
    Return data
End Function


Using Buffer.BlockCopy (Buffer is a static class that provides fast copying operations to byte streams) copies the data from one byte array to another, but allows us to define the length of the copy so that we avoid the messy extra null bytes.

I'm surprised, also, that you're not generating compiler errors.  MemoryStream.WriteByte() should not compile when you pass it parameters as strings because of type incompatibility.  You should retrieve the byte representation via System.Text.Encoding.ASCII, and write that byte array to the memory stream.  That could explain why your debugger never reaches your breakpoint - if there are compilation errors that are ignored, the debugger may be trying to break on code that doesn't exist.