I'm working on moving from local hashing towards BNLS. I was coding the 0x51 local hashing to BNLS substitute, when I ran across something that confused me.

The BNLS documentation said I should use BNLS_CDKEY and BNLS_VERSIONCHECK.

So I went to BNETDocs and searched for BNLS_VERSIONCHECK. I saw that there was no packet by that exact name, but two with similar names. So I assumed that those were the new packets to use.

Those packets were:

BNLS_VERSIONCHECKEX
BNLS_VERSIONCHECKEX2

I've been looking at each packet, and only saw slight differences. So what's the difference between those two in regards for purposes?

Also, for BNLS_VERSIONCHECKEX2, you'll see this:

[quote](DWORD) Product ID.*
(DWORD) Flags.**
(DWORD) Cookie.
(ULONGLONG) Timestamp for version check archive.
(STRING) Version check archive filename.
(STRING) Checksum formula.[/quote]

What exactly is ULONGLONG?

Thanks in advance for any assistance given. :-)

unsigned 64-bit integer

Easiest way to do it is using the FILETIME struct which is two Long values. it's basically two DWords (A QWord, I think?). Just remember not to flip the high and low values.

IIRC, BNLS treats the number as an unsigned 64-bit integer, so you should handle it accordingly

[code]
Private Sub BNLS_Send_VERSIONCHECKEX2()
Dim Client As Long
    On Error GoTo Erred
    Client = GetLSClient(Config.Game, Config.BNLS.Host)
    If Client = 0 Then
        RaiseEvent ConnectionError("BNLS does not support " & GameToName(Config.Game) & ".")
        Checksum = -1
        Exit Sub
    End If
    Packet.InsertDWORD Client
    Packet.InsertDWORD &H0
    Packet.InsertDWORD &H1
    Packet.InsertDWORD MPQTime.dwLowDateTime
    Packet.InsertDWORD MPQTime.dwHighDateTime
    Packet.InsertNTString mpqName
    Packet.InsertNTString CRevRequest
    wsBNLS.SendData Packet.SendBNLSPacket(BNLS_VERSIONCHECKEX2)
Exit Sub
Erred:
    RaiseEvent CritError(Err.Description, Err.Number, Err.Source, "BNLS_Send_VERSIONCHECKEX2")
End Sub
[/code]
Works fine for me. One DWord = Unsigned 32 bit integer. Two DWords = Unsigned 64 bit integer.

Alright, but what's the difference between those two packets?

I don't think EX has lockdown support... EX2 does.

So it'd be better to use EX2 for all game clients? Or are there certain game clients that I must use EX with?

everything works with ex2. well, right now war3 doesn't work on bnls... but it does with jbls, so ya.

EX was made when BNet changed to a diffrent CRev function.
EX2 was made cuz Bnet made some MORE changes, and it pissed off Sky.
So he was like 'Screw it I'll just have everyone send me EVERYTHING they have'
Basically you are providing BNLS with everything from 0x50 S->C
So use EX2.
All CRev functions are supported by all of BNLS's packets.
Its jsut a matter of which one to use.
Just use EX2 it works for all games (save WC3 on the real BNLS)
And it *should* continue to work for all future mods Bnet makes.

~-~(HDX)~-~

Think there're any plans on implementing WAR3 BNLS for EX2?

its already implmented.
Its just the new patch for wc3 effed over bnls's opatching program.
So the following servers return invalid results:
bnls.valhallalegends.com
63.161.183.91
63.161.183.200
63.161.183.201
63.161.183.202
63.161.183.203
63.161.183.206
63.161.183.207
63.161.183.208

Whereis jbls.org and hdx.jbls.org are fine, but they dont support lockdown. So wc2/sc dont work on those servers.
~-~(HDX)~-~

