Obtaining VerByte from Battle.snp

[Don Cullen]

I'm trying to code it so my bot is able to automatically update to the latest verbyte, even if BNLS doesn't have the latest verbyte (ATM, it does, but I'm speaking in the future scenarios). The method would preferably not involve brute forcing to get the verbyte.

From the two threads I've read, it seems the best way to go is to obtain it from Battle.snp:

http://forum.valhallalegends.com/index.php?topic=10742.15
http://forum.valhallalegends.com/index.php?topic=10120.0

Thoughts?

[brew]

It's at offset 0x012CB4 in battle.snp (as of the newest version)
That won't really help you. The exact location of the new verbyte is subject to change (perhaps even at every recompile) so the prefered method of getting a new verbyte is by brute forcing it, if the minor version of starcraft.exe changed. Or just use bnls.

[Don Cullen]

It's at offset 0x012CB4 in battle.snp (as of the newest version)
That won't really help you. The exact location of the new verbyte is subject to change (perhaps even at every recompile) so the prefered method of getting a new verbyte is by brute forcing it, if the minor version of starcraft.exe changed. Or just use bnls.

How exactly did you locate it, Brew?

[Barabajagal]

Uh... 012CB4 of what client?

[Hdx]

That location is:
SSHR: 0x04
W2BN: 0x5e
STAR: 0x6a
JSTR: 0x74
DSHR: 0x5e
DRTL: 0x5e
So, I guess he was talking about D1. If my memory serves thats the current VerByte.
Err. nvm.. My memory failed me.
~Hdx

[brew]

Uh... 012CB4 of what client?

I said the latest version. If STAR/SEXP's not the latest version of battle.snp, i must be crazy.

[Barabajagal]

Well I don't see 0xD1 anywhere on the 0x012CB0 line.

012CB0  00 6A 00 6A 00 6A 01 56  E8 4B EC FE FF 8D 55 C0

[brew]

What's the CRC of your version? Mine's
CRC32 (PKZIP) of file: 8051C4DD
CRC16 (Standard) of file: 6DE7
I used XVI32 by the way.
EDIT **
Ah i see where I went wrong, i was reading the line's offset and not the byte's offset (poorly designed gui IMO)
it's 0x012CCD.
EDIT 2**
I checked out your address, and it seems to be still completely different. So our file versions differed after all...?

51 52 50 6A  00 8D 46 30  50 FF D7 56  8B 35 D4 A2  03 19 68 D0...

[Hdx]

8051c4dd CRC32
75784e1f3c7d2db526e1b16ba5fe9119 MD5
Are you checking SEXP's or STAR's? They are diffrent.
Humm our CRCs are the same.
Humm, nvm, 0x12ccd is indeed 0xD1
Oh, Anyone know if the verbyte changed between 1.15->1.15.1? I cant remember.
03 19 53 FF D6 6a 00 68 precedes it in both versions.
~Hdx

[devcode]

8051c4dd CRC32
75784e1f3c7d2db526e1b16ba5fe9119 MD5
Are you checking SEXP's or STAR's? They are diffrent.
Humm our CRCs are the same.
Humm, nvm, 0x12ccd is indeed 0xD1
Oh, Anyone know if the verbyte changed between 1.15->1.15.1? I cant remember.
03 19 53 FF D6 6a 00 68 precedes it in both versions.
~Hdx

It's too bad that most (*not all) people don't check the validity of someone's findings especially when it comes from someone like brew (yes you're going down baby). It's funny he sounds so confident when saying these things when they're completely wrong, so sad. What he probably did was a search for "push 0xD1" (i'm guessing) and came up with that address in battle.snp. The assembly goes something like:

...
push 0xD1
...
call Storm.401<SMemAlloc>

The parameter D1 corresponds to line number (iago's work ), now this doesnt make sense...

Went through some quick analysis, and couple of breakpoints later we have a new address: 0x472BB0 (Starcraft.exe)
If you check the disassembly, it's moving 0xD1 into a buffer (along with some other stuff) and this gets later used when sending the 0x50 packet. How to retrieve this value in future versions? Pattern matching using (C7 46 10 ?? ?? ?? ?? C7 46 18 ?? ?? ?? ?? C7 46) *should* yield the address (Checked with sc 1.14 as well). Thank you have a nice day hi.

[Warrior]

Don't get too worked up about proving Brew wrong, it's a common occurence around these parts.

In fact, we've just learned to let him live in his fantasy world. It would be too much energy otherwise correcting him on every mistake he makes.

I must commend you though, it's not everyone who will waste their time for such a marginal gain in self confidence.

[devcode]

Don't get too worked up about proving Brew wrong, it's a common occurence around these parts.

In fact, we've just learned to let him live in his fantasy world. It would be too much energy otherwise correcting him on every mistake he makes.

I must commend you though, it's not everyone who will waste their time for such a marginal gain in self confidence.

My self confidence is already extremely high that such marginal gains create minimal impact I did this cause I actually wanted to know where the verbyte was being used from, else I wouldn't bother.

[Camel]

Oh, Anyone know if the verbyte changed between 1.15->1.15.1? I cant remember.

It did not. I can't remember any exceptions to this rule for any product: verbyte increments when minor version changes.

[brew]

Oh wow, you went above and beyond to check if i'm right. Nobody really cares. The point is that you're not going to find the verbyte in a fixed place, this has been proven time and time again. And actually, I searched the hex for 68 D1 00 00 00 (push D1h) and look@that, right where I said. Uh... I dunno about you, but I think 0xD1 is a pretty odd value to be pushing out of fucking nowhere. It's probably the verbyte, give it a rest.

EDIT*
By the way, your code will break within the next few versions of starcraft. The verbyte is a dword, not a byte.

[UserLoser]

verbyte is held in executable, passed through one of battle.snp's exports