Valhalla Legends Forums Archive | Battle.net Bot Development | C>0x3A question

AuthorMessageTime
MiCrOz
When I try to send 0x3A, I just get disconnected from bnet. I tried looking on BnetDoc's to see if there was anything that could help me, but didnt find anything. This is the code im using:

[code]Public Sub Send_0x3A()
Dim dblSeed As Long, PacketData As String
dblSeed = Val("&h" & StrToHex(StrReverse(Token)))
PacketData = String(7 * 4, vbNullChar)
Result = a(PacketData, CLng(dblSeed), frmMain.Password)
PacketBuf.InsertDWORD GetTickCount()
PacketBuf.InsertDWORD CLng(Val("&h" & StrToHex(StrReverse(Token))))
PacketBuf.InsertNonNTString PacketData
PacketBuf.InsertNTString frmMain.Account
PacketBuf.SendPacket frmMain.sckBnet, &H3A
AddChat vbGrayText, "[" & Format(Time, "hh:mm:ss") & "] ", _
&HFFFFC0, "Sent 0x3A"
End Sub
[/code]

This is what goes on in bot's screen:

[16:17:16] Attempting to connect...
[16:17:16] Connected to BattleNet
[16:17:16] Sent 0x01
[16:17:16] Sent 0x50
[16:17:16] Received 0x50
[16:17:16] Sent 0x51
[16:17:16] Received 0x51
[16:17:16] Sent 0x3A
[16:17:16] Winsock Disconnected
June 25, 2003, 8:18 PM
Camel
you need to actually hash the password

[code] SendPacket &H29, _
HashPass(frmSetup.uPass, CVL(ServerHash), CVL(ServerHash), True) & _
frmSetup.uLogin & Chr(0)[/code]

[code]Public Function HashPass(ByVal password As String, Key As Long, seed As Long, prependkey As Boolean) As String
Dim hashout As String * 20
hashout = CalcHashBuf(password)
HashPass = MKL(seed) & MKL(Key)
HashPass = IIf(prependkey, HashPass, MKL(seed)) & CalcHashBuf(HashPass & hashout)
End Function[/code]

if you're using bnetauth.dll, X is equivalent to CalcHashBuf and X2 does the same thing as HashPass
June 25, 2003, 9:27 PM
DarkMinion
0x3a isn't the logon packet either...0x29
June 25, 2003, 10:49 PM
Camel
[quote author=DarkMinion link=board=17;threadid=1697;start=0#msg12944 date=1056581348]
0x3a isn't the logon packet either...0x29
[/quote]
either one is acceptable
June 25, 2003, 11:43 PM
DarkMinion
0x29!!!!!!!!!!!!!!! >:(

:D
June 26, 2003, 12:25 AM
Camel
agreed, but still...either one is acceptable
June 26, 2003, 1:01 AM
c0ol
[quote author=DarkMinion link=board=17;threadid=1697;start=0#msg12944 date=1056581348]
0x3a isn't the logon packet either...0x29
[/quote]
0x29 is the old packet, 0x3a is a newer version that supports many more error codes.
June 26, 2003, 1:33 AM
Camel
[quote author=c0ol link=board=17;threadid=1697;start=0#msg12968 date=1056591214]
0x29 is the old packet, 0x3a is a newer version that supports many more error codes.
[/quote]

really, many more?
::scratches head::
care to elaborate?
June 26, 2003, 1:37 AM
kamakazie
SID_LOGONRESPONSE2 is more convenient, that is you can determine whether or not an account actually exists. With SID_LOGONRESPONSE, when you get rejected you have to send SID_CREATEACCOUNT(2) to determine whether or not the account exists.
June 26, 2003, 5:31 AM
Camel
Ok, so that's one more. Last time I checked, one didn't qualify as 'many.'
June 26, 2003, 6:46 AM
MiCrOz
So since I'm using bnetauth.dll I can use x(stuff) for CalcHashBuf and x2(stuff) for HashPass?
June 26, 2003, 6:54 PM
Camel
[quote author=MiCrOz link=board=17;threadid=1697;start=0#msg13012 date=1056653693]
So since I'm using bnetauth.dll I can use x(stuff) for CalcHashBuf and x2(stuff) for HashPass?
[/quote]

you could do one of the following with bnetauth.dll:
- use x2 once and forget about all of the code i posted (and probably have no idea what goes on in pass hashing)
- or use x twice (x is the broken sha-1 hashing function which is called twice by x2).

if you really want to know what goes on, basicly what you need to understand is that x is a function that hashes (basicly, produces seemingly random 120 bits that uniquely [i use unique very loosely here] identifies) some string.
the FIRST_HASH of some password will always return the same thing because it uniquely identifies YOUR_PASSWORD
the SECOND_HASH will change from connection-to-connection because it is the result of a hash of (SERVER_KEY + CLIENT_KEY + FIRST_HASH).
SERVER_KEY being 32bits sent by bnet, and CLIENT_KEY being 32bits generated by the client.
your client then sends the SERVER_KEY, the CLIENT_KEY, and the SECNOD_HASH to bnet. bnet then hashes the SERVER_KEY and CLIENT_KEY you sent with its (single hashed, almost always to your FIRST_HASH) copy of BNETS_SINGLE_HASH to produce BNETS_DOUBLE_HASH. bnet then compares BNETS_DOUBLE_HASH to your SECOND_HASH. if they are the same, your password was correct.

that's the bureaucratic price you pay for security :)
June 27, 2003, 7:26 AM

Search