lockdown-IX86-XX.mpq update?

[Warrior]

Can someone please either split or delete the offtopic posts in this thread, it'd be much more productive to see work pertaining to fixing this issue.

[RealityRipple]

That would be nice... Also, would someone mind documenting the changes in CheckRevision? It's always nice to have a map of the territory you're going to explore, even if the map's sketchy.

[RealityRipple]

I meant a plain-english documentation of what's changed on the exterior. Everyone seems to be going after a quick solution, instead of finding a way to emulate the CheckRevision correctly for as many future changes as we can guess. An accurate emulation won't have to be changed ever again if it is truly accurate. As for an older copy of Starcraft.exe, how much older? one revision down?

[rabbit]

Maybe Battle.net will wise up and add in ChanServ like operability.

[l)ragon]

I'm trying to find the send 0x51 sub in starcraft.exe
It would be so much easier if my decompiler didn't suck

Use IDA.

[PaiD]

W2BN is now seeing the lockdown mpqs

[Maddox]

I'll look at it later.

This might be fun... haven't done any bot stuff in quite a while.

[Skywing]

I have devised a solution for logging onto bnet with the affected clients.  However, I am not going to disclose any details because I feel that battle.net is a better place without the floods/loads etc that come along with loading starcraft.  I feel that someone else may solve this issue, but I think they should use caution before releasing any information about this patch.

I agree with this sentiment, perhaps more due to that this seems to be an obvious antihack move.  I think that for the immediate future, I'll be declining to post my notes and implementations on what has changed.

In the event that I enable the new version check system on BNLS, the protocol specification has been updated with a new message (BNLS_VERSIONCHECKEX2) that removes the burden of parsing version check module filenames from the client.  This improves future compatibility with new version check mechanisms that may be deployed on Battle.net.  Third-party software implementing the BNLS protocol, especially third-party implementations of the server end of the BNLS protocol, should use this new message to support this (and other) future version check mechanisms that are deployed on Battle.net

The BNLS protocol specification has been updated to reflect this new message.  Please note that for the time being, support for this message has not been enabled on BNLS.

[Kp]

@Kp, do you really think blizzard would do that too us? I mean they have never tried before... Worst i'd expect would be an account/cdkey ban.

Probably not, but a little extra paranoia cannot hurt.

[Edit: add below text.]

Can someone please either split or delete the offtopic posts in this thread, it'd be much more productive to see work pertaining to fixing this issue.

Done.  I ended up moving some posts by regulars just to keep the threading consistent.  I did not delete any posts yet.  If anyone feels their post is in the wrong thread, PM me and I'll fix it.

[MysT_DooM]

In theory if you were to put the correct information for each file # in the memory space for which bnet checks then it would possibly work right?

[BreW]

That's only part of the equasion, don't forget that the checkrevision values can't be just strings anymore.

[Maddox]

That's only part of the equasion, don't forget that the checkrevision values can't be just strings anymore.

They're still null terminated though.

[Hdx]

The protocol itself is exactly the same.
Its just the function that has changed.
This way blizzard does not need to patch SC or any other client they want to put the new patch on.
~-~(HDX)~-~

[Zakath]

"The new patch?" I thought the whole point was that it wasn't a patch.

[Hdx]

bad word choice....
But you get what I mean.
They Fixed things without needing a full patch.
~-~(HDX)~-~