Looking for warden modules from 1.12.1

[namreeb]

I'm looking for locally cached warden modules from 1.12.1. Anyone know where I might get these?

[Jadd]

PM TOM_RUS. I'm not sure if he deals with warden at all though.

[namreeb]

I've already asked him. He doesn't have them, although he pointed out that they might be the same as more recent versions.

[BoogieManTM]

They're not exactly the same. They were slightly more primitive back then. They employed basically the same techniques for detection (with a few methods being added over the years), but now they have better crypto systems. An encryption key scrambler post-initialization, for example. I may have some old research docs that explained them better and possibly even some modules - catch me on MSN.

[~Unknown~]

They're not exactly the same. They were slightly more primitive back then. They employed basically the same techniques for detection (with a few methods being added over the years), but now they have better crypto systems. An encryption key scrambler post-initialization, for example. I may have some old research docs that explained them better and possibly even some modules - catch me on MSN.

a wild BoogieMan appears!

[Ramono]

I havent done anything with 1.21.1 but i'm sending the sniffed 3.3.5a module to my 2.4.3 clients and it works propperly, have you tested this for 1.21.1?

[BoogieManTM]

I havent done anything with 1.21.1 but i'm sending the sniffed 3.3.5a module to my 2.4.3 clients and it works propperly, have you tested this for 1.21.1?

That is definitely an option if he has any 1.12.1 packet dumps. otherwise what's to sniff?

[namreeb]

That is definitely an option if he has any 1.12.1 packet dumps. otherwise what's to sniff?

I'm confused, why would I need a packet dump from 1.12.1? I think he's suggesting using a module from a later version of WoW and sending it to the 1.12.1 clients. This would require a packet dump of the source client when it was sent.

I havent done anything with 1.21.1 but i'm sending the sniffed 3.3.5a module to my 2.4.3 clients and it works propperly, have you tested this for 1.21.1?

I am in the process of testing that. Did you have to change anything on the server side for the client to accept the module? There is so much encryption and decryption going on that I am getting really confused. It *seems* like the only encryption going on here (edit: I mean in terms of sending the module) is with the keys the client and server both generate on their own from the K value of the initial auth handshake. Is that correct?

[BoogieManTM]

I'm confused, why would I need a packet dump from 1.12.1? I think he's suggesting using a module from a later version of WoW and sending it to the 1.12.1 clients. This would require a packet dump of the source client when it was sent.



I am in the process of testing that. Did you have to change anything on the server side for the client to accept the module? There is so much encryption and decryption going on that I am getting really confused. It *seems* like the only encryption going on here (edit: I mean in terms of sending the module) is with the keys the client and server both generate on their own from the K value of the initial auth handshake. Is that correct?

Ah, right. I don't think it's going to work that far back though. 2.x is when Warden was upgraded.

But what I was implying was that if you have a full 1.12.1 retail packet dump and you know the K value of that dump then you can reconstruct the warden module that was sent over the wire (if one was sent over the wire)

[namreeb]

My main problem at the moment is that, according to TOM_RUS's warden code, there should be five server->client "warden opcodes" available. The 1.12.1 client as I see it seems to only be aware of three. Opcode 0 to query the presence of a module, Opcode 1 to send a module, and Opcode 2 to execute a module. I assume their intended functions based on the names TOM_RUS has assigned them in his code:

    WARDEN_SMSG_MODULE_USE                      = 0,
    WARDEN_SMSG_MODULE_CACHE                    = 1,
    WARDEN_SMSG_CHEAT_CHECKS_REQUEST            = 2,

I have verified that the function of the opcode 0 and opcode 1 are consistent with the function implied by their names. However, when I look at the handler for opcode 2 (aka "WARDEN_SMSG_CHEAT_CHECKS_REQUEST"), it does not look like it is executing the module to me. This is what I have for that handler:

signed int __thiscall WardenPacket__Handle_WARDEN_SMSG_CHEAT_CHECKS_REQUEST(Warden *this, WardenPacket *packet)
{
  WardenPacket *packet2; // ebx@1
  Warden *warden; // edi@1
  signed int v5; // [sp-4h] [bp-150h]@4
  char str; // [sp+8h] [bp-144h]@3
  unsigned __int8 buff[40]; // [sp+108h] [bp-44h]@5
  int hash[7]; // [sp+130h] [bp-1Ch]@5
  int v9[5]; // [sp+190h] [bp+44h]@5
  char v10; // [sp+1A4h] [bp+58h]@5
  WardenPacket replyPacket; // [sp+1B4h] [bp+68h]@5

  packet2 = packet;
  warden = this;
  if ( WardenPacket__PeekByte(packet, &packet) && packet2->Length - packet2->BufferPosition >= packet )
  {                                             // at this point, packet now holds an int32 value of the length of an incoming string
    WardenPacket__ReadString(packet2, &str, 0xFFu);
    if ( packet2->BufferPosition <= packet2->Length )
    {
      replyPacket.BufferPosition = 0;
      replyPacket.Data = buff;
      replyPacket.Length = 37;
      HMACSHA1__Init(hash);
      HMACSHA1__HashString(hash, &str);
      HMACSHA1__Output(hash, v9);
      MD5__Init(&hash[2]);
      MD5__HashString(&hash[2], &str);
      MD5__Output(&hash[2], &v10);
      BYTE3(packet->Data) = 2;
      WardenPacket__Write8(&replyPacket, (&packet->Data + 3));
      WardenPacket__WriteBytes(v9, &replyPacket, 20u);
      WardenPacket__WriteBytes(&v10, &replyPacket, 16u);
      WardenPacket__SendResponse(warden, buff, replyPacket.BufferPosition);
      return Continue;
    }
    v5 = PacketReadOverflow;
  }
  else
  {
    v5 = PacketTooShort;
  }
  return v5;

This doesn't seem to execute any module, but rather to simply report back the HMACSHA1 and MD5 hashes of the data which is sent. That seems rather pointless to me, so I assume I am making a mistake somewhere -- but I don't see where. Also, if this function indeed does not execute the loaded module, how does that happen? Is perhaps the Warden VMT altered after a module is loaded, and I have missed that?

[TOM_RUS]

That looks very similar to what warden on MAC does.

[namreeb]

Update: The 79C0768D657977D697E10BAD956CCED1 module does appear to be working on 1.12.1.

Update 2: The reason the table of warden server->client opcodes had functions only in the 0, 1 and 2 positions is that at the point of that dump, it was only the Maiev module which was loaded. I repeated the dump after the actual warden module was loaded and found the additional handlers I expected to see. This also explains its similarity to the warden client on a Mac. According to Boogieman, it uses only the Maiev module.

[MaiN]

I'm confused, why would I need a packet dump from 1.12.1? I think he's suggesting using a module from a later version of WoW and sending it to the 1.12.1 clients. This would require a packet dump of the source client when it was sent.



I am in the process of testing that. Did you have to change anything on the server side for the client to accept the module? There is so much encryption and decryption going on that I am getting really confused. It *seems* like the only encryption going on here (edit: I mean in terms of sending the module) is with the keys the client and server both generate on their own from the K value of the initial auth handshake. Is that correct?

I seem to remember that, if you're lazy, you don't have to employ all of the encryption. Just the RC4 with the key you get at auth is required if you don't send packet 5. This also skips the key scrambling method (even if this is only in the newer Warden).