[BNET] 0x51

[Ryan Marcus]

Send data (103 bytes).
<0000003B< FF 51 67 00  47 00 00 00  35 30 32 00  34 32 35 33  .Qg.G...502.4253
<0000004B< 31 00 00 00  01 AE 8C 8E  0D 00 00 01  00 00 7A 6C  1.............zl
<0000005B< 30 00 00 00  00 10 04 F4  B3 A0 05 C3  38 78 D0 A9  0...........8x..
<0000006B< 9F 14 30 B2  3C 6E 71 7E  AD 73 74 61  72 63 72 61  ..0.<nq~.starcra
<0000007B< 66 74 2E 65  78 65 20 30  38 2F 30 37  2F 30 35 20  ft.exe 08/07/05
<0000008B< 31 34 3A 30  36 3A 34 32  20 31 30 39  33 36 33 32  14:06:42 1093632
<0000009B< 00 4C 75 78  65 72 00                               .Luxer.

Assuming the CDKey hash is correct, whats wrong here?

[MyndFyre]

What's the response?

[Hdx]

Send data (103 bytes).
<0000003B< FF 51 67 00  47 00 00 00  35 30 32 00  34 32 35 33  .Qg.G...502.4253
<0000004B< 31 00 00 00  01 AE 8C 8E  0D 00 00 01  00 00 7A 6C  1.............zl
<0000005B< 30 00 00 00  00 10 04 F4  B3 A0 05 C3  38 78 D0 A9  0...........8x..
<0000006B< 9F 14 30 B2  3C 6E 71 7E  AD 73 74 61  72 63 72 61  ..0.<nq~.starcra
<0000007B< 66 74 2E 65  78 65 20 30  38 2F 30 37  2F 30 35 20  ft.exe 08/07/05
<0000008B< 31 34 3A 30  36 3A 34 32  20 31 30 39  33 36 33 32  14:06:42 1093632
<0000009B< 00 4C 75 78  65 72 00                               .Luxer.

Assuming the CDKey hash is correct, whats wrong here?

No response, disconnected/ipbanned for invalid format.
Your adding the EXE version and EXE hash as NT string, when you should be adding them as DWORDS.
~-~(HDX)~-~

[Ryan Marcus]

Thanks HDX, I should have looked a little closer at the BnetDocs page:

(DWORD)       Client Token
(DWORD)       EXE Version
(DWORD)       EXE Hash
(DWORD)       Number of keys in this packet
(BOOLEAN)    Using Spawn (32-bit)

For Each Key:
(DWORD)       Key Length
(DWORD)       CD key's product value
(DWORD)       CD key's public value
(DWORD)       Unknown (0)
(DWORD[5])    Hashed Key Data

(STRING)     Exe Information
(STRING)     CD Key owner name

Thanks agian for pointing my simple mistake out! :)

[Ryan Marcus]

Hmm... I changed it to DWORDS, but it still gets disconnected.. Here is my code:


SendAuthCheck

Code Select Expand


  dim thepacket as new PacketBuilder
 
  '(DWORD)          Client Token
  '(DWORD)          EXE Version
  '(DWORD)          EXE Hash
  '(DWORD)          Number of keys in this packet
  '(BOOLEAN)        Using Spawn (32-bit)
  '
  'For Each Key:
  '(DWORD)          Key Length
  '(DWORD)          CD key's product value
  '(DWORD)          CD key's public value
  '(DWORD)          Unknown (0)
  '(DWORD[5])       Hashed Key Data
  '
  '(STRING)         Exe Information
  '(STRING)         CD Key owner name
 
 
  thepacket.InsertDWORD(ClientToken)
  thepacket.InsertDWORD(VersionByte)
  thepacket.InsertDWORD(VersionHash)
  thepacket.InsertDWORD("1") // Number of keys in packet.. No support for expansions.
  thepacket.InsertByte(1) // Not spawn
  thepacket.InsertString(CDKeyHash, false)
  thepacket.InsertString(EXEInfo, true) 'EXE Info
  thepacket.InsertString(CDKeyOwner, true)
 
 
  thepacket.ApplyHeaders(Globals.GetPacketIDBNET("SID_AUTH_CHECK"))
  me.Write thepacket.GetPacket


InsertDWORD:

Code Select Expand


subpacket = subpacket + MakeDWORD(data)


MakeDWORD:

Code Select Expand


  Dim tmp  as String
  Dim a  as String
  Dim B  as String
  Dim c  as String
  Dim D  as String
  DIM varMakeDWORD as String
  tmp = Right(chr(0) + chr(0) + chr(0) + chr(0) + chr(0) + chr(0) + chr(0) + chr(0) + tohex(Data), 8)
  a = Mid(tmp, 1, 2)
  B = Mid(tmp, 3, 2)
  c = Mid(tmp, 5, 2)
  D = Mid(tmp, 7, 2)
  varMakeDWORD=Chr(Val("&H" + D))
  varMakeDWORD= varMakeDWORD + Chr(Val("&H" + c))
  varMakeDWORD= varMakeDWORD + Chr(Val("&H" + B))
  varMakeDWORD= varMakeDWORD + Chr(Val("&H" + a))
  Return varMakeDWORD


