[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]

  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]

subpacket = subpacket + MakeDWORD(data)

MakeDWORD:

Code: [Select]

  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]

  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]

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.

[Hdx]

Please note that BNCS/D2GS/D2RS use little-endin
~-~(HDX)~-~

[Joe]

Not SCGS, W2GS, or W3GS? Not that there is a GS for them.. but.. nevermind.

MyndFyre, I meant that.

[Eric]

Can you not use api calls or something in RB?

Win32 API on a Macintosh?

[Sidoh]

Can you not use api calls or something in RB?

Win32 API on a Macintosh?

Hahahaha.

[Blaze]

I don't know anything about RB, thats why I asked a question.  Sorry for trying to be informed, I'll never do it again.

[MyndFyre]

Can you not use api calls or something in RB?

Win32 API on a Macintosh?

WINE

[Eric]

Can you not use api calls or something in RB?

Win32 API on a Macintosh?

WINE

I don't believe Wine has been ported to Macintosh yet, and even if it was, ewwww @ making a program dependent on it.

[Newby]

Thanks for the link to wine. I don't think I would have found it without your help!

EDIT -- Do you really think those are the only distros of Linux there are? That is why there is the source download! :p

[Joe]

Thou shalt tell him, Newblare! </greek>

LoRd is right, WINE simply implements the Win32 APIs, and runs EXEs just as a Windows computer would. Hence the name, Wine is not an emulator.

[Eric]

EDIT -- Do you really think those are the only distros of Linux there are? That is why there is the source download! :p

I don't believe Wine has been ported to Macintosh yet, and even if it was, ewwww @ making a program dependent on it.

Don't let puberty control you by letting the sudden increase in hormones go to your head.  Take the time to read before you post.

[Newby]

I realized you said "I don't think", because apparently you didn't. I just thought I'd help you think.

[MyndFyre]

Maybe you could google first, LoRd.  "wine on os x" reveals a great first link:

http://darwine.opendarwin.org//

While the basic compatibility is there as Darwin is largely FreeBSD, there is the hurdle of its Mach kernel which uses the Mach-O format rather than ELF. This part has been achived with success. It means that WineLib is now working on Mac OS X, and that developers should be able to recompile their Win32 Apps using WineLib and make them work in Mac OS X.

[Eric]

Apple has decided to switch from IBM PowerPC to Intel Processor. It means that Wine will be able to work on Mac OS X/x86 as well that it does on linux, with a limited effort. You might notice that there is already some code to support Mac OS X/x86 in the Wine's source code, but it is untested.

It will apparently only run on IBM-based Macs.

[MyndFyre]

Apple has decided to switch from IBM PowerPC to Intel Processor. It means that Wine will be able to work on Mac OS X/x86 as well that it does on linux, with a limited effort. You might notice that there is already some code to support Mac OS X/x86 in the Wine's source code, but it is untested.

It will apparently only run on IBM-based Macs.

Maybe you should read the entire FAQ:

The first phase is the port of Wine to Darwin/PowerPC with X11 (XFree86).

It doesn't yet run a Win32 EXE out of the box, but it brings cross-platform code compatibility to Mac OS X with WineLib.  If you had read the FAQ, it addressed the Mac OS X switch to Intel, but it clearly indicates that Darwine is not limited to Darwin-x86.

[Joe]

Awesome. I wonder if they'll make it work on PPC Linux!