Proxy to manipulate?

[kynox]

I load fresh warden module into memory, initalize it, as described in skillsecurity wiki
(in pyton with ctypes it not so hard - just need to understand, what happens under the hood)

when I feed it with current RC4 state (box1, i1, j1, box2, i2, j2, err - 520 bytes total) via GetRC4Data callback

after that I give it encrypted SEED packet, captured from stream and got encrypted SEED responce via SendPacket callback - exaclty same, as live warden sent to server.

after that I read new RC4 state with i1=0 and i2=0 (i.e not used for encryption) from warden's memory (from addr, there old state was written to).

but when I try to decrypt next warden pkt with this new RC4 state - I got nonsense result.

also when I give this pkt to module, it don't do any job - PacketHandler return 0, and no callbacks fired.

what I missed ?

Loading module AF203602B6E8414A835A10B4E3DC8EEC.raw
Allocated mem for module: 0x010b0000
Copying code sections to module.
Adjusting references to global variables...
Updating API library references...
Lib: KERNEL32.dll, offset: 0x00007000
   Function: GetConsoleMode,      0x7c81ac50
   Function: GetStdHandle,      0x7c812fd9
   Function: Sleep,      0x7c802446
HOOKED
   Function: GetModuleHandleA,      0x00f70fa4
   Function: TlsAlloc,      0x7c812e3f
   Function: TlsFree,      0x7c813777
   Function: TlsGetValue,      0x7c8097e0
   Function: TlsSetValue,      0x7c809c65
   Function: RaiseException,      0x7c812aa9
HOOKED
   Function: GetProcAddress,      0x00f70fdc
   Function: GetSystemInfo,      0x7c812df6
   Function: GetVersionExA,      0x7c812b7e
   Function: VirtualQuery,      0x7c80ba71
   Function: QueryDosDeviceA,      0x7c85d344
   Function: GetTickCount,      0x7c80934a
   Function: DuplicateHandle,      0x7c80de9e
   Function: CloseHandle,      0x7c809be7
   Function: FreeLibrary,      0x7c80ac7e
   Function: GetCurrentProcess,      0x7c80de95
HOOKED
   Function: LoadLibraryA,      0x00f70fc0
   Function: GetProcessHeap,      0x7c80ac61
   Function: HeapFree,      0x7c90ff2d
   Function: TerminateProcess,      0x7c801e1a
   Function: UnhandledExceptionFilter,      0x7c863fca
   Function: SetUnhandledExceptionFilter,      0x7c84495d
   Function: QueryPerformanceCounter,      0x7c80a4c7
   Function: GetCurrentThreadId,      0x7c8097d0
   Function: GetCurrentProcessId,      0x7c8099c0
   Function: GetSystemTimeAsFileTime,      0x7c8017e9
   Function: RtlUnwind,      0x7c92abc5
Lib: USER32.dll, offset: 0x0000707c
   Function: CharUpperBuffA,      0x7e36ae3f
   Function: CreateWindowExA,      0x7e37e4a9
   Function: ScrollWindowEx,      0x7e380187
   Initialize Function is mapped at 0x010b263d
 <-- GetModuleHandleA('kernel32.dll') = 0x7c800000
 <-- GetProcAddress(0x7c800000, 'AddVectoredExceptionHandler') = 0x7c936c2a
 <-- GetProcAddress(0x7c800000, 'RemoveVectoredExceptionHandler') = 0x7c936c96
 <-- AllocateMemory(2032)
 <-- AllocateMemory(60)
 <-- AllocateMemory(44)
 <-- LoadLibraryA('kernel32.dll') = 0x7c800000
HOOKED
 <-- GetProcAddress(0x7c800000, 'CreateToolhelp32Snapshot') = 0x00f70f88
 <-- GetProcAddress(0x7c800000, 'Module32First') = 0x7c8653a0
 <-- GetProcAddress(0x7c800000, 'Module32Next') = 0x7c865525
 <-- GetModuleHandleA('kernel32.dll') = 0x7c800000
 <-- GetProcAddress(0x7c800000, 'wine_get_unix_file_name') = 0x00000000
 <-- AllocateMemory(92)
Module Initialized, return 0x00cd2b60
GenerateRC4Keys = 0x17512352
Unload = 0x17523824
PacketHandler = 0x17512560
Tick = 0x17504864
 -> GenerateRC4Keys
 <-- GetRC4Data <warden.LP_c_ubyte object at 0x019089E0> 520
 -> PacketHandler
 <-- SendPacket(0x01908af8, 21)
