BNCSutil (0x29,0x3A)

LivedKrad · June 13, 2005, 10:19 PM

I didn't know if this was the appropriate place to ask questions concerning a 3rd-party library, but I'll do so anyway in hopes of getting a response.

I'm using (obviously) the BNCSutil library for local hashing. I have gotten all the way (as long of a way as it is

) to 0x29 (SID_LOGONRESPONSE). I figured that OLS is used here because I think only NLS is used for WAR3 and W3XP? Anyway, I used ready-made function doubleHashPassword, and yet the packet still will not send correctly. I've checked the other values in the packet and the length of the packet, and made sure the header was correct. I'm assuming this is this problem.

Code Select


Public Sub bldLOGON()
Debug.Print "Preparing 0x29.."
InsertDWORD clnttoken
InsertDWORD AUTHINFO.srvtoken
InsertNonNTString doubleHashPassword(uconf.pass, clnttoken, AUTHINFO.srvtoken)
InsertSTRING uconf.user
Call tmpSend(&H29, buf)
End Sub

Both the ClientToken and ServerToken values are correct as I have used them in the previous packets. Is there anything else I'm missing here? *confused*.

Hdx · June 13, 2005, 10:29 PM

Try posting a full packet log
Also what value is your client token? Why do you not set it. It dosen't have to be constant throught the eintire login. GTC() would suffice.
~-~(HDX)~-~

LivedKrad · June 13, 2005, 10:33 PM

Quote from: HdxBmx27 on June 13, 2005, 10:29 PM
Try posting a full packet log
Also what value is your client token? Why do you not set it. It dosen't have to be constant throught the eintire login. GTC() would suffice.
~-~(HDX)~-~

I know it does not have to be constant, I feel it's more clarifying and easily readable throughout the source if I use the same variable "clnttoken". (It does however start out as GTC() when I load the program).
Secondly, packet dump for 0x29:

Code Select


0000  FF 3A 2E 00 3D 5D BF 0B 20 10 D6 EE 92 70 56 A7    .:..=].. ....pV.
0010  32 61 97 BA 61 B3 96 E4 FA 47 AA 36 EE 78 2E 10    2a..a....G.6.x..
0020  78 2E 4C 69 76 65 64 4B 72 61 64 2E 78 00          x.LivedKrad.x.

(Size was total 46 bytes with packet header)

Edit: I am aware that what I am sending is 0x3A. However BnetDocs resports that they are interchangeable so long as you handle the extra response code in 0x3A.

Hdx · June 13, 2005, 10:40 PM

Everything looks fine, cept you gave me your 0x29 code not your 0x3A code (witch is the packet you sent)
I would still like a FULL packet log so I can see everything your using.
Below is the code I used when I used BNCSutil (Before I made Hdx.dll <3)

Code Select

Public Sub Send0x3A(Index As Integer, ServerTok As Long)
    With PBuffer
        ClientTok = GetTickCount
        .InsertDWORD ClientTok
        .InsertDWORD ServerTok
        .InsertNonNTString doubleHashPassword(Config(Index).Password, ClientTok, ServerTok)
        .InsertNTString Config(Index).Username
        .SendPacket Index, &H3A
    End With
End Sub

~-~(HDX)~-~

Hdx · June 13, 2005, 10:46 PM

Quote
Code Select Expand
5 Hide Hide 24 Recv 0000 FF 51 18 00 01 02 00 00 4C 69 76 65 64 4B 72 61 .Q......LivedKra 0010 64 20 2D 20 55 53 45 00 d - USE.

Theres your problem your not checking to see if your cdkey is in use, witch it is (0x201)
~-~(HDX)~-~

LivedKrad · June 13, 2005, 10:50 PM

Yes when I went back over my log I saw that too, however I rectified the problem of the key being in use.. and yet still nothing.

Updated packet dump:

Code Select


1  192.168.1.100:2146  24.24.237.251:6112  59  Send  
0000  01 FF 50 3A 00 00 00 00 00 36 38 58 49 50 58 45    ..P:.....68XIPXE
0010  53 CB 00 00 00 00 00 00 00 00 00 00 00 00 00 00    S...............
0020  00 00 00 00 00 00 00 00 00 55 53 41 00 55 6E 69    .........USA.Uni
0030  74 65 64 20 53 74 61 74 65 73 00                   ted States.

2  24.24.237.251:6112  192.168.1.100:2146  8  Recv  
0000  FF 25 08 00 1D E0 55 0D                            .%....U.

