Warden changes

Hey everyone.

Just a quick update on the status of Warden; For the entire weekend, the warden server was actually offline, which i found rather odd, but i guess even WardenGuy doesn’t work on the weekends.

Now, onto the 11 changes. Regarding DLL detection, two new dlls have been added to the hit list and based on the scan size, it’s safe to assume they’re the same module, just different variants.

That leaves us with 9 memory scans, specifically targeting allocated memory (I’m looking at you, “passive” botters who find yourselves injecting large code stubs). These all seem to be different offenders, based on the diversity in the offsets and sizes.

Don’t say i didn’t warn you!

Clarification

It seems a lot of people haven’t understood what i was trying to convey. (Fair enough. It was late, and i was tired)

This update isn’t looking for memory changes in WoW’s .text/.data sections. These are targeting injected DLL files and the memory those DLL(or VirtualAllocEx’d memory from a third party process) allocate.

Update #2

Well, that was quick. Hawker asked me if there were any worrying updates to Warden, so i gave him the following picture from my tool. Hawker posted it on his forum before asking me, but promptly removed it when asked. Someone snagged it before it was taken down, so i guess its public domain now.

Cypher’s Blog!

So, it’s been a while since i posted here (protip: leave comments and request shit!) so i may as well use this time to publicly laugh at Cypher, who’s blog is being DDoS’d right now. Nothing more to say than “lol, skiddies”.

3D Rendering

Well, lately I’ve been rather (obsessed) “curious” as to the possibilities in 3D rendering in WoW. In the following clip, i present some of my work and put forward a potential use for the code!

Gatherbuddy Detection

Well, seems there’s a wave flying through and GB was in it’s path.

Something worth noting about this, is that GB wasn’t the target. GB wrote to some memory that LuaFoo did too. Once LuaFoo got detected, sadly, GB as a side-effect to the new memory scan was hit (dating before they installed their tripwire).

So to summarize, direct all hate to Apoc (:D!).

LuaFoo (by Apoc) Detected

Just received an email from my logger notifying me that the memory at 0×40100A is now being scanned. LuaFoo used this for a lua callback.

Nod-O Bullshit

Jay aka Krypton88 aka LegacyAX aka StrategicX, etc, the kid behind Nod-O continues to claim that his “bot” is “Warden safe” which is utter bullshit.

His bot is riddled with chunks of code from various sources, one in particular is from the MMOwned community; unknown to Jay (see: Illiterate down-syndrome child), a side-effect of his code theft is that with a large chunk of assembly injected into WoW, it’s trivial to detect.

He claims that everything is copyright to him, and that he wrote everything; more lies. He claims to be in his twenties, with a wife and at least one lawyer, unconfirmed, but enjoy a video of him in his e-gangster stage, dating December of last year.

In closing, don’t trust this compulsive liar with your money.

Nod-O Source: (Removed.. I’m not “not” telling you to google it though )
Video URL: http://www.youtube.com/watch?v=28BWZEfkLOI
Mirror: http://filebeam.com/087d432488c3b42cc6a522c24cd8b5c6
Proof of video existence: http://img200.imageshack.us/img200/9567/proofofvideo.png

References:
AutoIt forum alias: http://www.autoitscript.com/forum/index.php?showuser=46178
Stolen assembly library: http://www.autoitscript.com/forum/index.php?showtopic=86672
Stolen AutoIt code: http://www.mmowned.com/forums/wow-memory-editing/248831-3-1-3-autoit-teleport-mining-herbalism-bot.html

Warden’s existence on the Mac

A friend asked me recently whether the Mac WoW client actively ran a copy of the Warden module we see on Windows.

Yes, Mac’s do have a Warden and yes Blizzard are streaming modules to your Mac. However, the modules they stream are just shells, which i assume is to prevent clientless bots (although, it would be stupidly easy to emulate). I have omitted the exact details of what happens, however reversers shall bare witness to the comical side of the warden dev with constants like 0×1337F00D and 0xDEADBEEF instead of a tedious polymorphic crypto function.

