• Welcome to Valhalla Legends Archive.
 

Need help with packet 0x51 (or something)

Started by HydraPride, June 16, 2003, 01:00 PM

Previous topic - Next topic

HydraPride

I'm attempting to connect to battle.net with a c++ program. It works so far, except for one thing: there is a packet that starts with

FF 51 70 00

which I cannot understand. When I want to send it, I have the exe data for it, but I dont know what else goes in it. I've been trying to figure this out for the longest time... and I'd really appreciate any help.

I guess my question is "how do I make a hash value PROPERLY?"


HydraPride

#2
hmm... let me be more specific:
Game: Starcraft

1) how do i get the hash value i need (i've been looking all day and none of the functions i have found seem to work >:()
2) The packet I got (0x51) starts with FF 51 70 00 -- Is THAT the client token?
3) I'm looking at http://www.valhallalegends.com/arta/bnetdocs/content.php?id=51&Sender=C (the documentation for 0x51) and are we sure that's right?
4) The reason I think that's not correct is because I looked at the packets my SC is sending when it logs on normally, and that just doesnt add up. I think it's off by one DWORD.

I would really appreciate answers. :-[ thanks.

K

FF 51 70 00 is the packet header.  0x51 is the packet ID, and 0x0070 is the length.  

HydraPride

Thus I can conclude
Packet header = client token?
I mean I believed that at first... but it still doesnt make sense. When I plug in DWORDs for everthing else, there's still an extra DWORD. would anyone know why?

Still looking for answers to the other questions (namely question 1)

Zakath

Client session is generated by YOU, the CLIENT. It's generally accepted to use GetTickCount() for the purpose of creating it.

By the way, seeing as Arta has written several rather sophisticated Bnet applications, it's a pretty safe bet that the documentation he's got up is correct. :P
Quote from: iago on February 02, 2005, 03:07 PM
Yes, you can't have everybody...contributing to the main source repository.  That would be stupid and create chaos.

Opensource projects...would be dumb.

Yoni

Or if you use BNLS, you can optionally have BNLS create the client token for you. ;)

UserLoser

Then it should be called the BNLSToken, since the source is not from the client, it's from BNLS :P

HydraPride

cool cool
And in resonse to number one on my list...? =p
thanks

Camel

Quote from: Yoni on June 16, 2003, 08:10 PM
Or if you use BNLS, you can optionally have BNLS create the client token for you. ;)
ewwww
why bother with two packets when none will do just fine or even better? (not flaming the existance of bnlstoken, more the usage of bnlstoken =P)

HydraPride

Ok i think I got this figured out -- except for one thing... what is the server token ? FF 51 70 00? FF 51? aaaaaaaah!

Yoni

Quote from: UserLoser on June 16, 2003, 08:43 PM
Then it should be called the BNLSToken, since the source is not from the client, it's from BNLS :P
That's what you're led to believe. A bot that uses BNLS to log on effectively acts as a proxy. BNLS is delighted to log on to Battle.net over and over many times per minute, but is dismayed to find that its proxies disconnect it after a few seconds.

HydraPride

Guys, if I try and base an 0x51 packet off of prolix, should it work out? Does its hash calculations work and all that?

HydraPride

Ok. And, assuming that  I get this data (I think I have it but i'm not sure of its legitimacy), how do I send it? When I try and send it, am I supposed to attempt to put it in ASCII?
I use C++.
for sending general packets, I can use
sprintf(DATA, "%c", 0x00);
to make the string read 00 as the first packet.
However, sending DWORDs is a different story. I am assuming %d in the sprintf line will not work , because that will send some group of numbers. How do I do this? Bitwise?

iago

Quote from: Zakath on June 16, 2003, 08:04 PM
Client session is generated by YOU, the CLIENT. It's generally accepted to use GetTickCount() for the purpose of creating it.

By the way, seeing as Arta has written several rather sophisticated Bnet applications, it's a pretty safe bet that the documentation he's got up is correct. :P

The "right" way is actually gettickcount() + _time().  But what do I know? :-)
.text:19016A25 230                 mov     al, byte_19033188 ; Move this byte to the bottom part of eax
.text:19016A30 230                 test    al, 1           ; Check of eax (that byte) is TRUE
.text:19016A44 230                 jnz     short loc_19016A68 ; If al wasn't 1, jump
.text:19016A46 230                 or      al, 1           ; set al to 1
.text:19016A48 230                 push    ebx             ; time_t *
.text:19016A49 234                 mov     byte_19033188, al
.text:19016A4E 234                 call    _time           ; Retrieves the current time in seconds
.text:19016A53 234                 add     esp, 4
.text:19016A56 230                 mov     esi, eax        ; Move the current time into esi
.text:19016A58 230                 call    ds:GetTickCount
.text:19016A5E 230                 add     esi, eax        ; Add the tickcount to the current time
.text:19016A60 230                 mov     TimePlusTickCount, esi
.text:19016A66 230                 jmp     short loc_19016A6E
.text:19016A68     ; ---------------------------------------------------------------------------
.text:19016A68    
.text:19016A68     loc_19016A68:                           ; CODE XREF: sub_19016810+234j
.text:19016A68 230                 mov     esi, TimePlusTickCount ; If there was already a tickcount, use it
.text:19016A6E    
.text:19016A6E     loc_19016A6E:                           ; CODE XREF: sub_19016810+256j
.text:19016A7E 234                 mov     [esp+234h+OutgoingPacket.ClientToken], esi ; Set the client token to esi (Client Token = TickCount + Time)

This'll make an interesting test for broken AV:
QuoteX5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*