3  24.24.237.251:6112  192.168.1.100:2146  101  Recv  
0000  FF 50 65 00 00 00 00 00 28 2C A2 61 E5 DA 07 31    .Pe.....(,.a...1
0010  20 10 D6 EE CB 1D C5 01 49 58 38 36 76 65 72 30     .......IX86ver0
0020  2E 6D 70 71 00 41 3D 32 30 34 36 30 36 35 37 38    .mpq.A=204606578
0030  38 20 42 3D 32 30 38 38 35 30 34 38 34 33 20 43    8 B=2088504843 C
0040  3D 32 33 35 36 33 33 31 34 30 20 34 20 41 3D 41    =235633140 4 A=A
0050  2B 53 20 42 3D 42 5E 43 20 43 3D 43 5E 41 20 41    +S B=B^C C=C^A A
0060  3D 41 2B 42 00                                     =A+B.

4  192.168.1.100:2146  24.24.237.251:6112  110  Send  
0000  FF 51 6E 00 BE 4A CF 0B 03 02 01 01 C2 1E EC 58    .Qn..J.........X
0010  01 00 00 00 00 00 00 00 0D 00 00 00 01 00 00 00    ................
0020  4F EF 51 00 00 00 00 00 62 A6 C9 4B 7A E8 03 20    O.Q.....b..Kz.. 
0030  57 3D B7 02 FF 1F 89 3D 31 38 AA 97 73 74 61 72    W=.....=18..star
0040  63 72 61 66 74 2E 65 78 65 20 30 36 2F 31 34 2F    craft.exe 06/14/
0050  30 35 20 30 30 3A 30 34 3A 32 33 20 31 30 39 33    05 00:04:23 1093
0060  36 33 32 00 4C 69 76 65 64 4B 72 61 64 00          632.LivedKrad.

5  24.24.237.251:6112  192.168.1.100:2146  9  Recv  
0000  FF 51 09 00 00 00 00 00 00                         .Q.......

6  192.168.1.100:2146  24.24.237.251:6112  46  Send  
0000  FF 3A 2E 00 BE 4A CF 0B 20 10 D6 EE B3 33 66 D6    .:...J.. ....3f.
0010  35 CB 17 37 4C 24 AF DC 5F A7 34 52 69 6A A3 E6    5..7L$.._.4Rij..
0020  78 2E 4C 69 76 65 64 4B 72 61 64 2E 78 00          x.LivedKrad.x.

Hdx · June 13, 2005, 11:00 PM

Check how your getting the server token.
It's 28 2C A2 61 not 20 10 D6 EE
2nd DWORD not 4th, thats the 1st 1/2 of the file time.
~-~(HDX)~-~

Eric · June 13, 2005, 11:08 PM

Quote from: HdxBmx27 on June 13, 2005, 11:00 PM
Check how your getting the server token.
It's 28 2C A2 61 not 20 10 D6 EE
2nd DWORD not 4th, thats the 1st 1/2 of the file time.
~-~(HDX)~-~

If he was using an incorrect server token, he would have not passed the CD-Key check.

Hdx · June 13, 2005, 11:10 PM

Quote from: LoRd[nK] on June 13, 2005, 11:08 PM
If he was using an incorrect server token, he would have not passed the CD-Key check.

It is possible he got them mised up between the diffrent packets.

Quote3 24.24.237.251:6112 192.168.1.100:2146 101 Recv
0000 FF 50 65 00 00 00 00 00 28 2C A2 61 E5 DA 07 31 .Pe.....(,.a...1
0010 20 10 D6 EE CB 1D C5 01 49 58 38 36 76 65 72 30 .......IX86ver0

6 192.168.1.100:2146 24.24.237.251:6112 46 Send
0000 FF 3A 2E 00 BE 4A CF 0B 20 10 D6 EE B3 33 66 D6 .:...J.. ....3f.
0010 35 CB 17 37 4C 24 AF DC 5F A7 34 52 69 6A A3 E6 5..7L$.._.4Rij..
0020 78 2E 4C 69 76 65 64 4B 72 61 64 2E 78 00 x.LivedKrad.x.

~-~(HDX)~-~

Eric · June 13, 2005, 11:16 PM

QuoteIt is possible he got them mised up between the diffrent packets.

The server token remains the same during the duration of the connection.

Hdx · June 13, 2005, 11:19 PM

I know it stays constant, but there could of been a coding error witched messed it up.

Fixed on AIm:

Quote
(21:11:07) LivedKrad: Lol
(21:11:14) LivedKrad: I was parsing the location of the server token correctly
(21:11:36) LivedKrad: It's just early on in the bot, i had made a small template of the parsing function and left some nondescript variable as the server token
(21:11:53) LivedKrad: And then when i went back in to make the global server token variable and clean it up, I left the template code there.
(21:11:56) LivedKrad: (dunno why)
(21:12:15) LivedKrad: So I was parsing ahead actually 8 bytes instead of starting at the beginning of the data.

Currently listening to: *** 873. Soggy Bottom Boys - Gin and Juice
~-~(HDX)~-~