[quote]Message ID: 0x50
Message Name: SID_AUTH_INFO 
Direction: Client -> Server (Sent)

Format:

(DWORD) Protocol ID (0)
(DWORD) Platform ID
(DWORD) Product ID
(DWORD) Version Byte
(DWORD) Product language
(DWORD) Local IP for NAT compatibility*
(DWORD) Time zone bias*
(DWORD) Locale ID*
(DWORD) Language ID*
(STRING) Country abbreviation
(STRING) Country[/quote]

HdxBmx27 and I both got curious as to if there was a way to obtain Product Language-- there was no information on that specific DWORD in the BNETDocs, so I decided to look into it. I would assume so is Hdx, but I could be wrong. In any case--

My initial assumption was that the prod lang was stored inside a resource string, which would also be stored inside starcraft.exe. Hdx agreed, due to the fact if you right click on the file, click properties, then click the version tab, then click the Language item, you'd see "United States (English)".

But after some consideration-- I decided to do some checking. I used a resource viewer to pry open the file and examine the resources, and found the string containing the info when you click the version tab:

[quote]OriginalFilename:
Starcraft.exe
InternalName:
Starcraft
FileVersion:
Version 1.13d
FileDescription:
Starcraft
ProductName:
Starcraft
ProductVersion:
Version 1.13d
CompanyName:
Blizzard Entertainment[/quote]

As you can see, no mention of language is found. I also recalled that if one used GetLocaleInfo, it'd return the abbreviation (USA), and also the full name (United States), as well as the language (English). But it cannot be that, since that's used with the last two strings in the 0x50 packet... Which leads me to reason that it's not stored inside a resource string.

Another reason is because, according to Hdx, the prod lang dword has to be USeg for the US, or GBeg for Great Britain. GetLocaleInfo doesn't, AFAIK, return anything in a such format. So my further reasoning is that to figure this out, one'd have to track it down.

What I'm dying to know is, how did people know it was supposed to be USeg or GBeg? When packet logging while SC connects, those are seen. Logic states that if someone used IDL (I think that's the program, or was it SoftIce? Gotta be SoftIce), and monitored memory while logging in-- one could set up a BP at whatever sent the Prod Lang, and use that as a reference to find out whether the string is stored inside the EXE or another file, or whether Starcraft uses a function to determine the Prod Lang. What do you guys think?

BNETDocs also states the Prod Lang is currently under investigation-- what has this investigation so far produced?

[quote]
Another reason is because, according to Hdx, the prod lang dword has to be USeg for the US, or GBeg for Great Britain. GetLocaleInfo doesn't, AFAIK, return anything in a such format. So my further reasoning is that to figure this out, one'd have to track it down.
[/quote]

Correct, it doesn't.  It uses some other Get*() call that I forgot somewhere inside Battle.snp.  It's 'enUS' anyways, IIRC.

The product language field is proprietary. It facilitates Blizzard's multi-lingual MPQ stuff. Don't know much more than that.

I think it uses the result of GetSystemDefaultLangID and based off that result it chooses which.  If only I had IDA and battle.snp, I could tell you excactly.  But I do know it's like GetProcAddress(kernel32, "GetSomethingLang"), then calls the address that returns.

That's out of my depth, but I do have IDA and battle.snp if you want them...

And as for your theory, makes perfect sense because I know that API will return the local lang-- but the only thing is-- it also identifies the country (US, GB)-- would that API return the data in that form?

[quote author=Kyro link=topic=12779.msg127885#msg127885 date=1126557414]
That's out of my depth, but I do have IDA and battle.snp if you want them...

And as for your theory, makes perfect sense because I know that API will return the local lang-- but the only thing is-- it also identifies the country (US, GB)-- would that API return the data in that form?
[/quote]

No, like I said: based on the result it chooses a language for you.  I posted the code for this a while ago actually....  The code there looks horribly wrong, but it should be easy to see where I messed up when reversing it