Proxy to manipulate?

[SinnerG]

I was wondering, wouldn't it be possible to do a 'man in the middle' attack by putting a 'proxy' server in between your wow client and the wow server?

Idea would be that your 'bot' sits in the middle, and if for example it needs the latest 'quest' info, it can just send the raw package requesting this info.

Advantage would be that it would be very hard for Warden to detect this

Just an idea..

Edit: Got a working POC > read the latter posts

[amadmonk]

It's actually very easy to detect this, since both the packet stream and (more importantly) the Warden info are encrypted. Specifically with Warden, the keys rotate, which makes a true clientless bot nigh impossible (not completely impossible, just really, really hard).

AFAIK only one or two people have ever made this work, and it's still fairly fragile. boogeyman etc. feel free to correct me if you've actually cracked this nut for good.

Edit: just realized you weren't specifically talking about a clientless bot, but still the problems are similar.

[SinnerG]

Yeah, more like talking about reading/modifying packages on the go.

I'd say, combine a simple 'proxy' server with the code found at http://www.mmowned.com/forums/wow-me...ecryption.html and it could work (I cant do it though, lack the required C skills :/)

Or am I seeing things wrong?

[pendra]

Reading packets is easy. Modifying packets is also easy, but you never know what blizzard can detect. If the server can tell that it's getting packets that did not come from the client, they've got you.

If you want to add your own packets beyond what the client is generating, it gets a bit more complex due to the encryption effectively sequencing the packets. You would have to decrypt the messages coming out of the client and then re-encrypt them at the appropriate sequence point, and keep track of the disparity between the sequence number you're actually on and the sequence number the client thinks you're on, which will be different since you're adding packets on the outgoing side and picking out the responses on the return side.

EDIT: Warden may very well do something on the client side that would detect you doing this without also breaking the warden encryption and twiddling with that, I wouldn't know.


It would be easier and probably safer to just induce the client to ask for whatever information you need.

[SinnerG]

Well, I'll see what I can cook up :P

Btw, I know that there is C code available about encrypting / decrypting wow packets, but is there a 'paper' available online describing the protocol itself?

[kynox]

It's actually very easy to detect this, since both the packet stream and (more importantly) the Warden info are encrypted. Specifically with Warden, the keys rotate, which makes a true clientless bot nigh impossible (not completely impossible, just really, really hard).

AFAIK only one or two people have ever made this work, and it's still fairly fragile. boogeyman etc. feel free to correct me if you've actually cracked this nut for good.

Edit: just realized you weren't specifically talking about a clientless bot, but still the problems are similar.

It's actually rather easy to decrypt warden packets, providing you have the session key and can apply the RC4 on all the packets - otherwise your keys will desynchronise.

[SinnerG]

Well, an alternative use of all this would ofc be catching warden reporting bad a 'possitive' and turning it into a 'negative'

This would mean that Warden can try as hard as it wants: we could use any bot without possible detection! :P

edit: If making a regular proxy (aka not using winpcap or anything) you'll have to modify 1 package atleast : the realm ip needs to be changed to your 'own' ip

[lanman92]

What?





_

[SinnerG]

See, the protection warden offers stands or falls when it comes to sending back to result to blizz.

If we can somehow alter / prevent this, warden can detect as much as it wants : blizz wont know (ofc, thats the 'idea' )

Anyway, still dont know how to code the encryption/decryption yet but the base for unencrypted packages is almost there

RealmProxy: Client connected
Received (from wow client) 41 byte(s)
AUTH_LOGON_CHALLENGE - SINNERG trying to login
Received (from realm server) 119 byte(s)
Sending data to Session...
Received (from wow client) 75 byte(s)

What?_

edit: Btw, using old wowwow code + MaNGOS to aid me :P

