I was looking at the BNETDocs, and noticed that the strings up there aren't specified as whether they should be null terminated or not. So quick question: how does one know whether a string should be null terminated? I know I could just packet log it (and did), but I was wondering if there was a method to it?

... All "Strings" are null terminated, NonNTStrings aren't strings but DWORD's...  It was a retarded hack of a function that should never be used.

As Ersan somewhat stated, all strings in the BNCS protocol are null terminated since there's no length byte to proceed them in any message.  The whole "NonNTString" function that is commonly used in public sources was mainly put there for the lazy people who didn't want to convert 'SEXP' to a little-endian unsigned 32-bit integer so they would do InsertNonNTString "PXES"

Gotcha, Thank you both. Appreciate the quick response. :-)

Yeah.... if you ever see a dword in a packet that looks like a string without a null terminator, it probably is. Because the packets you send all turn out to be strings anyways, it REALLY, won't matter what you insert the data as, it's still data. FFS, if you wanted to you could send the entire packet as one big string. But we don't do that, because let's face it, nothing's constant. And most of the time a value such as a checksum or something else is really a long, or a dword, it's still converted to and represented as a string. So anotherwords, say you have a value like 02 00 00 00 in... a chat packet for instance. We know from research it's a dword, and it's real value is 0x00000002. But we can also represent it as a string. It would just be a Chr(2) and three null characters. It doesn't matter what data type it is when being sent/received through a winsock, because it's still data. We might parse, the 0x50 different, for instance. We extract the server token from the packet by using a mid$() function, then later converting it on our own to an acual number value... Is this your first bot ?
And @ UL, if you're making the client a string literal, then why not include the platform ID too? Having a constant client like that pared without an "68XI" just seems silly. As if you were going to leave the platform variable.

Yes, it's my first bot.

