Author | Message | Time |
---|---|---|
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 |