To be honest, why would anyone waste their time setting up a filetime strut? The simpler the better, and I would go with the BNLS 0x09 (not sure what it's official name is) which is nothing more then what you acually NEED from bnls. My method involves sandwiching a connection to bnls and sending the 0x09 in between the S > C 0x50 and the C > S 0x51, like so:
    {
        1. Receive 0x50.
        2. Connect to BNLS.
        3. On BNLS connect, send the 0x09.
        4. On data arrival, parse the 0x09.
        5. On parse 0x09, the BNLS winsock is closed and the values of checksum, exeinfo, and exeversion are passed to Send0x51.
        6. Send0x51 is sent to Battle.net.
    }

So, in VB6 it's like:
Public Sub BNLSSend0x09()
    Dim Buf$
    Dim i As Long
    Select Case Client
        Case "STAR": i = 1
        Case "SEXP": i = 2
        Case "W2BN": i = 3
    End Select
    Buf = pbuffer.MakeDWORD(i) & pbuffer.MakeDWORD(mpqNumber) & ChecksumFormula
    frmMain.BNLSWS.SendData pbuffer.MakeWORD(Len(Buf) + 3) & Chr(&H9) & Buf
    AddChat vbYellow, "[BNLS] Sending 0x09..."
End Sub

Public Sub BNLSParse0x09(Data As String)
    EXEVersion = pbuffer.GetDWORD(Mid(Data, 8, 4))
    Checksum = pbuffer.GetDWORD(Mid(Data, 12, 4))
    EXEInfo = KillNull(Mid$(Data, 16))
    frmMain.BNLSWS.Close
    Send0x51 Checksum, EXEVersion, EXEInfo
End Sub

And another thing: The 0x09 works with all clients.

However 0x09 only supports the digit of the library name... Therefore if Battle.net patched the library to not use digits, or patched lockdown libraries but kept the same name, you would have neither the file name nor the filetime of when the file was last updated to send to BNLS, therefore BNLS would hash your request with the files that it currently has, resulting in a wrong result.

packetlog ^^

The reason 0x1a is good is that it is all the checkrevision information you need in one packet.
In theroy you could use BNLS for that packet and that one alone (Like Brew is doing with 0x09)
And I will repeat this again: [u]0x1A DOES SUPPORT ALL GAMES, IT IS THAT BNLS ITSELF (The Actuall local copy of the game) IS NOT PATCHED![/u]
Brew, how would you obtain the updated verion byte?
How would you tell BNLS to use a spacific Checkrevision function (EXA: your users are connecting to a emu server)
This is how you should be useing BNLS if you JUST want the crev data:
    {
        1. Receive 0x50.
        2. Connect to BNLS.
        3. On BNLS connect, send the 0x1a.
        4. On data arrival, parse the 0x1a
        5. On parse 0x1a, the BNLS winsock is closed and the values of checksum, exeinfo, and exeversion are passed to Send0x51, The version byte is stored in the configuration file for future use.
        6. Send0x51 is sent to Battle.net.
    }
~-~(HDX)~-~

cute....
the only thing I found different was a new verbyte. IN case there's ever an "in a blue moon" client update.

Brew, you're an idiot, seriously.  Stop promoting outdated and soon-to-be-defunct methods.

Was insulting really neccessary? Even if his methods were inefficent, was it really neccessary? Can't we just be professional here?

No, I'm afraid the internets aren't serious business.

It can be.

i always go with 0x18, and it always works.

0x1a is a waste of several extra bytes.

how would you use it if bnet changed to randomly named mpqs?
for example:
pig.mpq
dog.mpq
monkey.mpq

Anyways, i'll try to refrane from posting ater my final comment.
BNLS_VERSIONCHECKEX2 was created so that bnls would have as much information as the game does.
It was created so that Skywing could be ale to simply update BNLS and all of the bot developers would NOT need to modify there products.
Which in turn saves  lot of hassel developer wise and consumer wise.
There is a prime examle right now.
StealthBot is widly used, but there are two versions of it out.
The oly diffrence is how t grabs the mpq archive id.
It woud be much less hassel just to sa something like the following:
Bnet has made some changes to it's method to verrify yu are useing the latest version f there game, so if you are getting te error [BNET] Version CheckFailed, please be patient, we are working on it.

And the other post being:
Bnls has beenupdated to reflect recet changes, your bots should now be working.

Its allment to make life easier even if right now its a waste of a FEW bytes.
~Hdx

[quote author=Hdx link=topic=16302.msg164826#msg164826 date=1171469547]
how would you use it if bnet changed to randomly named mpqs?
for example:
pig.mpq
dog.mpq
monkey.mpq

Anyways, i'll try to refrane from posting ater my final comment.
BNLS_VERSIONCHECKEX2 was created so that bnls would have as much information as the game does.
It was created so that Skywing could be ale to simply update BNLS and all of the bot developers would NOT need to modify there products.
Which in turn saves  lot of hassel developer wise and consumer wise.
There is a prime examle right now.
StealthBot is widly used, but there are two versions of it out.
The oly diffrence is how t grabs the mpq archive id.
It woud be much less hassel just to sa something like the following:
Bnet has made some changes to it's method to verrify yu are useing the latest version f there game, so if you are getting te error [BNET] Version CheckFailed, please be patient, we are working on it.

And the other post being:
Bnls has beenupdated to reflect recet changes, your bots should now be working.

Its allment to make life easier even if right now its a waste of a FEW bytes.
~Hdx
[/quote]

Quit giving Blizzard ideas!

[quote author=[RealityRipple] link=topic=16302.msg164648#msg164648 date=1171314690]
Easiest way to do it is using the FILETIME struct which is two Long values. it's basically two DWords (A QWord, I think?). Just remember not to flip the high and low values.
[/quote]

So basically, I extract it in this exact order:

MPQLow = PktDeBuf.rDWORD
MPQHigh = PktDeBuf.rDWORD

Then when I send it to BNLS, it's done via

.InsertDWORD MPQLow
.InsertDWORD MPQHigh

This way, I'll avoid flipping it, right?

If you're using BNLS, you should actually be treating the archive FILETIME structure as an unsigned 64-bit integer instead.

Explain please. :)

[Edited to add 'please']

[quote author=Kyro link=topic=16302.msg164849#msg164849 date=1171480938]
Explain.
[/quote]

Don't copy the eight bytes from SID_AUTH_INFO into a Win32 FILETIME structure.  Just extract the eight bytes instead into an unsigned 64-bit (8-byte) integer.  This will ensure you that you will always be sending proper data to the BNLS server.

I apologize for being stupid.

That being said, how exactly would I extract them into an unsigned 64 bit integer?

[quote author=Kyro link=topic=16302.msg164853#msg164853 date=1171481299]
I apologize for being stupid.

That being said, how exactly would I extract them into an unsigned 64 bit integer?
[/quote]

Pretty much the same exact way you extracted the values into the FILETIME structure.  Just use a proper datatype

[quote author=Kyro link=topic=16302.msg164853#msg164853 date=1171481299]
I apologize for being stupid.

That being said, how exactly would I extract them into an unsigned 64 bit integer?
[/quote]

I don't think you can do that with VB, although you might be able to do it with As Currency... however, the easiest way would be to just extract the 8 bytes from the packet and send them back using a String variable type or a byte array.

This is how I'm extracting the filetime:

[code]Dim MPQFileTime As String
...
...
MPQFileTime = PktDeBuf.rFILETIME(True)[/code]

This is the rFILETIME function in the pktdebuf class:

[code]Public Function rFILETIME(Optional QWORD As Boolean = False) As String
    Dim strFT() As String, strTMP As String
    If Not QWORD Then
        strFT = Split(rNTString & Space(1), Space(1))
        If strFT(0) > 2147483647 Then strFT(0) = (strFT(0) - 4294967296#)
        If strFT(1) > 2147483647 Then strFT(1) = (strFT(1) - 4294967296#)
    Else
        ReDim strFT(0 To 1)
        strFT(1) = rDWORD
        strFT(0) = rDWORD
    End If
    rFILETIME = strFT(0) & Space(1) & strFT(1)
End Function[/code]

That's from Hdx's packet debuffer class.

So in other words, I'm extracting the filetime into a string variable. How would I then proceed to turn around and send this to BNLS?

No, a string isn't a integer.  Create a function that extracts a 64-bit integer.  That function is messyy and pointless anyways, could have just used CopyMemory to copy into the FILETIME structure

How would that be done then?

BTW, you said:

[quote author=UserLoser link=topic=16302.msg164851#msg164851 date=1171481137]
[quote author=Kyro link=topic=16302.msg164849#msg164849 date=1171480938]
Explain.
[/quote]

Don't copy the eight bytes from SID_AUTH_INFO into a Win32 FILETIME structure.  Just extract the eight bytes instead into an unsigned 64-bit (8-byte) integer.  This will ensure you that you will always be sending proper data to the BNLS server.
[/quote]

So which is it? copy into filetime structure or don't?

[quote author=Kyro link=topic=16302.msg164860#msg164860 date=1171483428]
How would that be done then?

BTW, you said:

[quote author=UserLoser link=topic=16302.msg164851#msg164851 date=1171481137]
[quote author=Kyro link=topic=16302.msg164849#msg164849 date=1171480938]
Explain.
[/quote]

Don't copy the eight bytes from SID_AUTH_INFO into a Win32 FILETIME structure.  Just extract the eight bytes instead into an unsigned 64-bit (8-byte) integer.  This will ensure you that you will always be sending proper data to the BNLS server.
[/quote]

So which is it? copy into filetime structure or don't?
[/quote]

If you're using the latest BNLS version check message, don't.  If you're doing a local version check and have to compare the FILETIME structures on the file, do.

Okay, then I won't. I'm using BNLS_VERSIONEX2.

At the highly probable risk of sounding extremely stupid, how exactly would I extract eight bytes into an unsigned 64 bit (8 byte) integer in vb?

I was going to extract 4 bytes at a time via DWORD and pop each segment into a long variable... but it seems ive been told that's an inefficent way to do it?

It's MUCH easier just to use a FILETIME struct for this when you're using a language that doesn't natively support 64 bit integers. I don't see what the problem with using it is. I've been using it since I added MPQ downloading to my bot (back when BNLib.dll still worked), and I've never had problems with it.

I actually wrote that function to jut extract the data for debug purposes mainly.
Considering I never really did anything with it.
BUT, Considering you are using VB, And VB does not natively support 64-bit integers. (The Highest it goes is 32-bit signed)
Your best bet would be to do as Ul said, Copy the data into a FileTime struct using CopyMemory()
Which would look something like the following:
[code]Dim ftData as FileTime
CopyMemory strBufferedData, ftData, 8[/code]
Something like that, It's been a while since I worked with VB.
As for giving Blizzard Ideas :P I actually send them a 4 page document emphasizing some of there shortcomings/mistakes (In my opinion) of BNCS protocol in general.
They've only taken my advice on two occasions.
~-~(HDX)~-~

It's okay, I solved the problem. I noticed that I was extracting it using the function into a string variable, so I included it in the packet with:

.InsertNonNTString MPQFileTime

So basically, your function worked fine.

No, not it didn't
my function returns it in a specificly formatted string that I sent to my BNCSFileTimeToDate() function.
~Hdx

[quote author=Hdx link=topic=16302.msg164892#msg164892 date=1171498614]
As for giving Blizzard Ideas :P I actually send them a 4 page document emphasizing some of there shortcomings/mistakes (In my opinion) of BNCS protocol in general.
They've only taken my advice on two occasions.
~-~(HDX)~-~
[/quote]

Link to it, please.

Don't have it anymore, it was like 4 years ago when i was working intently on adding full emulation to my bot.
http://www.jbls.org/Downloads/clsBuff.cls
Thats not my best work, but thats one of my 1/2 way decent buffer classes.
~-~(HDX)~-~

[quote author=UserLoser link=topic=16302.msg164842#msg164842 date=1171479590]
[quote author=Hdx link=topic=16302.msg164826#msg164826 date=1171469547]
how would you use it if bnet changed to randomly named mpqs?
for example:
pig.mpq
dog.mpq
monkey.mpq

Anyways, i'll try to refrane from posting ater my final comment.
BNLS_VERSIONCHECKEX2 was created so that bnls would have as much information as the game does.
It was created so that Skywing could be ale to simply update BNLS and all of the bot developers would NOT need to modify there products.
Which in turn saves  lot of hassel developer wise and consumer wise.
There is a prime examle right now.
StealthBot is widly used, but there are two versions of it out.
The oly diffrence is how t grabs the mpq archive id.
It woud be much less hassel just to sa something like the following:
Bnet has made some changes to it's method to verrify yu are useing the latest version f there game, so if you are getting te error [BNET] Version CheckFailed, please be patient, we are working on it.

And the other post being:
Bnls has beenupdated to reflect recet changes, your bots should now be working.

Its allment to make life easier even if right now its a waste of a FEW bytes.
~Hdx
[/quote]

Quit giving Blizzard ideas!
[/quote]

I've already expressed the dog cat monkey idea, except in more professional-esque names.

Any idea someone gives Blizzard on these forums as of now is mostly reiteration of what's already been said at the release of lockdown.