Rudimentary Warden information

[PunK]

Hmm thanks for the clarification Ringo.

I haven't quite done much with encryption and I might as well start learning now since i'll probably be doing it later. And also to help contribute a little bit seeing how a lot of people rely on certain others to fix there problems.

So once your online, the values will never change until a new session is made (reconnecting)? If that's the case... then what was the point of changing warden to a static value vs. the old varying value? Was this another sad attempt to try to "prevent" bots and complicate things?

[Don Cullen]

Was this another sad attempt to try to "prevent" bots and complicate things?

It wasn't an attempt to prevent bots from connecting to Battle.net nor was it an attempt to complicate bot development. The whole point of Warden is to prevent/complicate hacking/cheating. If a bot developer finds a way to defeat Warden just so a bot can use Starcraft to connect to Battle.net, the end result is hackers can use this information to enable their hacks to work in games and not be caught by Warden not just in Starcraft, but in all other games that make use of Warden. Unlike other games, Starcraft has Warden running both in game and chat lobby. In other games, they have two separate servers; chat server, and game servers. But for Starcraft, they have a single server for both chat and game. So because of that, for other games, they run Warden on the game servers, but for Starcraft, since the server handles both chat/game, Warden runs for both.

Just wanted to point that out so people don't mistakenly assume Warden was intended to complicate botmaking.

[brew]

Can we... run the modules in a virtual environment or something?

Yes

I've never understood why that wouldn't be possible for dealing with things like checkrevision and warden. Just emulate enough of the game's memory to pass as a running client?

Problem: The addresses in the 0x02 packet, for example. They're absolute!

Answer: Perhaps if we relocated our application's image base to something other than 0x400000 so Starcraft can load at what it wants to?

Problem: What about the apis it calls? Like GetCurrentProcess, CreateToolhelp32Snapshot, Module32First, Module32Next etc?

Answer: Hook them!!

Problem: Okay, so we've somehow managed to emulate the starcraft environment to the point that the warden module would produce correct responses. How are we going to capture them now? Somehow programatically (pattern recognition?) find the subroutine that crypts the response and set a detour?

Answer: Warden might now check the integrity of itself.

Problem: NOOOOOO

So even if you somehow find a way around that last problem and possibly others, how practical would it be?

[Mystical]

Was this another sad attempt to try to "prevent" bots and complicate things?

It wasn't an attempt to prevent bots from connecting to Battle.net nor was it an attempt to complicate bot development. The whole point of Warden is to prevent/complicate hacking/cheating. If a bot developer finds a way to defeat Warden just so a bot can use Starcraft to connect to Battle.net, the end result is hackers can use this information to enable their hacks to work in games and not be caught by Warden not just in Starcraft, but in all other games that make use of Warden. Unlike other games, Starcraft has Warden running both in game and chat lobby. In other games, they have two separate servers; chat server, and game servers. But for Starcraft, they have a single server for both chat and game. So because of that, for other games, they run Warden on the game servers, but for Starcraft, since the server handles both chat/game, Warden runs for both.

Just wanted to point that out so people don't mistakenly assume Warden was intended to complicate botmaking.

You might say that, but if it was soley for hacks, then it'd be used like warden on d2 & w3 and not be active untill in game, but no! this is active from the second you login. thus meaning its a prevention for BOTH.

[Don Cullen]

You might say that, but if it was soley for hacks, then it'd be used like warden on d2 & w3 and not be active untill in game, but no! this is active from the second you login. thus meaning its a prevention for BOTH.

Read what I said earlier:

Unlike other games, Starcraft has Warden running both in game and chat lobby. In other games, they have two separate servers; chat server, and game servers. But for Starcraft, they have a single server for both chat and game. So because of that, for other games, they run Warden on the game servers, but for Starcraft, since the server handles both chat/game, Warden runs for both.

The server is using old software; it runs warden on both not because they wanted it to cover both chat and game, but because they had no choice since both game and chat were both a SINGLE server. I don't know how to explain it any more simpler than that. Warden is intended to combat game hackers/cheaters, not bots. If it was intended to combat bots, then they would have applied Warden to the chat servers of all other games, not just the game servers.

[Hdx]

