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!
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!).
Just received an email from my logger notifying me that the memory at 0x40100A is now being scanned. LuaFoo used this for a lua callback.
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
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 0x1337F00D 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[] = { 0x9E, 0xBB, 0x81, 0x0F, 0x34, 0xE9, 0xDF, 0x8A, 0xB8, 0xBA, 0x13, 0xD9, 0x3D, 0xCA, 0x0D, 0x50 };
BYTE Module[ 0x1A96 ] = {0};
FILE* fp = fopen("Warden.bin", "rb");
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.
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:
virtual 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.
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="0x0001067a" versionb="0×00020800" featuresc="0x0c08e3fd" 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="0x001bbef0" 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="0x001bbef0" 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="0x00000f1f" speakers="0×00140004" module="{0.0.0.00000000}.{5a72ad61-a2b5-4179-b2ff-c3eb4d728007}" desciption="Speakers (USBAudio Device)"/>
<audio id="2" caps="0x00000f1f" 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!
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.
So, trollin’ youtube, as you do; i stumbled upon what can only be described as Mimic’s ‘Best hacker’ just having heard he was fired due to the ban wave.
Mimic have pushed out revision .51 of shitbox Mimic. As per their usual attempt to circumvent Warden, they have introduced another flaw. It’s currently undetected, until WardenDev feels like throwin’ another wave into the mix.
When will these guys learn?