When should this be sent? I keep getting Invalid version response from S=>C SID_AUTH_CHECK
I am currently sending it after I receive SID_AUTH_INFO response
whenever you want...
you can send any BNLS packet anytime.
is there an echo in here?
I posted a more detailed description of what you posted. :-*
BNCS C->S Protocol Byte: 0x01
BNCS C->S 0x50
BNCS S->C 0x50
If Client.protocol == NLS
BNLS C->S 0x0D
BNLS S->C 0x0D
End If
BNCS S->C 0x25
BNCS C->S 0x25
BNLS C->S 0x1A
BNLS S->C 0x1A
BNLS C->S 0x0C
BNLS C->S 0x51
If Client.protocol != NLS
BNLS C->S 0x0B
BNLS S->C 0x0B
BNCS C->S 0x3A
BNCS S->C 0x3A
Else
BNLS C->S 0x02
BNLS S->C 0x02
BNCS C->S 0x53
BNCS S->C 0x53
BNLS C->S 0x03
BNLS S->C 0x03
BNCS C->S 0x53
BNCS S->C 0x53
BNCS S->C 0x45
End If
If Client.UDPGames == True
BNCS C->S UDP 0x09
BNCS C->S UDP 0x09
BNCS C->S UDP 0x09
BNCS S->C UDP 0x09
BNCS S->C UDP 0x09
BNCS S->C UDP 0x09
BNCS S->C UDP 0x09
BNCS S->C UDP 0x09
BNCS S->C UDP 0x09
BNCS S->C UDP 0x09
BNCS S->C UDP 0x09
BNCS S->C UDP 0x09
BNCS C->S 0x14
End If
BNCS C->S 0x0A
BNCS C->S 0x0B
BNCS C->S 0x0CBah I'm bored, but that should be correct. (Its off the top of my head)
~-~(HDX)~-~
I assume your parsing out ur 0x1A responce correctly, but also use the exeinfo provided in 0x1A , you cant have it like "DDA-TRiCk`BoT" or watever , bnet now checks that
When does bnls send back the exe information?
(BOOL) Success*
(DWORD) Version.
(DWORD) Checksum.
(STRING) Version check stat string.
(DWORD) Cookie.
(DWORD) The latest version code for this product.
Do any of those mean exe information, I'm stumped here.
Quote from: heRo on December 04, 2006, 04:43 PM
When does bnls send back the exe information?
(BOOL) Success*
(DWORD) Version.
(DWORD) Checksum.
(STRING) Version check stat string.
(DWORD) Cookie.
(DWORD) The latest version code for this product.
Do any of those mean exe information, I'm stumped here.
well let's see, exe info is a string, and there is only one string in there. ::)
Quote from: l2k-Shadow on December 04, 2006, 04:48 PM
Quote from: heRo on December 04, 2006, 04:43 PM
When does bnls send back the exe information?
(BOOL) Success*
(DWORD) Version.
(DWORD) Checksum.
(STRING) Version check stat string.
(DWORD) Cookie.
(DWORD) The latest version code for this product.
Do any of those mean exe information, I'm stumped here.
well let's see, exe info is a string, and there is only one string in there. ::)
Actually, thats what I was going to edit my post w/, but I didn't know if I was even looking at the right packet for the info. Why don't they match bnetdocs; for example in 0x51 it says EXE Info, shouldn't it in the BNLS packet?
@School so typing fast btw.
Oh maybe it's the ULONGLONG? I just assumed that was FILETIME? does it have a different format/size? how many bytes should it be in length?
0x1A
(DWORD) Product ID.*
(DWORD) Flags.**
(DWORD) Cookie.
(ULONGLONG) Timestamp for version check archive.
(STRING) Version check archive filename.
(STRING) Checksum formula.
Heres what I'm getting from BNLS compared to hashing
D2DV
Using Hashes
version: 16780032
checksum: 522892090
exeinfo: Game.exe 07/19/06 11:54:27 2125824
Using BNLS
version: 0
checksum: -1895759861
exeinfo: í~Game.exe 08/17/05 01:11:43 2125824
Quote from: DDA-TriCk-E on December 04, 2006, 04:59 PM
Oh maybe it's the ULONGLONG? I just assumed that was FILETIME? does it have a different format/size? how many bytes should it be in length?
0x1A
(DWORD) Product ID.*
(DWORD) Flags.**
(DWORD) Cookie.
(ULONGLONG) Timestamp for version check archive.
(STRING) Version check archive filename.
(STRING) Checksum formula.
#include <iostream.h>
void main() {
cout << sizeof(unsigned long long) << "\n";
}
It's the timestamp of the MPQ file so that the client would know if the mpq was updated in case it has an outdated file in it's cache.
Quote from: l2k-Shadow on December 04, 2006, 05:04 PM
Quote from: DDA-TriCk-E on December 04, 2006, 04:59 PM
Oh maybe it's the ULONGLONG? I just assumed that was FILETIME? does it have a different format/size? how many bytes should it be in length?
0x1A
(DWORD) Product ID.*
(DWORD) Flags.**
(DWORD) Cookie.
(ULONGLONG) Timestamp for version check archive.
(STRING) Version check archive filename.
(STRING) Checksum formula.
#include <iostream.h>
void main() {
cout << sizeof(unsigned long long) << "\n";
}
It's the timestamp of the MPQ file so that the client would know if the mpq was updated in case it has an outdated file in it's cache.
Is that the same as the 'FILETIME' of the MPQ received in 0x50?
Heres what I'm getting from BNLS compared to hashing
D2DV
Using Hashes
version: 16780032
checksum: 522892090
exeinfo: Game.exe 07/19/06 11:54:27 2125824
Using BNLS
version: 0
checksum: -1895759861
exeinfo: í~Game.exe 08/17/05 01:11:43 2125824
yes it's the FILETIME, however, it looks like you're parsing the data wrong, considering you have some crap in front of the Game.exe, maybe if you pasted your parsing code for parsing 0x50 and sending/receiving 0x1A..?
Okay heres 0x50
Private Sub Recv0x50()
Dim lngRevision As Long
ClientToken = GetTickCount
With objPacket
lngRevision = .GetDWORD
ServerToken = .GetDWORD
.Skip 4
MpqFileTime = .GetULONG
MpqArchive = .GetCString
ChecksumFormula = .GetCString
If lngRevision = 2 Then useNLS = True Else useNLS = False
End With
With objPacketBNLS
.InsertDWORD CLng(IIf(lngRevision = 0, 1, lngRevision))
.SendBNLSPacket ObjectIndex, BNLS_CHOOSENLSREVISION
End With
End Sub
Heres 0x1A send
Case BNLS_CHOOSENLSREVISION '(0x0D)
With objPacketBNLS
If .GetDWORD = &H1 Then
ProductID = BNLSGetProductID(Profile(Index).Config.ProductID)
With objPacketBNLS
.InsertDWORD ProductID
.InsertDWORD &H0
.InsertDWORD ServerToken
.InsertULONG MpqFileTime
.InsertCString MpqArchive
.InsertCString ChecksumFormula
.SendBNLSPacket ObjectIndex, BNLS_VERSIONCHECKEX2
End With
AddChat ObjectIndex, GetColor(COL_SUCCESS), "BNLS: Login information authenticated!"
Else
AddChat ObjectIndex, GetColor(COL_FAILED), "BNLS: Revision number was not recognized."
End If
End With
And heres 0x1A recv
Case BNLS_VERSIONCHECKEX2
With objPacketBNLS
If .GetBYTE = &H1 Then
EXEversion = .GetDWORD
Checksum = .GetDWORD
EXEinfo = .GetCString
Debug.Print EXEversion
Debug.Print Checksum
Debug.Print EXEinfo
AddChat ObjectIndex, GetColor(COL_SUCCESS), "BNLS: Version check passed!"
If Profile(Index).Config.ProductID = "D2XP" Or Profile(Index).Config.ProductID = "W3XP" Then
.InsertDWORD &H1
.InsertBYTE &H2
.InsertDWORD &H1
.InsertDWORD ServerToken
.InsertCString Profile(Index).Config.Cdkey
.InsertCString Profile(Index).Config.CdkeyExp
.SendBNLSPacket ObjectIndex, BNLS_CDKEY_EX
Else
.InsertDWORD &H1
.InsertBYTE &H1
.InsertDWORD &H1
.InsertDWORD ServerToken
.InsertCString Profile(Index).Config.Cdkey
.SendBNLSPacket ObjectIndex, BNLS_CDKEY_EX
End If
AddChat ObjectIndex, GetColor(col_info), "BNLS: Hashing cdkeys.."
End If
End With
.InsertULONG MpqFileTime
A filetime struct has two 4-byte halves, totalling 7 bytes an a null terminator.
As for why your parsing's off:
If .GetBYTE = &H1 Then
The BOOL response is 4 bytes long (GetDWORD), not one. I have no idea why Skywing did that.
A FILETIME is not a delimited item. It is two raw four-byte halves (or a single unaligned eight-byte field); there is no null terminator.
Aside from fields with an explicit (dynamic) length or null delimited fields, all fields in the body of BNLS messages tend to be at least four bytes in length.
Whenever I send 0x51 using Version, Checksum and ExeInfo from 0x1A I get disconnected and IPbanned on the server
paste your fixed 0x1A parse + 0x51 send?
Therefore, we can conclude that you're doing it wrong. If you want more help, we need more information. Perhaps you should post the actual bytes sent? You can censor the cdkey data, but without seeing the outbound message we cannot even be sure you're sending the data in the right order.
Quote from: Skywing on December 04, 2006, 08:00 PM
A FILETIME is not a delimited item. It is two raw four-byte halves (or a single unaligned eight-byte field); there is no null terminator.
Sorry, I have no idea where I read that it was nullterm, it's 8 bytes regardless.
these posts in this topic should help you out also
http://forum.valhallalegends.com/index.php?topic=15960.210
Thanks I'll try everything you guys said, I still don't know why it's disconnecting me, everything looks correct compared to BnetDocs but I'll get back to you if I fix it...
Quote from: DDA-TriCk-E on December 04, 2006, 04:59 PM
Oh maybe it's the ULONGLONG? I just assumed that was FILETIME? does it have a different format/size? how many bytes should it be in length?
0x1A
(DWORD) Product ID.*
(DWORD) Flags.**
(DWORD) Cookie.
(ULONGLONG) Timestamp for version check archive.
(STRING) Version check archive filename.
(STRING) Checksum formula.
Heres what I'm getting from BNLS compared to hashing
D2DV
Using Hashes
version: 16780032
checksum: 522892090
exeinfo: Game.exe 07/19/06 11:54:27 2125824
Using BNLS
version: 0
checksum: -1895759861
exeinfo: í~Game.exe 08/17/05 01:11:43 2125824
Apart from (what looks like) not skipping the BNLS packet header, I dont think BNLS_VERSIONCHECKEX2 supports d2/w3 clients as of yet?
It should support those clients.
Quote from: Ringo on December 05, 2006, 08:58 AM
Apart from (what looks like) not skipping the BNLS packet header, I dont think BNLS_VERSIONCHECKEX2 supports d2/w3 clients as of yet?
I already mentioned that he was treating the boolean success as one byte instead of four. And yes it does.
Quote from: Skywing on December 05, 2006, 10:26 AM
It should support those clients.
Oh my bad, I thought D2/W2 clients couldnt use it yet :P
Quote from: Ersan on December 05, 2006, 11:12 AM
I already mentioned that he was treating the boolean success as one byte instead of four.
Ok, but dont expect an award or anything..
Quote from: Ersan on December 05, 2006, 11:12 AM
And yes it does.
Thanks.
Quote from: Ersan on December 05, 2006, 11:12 AM
Quote from: Ringo on December 05, 2006, 08:58 AM
Apart from (what looks like) not skipping the BNLS packet header, I dont think BNLS_VERSIONCHECKEX2 supports d2/w3 clients as of yet?
I already mentioned that he was treating the boolean success as one byte instead of four. And yes it does.
Yeah I have been treating it as four bytes since you pointed that out, still doesnt work.
Post a packet log + Your changed handle code.
~-~(HDX)~-~
The error had to do with BNLS_CDKEY_EX it wasn't returning the cdkey data correctly.
Quote from: DDA-TriCk-E on December 07, 2006, 10:56 PM
The error had to do with BNLS_CDKEY_EX it wasn't returning the cdkey data correctly.
you sure it wasnt you providing / misinterpreting incorrect data?
perhaps, are you supposed to send BNLS_CDKEY_EX for original clients cdkeys? because it worked fine when I only sent BNLS_CDKEY_EX for expansion clients and BNLS_CDKEY for original clients...
It's probably you sending incorrect data to hash multiple cd-keys though.
Did you read this?:
Quote
Note: When using Lord of Destruction, two CD-keys are encrypted, and they must share the same client session key. There are several ways to do this. One way is to provide both CD-keys in this packet, using the flag CDKEY_SAME_SESSION_KEY (0x01). Another way is to use BNLS_CDKEY (0x01) to encrypt the first CD-key, then use this packet with the flag CDKEY_GIVEN_SESSION_KEY (0x02) to encrypt the second CD-key with the same client session key.
Providing code/packet log could also help us determine the problem.