You might say that, but if it was soley for hacks, then it'd be used like warden on d2 & w3 and not be active untill in game, but no! this is active from the second you login. thus meaning its a prevention for BOTH.

As many others have stated, I believe it was simply a anti-hack mechanism {as it has been used many times before} and the anti-bot aspect is simply an added bonus for them.
The main diffrence between SC in-game setup and D2/WC2 in-game setup is that D2 and WC3 game servers are controlled by Blizzard. Whereas SC is a ad-hoc style which is governed solely by the person who hosted the game.
If they decided to expand warden's 0x5E packet for D2 and WC3, then this, I would call, is a direct attack against bot users. Untill that day I still say Warden's effect on non-game bots is simply a side effect.

Anyways I've been poking it a little, as I don't know near enough about reversing to understand much. But I did get Battle.snp to load/parse it. It bitched at me for not having SC up, but hey.. its something.

[PunK]

Hmm, yeah I assumed it was an added bonus and to also prevent hacking.

Is iago's reverse engineering tutorial on his wikipedia?

[Dale]

Is iago's reverse engineering tutorial on his wikipedia?

Yes.
http://www.skullsecurity.org/wiki/index.php/Assembly

[vector]

Visual Basic 6.0.

I seriously wasn't thinking when I posted that.

I was thinking Visual Basic modules...

[Mystical]

You might say that, but if it was soley for hacks, then it'd be used like warden on d2 & w3 and not be active untill in game, but no! this is active from the second you login. thus meaning its a prevention for BOTH.

As many others have stated, I believe it was simply a anti-hack mechanism {as it has been used many times before} and the anti-bot aspect is simply an added bonus for them.

basicly what i ment, i just believe they figured why not kill 2 birds with 1 stone.

[Ringo]

Well, bnet might see bots (more so, the abuseive ones) as hacks and what not anyway.

Anyway, if what herzog said is true, and each module has a differnt method/function of calculating the responce to 0x05 (makes sence), then that would also mean, the way (or should I say, the seed) the new encryption keys are generated would also be differnt for a given module.
It would be one of the better ways of module verification.
Never the less, the requests after the 0x04/0x05, are still pretty flawed, like the orginal version of warden starcraft saw.
The only thing that's stopping us from taking advantage of that, is the way the new encryption keys are generated.
I guess you could load the module up into memory and execute it, but that sounds a little bit like blind faith
If you need to create an image of starcraft (or most of it) in memory, you might as well run a legit version of the client -- at least that way, it's going to be pretty safe.
I guess one other way of doing it, would be to load the module, parse it, seek out the needed function's and execute them to generate the responce to 0x05, and the new encryption keys, then take over from there -- but that still seems like an awfull lot of work.

[iago]

Problem: Okay, so we've somehow managed to emulate the starcraft environment to the point that the warden module would produce correct responses. How are we going to capture them now? Somehow programatically (pattern recognition?) find the subroutine that crypts the response and set a detour?

Answer: Warden might now check the integrity of itself.

The response is returned and sent by Battle.snp. If you call the Warden functions, it'll return the data to you.

[brew]

Problem: Okay, so we've somehow managed to emulate the starcraft environment to the point that the warden module would produce correct responses. How are we going to capture them now? Somehow programatically (pattern recognition?) find the subroutine that crypts the response and set a detour?

Answer: Warden might now check the integrity of itself.

The response is returned and sent by Battle.snp. If you call the Warden functions, it'll return the data to you.

I was referring to what would have to be done if you wanted warden to deal with just the base decrypted payload. All battle.snp does is send the finished product.

[PunK]

has anybody come to any new conclusions?

[brew]

has anybody come to any new conclusions?

Yes. Warden's very nature has us cornered. Picture it like this:

There's a giant dick heading for your mouth.
You say, "Oh man i'm gonna have to suck this thing!" and brace for impact,
however at the last minute it changes trajectory and stabs you in the eye.
You now have this giant penis inside of your eyesocket, impailing your skull.
It pulls out, and rams back in, over and over and over.
You end up dying a slow, painful death.


There's nothing we can do, really, besides loading the module to respond to the 0x05 challenge for us and hope it doesn't detect anything that'd screw the output.