Warden anti-hack is back..

[brew]

The warden! He's back again, with avengence! We've really gotta find a way to respond to this packet. Honestly. So let's start from what we DO know.
So far, the packet's payload (37 bytes) is RC4 encrypted with the key made up of 4 DWORDs from various values in the 0x51. Errrr.... This is all we know (pretty much) right now. Isn't anyone interested in finding a way to kill the warden once and for all? Even though the inital topic about it died a while ago?

[Dale]

http://www.rootkit.com/vault/hoglund/Governor.zip

If anyone haven't used this or heard of this it monitors Wardens activity.


EDIT: That's only for WoW.

[GSX]

Uhm, I don't believe that Warden is active on USWest.

I have been logged on for several hours without any problem, but when I connect on East, I get fried.

Nevermind, it's because I haven't reconnected in over 5 days. O_o

[Dale]

Well, I recently got hooked into finding out what warden was all about. From what I've read...

Warden checks:
- Process names.
- Window titles.
- Scans a small portion of code segment.

Warden then takes the scanned strings and hashes them comparing them to the list of hashes known to correspond to programs that induce cheating.

According to something I read up on Warden does not send information, it only sends a flag.

Uhm, I don't believe that Warden is active on USWest.

I have been logged on for several hours without any problem, but when I connect on East, I get fried.

Nevermind, it's because I haven't reconnected in over 5 days. O_o

Uh, That must of changed, because I got this.

Code Select Expand


[9:56:28 PM] Last logon: Thu Aug 30  1:58 AM
[9:56:28 PM] Joined channel Op Council (flags 0x00000000)
[9:56:28 PM] Account created: June 18, 2006 at 08:04:45 PM
[9:56:28 PM] Last logon: August 30, 2007 at 01:58:53 AM
[9:56:28 PM] Last log off: July 7, 2007 at 05:21:06 AM
[9:56:28 PM] Time Logged: 10 days, 9 hours, 30 minutes, 25 seconds.
[10:08:08 PM] You are currently IPBanned on this realm/server.
[10:08:08 PM] BNET ERROR: Connection is aborted due to timeout or other failure [ 10053 ]
[10:08:08 PM] Disconnected from Battle.net.


[iCe]

you get ipbanned now if you dont reply to warden?

[Newby]

10053 = IPBan? As far as I know, the description is there for a reason... and the description is right...

[vuther.de]

He's using daemonchat, and when you get the message 10053 I just do a AddChat saying you were IP'd since that's the message you receive when you get IP'd.

[Dale]

He's using daemonchat, and when you get the message 10053 I just do a AddChat saying you were IP'd since that's the message you receive when you get IP'd.

yup

EDIT:
I don't know if this helps at all, but I'm trying.. I received this about 1 minute before being disconnected by warden

Code Select Expand


0000  00 18 f8 29 19 e9 00 18  f8 3f 4a b4 08 00 45 00   ...).... .?J...E.
0010  00 28 0a 2a 00 00 ff 06  5c 9f 3f f1 53 09 c0 a8   .(.*.... \.?.S...
0020  01 64 17 e0 0e de f1 33  94 94 00 00 00 00 50 04   .d.....3 ......P.
0030  00 00 ae 53 00 00                                  ...S..           


[brew]

According to something I read up on Warden does not send information, it only sends a flag.

Is that so..? Then that flag must be included in the single byte response that starcraft client sends to battle.net. . . All we really have to do is find the appropriate flag to send back, together with the "other" psuedo-random value within that byte. So far we've just tried to find the encryption key for the encrypted packet contents sent TO us, even if we do decrypt it how useful will this be? While reverse engineering starcraft, did anyone even attempt to see the decrypted value and/or what it does with that information upon receiving? To be completely honest, I think that the data might be static. Blizzard has been coming up with a lot of good ideas lately, that really have turned out to be completely bad ideas anyways (i.e., dx video buffer for lockdown hashing). So, maybe someone can just work out whatever process is used to get the value of that one single byte (remember, only 256 possiblites) from that decrypted packet's content? Perhaps we can find a way to completely bypass having to decrypt this. Of course, one may argue the contents of this packet are dynamic, which is more likely. You'd never know unless you do it. But who knows, maybe the flag value is OR'd with the first hi byte of an uptime value? Or something equally lame?

[MrRaza]

WHO KNOWS!

[warz]

Why so much guessing? Somebody with so much time to devote to bnet, such as brew, should spend a little bit of that time checking this stuff out in a debugger.

[rabbit]

Or get a girlfriend...

[Dale]

Or get a girlfriend...

Was that necessary?..

[vuther.de]

If brew posts in something, rabbit usually posts back in it with a smart remark.

[Dale]

If brew posts in something, rabbit usually posts back in it with a smart remark.

Oh, Still a large amount of immature people still here, huh?