There is something that I cannot figure out, and that there is some bug in my code that makes VB 2005 stop in the middle of my sub. It is C->S SID_AUTH_INFO:
Private Sub winSock_ConnectEvent(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles winSock.ConnectEvent
strSendData = vbNullString
AddChat(Color.SpringGreen, "<- Connected!")
If strProduct = "Warcraft III FT" Then
'// C -> S 0x50 (SID_AUTH_INFO)
winSock.SendData(Chr(1)) '// Sub Stops Here...
InsertDWORD(&H0) '// Protocol ID (0)
InsertNonNTString("68XI") '// Platorm ID (IX86)
InsertNonNTString("PX3W") '// Client ID (W3XP)
InsertDWORD(&H15) '// 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 If
End Sub
If any visual basic 2005 users out there could point out whats going wrong.. i would appreciate it.
Have you tried debugging? I'd bet that if you stepped through line by line, you could find out which line was causing it to stop.
Visual Basic 2005 has GREAT support for this kind of thing. It's called "setting breakpoints" and then clicking the arrow button that looks like a play icon on a VCR or DVD player for you youngsters out there.
If he's useing the winsock 6.0 control, that could be the source of his problem to.
I found a few of the old controls will crash and disapear for no reason with .Net.
I used breakpoints, revised it, now it passes winSock.SendData line and stops at the next one, which the problem I believe is due to CopyMemory (my question in the other topic). MakeWORD is my problem.
Public Declare Sub CopyMemory Lib "kernell32.dll" Alias "RltMoveMemory" (ByVal Destination As String, ByVal Source As Integer, ByVal Length As Long)
Private Sub winSock_ConnectEvent(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles winSock.ConnectEvent
strSendData = vbNullString
AddChat(Color.SpringGreen, "<- Connected!")
If strProduct = "Warcraft III FT" Then Send_SIDAUTHINFO()
End Sub
'// Now my module
Public Sub Send_SIDAUTHINFO()
'C -> S 0x50 (SID_AUTH_INFO)
frmMain.winSock.SendData(&H0)
InsertDWORD(&H0)
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
Public Function InsertDWORD(ByVal Data As Long)
strSendData = strSendData & MakeWORD(Data)
End Function
Public Function MakeWORD(ByVal Value As Short) As String
Dim Result As String
Result = CStr(CDbl(Result) * 2)
CopyMemory(Result, Value, 2)
MakeWORD = Result
End Function
That's all the code you need to see. The code stops functioning at MakeWORD. I used Visual Basic 2005's code upgrader to convert the original MakeWORD function from VB6. Just wondering if its the Long/Short interferance or just the converter trouble or some other problem :-\
Perhaps you should use .NET's Bitconverter class instead of CopyMemory?
Also, your code says 'InsertDWORD' then you are making a WORD instead of a DWORD and I'm pretty sure dealing with a Byte Array is faster than a String in VB.NET
Please..... .NET or not, a string IS a byte array. How could it be faster?
Problem solved.
Okay, what's the problem? Just incase I get stuck with .net and I encounter this problem too....
Bah nvm, I have run into a stupid problem.
0030 ff ff 2b 92 00 00 00 00 00 00 ff 50 35 38 30 30 ..+..... ...P5800
0040 30 30 30 36 38 58 49 50 58 33 57 30 30 30 30 30 00068XIP X3W00000
0050 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00000000 00000000
0060 30 30 30 55 53 41 00 55 6e 69 74 65 64 20 53 74 000USA.U nited St
0070 61 74 65 73 00 ates.
All these 0's are making me cry. They wont go to "00" instead of "30".
EDIT:
Is this right? :
Public Function MakeDWORD(ByVal Value As Integer) As String
Dim Result() As Byte
Result = BitConverter.GetBytes(Value)
Dim i As Integer
For i = 0 To Result.GetUpperBound(Result(i))
MakeDWORD = MakeDWORD & Result(i)
Next i
End Function
EDIT: 0x30 = 48 = ascii value of the character 0.
I'm guessing it's because your treating them as strings.
Quote from: Sorc.Polgara on March 08, 2007, 10:27 PM
EDIT: 0x30 = 48 = ascii value of the character 0.
I'm guessing it's because your treating them as strings.
It's
InsertDWORD(ByVal Data as Long)How can I change these to "00" ... I don't see where I'm treating them as strings. I'm looking at all the codes on this forum and I do not see a difference.
Quote from: brew on March 08, 2007, 09:17 PM
Okay, what's the problem? Just incase I get stuck with .net and I encounter this problem too....
That's because you're wrong:
Quote from: brew on March 08, 2007, 09:04 PM
Please..... .NET or not, a string IS a byte array. How could it be faster?
In .NET, a string is NOT a byte array. A string is an array of Unicode characters, each of which is two bytes wide.
Not to mention that strings in .NET are immutable. That means once declared, they cannot be changed. When you make an assignment like this:
// C#
string abc = "abc";
abc = abc + "def";
' VB
Dim abc As String = "abc"
abc = abc & "def"
what actually happens is that a string is allocated in the CLR that says "abc". That string is, by itself, about 16 bytes (some internal state, a marker to the runtime object type, and then two bytes for length and two bytes per character - .NET strings are stored wide Pascal style). Then, on the second line, the CLR allocates a string "def" which takes the same amount of space. And then, the CLR allocates a third string variable of about 22 bytes (7 * 2 bytes for the text + length prefix and 8 bytes for internal state), and that's what the variable abc finally gets the reference to. The CLR string "abc" and the CLR string "def" are marked for garbage collection at the end of the method's execution because they no longer have outstanding referenced (unless they're used as constants elsewhere in code, in which case they're interned - for more information look up .NET String Internment).
The end result of making lots of allocations like this is that you end up with a LOT of generation 0 garbage collections, resulting in poor performance and high memory usage. On the other hand, if you use byte arrays, or one idea I'm considering is using a List<byte[]>, or EVEN BETTER is a MemoryStream since that dynamically resizes according to performance research and a logarithic formula which has been shown to be efficient (you'll notice that this is the way that JinxBot's DataBuffer (http://www.jinxbot.net/CodeBrowse/JinxBot/JinxBot.Core/Net/DataBuffer.cs.aspx) works, designed after spending lots of time in CLR Profiler).
Quote from: iNsaNe on March 08, 2007, 10:56 PM
Quote from: Sorc.Polgara on March 08, 2007, 10:27 PM
EDIT: 0x30 = 48 = ascii value of the character 0.
I'm guessing it's because your treating them as strings.
It's InsertDWORD(ByVal Data as Long)
How can I change these to "00" ... I don't see where I'm treating them as strings. I'm looking at all the codes on this forum and I do not see a difference.
Well all of the code you've been looking at on the forum has likely been VB6 code and not VB.NET.
And the common VB6 way of adding data to a buffer is by treating everything as a string.
So, your code:
Public Function InsertDWORD(ByVal Data As Long)
strSendData = strSendData & MakeWORD(Data)
End Function
Thus, someone correct me if I'm wrong, the above code is treating the WORD (2 bytes) returned by MakeWORD() as a string because it's typecasting the WORD to a string and concatenating it to variable strSendData, which I'm assuming is a String. I'm not familiar with .NET, so I could be wrong.
But yeah, stop treating the buffer (strSendData) as a string, and treat it as a byte array.
EDIT: Why the hell is InsertDWORD() calling MakeWORD()? I'm assuming that's what was causing this topic's original problem, which you fixed.
That's not my code. I changed it:
Public Function MakeDWORD(ByVal Value As Integer) As String
Dim Result() As Byte
Result = BitConverter.GetBytes(Value)
Dim i As Integer
For i = 0 To Result.GetUpperBound(Result(i))
MakeDWORD = MakeDWORD & Result(i)
Next i
End Function
And I'm not sure if it has errors or not, but I feel it is working. The only problem is is that when I go to pause, I go to check strSendData (yes its a string), and each array is set to 0. That is why there are so many 0's. I am trying to convert them so they are "." and I can't figure out how.
000068XIPX3W000000000000000000000000USA.United States.
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.
Allow me to suggest using MBNCSUtil (http://www.jinxbot.net/mbncsutil/beta/) - using the DataReader/DataBuffer or derived classes rather than the VB6 garbage. VB6 packet handling code simply does not translate to .NET.
Quote from: iNsaNe on March 08, 2007, 11:56 PM
That is why there are so many 0's. I am trying to convert them so they are "." and I can't figure out how.
You don't want the literal character ".". That's what packet capture tools use to represent values that aren't ASCII.
That's C#... it doesn't help me with Visual Basic.
Quote from: MyndFyre[vL] on March 09, 2007, 12:02 AM
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.
Quote from: MyndFyre[vL] on March 09, 2007, 12:02 AM
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.
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.
Quote from: iNsaNe on March 09, 2007, 12:17 AM
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:
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())
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.
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:
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:
Private msBuffer As New MemoryStream
Now take a look at this code:
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 (http://www.jinxbot.net/CodeBrowse/MBNCSUtil_1_3_0_6/DataBuffer.cs.aspx) 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.
Quote from: Sorc.Polgara on March 09, 2007, 12:32 AM
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.
Quote from: MyndFyre[vL] on March 09, 2007, 09:49 AM
Quote from: Sorc.Polgara on March 09, 2007, 12:32 AM
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.
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#
Or, if you still like the BASIC series, PowerBasic.
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.
Wow. I'm still having problems. It stops after everytime i use msBuffer (Private msBuffer = new MemoryStream)
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
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.
It's one class named clsPacketBuffer
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
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 (http://www.jinxbot.net/CodeBrowse/JinxBot/JinxBot.Core/Net/DataBuffer.cs.aspx), specifically the GetData() method, you'll see:
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:
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.
Quote from: MyndFyre[vL] on March 10, 2007, 02:27 AM
I'm surprised, also, that you're not generating compiler errors.
Me too.