ToHex:

Code Select Expand


  Dim i  as Integer
  DIM varToHex as String
  For i =  1 To Len(Data)
    varToHex= varToHex + Right("00" + hex(Asc(Mid(Data, i, 1))), 2)
  Next
  Return varToHex


I am pretty sure that all the methods except the first are correct, because DWORDs worked in 0x50..


Thanks, again, for dealing with me (I know its hard ;) ) and thanks in advance!


[edit]
Please move this thread.. Please.

[Blaze]

Can you not use api calls or something in RB?

[Ryan Marcus]

I am guessing not.. Why would it matter?

What exactly do you want me to do?

[Hdx]

  thepacket.InsertDWORD(ClientToken)
  thepacket.InsertDWORD(VersionByte)
  thepacket.InsertDWORD(VersionHash)
thepacket.InsertDWORD("1")
  thepacket.InsertByte(1) // Not spawn
  thepacket.InsertString(CDKeyHash, false)
  thepacket.InsertString(EXEInfo, true) 'EXE Info
  thepacket.InsertString(CDKeyOwner, true)

DWORDS <> STRINGS!!!!!!!!
Dammen
~-~(HDX)~-~

[Ryan Marcus]

Sorry, I am very confused.

In BnetDocs it says that should be a DWORD:

(DWORD)          Number of keys in this packet

Does that mean I should make a DWORD out of "1", &H01, chr(1), asc("1"), or somthing else? Sorry for my stupidity..

[Hdx]

It means STOP TRATING NUMBERS AS STRING
Dude, "1" <> 1
So take off the quotes, stop using them unless your inserting a string.
~-~(HDX)~-~

[Blaze]

I am guessing not.. Why would it matter?

Because rtlmovememory beats your makedword function.

[Ryan Marcus]

It means STOP TRATING NUMBERS AS STRING
Dude, "1" <> 1
So take off the quotes, stop using them unless your inserting a string.
~-~(HDX)~-~

I know "1" <> 1, one is a string in the other is an integer. But my DWORD method only takes strings, and I have no idea how I would write it to work with integers and have a different result...

After packet logging a bit, it lookes like its more like &H01 + &H00 + &H00 + &H00, so I think (although its dumb) I will just do it that way.

[edit]

Thank you very, very, very, much!

I got it to work:

Code Select Expand


Send data (103 bytes).
<0000003B< FF 51 67 00  07 00 00 00  35 30 32 00  34 32 35 33  .Qg.....502.4253
<0000004B< 01 00 00 00  01 35 24 91  0D 00 00 01  00 00 7A 6C  .....5$.......zl
<0000005B< 30 00 00 00  00 2D 52 7C  BD 98 8D 88  86 08 3B 96  0....-R|......;.
<0000006B< 42 C2 55 77  AA B1 4E 13  6D 73 74 61  72 63 72 61  B.Uw..N.mstarcra
<0000007B< 66 74 2E 65  78 65 20 30  38 2F 30 37  2F 30 35 20  ft.exe 08/07/05
<0000008B< 31 34 3A 30  36 3A 34 32  20 31 30 39  33 36 33 32  14:06:42 1093632
<0000009B< 00 4C 75 78  65 72 00                               .Luxer.


I get a response, and I am not disconnected, so I hope it worked. Thanks!

[Joe]

"&H01 + &H00 + &H00 + &H00"

0x01000000 is a big endian 0x1.

[Ryan Marcus]

Alright, here are the two packets:

Send data (103 bytes).
<0000003B< FF 51 67 00  66 00 00 00  35 30 32 00  34 32 35 33  .Qg.f...502.4253
<0000004B< 01 00 00 00  01 A9 38 91  0D 00 00 01  00 00 7A 6C  ......8.......zl
<0000005B< 30 00 00 00  00 88 91 C8  27 35 78 A7  78 56 91 D4  0.......'5x.xV..
<0000006B< BB 37 75 A4  A1 04 7F B4  E5 73 74 61  72 63 72 61  .7u......starcra
<0000007B< 66 74 2E 65  78 65 20 30  38 2F 30 37  2F 30 35 20  ft.exe 08/07/05
<0000008B< 31 34 3A 30  36 3A 34 32  20 31 30 39  33 36 33 32  14:06:42 1093632
<0000009B< 00 4C 75 78  65 72 00                               .Luxer.

Receive data (9 bytes).
>0000006B> FF 51 09 00  01 01 00 00  00                        .Q.......

As far as I can tell, this says invalid version. I don't see why it would be, because I am using RCRS for version info and JavaOp is connecting fine..

What did I do this time..

[MyndFyre]

"&H01 + &H00 + &H00 + &H00"

0x01000000 is a big endian 0x1.

WTF?  Joe, 0x01000000 is always the same number.  Endianness is not represented in 0x notation.

00 00 00 01 is a big-endian memory representation of 0x01.
01 00 00 00 is a little-endian memory representation of 0x01.

Endianness only matters in memory representation, not how you write it out in 0x notation.