(1, 17)
encrypted responce
0000: 52 58 2e be 97 dd fe dc ad a7 87 bc 1b ca ef 56  |  RX............V
0010: 7b fe 5c ce b6                                   |  {.\..

decrypted responce
0000: 04 0e 94 81 61 d0 b6 8b fb aa d5 60 eb a0 f1 8a  |  ....a......`....
0010: 73 d6 5c ad ad                                   |  s.\..

AFTER SEED -> HASH

serv pkt encrypted
0000: ac 03 4d 10 f6 d2 b7 b9 dc 96 5f 9f 75 ff f4 dc  |  ..M......._.u...
0010: 82 25 74 8c c0 c7 da 41 eb 7d 90 c0 3a 2a c0 74  |  .%t....A.}..:*.t
0020: 10 f4 d6 2f 6c 46 cb 71 5e ce 0b 22 bf b4 8b 56  |  .../lF.q^.."...V
0030: 35 1e 52 af 15 3f 4e 14 b7                       |  5R.?N.

serv pkt decrypted
0000: 69 b6 97 1c 52 8d 97 9a 70 c4 7f 5d f3 6e 6e df  |  i..R...p.].nn.
0010: a5 ff 96 72 bd f9 94 89 5c cc 18 e1 7d e8 dc d4  |  ...r....\..}...
0020: 42 eb c4 80 87 77 8b 86 c0 ea ff e0 82 dc 8b b5  |  B....w..........
0030: 40 42 6b ed b7 4b 4f 4e 80                       |  @Bk..KON.

 -> PacketHandler
(0, 0)

 <-- ReleaseMemory(0x00ca61d0)
 <-- ReleaseMemory(0x00c207a8)
 <-- ReleaseMemory(0x00aba020)
 <-- SetRC4Data <warden.LP_c_ubyte object at 0x00CFCBC0> 520
 <-- ReleaseMemory(0x00cd2b60)

Not sure - What packet are you passing to warden?

[abdula123]

I found error - it was in reading RC4 state from loaded warden module.

while checking out everything what I can miss, I also found simple way to grab current RC4 state from live warden module in WOW process. so, no more module loading.

by the way - did warden checks, that its own memory was read from another process?

decrypted
0000: 02 46 57 6f 72 6c 64 5c 45 78 70 61 6e 73 69 6f  |  .FWorld\Expansio
0010: 6e 30 32 5c 44 6f 6f 64 61 64 73 5c 53 74 6f 72  |  n02\Doodads\Stor
0020: 6d 70 65 61 6b 73 5c 49 63 65 53 68 61 72 64 73  |  mpeaks\IceShards
0030: 5c 46 72 6f 73 74 47 69 61 6e 74 49 63 65 53 68  |  \FrostGiantIceSh
0040: 61 72 64 30 34 2e 4d 32 00 e8 a5 01 20 45 d9 18  |  ard04.M2.... E.↑
0050: 24 49 e7 f6 2c 4f bd e6 80 3f 7d da 94 ce 12 2c  |  $I..,O...?}....,
0060: 7c 9b 40 20 3a 0c d7 1f 01 04 20 f7 c7 0f 56 c0  |  |.@ :..▼.. ...V.
0070: 39 a6 57 0e 2c 2f 24 90 bc fb cd 66 5f ed 5b 3c  |  9.W.,/$....f_.[<
0080: 87 3e c0 f8 60 00 00 11 20 10 75 70 2b a8 a8 02  |  .>..`... .up+...
0090: d5 f6 7a 41 6c b3 4c 11 e0 c9 b0 62 de 09 4d ab  |  ..zAl.L....b..M.
00a0: e0 78 a0 00 00 18 dd                             |  .x...↑.

Ы!

[XTZGZoReX]

while checking out everything what I can miss, I also found simple way to grab current RC4 state from live warden module in WOW process. so, no more module loading.

Care to share that? I haven't been able to figure a way.

by the way - did warden checks, that its own memory was read from another process?

AFAIK, no.

[abdula123]

Care to share that? I haven't been able to figure a way.

open wow.exe in IDA.

find .\WardenClient.cpp string and 7 offsets after it.
these offsets (which points to functions) is struct FuncList - as decribed in skullsecurity wiki

set breakpoint in GetRC4Data (last fn in struct) and launch wow.exe in IDA debugger.

skip first breakpoint activation - its internal module (MAIEV.MOD or something like it) loading, and wait second.

it happens after loading of fresh warden module, and you will stand in middle of callback from warden's GenerateRC4Keys function.

from there, examining memory of live warden module you can figure out (assume, you already calculated current MAIEV.MOD keys, decrypt all previous packeds, and know current RC4 state) where placed live RC4 state, where placed pointers to it, how to grab it, and can build shorthest path from wow.exe's static pointers (I managed to do it in 3 pointer "jumps").

and yes, you need to do it after each wow patch





also, how many warden modules exists at this moment.
I suspect, that there is a finite quantity of modules, and they repeats from time to time. did I miss something?

[TOM_RUS]

Care to share that? I haven't been able to figure a way.

offset = 0x00D51EF4;

public static byte[] GetWardenRC4State(uint offset)
{
    using (var pmr = new ProcessMemoryReader(GetProcess(ProcessName)))
    {
        return pmr.Read(pmr.ReadUInt(offset) + 0x20, 0x204);
    }
}

[abdula123]

offset = 0x00D51EF4;

WOW!

its even easier that I found. 1 jump

why you did not post it before I spent so many hours on warden?

[TOM_RUS]

WOW!

its even easier that I found. 1 jump

why you did not post it before I spent so many hours on warden?

Becase I found it today. Took not more than 5 minutes.

wardenInitReturn is 0x00D51EF4

signed int __cdecl Packet_SMSG_WARDEN_DATA(int a1, int a2, int a3, CDataStore *this)
{
  int v4; // ecx@1
  signed int result; // eax@2
  unsigned int v6; // esi@3
  int v7; // [sp+0h] [bp-4h]@1

  v7 = v4;
  if ( a2 == SMSG_WARDEN_DATA )
  {
      SCritSect__Enter(&stru_D51F08);
      v6 = this->Length - this->Position;
      CDataStore__GetBytesArray(this, (char *)&v7, this->Length - this->Position);
      a2 = 0;
      if ( dword_D51EF0 )
      {
          (*wardenInitReturn)->PacketHandler(wardenInitReturn, v7, v6, &a2);// this, data, length, &result
          sub_7B3F80();
      }
      SCritSect__Leave(&stru_D51F08);
      result = 1;
  }
  else
  {
      result = 0;
  }
  return result;
}

char __cdecl sub_7B3F80()
{
  int v0; // eax@2
  WardenExports **v2; // eax@5
  WardenExports *v3; // esi@6
  ClientConnection *v4; // eax@6
  int v5; // eax@6

  if ( !dword_D51EEC )
      return 0;
  Warden__UnloadModule();
  v0 = BLLLoader__GetExport(dword_D51EEC, 1);
  if ( !v0 || (v2 = (WardenExports **)((int (__thiscall *)(_DWORD))v0)(&off_A95BF4), wardenInitReturn = v2, !v2) )
  {
      sub_7B3EE0();
      return 0;
  }
  v3 = *v2;
  v4 = ClientServices__GetCurrent();
  v5 = ClientServices__GetSessionKey(v4);
  v3->GenerateRC4Keys(wardenInitReturn, v5, 40);
  dword_D51EF0 = dword_D51EEC;
  dword_D51EEC = 0;
  return 1;
}

[kiborgrus]

Nice Tom_Rus!

[abdula123]

Becase I found it today. Took not more than 5 minutes.

... assuming to have some wow.exe symbols and structs, expirience in wow reversing, and good reversing skills in general

this assumption is wrong in my case

also it take time to load warden module from my own python code.

[abdula123]

what does PAGE_CHECK warden check work?

for example this:

check_type : PAGE_CHECK
seed : 1474620449
sha : c2c38d5e2c5736f0ac2d109662338a39fb7f0d93
addr : 209352 = '0x000331c8'
bytesToRead : 75

return - e9

it like to:
initialize sha1 with seed, hash 75 bytes of data at addr 0x000331c8, checks with supplied hash and return E9, if it match ?

but addr 0x000331c8 is strange - its not RVA, and there is no sensitive code/data in wow.exe file at this offset. how read it?


edit:
is it correct, that there 29 distinct wow.exe memory checks now (at least was seen for last 2 days), covering 222 bytes total ?

[SinnerG]

Well, if you're sure that it must return 'e9' then why not 'care' about what it checks and just return it? :P

Ofc, this idea will fail if they use this to check stuff that is guaranteed to fail (to prevent this idea)

[TOM_RUS]

More like this:

initialize HMACSHA1 with seed, hash 75 bytes of data at addr 0x000331c8, checks with supplied hash and return E9, if it NOT match ?

And address is moduleBase+address from packet (it scans all modules including wow.exe).

[abdula123]

More like this:


And address is moduleBase+address from packet (it scans all modules including wow.exe).

how warden select which module to scan? - there is no module name in PAGE_CHECK request.


also, why Warden Guy even bother to do a hashing instead of just do MEM_CHECK at this address, and look at its content (returned by MEM_CHECK) ?



-----
looks like it time to setup vmware, register another trial account, tamper wow's memory at "interesting" addreses and look how warden will react on this

[TOM_RUS]

how warden select which module to scan? - there is no module name in PAGE_CHECK request.


also, why Warden Guy even bother to do a hashing instead of just do MEM_CHECK at this address, and look at its content (returned by MEM_CHECK) ?



-----
looks like it time to setup vmware, register another trial account, tamper wow's memory at "interesting" addreses and look how warden will react on this

1) It scans all modules. That's why there's no module name.
2) No idea. Ask him instead :P

[abdula123]

1) It scans all modules. That's why there's no module name.
2) No idea. Ask him instead :P

looks like I miss something again.

if it scan all modules - that moduleBase is? exe's 0x00400000 ?

and what difference betheen PAGE_CHECK_1 and PAGE_CHECK_2 codes?