InsertNTString, InsertNonNTString

[Barabajagal]

BreW, no. DWord = 4 bytes. A DWord or Long variable uses less memory than a string. And 0 is not always false. Data is not just data. If you try to extract a 4 character string where you should extract a DWord, it's going to be backwards because of the endian difference. ASCII data uses characters 10 and 13 as enters, whereas BINARY data uses just 13. There are differences in data types, usage, etc... The sooner you learn that the types do matter, the better.

[brew]

Ofcourse types do matter, but when you're creating/parsing a Battle.net packet, it doesn't matter too much at all. This entire topic was geared towards creating a packet. And, big deal if a value is backwords. It's still a value. If you want the proper value, ofcourse you would reverse it first and so on. But like I said, data types don't matter too much. It's the way the remote computer parses it, is what really counts. And @ l2k-Shadow, Okay, what if it's a variant? How about Winsock.GetData data? Isn't that a string? Data is transfered over networks as a string. Which happens to be an array of characters, or bytes if you will. (byte is what's used in vb6, while char is the equivalent data type in C/C++ and everything else.)

[Barabajagal]

look at the rest of the inputs for getdata. DATA, LENGTH, TYPE. You can use icByteArray and it will return the data as a byte array.

[brew]

As per my previous post, a byte = char, therefore a byte array = a char array. And we all know the formal definition of a character array.

[Don Cullen]

Alright. So why is BNLS_CDKEY returning boolean? Is this for telling us whether the cdkey provided was invalid or valid? or is it for telling us whether the attempt to generate data for use with 0x51 failed?

Also, I noticed this:

(DWORD[9])

What does the number 9 mean?

Edit, quoted BNLS_CDKEY for reference:

Message ID:     0x01
Message Name:    BNLS_CDKEY
Direction:    Server -> Client (Received)

(BOOLEAN)    Result
(DWORD)       Client Token
(DWORD[9])    CD key data for SID_AUTH_CHECK

[brew]

Uhhh... I believe there is a boolean from byte position 4-8 in ALL bnls packets, to tell if the requested action was successful. As for the (DWORD[9]), that (obviously) means it's an array of 9 DWORDs. I, myself, have no idea what all 9 are for. But they're probably values such as the private value, public value, product value, etc. Looks like we need skywing for this one =[

[Hdx]

Yes, the boolean is telling you if it was able to generate the correct hashed data.
If it is false then there is no more data in the packet, your cdkey is invalid and you need to get a new one.
(DWORD[9]) Means that it is an array of 9 DWORDS
Its just like:
(DWORD) 1st hashed data part
(DWORD) 2nd hashed data part
(DWORD) 3rd hashed data part
(DWORD) 4th hashed data part
(DWORD) 5th hashed data part
(DWORD) 6th hashed data part
(DWORD) 7th hashed data part
(DWORD) 8th hashed data part
(DWORD) 9th hashed data part

~Hdx

[Don Cullen]

Okay... So I just pull all 9 DWORDs into one variable?

Or does each DWORD in that array have a specific purpose? If so, what's each DWORD purpose? Do they come in a specific sequence? If not, how do I know which DWORD is for which purpose?

[brew]

I have no clue. At all. we REALLY need skywing over here. He can possibly update BNLSprotocol.txt so it's not as vague next time as well

[Hdx]

its inthe order that you send in 0x50
and yes each dword hs a meaning which is why its needed.
anyways, if you know what you re doing you need no help from sky
~Hdx

[Don Cullen]

So... You're saying that BNLS 0x01 generates the data which would be used in generating the 0x50 packet to send to BNET? Now I'm confused. Why would Skywing do that when it's easy to make an 0x50 packet? The whole point of my trying to parse the 0x01 packet was so I could generate a 0x51 packet.

I was trying to do it like this:

BNET 0x01 C->S
BNET 0x50 C->S
BNET 0x50 S->C
BNLS 0x01 C->S
BNLS 0x01 S->C  <--- this is where i am right now
BNLS 0x1A C->S
BNLS 0x1A S->C
BNET 0x51 C->S
BNET 0x51 S->C
BNET 0x29 C->S
BNET 0x29 S->C

[Hdx]

Ya 0x51 sorry, typo.
I'm using my on-screen keyboard cuz my batteries died.
~-~(HDX)~-~

[Don Cullen]

Alright, now it makes more sense. You say it's in the same sequence as the 0x51 packet. According to BNETDocs, it says the 0x51 packet is formed like this:

Message ID:     0x51
Message Name:    SID_AUTH_CHECK
Direction:    Client -> Server (Sent)
Used By:    Starcraft, Starcraft Broodwar, Diablo II, Diablo II LOD, Warcraft III, Warcraft III: TFT

(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

So I'm assuming that the 9 DWORDs referred to in the S->C BNLS 0x10 packet would be used for this specific part:

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

And it'd be in that exact sequence, right? Correct me if I'm wrong. :-)

[edit: fixed typos]

[Hdx]

Correct.
~Hdx

[brew]

Haha, I've always treated the keyhash as a 20 byte Non NT string.