S > Clean C > dirty C

[vector]

Now, I heard it was possible to bypass warden by connecting to warden on a clean client, then forwarding the data to the dirty client, in this case StealthBot, or what bot have you. How is this done?

[iago]

I believe you're talking about using a "shim". My very first bot worked like that, but I'm not sure how useful that would be...

[rabbit]

Wasn't nbbot a shim?

[zorm]

Rabbit: Nope.

[Hdx]

Setup a server w/ a BNCS ad Sock5 end.
SC->Loalhost (Need a gateway editor)
SB->Proxy->Localhost->bnet!
When the proxy server gets 0x5e send to SC over the BNCS connection.
When SC sends the reply, send on the proxy.
Simple.
~Hdx

[Camel]

Setup a server w/ a BNCS ad Sock5 end.
SC->Loalhost (Need a gateway editor)
SB->Proxy->Localhost->bnet!
When the proxy server gets 0x5e send to SC over the BNCS connection.
When SC sends the reply, send on the proxy.
Simple.
~Hdx

I don't believe it is that simple. From what I understand, the key to decrypt warden is based on the client/server tokens (specifically, the cd key hash), and therefore you really need to hijack SC's connection using the proxy rather than redirect just warden packets to it.

Of course, I've done no research in to this, I'm just going off of what I've read about it.

[Joe]

If you integrate Hdx's piece of software into the bot itself, it becomes easy to bypass that. Client token is ridiculously easy -- you can simply use whatever one the client specifies when it connects to the proxy, and send that as your bot. As for the server token, when the bot receives SID_AUTH_INFO, then respond to the client with the server token from the true Battle.net.

Allow me to be the first to say this is a kludge and should not be a permanent solution. But kludges are good for holding things over, so this could be a good idea. :)

[Hdx]

Just to let everyone know, a proof of concept connection was implemented a while ago. And it DOES work. It's not quite as simple as I said (you have to trick SC into thinking you have the same server/client tokens as your bot, not hard as they are public vareables)
But, as joe stated, this should not be a solution its merely one way to do it. (A bad way)
~Hdx

[Camel]

x86] link=topic=10159.msg129492#msg129492 date=1189105964]
Allow me to be the first to say this is a kludge and should not be a permanent solution. But kludges are good for holding things over, so this could be a good idea. :)

It's a crutch, and I don't support it at all. When CSB came out, a whole host of people gave up on trying to come up with a good solution to the problem it solved. We're supposed to learn from history, right?

Of course, I can't make you do anything, but I hope you can at least see it the way I do.

[vector]

Setup a server w/ a BNCS ad Sock5 end.
SC->Loalhost (Need a gateway editor)
SB->Proxy->Localhost->bnet!
When the proxy server gets 0x5e send to SC over the BNCS connection.
When SC sends the reply, send on the proxy.
Simple.
~Hdx

I don't believe it is that simple. From what I understand, the key to decrypt warden is based on the client/server tokens (specifically, the cd key hash), and therefore you really need to hijack SC's connection using the proxy rather than redirect just warden packets to it.

Of course, I've done no research in to this, I'm just going off of what I've read about it.

Well, from what I know about warden, it just needs a reply from the client, and since you are forwarding e5 to the dirty client (stealthbot), there should be no problem with this. I may be wrong though.

[Camel]

You can take that approach, but you have to understand that it's not just as simple as forwarding the packets to some random SC client. You have to let your SC client pick the client key, you have tell the SC client the server key, and you have to use the same CD key that the SC client is registered to. Of course, this is assuming that what I've read about it is correct - I can not verify that information.