[quote author=BreW link=topic=16301.msg164642#msg164642 date=1171311625]
Yeah.... if you ever see a dword in a packet that looks like a string without a null terminator, it probably is. Because the packets you send all turn out to be strings anyways, it REALLY, won't matter what you insert the data as, it's still data. FFS, if you wanted to you could send the entire packet as one big string. But we don't do that, because let's face it, nothing's constant. And most of the time a value such as a checksum or something else is really a long, or a dword, it's still converted to and represented as a string. So anotherwords, say you have a value like 02 00 00 00 in... a chat packet for instance. We know from research it's a dword, and it's real value is 0x00000002. But we can also represent it as a string. It would just be a Chr(2) and three null characters. It doesn't matter what data type it is when being sent/received through a winsock, because it's still data. We might parse, the 0x50 different, for instance. We extract the server token from the packet by using a mid$() function, then later converting it on our own to an acual number value... Is this your first bot ?
And @ UL, if you're making the client a string literal, then why not include the platform ID too? Having a constant client like that pared without an "68XI" just seems silly. As if you were going to leave the platform variable.
[/quote]

I currently allow the user to select what platform they're using.  I made a typo in my post and put " instead of '.

"NTString" and "NonNTString" are not data types. String and void would be more appropriate representations.

There is one use for Non-NTStrings (Voids) beyond laziness: SID_REGISTRY. But it's defunct.

[quote author=l2k-Shadow link=topic=16301.msg164660#msg164660 date=1171319055]
"NTString" and "NonNTString" are not data types. String and void would be more appropriate representations.
[/quote]

void isn't really a datatype

[quote author=[RealityRipple] link=topic=16301.msg164663#msg164663 date=1171320443]
There is one use for Non-NTStrings (Voids) beyond laziness: SID_REGISTRY. But it's defunct.
[/quote]

No, there is not.  The purpse of that is because SID_REGISTRY can return a binary value, DWORD (integral) value, or a string value.

when the client sends a string value in SID_REGISTRY, does it have a null terminator?

I dont think it would have to have a null terminator, because we only add a null char after strings as a convention to seperate strings from eachother. when they are completely seperated and labeled, we don't really have a need to label where the end of this string is. same thing happens with say.... object captions in vb6.
and in general, it doesn't matter what data type it is in packets, it's just what you choose it to be. It's data after all, so you can choose what to make of it. FFS, if you wanted to, the mpq filename in the s > c 0x50 could be represented as a number. So for that reason I disagree with l2k-Shadow, because there is just really, one data type. Data itself.

[quote author=[RealityRipple] link=topic=16301.msg164675#msg164675 date=1171325068]
when the client sends a string value in SID_REGISTRY, does it have a null terminator?
[/quote]

Yes

*sigh*
i'm probably wrong. again.

[quote author=UserLoser link=topic=16301.msg164691#msg164691 date=1171336462]
[quote author=[RealityRipple] link=topic=16301.msg164675#msg164675 date=1171325068]
when the client sends a string value in SID_REGISTRY, does it have a null terminator?
[/quote]

Yes
[/quote]

You may wanna mention that on the BNetDocs page for it then... although I guess people should assume all strings are null terminated.

Its defined in BNetDocs what each data type is.
So whats the point of this?
And as for making the packet what we want.
What it REALLY is is a stream of memory.
In most languages, there are data types to make life a lot easier.
For example which is easier to understand someone saying 104 101 108 108 111, or something saying hello
Programming is ment to make your life easier, so don't make it more complicated then it is.
If you understand how memory works then you will understand how Bnet games communicate. But cause according to what I find in some of tyhe games. All it is doing when its sending the packet is Sending 0xff, sending the packet ID, (stored in a byte vareable that is constant) the length of the packet data is stored in a short, which is a word (2 bytes) in memory [in most computers]
and then its jsut starting at point x in memory and spitting out untill it reaches the end.
Its not treating it as any data type but raw data..
Humm I think I sound like a moron.
Anyways in conclusion, the data types are a convention agreed upon by anyone who actually knows what they are doing to be the most efficient/easiest way of doing things.
~Hdx

[quote author=[RealityRipple] link=topic=16301.msg164695#msg164695 date=1171337062]
[quote author=UserLoser link=topic=16301.msg164691#msg164691 date=1171336462]
[quote author=[RealityRipple] link=topic=16301.msg164675#msg164675 date=1171325068]
when the client sends a string value in SID_REGISTRY, does it have a null terminator?
[/quote]

Yes
[/quote]

You may wanna mention that on the BNetDocs page for it then... although I guess people should assume all strings are null terminated.
[/quote]

Agreed.

[quote author=[RealityRipple] link=topic=16301.msg164695#msg164695 date=1171337062]
[quote author=UserLoser link=topic=16301.msg164691#msg164691 date=1171336462]
[quote author=[RealityRipple] link=topic=16301.msg164675#msg164675 date=1171325068]
when the client sends a string value in SID_REGISTRY, does it have a null terminator?
[/quote]

Yes
[/quote]

You may wanna mention that on the BNetDocs page for it then... although I guess people should assume all strings are null terminated.
[/quote]

Why would I have to?  When using RegQueryValueEx, the string will be NULL terminated.  It's marked as void for a reason.  Void means there is no datatype, it could be anything the server requested.

O.o I forgot QueryValue had a null terminator... I always use a function i made a while ago that removes it automatically... Sorry.

[quote author=BreW link=topic=16301.msg164642#msg164642 date=1171311625]
Because the packets you send all turn out to be strings anyways
[/quote]

Nope. Byte array.

At the risk of sounding stupid, I was looking at S->C 0x01 BNLS_CDKEY packet in BNETDocs, and noticed that part of the packet was a boolean value. How exactly would I extract a boolean? Do I extract it as a WORD, or...?

It's 4 bytes.

[quote author=Joe[x86] link=topic=16301.msg164730#msg164730 date=1171405660]
[quote author=BreW link=topic=16301.msg164642#msg164642 date=1171311625]
Because the packets you send all turn out to be strings anyways
[/quote]

Nope. Byte array.
[/quote]

Wrong. You're passing a string value when you send a packet using a Winsock control.. Try it yourself (Winsock.SendData datahere)
And you don't have to end your string with a null terminator for it to be a string.

and @ HDX, I agree. But in bnetdocs, it should be a string, with a null terminator (assumed) unless specifically stated otherwise. anything else that's a "nonntstring" should really, be left alone with their true file type name (ex. DWORD, FILETIME)

[quote author=BreW link=topic=16301.msg164736#msg164736 date=1171407980]
[quote author=Joe[x86] link=topic=16301.msg164730#msg164730 date=1171405660]
[quote author=BreW link=topic=16301.msg164642#msg164642 date=1171311625]
Because the packets you send all turn out to be strings anyways
[/quote]

Nope. Byte array.
[/quote]

Wrong. You're passing a string value when you send a packet using a Winsock control.. Try it yourself (Winsock.SendData datahere)
And you don't have to end your string with a null terminator for it to be a string.
[/quote]

Winsock.SendData accepts a variant expression, not a string value. You can pass it a byte array and achieve the exact same result as passing a string. Strings are byte arrays.

And byte arrays are strings. Strings are the more common data type, but they're the same thing.

Nope.  A string is either a series of bytes with a null terminator, or a WORD with the length of the string and then the actual string data.  A byte array is an array of bytes.  Learn the difference.

http://bnetdocs.valhallalegends.com/content.php?Section=d&id=8
[quote] STRING  Null-terminated array of characters.[/quote]
On bnetdocs there is no such thing as a non nt strng
Learn to read EVERYTHING!
~Hdx

"A series of bytes"... hmm what's another word for series? ARRAY. whaddya know.

This is sad. Data is data. Stop arguing about it. It's all the same thing, it's just the way we choose to represent a certain value is what's different. O.K.?
And Kyro, try extracting a boolean value by extracting it as a 4 byte string, then using CBool(). Although it's obvious that FALSE is a 0, and anything else is a TRUE. Do whatever pleases you.

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.

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.)

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.

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.

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:

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

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

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

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?

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

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

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

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

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:

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

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

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

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

[edit: fixed typos]

Correct.
~Hdx

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

[quote author=BreW link=topic=16301.msg164781#msg164781 date=1171425424]
Haha, I've always treated the keyhash as a 20 byte Non NT string. :(
[/quote]

The definition of a newbie

lol this thread should've ended after UL's post...  You guys find any reason to argue don't you.

Thanks for the help, ya'all. Hopefully I can handle the rest...

[quote author=[RealityRipple] link=topic=16301.msg164744#msg164744 date=1171412660]
"A series of bytes"... hmm what's another word for series? ARRAY. whaddya know.
[/quote]
You're a douchebag.  There are limiting factors on what I said (IE: null terminator or WORD length).  Stop being a douchebag, you douchebag.

[quote author=UserLoser link=topic=16301.msg164787#msg164787 date=1171431624]
[quote author=BreW link=topic=16301.msg164781#msg164781 date=1171425424]
Haha, I've always treated the keyhash as a 20 byte Non NT string. :(
[/quote]

The definition of a newbie
[/quote]

So it's not newbie if I use 5 dwords instead?
And for fucks sake shut UP. this isn't an argument thread.

You're making it one.

BreW, stick a null terminator at the very end of your packet and see if you don't get disconnected for breaking protocol. A Socket is an endpoint of a byte stream. It's not a String.

It's a stream? Then why do we have packets? And by string, I am refering to an array of bytes. Or chars, for that matter. A string doesn't have to have a null terminator to be a string. A null termintaed string is just an array of bytes, which happens to end with an 0x00.

[quote author=BreW link=topic=16301.msg164834#msg164834 date=1171473448]
A string doesn't have to have a null terminator to be a string.
[/quote]It's not a string unless it has a null terminator or a specified length.  You're just wrong.  About everything.  Stop posting here.

[quote author=BreW link=topic=16301.msg164834#msg164834 date=1171473448]
It's a stream? Then why do we have packets? And by string, I am refering to an array of bytes. Or chars, for that matter. A string doesn't have to have a null terminator to be a string. A null termintaed string is just an array of bytes, which happens to end with an 0x00.
[/quote]

Do you even know what a packet is?  Why do you have them?  A packet is a stream of data that is sent and received between two connected parties in order to communicate.  A simple TCP packet consists of a 24-byte header, then the actual data (or in this case, the Battle.net packet starting with a magic value 255).

To educate your self before attempting to write any sort of application, read this article about different types of strings, and this article about the transmission control protocol.

[quote author=UserLoser link=topic=16301.msg164846#msg164846 date=1171480343]
(or in this case, the Battle.net packet starting with a magic value 255).
[/quote]
The magic value is -1!  :P
[color=black]Let's see how many people miss that joke.  I'm well aware that a byte of -1 and 255 are identical.[/color]

[quote author=BreW link=topic=16301.msg164834#msg164834 date=1171473448]
It's a stream? Then why do we have packets? And by string, I am refering to an array of bytes. Or chars, for that matter. A string doesn't have to have a null terminator to be a string. A null termintaed string is just an array of bytes, which happens to end with an 0x00.
[/quote]
A string is a logical concept that extends a basic array of bytes or characters and associates special meaning to it.  Specifically, it associates that the bytes or characters are related in a meaningful way.

A TCP/IP connection represents a read/write stream to a destination endpoint.  A packet is a data-link layer component of networking that encapsulates information about data being sent.  If you were to use raw sockets, for instance, you wouldn't actually use a packet.  Of course, data that you put on the network would be virtually meaningless.

We have packets to make our data manageable and meaningful, but the fact that packets exist is something programmers should rarely be conscious of.  JinxBot's WoW plugin interfaces with the socket as a stream, not in terms of packets, reading just enough data to know how much more to read (equivalent to reading the packet header).  The BNCS plugin for JinxBot, and the BNLS extensions of MBNCSUtil v2.0 also treat sockets in this way.

[quote author=MyndFyre[vL] link=topic=16301.msg164861#msg164861 date=1171483473]
[quote author=UserLoser link=topic=16301.msg164846#msg164846 date=1171480343]
(or in this case, the Battle.net packet starting with a magic value 255).
[/quote]
The magic value is -1!  :P
[/quote]

Prove it :P

Someone should see how it's handled in Battle.snp (their Socket functions are in there, right?). If it's declared as a unsigned byte, then it's 255, but if it's a signed byte then it's -1. At least, I think so.

But yeah BreW, you know to stop arguing when both rabbit and UserLoser say that I'm right. :P

[quote author=Joe[x86] link=topic=16301.msg164940#msg164940 date=1171583309]
But yeah BreW, you know to stop arguing when both rabbit and UserLoser say that I'm right. :P
[/quote]Hey, we (at least I) never went that far, I only said he was wrong :P