InsertNTString, InsertNonNTString

[Don Cullen]

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?

[Ersan]

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

[UserLoser]

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"

[Don Cullen]

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

[brew]

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.

[Don Cullen]

Yes, it's my first bot.

[UserLoser]

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.

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

[l2k-Shadow]

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

[Barabajagal]

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

[UserLoser]

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

void isn't really a datatype

[UserLoser]

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

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

[Barabajagal]

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

[brew]

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.

[UserLoser]

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

Yes

[brew]

*sigh*
i'm probably wrong. again.