Warden on a Mac is a “Mach-O”(http://en.wikipedia.org/wiki/Mach-O) file type. I’m not from a Mac background, so I’ll just assume its the safe way of loading up assembly and executing it.

__text:001F0301                 mov     ecx, offset s_WardenDecryptKey
__text:001F0306                 mov     edx, 1A96h
__text:001F030B                 mov     eax, offset s_WardenModule
__text:001F0310                 call    WardenModule__Load

__data:00B9A420 s_WardenDecryptKey db 9Eh, 0BBh, 81h, 0Fh, 34h, 0E9h, 0DFh, 8Ah, 0B8h, 0BAh
__data:00B9A420                                         ; DATA XREF: sub_1F02EA+17o
__data:00B9A420                 db 13h, 0D9h, 3Dh, 0CAh, 0Dh, 50h

__data:00B9A440 s_WardenModule  db 4Eh, 5, 50h, 0A4h, 0D2h, 0CBh, 1Ah, 0D6h, 6, 25h, 0FEh [..omitted]

BYTE RC4Key[] = { 0×9E, 0xBB, 0×81, 0×0F, 0×34, 0xE9, 0xDF, 0×8A, 0xB8, 0xBA, 0×13, 0xD9, 0×3D, 0xCA, 0×0D, 0×50 };
FILE* fp = fopen( "Warden.bin", "rb" );

BYTE Module[ 0x1A96 ] = {0};
fread( Module, sizeof( Module ), 1, fp );   
fclose( fp );

RC4 rc4;
rc4.Init( RC4Key, 16 );
rc4.Apply( Module, sizeof( Module ) );

DWORD_PTR Size = *reinterpret_cast< PDWORD_PTR >( &Module );
std::vector< BYTE > Uncompressed( Size );

int iResult = uncompress( &Uncompressed[0], &Size, &Module[4], sizeof( Module ) – 4 );
if ( iResult != 0 )
{
    std::cout << "Error uncompressing" << std::endl;
    return 1;
}

fp = fopen( "WardenOut.bin", "wb" );
fwrite( &Uncompressed[0], Size, 1, fp );
fclose( fp );

Yeah. The code isn’t pretty, but i don’t care as its not something i intend to spend any more time on.

The possibility for Blizzard to start scanning is very real.

.NET JIT

Recently i came across a packer/obfuscator for .NET executables. At first i was puzzled, as the names of the objects were intact. The function bodies IL code was unable to be decompiled, however.

Immediately i noticed that the IL code had been tampered with as the opcodes were obviously corrupt. Curious, i set an on-access hardware breakpoint on the IL code and stumbled upon a very interesting method this particular packer (CodeVeil) had implemented.

Codeveil had hooked the Just-In-Time(JIT) “CILJit::compileMethod” routine. What this function does is rather self explanatory, however what Codeveil utilized it for was rather neat. When the .NET Framework wanted to compile a method, Codeveil would decrypt the entire assembly prior to calling the original compileMethod and then re-encrypt the assembly.

Xor encrypt/decryption:

0042D7B0    66:0F280F    movaps xmm1,dqword ptr ds:[edi]
0042D7B4    66:0F2806    movaps xmm0,dqword ptr ds:[esi]
0042D7B8    66:0FEFCB    pxor mm1,mm3
0042D7BC    66:0F290E    movaps dqword ptr ds:[esi],xmm1
0042D7C0    66:0FEFC3    pxor mm0,mm3
0042D7C4    66:0F2907    movaps dqword ptr ds:[edi],xmm0
0042D7C8    83C6 10    add esi,10
0042D7CB    83C7 10    add edi,10
0042D7CE    49        dec ecx
0042D7CF  ^ 75 DF    jnz short 0042D7B0

To do this, they first call the “getJit” export of mscorjit.dll which returns an instance of the CILJit class. From here, the following virtual functions are available to be hooked:

CorJitResult __stdcall CILJit::compileMethod(ICorJitInfo *, CORINFO_METHOD_INFO*, unsigned int, unsigned char**, unsigned long*)
virtual void __stdcall CILJit::clearCache(void)
virtual int __stdcall CILJit::isCacheCleanupRequired(void)

In summary, this is a really easily bypassed protection. All one has to do is locate the decryption/encryption function, BP the retn and then dump the assembly.

Blizzard Survey Write-up

Hi, everybody! [Hi, Dr. Nick!]. Well, it’s been a while since i blogged [feel free to leave comments requesting write-ups!], and since I’ve heard a lot of misinformed individuals speculating that the Survey message in WoW is an elaborate attempt to detect botters, i figured why not take the time to silence them.

So. First things first. No!, it is literally JUST a survey. For those who want to see how it works, keep reading.

WoW loads up Survey.dll from a MPQ file stored in your Cache directory. It then allocates a 0×1004 byte sized structure to be passed to the “ExtraWork” export of Survey.dll.

struct SurveyStruct
{
  __int16 GameIndex;
  __int16 field_2;
  char Data[4096];
};

Data is nulled before being sent, and the first two ints are set to the locale and survey version. Survey.dll takes the information passed, verifies the survey hasn’t already been executed, and then forms a large XML response of your hardware information.

Yes, it really is only your hardware info. It’s not all your emails, divulging your secret affair with Arnold and how you plan to walk his dog in secret. Conspiracy theorists be gone!

<systemdescription platform="Win32" arch="x86" version="2.1.1" survey="251">
    <game name="worldofwarcraft" locale="enUS"/>
    <cpu num="2" vendor="GenuineIntel" versiona="0×0001067a" versionb="0×00020800" featuresc="0×0c08e3fd" featuresd="0xbfebfbff" exfeaturesc="0×00000001" exfeaturesd="0×20100000" cores="0×04000121" cache="\x01\xb1\xb0\x05\xf0\x57\x56\x4e\x30\xb4" brand="Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz" maxspeed="3000" currspeed="3000"/>
    <ram physical="6142"/>
    <os platform="2" arch="9" major="6" minor="1" additional="" build="7600" privilege="15" filesystem="NTFS" freedisk="792933" totaldisk="953866" lang="1409" cp="1252" tz="720" dst="60" flags="0×30000010"/>
    <directx version="9.0.904"/>
    <hardware battery="0"/>
    <media id="1" type="51"/>
    <mediaid="2" type="51"/>
    <video id="1" vendor="0×1002" device="0×9442" master="1" devcaps="0×001bbef0" vertex="0xfffe0300" pixel="0xffff0300" width="1680" height="1050" refresh="59" format="0×00000016" vram="504" bus="" busmult="0" gpu="1" driver="atiumdag.dll"version="8.14.10.678" description="ATI Radeon HD 4800 Series "/>
    <video id="2" vendor="0×1002" device="0×9442" master="1" devcaps="0×001bbef0" vertex="0xfffe0300" pixel="0xffff0300" width="1920" height="1080" refresh="60" format="0×00000016" vram="504" bus="" busmult="0" gpu="1" driver="atiumdag.dll" version="8.14.10.678" description="ATI Radeon HD 4800 Series "/>
    <audio id="1" caps="0×00000f1f" speakers="0×00140004" module="{0.0.0.00000000}.{5a72ad61-a2b5-4179-b2ff-c3eb4d728007}" desciption="Speakers (USBAudio Device)"/>
    <audio id="2" caps="0×00000f1f" speakers="0×00140004" module="{0.0.0.00000000}.{05b444c0-da37-4730-8382-efe87c34125b}" desciption="Digital Audio (S/PDIF) (High Definition Audio Device)"/>
    <options renderer="directx" window="0" widescreen="1" resolution="" width="800" height="600" multisample="0" musicvolume="0" farclip="0" refresh="0" colorbits="0"/>
    <vista system="5.8" memory="6.9" cpu="6.5" disk="5.8" d3d="7.3" graphics="7.3"/>
</systemdescription>

Gasp! All my secrets!

Gatherbuddy

I just want to take a minute to warn my readers about Gatherbuddy.

Based on the last build i saw, Gatherbuddy injects a DLL for various reasons. Now, you’re thinking “Oh but Mr Kynox! They have anti-wardens and will tell us when there is an update!”.

Gatherbuddy can be detected without a module update, meaning their “tripwire” (which i question even exists) is completely useless. Warden only needs a tiny bit of information added into the already existing scans (via a packet) and thus setting off no alarms.

Until Gatherbuddy drop the dll, you’re even more detectable than Mimic was, before it even started to protect itself.