[Solved] [VB] C -> S 0x50 Packet causes disconnection...

[Hdx]

Hurm Someone deleted my post...
I dont feel ike writing the code again so.
Theres an API called GetTimeZoneInformation.
It gets passed a "TIME_ZONE_INFORMATION" struct, and In that struct is a "Bias" property.
After Calling the API the .Bias value will be the EXACT OPPISIT of what it truly is. So jsut subtract it from 0 to get the right info (Correct = 0 - .Bias)
I found this API using google <3
as for the error, its cuz I put the ByVal in the wrong place, it should be on the 2nd argument of CopyMemory not the 1st.
~-~(HDX)~-~

[Don Cullen]

You're not the only one-- my post in response to your post got deleted too... >.<

I don't feel like retyping everything either, so I'll just sum up what I said--

Here's the C->S 0x50 packet sub in its final form, thoughts?

Code Select Expand

Public Sub P0x50()
    AddC vbWhite, "Assembling 0x50 Protocol packet..."
    If (bnetclient = "" Or VerByte = "") Then
        AddC vbRed, "Error! Missing bnet/verbyte values!"
        AddC vbRed, "Connection aborted locally."
        BNETDiscReq = True
        Call DMBot.BNET_Close
    Else
        With PacketBuf
            .InsertDWORD &H0  'BNET Protocol ID (Currently zero.)
            .InsertDWORD CLng("&H" & Replace(StrToHex("IX86"), " ", vbNullString)) 'IX86
            .InsertDWORD CLng("&H" & Replace(StrToHex(bnetclient), " ", vbNullString)) 'SEXP
            .InsertDWORD CLng("&H" & VerByte)   'Verbyte, changes with product upgrade.
            .InsertDWORD CLng("&H" & Replace(StrToHex("USeg"), " ", vbNullString))  'Product Language
            .InsertDWORD CLng("&H" & Replace(StrToHex(IP2NBO(DMBot.BNET.LocalIP)), " ", vbNullString))  'Local IP for NAT compatibility
            .InsertDWORD GetTimeZoneBias  'Time Zone bias
            .InsertDWORD GetUserDefaultLCID()  'Locale ID
            .InsertDWORD GetUserDefaultLangID  'Language ID
            .InsertNTString GetInfo(LOCALE_SABBREVCTRYNAME) 'Abbrev. of country
            .InsertNTString GetInfo(LOCALE_SENGCOUNTRY) 'Name of country
            .SendPacket DMBot.BNET, &H50     'Send 0x50 packet
        End With
        AddC vbWhite, "0x50 SID_AUTH_INFO packet sent."
    End If
End Sub

And the code you gave for the GetTimeZoneBias() is here:

Code Select Expand

Declare Function GetTimeZoneInformation Lib "kernel32.dll" (lpTimeZoneInformation As TIME_ZONE_INFORMATION) As Long
Declare Sub GetSystemTime Lib "kernel32" (lpSystemTime As SYSTEMTIME)
Declare Function SystemTimeToFileTime Lib "kernel32" (lpSystemTime As SYSTEMTIME, lpFileTime As FILETIME) As Long
Declare Sub GetLocalTime Lib "kernel32" (lpSystemTime As SYSTEMTIME)

Private Type SYSTEMTIME
    wYear As Integer
    wMonth As Integer
    wDayOfWeek As Integer
    wDay As Integer
    wHour As Integer
    wMinute As Integer
    wSecond As Integer
    wMilliseconds As Integer
End Type

Private Type FILETIME
    dwLowDateTime As Long
    dwHighDateTime As Long
End Type

Private Type TIME_ZONE_INFORMATION
  Bias As Long
  StandardName(0 To 31) As Integer
  StandardDate As SYSTEMTIME
  StandardBias As Long
  DaylightName(0 To 31) As Integer
  DaylightDate As SYSTEMTIME
  DaylightBias As Long
End Type

Public Function GetTimeZoneBias() As Long
    Dim tziInfo As TIME_ZONE_INFORMATION
    GetTimeZoneInformation tziInfo
    GetTimeZoneBias = 0 - tziInfo.Bias
End Function

And I also mentioned in my post (the one that deleted) that AFAIK, product languages are usually stored in resource strings that can be easily viewed using a resource viewer- resource strings are usually stored in either an EXE or a DLL, usually a DLL. I remember that much from using a resource viewer to poke around in various executables and DLLs to see if they had anything interesting within. I haven't poked around in the SC executables nor DLL files, but I'll do that as soon as I download a resource viewer to see if my theory is right.

[Edit: Decided to retype everything after all. Heh.]

[MyndFyre]

@Kp- got a suggestion of a good winsocket class/library that's better than the vb winsock?

No, but then I never suggested that you should use Windows sockets at all.  The address utility functions I mentioned are present in glibc as of several years ago, and probably in the userland libraries for most other systems too.  Windows is the only system I've found that doesn't have it.

And unfortunately that library is absent on the rather large majority of user desktop systems. 

[Kp]

And unfortunately that library is absent on the rather large majority of user desktop systems. 

That would be the fault of the system's administrator for installing and/or continuing to use a known-defective system.