Deriving version byte?

[Spht]

By the way, do they ever ban you for too many old/invalid version bytes?

A more relevant inquiry would be regarding the time between connection attempts to try those version messages.

[iago]

By the way, do they ever ban you for too many old/invalid version bytes?

A more relevant inquiry would be regarding the time between connection attempts to try those version messages.

That would be a great second question.  But if they don't ban you for trying, then it wouldn't matter how much time you leave between attempts. 

[Ringo]

By the way, do they ever ban you for too many old/invalid version bytes?

A more relevant inquiry would be regarding the time between connection attempts to try those version messages.

That would be a great second question.  But if they don't ban you for trying, then it wouldn't matter how much time you leave between attempts. 

I think if you try logon up to date version files but have a out of date version byte (or vise verser), battle.net will report invalid game version.
Where as if the hash files are out of date and match the patch of the version byte used, bnet will request the client patchs.
I can only guess, battle.net keeps old versions of the binarys and inclues them into there checkrevision list's, and/unless they keep (for example) around 500 revision forumlas and results on file for each client and each of its patch's.
It would make more sence to create a new list file in an mpq or somthing, rather than re-preforming check revision on *all* binarys every min or 2.

[TheMinistered]

Sorry to bump an old thread, but felt like I should?

Allright, I highly doubt blizzard has been modifying code related to the logon for SC/BW too much.  A simple pattern search algorithm that allows for ignoring bytes, which would change from version to version, should turn up the version byte quite easily.  The trick is making a pattern long enough to be unique.

example pattern:  74xx8D55948D4DD4C7459CxxxxxxxxC74594

where xx tells the patern search algorithm to ignore 1 byte.  Examples of instructions that you would want to use would be:

inc eax
dec eax
sub eax, ecx
add ecx, edx
...
...


anything involving memory addresses, etc, should be ignored -- basically run the pattern search algorithm over the binary file and you should be able to locate the offset where it's doing something like so:

mov ecx, 0xC9 ; assuming C9 is version byte

This should provide a somewhat reliable method of obtaining the version byte.

seems like it would be easier to just packetlog sc connecting though...

note: I just read a post by iago, it seems he has discovered it's stored in the resource section and has already figured a reliable way of locating it.  gg no re ;p ?!?!

[warz]

note: I just read a post by iago, it seems he has discovered it's stored in the resource section and has already figured a reliable way of locating it.  gg no re ;p ?!?!

Sorry, again, about bumping this old thread - but, can anyone confirm this?

[UserLoser]

Just look at the call to SnpInitialize or SnpQuery (IIRC those are the names of the Battle.snp exports), I forgot exactly which one, but a structure is passed to one of them from Starcraft.exe and it contains the version byte.  Then you should easily be able to derive the version byte for any .snp game

[warz]

Interesting. Both IDA and my debugger don't acknowledge any calls to SnpBind or SnpQuery. There is no SnpInitialize exported.

[UserLoser]

Like I said, "if I remember correctly" those were the exports...

So then it is SnpBind and SnpQuery, Starcraft.exe calls them when it loads the SNP before you connect to Battle.net.

[Maddox]

you could implement a machine code pattern function to locate a specific function across version changes that lets you know uses the version code.


-- edit: looks like TheMinistered has already suggested this.

[UserLoser]

Code Select Expand


.text:00472372                 mov     dword ptr [esi], 3Ch
.text:00472378                 mov     al, byte_58E408
.text:0047237D                 test    al, al
.text:0047237F                 pop     edi
.text:00472380                 jz      short loc_472392
.text:00472382                 mov     dword ptr [esi+0Ch], 'SEXP'
.text:00472389                 mov     dword ptr [esi+4], offset aBroodWar ; "Brood War"
.text:00472390                 jmp     short loc_4723A0
.text:00472392 ; ---------------------------------------------------------------------------
.text:00472392
.text:00472392 loc_472392:                             ; CODE XREF: SetVersionInfo+20j
.text:00472392                 mov     dword ptr [esi+0Ch], 'STAR'
.text:00472399                 mov     dword ptr [esi+4], offset aStarcraft_0 ; "Starcraft"
.text:004723A0
.text:004723A0 loc_4723A0:                             ; CODE XREF: SetVersionInfo+30j
.text:004723A0                 push    ebx
.text:004723A1                 lea     eax, [ebp+var_8]
.text:004723A4                 push    eax
.text:004723A5                 lea     ebx, [ebp+var_4]
.text:004723A8                 mov     dword ptr [esi+8], offset aInternalVersio ; "internal version unknown"
.text:004723AF                 mov     dword ptr [esi+10h], 0CFh
.text:004723B6                 mov     dword ptr [esi+18h], 8
.text:004723BD                 mov     dword ptr [esi+28h], 0FFh


Most recent Starcraft.exe, enjoy.  .SNP libraries are loaded in Storm 125 IIRC, so go around there and see how to call SnpBind and SnpQuery, etc.

byte_58E408 would be IsExpansion, and the 0xCF @ 004723AF  is the version byte