User Profile

When requesting this on non-D2 products (I've tried W2BN and DRTL) the following response is given:

SID_QUERYREALMS2 (id: 0x40, length: 12)
ff 40 0c 00 03 00 00 80 00 00 00 00                 .@..........

The first Unknown is 03 00 00 80.

Official Battle.net servers seem to ignore the timezone bias value here in favor of the explicitly set local time value, at least for the /time command.

Added information on additional version byte search patterns per this thread: https://vl.bnetdocs.org/index.php?topic=17116.msg174936#msg174936

When the official server sends this, it sends each entry in its own message with Number of entries set to 1 and Newest news timestamp set to the timestamp of the single entry that was sent in that message. Oldest news timestamp seems to be the same across all entries, but even when requesting all of the news, an entry with that timestamp is not guaranteed to also be sent.

For the "MotD" entry (timestamp = 0) the Newest news timestamp is neither 0 nor a value matching any of the other news entries that were sent. In my single sample it was newer than the newest actual news, but still a few years old. This MotD seems to be product-specific and can contain special characters. The last line seems to always be your last logon time, for example Last logon: Fri Sep 10 2:18 AM (double spaces between date and time intentional, not sure if it's do to the single-digit hour or some other reason). If no other MotD is set for a product it'll just be this line.

On the official server, news entries are sent newest-to-oldest, and the MotD is sent at the end.

I'm not sure if/when this was updated but the correct order is status and then location.

Also I do not appear to be getting sent this packet automatically from official servers anymore, even when a mutual friend changes location or status.

I'm assuming you mean 0 == failure and 1 == success?

Official clients send the Unix timestamp (seconds from epoch) for the current time. The value is probably not too important though as some bots just send an unrelated value like the ad ID+1.

Just for the record, the request ID is more like a cookie and the given values are just what the client at some point was seen using... they aren't actually required to be set that way to make the request.

Cleaned up markdown/formatting.

If you give an empty statstring value on DRTL/DSHR the server will assign you a default one LTRD 1 0 0 30 10 20 25 0 0 (replace LTRD with RHSD for DSHR). This translates to a character that is (according to StealthBot) a Level 1 Warrior with 0 dots, 30 strength, 10 magic, 20 dexterity, 25 vitality, and 0 gold.

The platform, product, and version byte values in this message (which were already sent once before this in SID_STARTVERSIONING) seem to be ignored by the server.

For D2 open character the statstring is also set in the same way as for realm characters (as commented above) but the value for the realm name (in the above as 'USEast') is instead just an empty string, so the value would be ',FarCrap'.

For both D2 open and D2 realm characters the 'username' field here is set to the character's name.

As of Starcraft version 1.15 (many many years prior to me making this comment), Blizzard removed the Sex field from user profiles and attempting to write this key will result in an IP ban.

Edit: this is based off a code comment found in StealthBot, but has not been confirmed.

Sometime in the late 2010's the official Battle.net servers updated and started using the channel field for 0x01 (first join) to indicate the base channel name, and then followed that with a language identifier and number, rather than the traditional country code.

For example the WAR3 client sent "W3" as the channel name and was put in "W3 En-1".

Also the server does not seem to care or do anything differently if you use D2 join (0x05) for non-D2 clients, and treats values not listed here (all the ones that I've tried anyways) as NoCreate join (0x00).

On PvPGN, due to an outdated interpretation of the protocol, this packet is solely responsible for determining your product. Nothing else you do leading up to the sending of this packet matters (including the version check) in that determination.

Idea: return the requested product code in the version byte field if the returned product value is 0 (failure). This way failed requests can be matched to their requested products.

Added information on the new algorithm for v3.

No comment on prior behavior but as of 2018-08-14 this is official for D2. Registered 16-character keys will be reported as in use, regardless of if the 26-character counterpart is online.

https://bnetdocs.org/news/147/battle-net-server-upgrade-14-august-2018