| Author | Message | Time |
|---|---|---|
| R.a.B.B.i.T | I fixed my 0x51 problems, as it turns out my code was not sending the version byte correctly (even though I thought I was). My new problem, however, is in 0x53 BNCS/0x02 BNLS: I get IPBanned upon sending it. My code for it is the following: [code]'BNLS Parser Case &H2 InsertNTString Mid(szData, 4, 32) 'I've also tried InsertNTString Mid(szData, 4) InsertNTString szUserName SendPacket BNCS, &H53[/code][code]'BNCS Parser Case &H51 Select Case GetWORD(Mid(szData, 5, 2)) Case &H0 HandleEvent 0x51Pass If varProduct = "3RAW" Or varProduct = "PX3W" Then InsertNTString szUserName InsertNTString szPassword SendPacket BNLS, &H2 Else '...[/code]I don't know what's going on. Can anyone spot a flaw in there? The username is NT if I am correct? The hash from BNLS is non-NT? I've tried all 4 combos of NT pieces, but none worked. | December 9, 2004, 10:35 PM |
| KkBlazekK | Ok, First of all 0x53 has a nonnt string, not a nt string. Second of all maybe your capping it at 32 is killing it? Your bnls 0x02 looks good. | December 9, 2004, 10:46 PM |
| R.a.B.B.i.T | The BNLSProtocol Spec says that the data for 0x53 sent in 0x02 is 8 DWORDs, hence the 32. I've also tried not capping it, but it's the same result. Using a non NT string gets me IPBanned from Battle.Net. Using an NT string merely halts logon and disconnects me. | December 9, 2004, 11:55 PM |
| The-FooL | The hash is non-NT, its not a string. Inserting it as a string is just an easy way to copy it over. | December 9, 2004, 11:57 PM |
| R.a.B.B.i.T | I know. And I've added it non NT before, but that didn't do anything. Also, I can't seem to connect to BNLS, and my JBLS is giving me "[BNLS Parse] Hash Exception: Error hashing: [CheckRevision] Files Not Found/Accessible (WAR3)Hashing.HashException", so it looks like I'll have to wait a bit. [edit] Solved the problem: my values were being edited before being sent. | December 10, 2004, 12:07 AM |
| KkBlazekK | Packet Log! | December 10, 2004, 12:15 AM |
| Zakath | 0x53 contains 8 DWORDs (the user's public key, a 256-bit number), and then the user's account (a null-terminated string). A DWORD is most definitely not a string, and should not ever be treated as such. | December 10, 2004, 12:33 AM |
| Soul Taker | I don't understand the huge amount of people that come here with problems and never look at a packet log. How do you ever hope to figure out the error in what you're sending blindly? | December 10, 2004, 5:28 AM |
| R.a.B.B.i.T | I did look at the packet logs, and then I looked more closely, which revealed my problem and I have since fixed it (hence the edit in my post saying "I fixed it"). | December 11, 2004, 3:25 AM |