edit2 : I wonder that if you fake sif you are working on MacOS, that it would ignore warden replies :P (I'd assume no though)

[Apoc]

See, the protection warden offers stands or falls when it comes to sending back to result to blizz.

If we can somehow alter / prevent this, warden can detect as much as it wants : blizz wont know (ofc, thats the 'idea' )

Anyway, still dont know how to code the encryption/decryption yet but the base for unencrypted packages is almost there





edit: Btw, using old wowwow code + MaNGOS to aid me :P

edit2 : I wonder that if you fake sif you are working on MacOS, that it would ignore warden replies :P (I'd assume no though)

Are you allergic to research, or just illiterate?

[SinnerG]

Am I missing something? Anyway, the goal (for me) is not to 'skip/modify' warden, but to read / write (perform) actions by injecting packages.

Since I yet have to figure out how to encrypt/decrypt messages, this is where I am atm:



Replaced the REALM_LIST with a reply of my own

// generate a list
using (var realms = new BinaryWriter(new MemoryStream()))
{
realms.Write((uint)0);
realms.Write((ushort)1);
/*

* pkt << uint8(i->second.icon); // realm type
pkt << uint8(lock); // if 1, then realm locked
pkt << uint8(color); // if 2, then realm is offline
pkt << i->first; // name
pkt << i->second.address; // address
pkt << float(i->second.populationLevel);
pkt << uint8(AmountOfCharacters);
pkt << uint8(i->second.timezone); // realm category
pkt << uint8(0x2C); // unk, may be realm number/id?
* */


realms.Write((byte)1);
realms.Write((byte)0);
realms.Write((byte)1);
realms.Write(Encoding.ASCII.GetBytes("WowProxia"));
realms.Write((byte)0);
realms.Write(Encoding.ASCII.GetBytes("127.0.0.1:1234"));
realms.Write((byte)0);
realms.Write((float)0);
realms.Write((byte)0);
realms.Write((byte)1);
realms.Write((byte)0x2C);

realms.Write((byte)0x10);
realms.Write((byte)0x00);
realmData = ((MemoryStream)realms.BaseStream).ToArray();
}

using (var reply = new BinaryWriter(new MemoryStream()))
{
reply.Write((byte)Opcode.REALM_LIST);
reply.Write((ushort)realmData.Count());
reply.Write(realmData);
var replyBytes =((MemoryStream) reply.BaseStream).ToArray();
WowClient.Send(replyBytes);
return null;
}

[abdula123]

It's actually rather easy to decrypt warden packets, providing you have the session key and can apply the RC4 on all the packets - otherwise your keys will desynchronise.

can you explain a bit more?

I use vanilawow sources to understand warden encryption.

now I can decrypt first packets

SMSG_WARDEN_DATA
0000: 00 e2 d5 0f 6d 73 cc ad 61 c4 35 9e 10 b9 a2 8f  |  ....ms..a.5.....
0010: 1b b9 d6 10 a9 54 4f 80 e4 fe b5 b9 ea 75 f8 0c  |  ....TO......u..
0020: 95 13 43 00 00                                   |  ..C..

CMSG_WARDEN_DATA
0000: 00                                               |  .

SMSG_WARDEN_DATA
0000: 01 f4 01 8f fd 0c 74 1f 41 b8 3d 5d b1 24 69 ac  |  ......tA.=].$i.
..........

....... alot of packets with payload .......

0000: 01 ab 00 7b e4 42 ac 3e be e8 63 41 be 53 b8 32  |  ...{.B.>..cA.S.2
......


CMSG_WARDEN_DATA
0000: 01                                               |  .

SMSG_WARDEN_DATA

0000: 05 92 40 43 be d3 13 ff 0a f5 a2 db 0b d5 03 0b  |  ..@C............
0010: 21                                               |  !

CMSG_WARDEN_DATA

0000: 04 7e 4a f4 ea 46 5f 11 25 01 76 9c f0 44 8d 8a  |  .~J..F_.%.v..D..
0010: b0 6c 73 37 09                                   |  .ls7.

i.e.:

<- MAIEV_MODULE_INFORMATION
-> MAIEV_RESPONSE_FAILED_OR_MISSING
<- MAIEV_MODULE_TRANSFER
.....
<- MAIEV_MODULE_TRANSFER
-> MAIEV_RESPONSE_SUCCESS
<- MAIEV_MODULE_SEED
-> MAIEV_RESPONSE_HASH

and after this point decryption fail, because keys changed.

how I can get or calculate a new keys?

[abdula123]

Am I missing something? Anyway, the goal (for me) is not to 'skip/modify' warden, but to read / write (perform) actions by injecting packages.

Since I yet have to figure out how to encrypt/decrypt messages, this is where I am atm:

Replaced the REALM_LIST with a reply of my own

1. read session key from wow process memory
2. calculate ARC4 keys for both direction (c->s, s->c),
3. initialize two copies of ARC4 for each direction.
4. for each direction decrypt headers with first ARC4, split stream to packets,
4. optionally, do some bad things with packets (add new, drop existing, modify)
5. re-encrypt headers of packets with second ARC4 (thanks god, they symmetrical so encryption==decryption) and send it.

so even if you add/remove packets from stream, or change its lenghts, crypto states of client/server will not "desynchronize".

[kynox]

1. read session key from wow process memory
2. calculate ARC4 keys for both direction (c->s, s->c),
3. initialize two copies of ARC4 for each direction.
4. for each direction decrypt headers with first ARC4, split stream to packets,
4. optionally, do some bad things with packets (add new, drop existing, modify)
5. re-encrypt headers of packets with second ARC4 (thanks god, they symmetrical so encryption==decryption) and send it.

so even if you add/remove packets from stream, or change its lenghts, crypto states of client/server will not "desynchronize".

I assume that "desynchronize" is pointed at me, which had you actually read my post correctly; you would notice the context of this was Warden.

If Warden processes a packet that he does not, or he sends a packet without informing Warden of this packet, the keys will desynchronise and content in the related direction will no longer be valid.

and after this point decryption fail, because keys changed.

how I can get or calculate a new keys?

They're generated again using a polymorphic function which computes new in/out keys. The function changes with each module (which are distributed daily, multiple times) - so you need to read the context from Warden itself.

[!@^^@!]

Well, an alternative use of all this would ofc be catching warden reporting bad a 'possitive' and turning it into a 'negative'

I don't think this is possible as i'd say warden is more advanced and acts as a "logger" instead of just sending that one fatal message to blizz...

ofc i may be wrong because I haven't done any research on warden.