I'm looking for locally cached warden modules from 1.12.1. Anyone know where I might get these?
I'm looking for locally cached warden modules from 1.12.1. Anyone know where I might get these?
PM TOM_RUS. I'm not sure if he deals with warden at all though.
I've already asked him. He doesn't have them, although he pointed out that they might be the same as more recent versions.
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.
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?
Last edited by Ramono; 05-01-2012 at 09:05 AM.
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?
Last edited by namreeb; 05-01-2012 at 04:19 PM.
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)
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:
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:Code:WARDEN_SMSG_MODULE_USE = 0, WARDEN_SMSG_MODULE_CACHE = 1, WARDEN_SMSG_CHEAT_CHECKS_REQUEST = 2,
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?Code: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;
That looks very similar to what warden on MAC does.
Last edited by TOM_RUS; 05-01-2012 at 06:11 PM.
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.
Last edited by namreeb; 05-01-2012 at 06:50 PM.
[16:15:41] Cypher: caus the CPU is a dick
[16:16:07] kynox: CPU is mad
[16:16:15] Cypher: CPU is all like
[16:16:16] Cypher: whatever, i do what i want