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:

https://davnit.net/bnet/vL/index.php?topic=10742.15
https://davnit.net/bnet/vL/index.php?topic=10120.0

Thoughts?

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.

[quote author=brew link=topic=17109.msg173873#msg173873 date=1192485916]
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.
[/quote]

How exactly did you locate it, Brew?

Uh... 012CB4 of what client?

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

[quote author=Andy link=topic=17109.msg173875#msg173875 date=1192487267]
Uh... 012CB4 of what client?
[/quote]
I said the latest version. If STAR/SEXP's not the latest version of battle.snp, i must be crazy.

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

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

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

[quote author=Hdx link=topic=17109.msg173880#msg173880 date=1192492413]
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
[/quote]

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.

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.

[quote author=Warrior link=topic=17109.msg173883#msg173883 date=1192497798]
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.
[/quote]
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.

[quote author=Hdx link=topic=17109.msg173880#msg173880 date=1192492413]
Oh, Anyone know if the verbyte changed between 1.15->1.15.1? I cant remember.
[/quote]

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

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.

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

[quote author=UserLoser link=topic=17109.msg173903#msg173903 date=1192561930]
verbyte is held in executable, passed through one of battle.snp's exports
[/quote]

[quote author=devcode link=topic=17109.msg173882#msg173882 date=1192496804]
It's too bad that most (*not all) people don't [show anything supporting] the validity of someone's findings
[/quote]

[quote author=Joe[x86] link=topic=17109.msg174883#msg174883 date=1195300292]
[quote author=UserLoser link=topic=17109.msg173903#msg173903 date=1192561930]
verbyte is held in executable, passed through one of battle.snp's exports
[/quote]

[quote author=devcode link=topic=17109.msg173882#msg173882 date=1192496804]
It's too bad that most (*not all) people don't [show anything supporting] the validity of someone's findings
[/quote]
[/quote]

?

Check SnpBind, I think that was it.  Whatever one passes over the big struct with addresses of most of the networking things

No, I've seen it. I concur. It exists.

Eh. Now that I think about it, I feel kind of stupid. Devcode, Kyro and I were all wrong. It IS stored in the executable (battle.snp didn't always change with a new patch, yet there was a verbyte change, and the verbyte is directly dependant on the executable's version). That'd make the most sense, anyways. Why do we care to have an actual algorithm for getting the verbyte, ffs, it seems like the pattern isn't going to change. I predict that starcraft's new verbyte after the patch is going to be 0xD3, then 0xD5, 0xD7, etc etc. Warcraft 3's is going to be 0x16, 0x17. DOES ANYONE SEE A PATTERN
Go ahead, waste your time finding a way to calculate the verbyte. I honestly don't care.

[quote author=brew link=topic=17109.msg174898#msg174898 date=1195398382]
Eh. Now that I think about it, I feel kind of stupid. Devcode, Kyro and I were all wrong. It IS stored in the executable.[/quote]

https://davnit.net/bnet/vL/index.php?topic=17116.0 shows the thread
http://www.bnetdocs.org/verbyte.html shows DevCode's code for getting the VerByte

Notice this specific part of the code:

[code]int main( ) {
GetVersionByte( "C:\\Program Files\\starcraft\\Starcraft.exe" );
}[/code]

Brew, if you must troll, please do not drag me nor DevCode into it.

Enough said. Thread locked, as solution has already been found, and this thread is now degenerating into pointlessness. If anyone has come up with a better and more efficent solution, or would like to discuss more on this, they're welcome to post in DevCode's VerByte thead here:

https://davnit.net/bnet/vL/index.php?topic=17116.0