Evening,
From this post onwards, this address will not be updated. To continue reading my updated posts, update your bookmarks and links to http://blog.kynox.org.
See you on the flip side!
Filed under: Uncategorized | Leave a Comment »
Evening,
From this post onwards, this address will not be updated. To continue reading my updated posts, update your bookmarks and links to http://blog.kynox.org.
See you on the flip side!
Filed under: Uncategorized | Leave a Comment »
Anyone using the tool “UltimateChat” by Jadd of MMOwned, this is now being detected as of a few minutes ago.
Have fun!
Filed under: General, Warden, world of warcraft | Tagged: gibson, haxen, the, Warden | 5 Comments »
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.
Filed under: Warden, world of warcraft | Tagged: Warden | 24 Comments »
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”.
Filed under: General | Tagged: cypher, ddos, lol | 3 Comments »
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!
Filed under: General, world of warcraft | Tagged: 3d rendering, world of warcraft | 3 Comments »
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!).
Filed under: General, Warden | Tagged: gatherbuddy, Warden | 17 Comments »
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.
Filed under: Uncategorized | 4 Comments »
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
Filed under: General | Tagged: down-syndrome, jay, krypton, mmowned, nod-o | 17 Comments »
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.
Filed under: General, Warden | Tagged: mac, Warden, wow | 12 Comments »
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.
Filed under: General | Tagged: .net, codeveil, jit, unpack | 3 Comments »