Starting Out

Where to start?  Oh, that’s right, the gathering of information.

Firstly, let’s start with talking about what we’re going to need to know, based on what we want to do.

• If we’re building a bot/tool for retail WoW, we’re going to want to know as much as possible about Warden.
• We’re obviously going to need a method of gathering the information we need from the client (memory-reading).
• If we’re thinking about injecting a DLL into the WoW client, we should probably research whether or not WoW has anti-injection methods in place (it does!).

Now, personally, I am not going to talk much about Warden on this blog.  I’m not looking to create my tool for retail WoW (yet) and I do not really want to spread what may be construed as misinformation due to the lack of proven knowledge about Warden.  Suffice it to say that doing ANYTHING to guard against Warden is far better than doing nothing.  Here’s a few pointers that may help, but also may not:

1. If you inject code, you had better figure out how to tell when Warden is scanning your memory modifications.  One way would be to catch Warden as it is initialized and hook its memory-reading routine so you can tell where it’s reading and shut off your tool or crash all of WoW if it’s about to read any of your hooks or the base of your injected code.  If you inject a DLL, unlink your module (search gamedeception.net for unlinking modules). [Kynox has pointed out that Warden scans through modules using the Process Page List, currently, so unlinking your module won't achieve much.  Instead, look into nulling your module's EAT, which will make you harder to detect but will screw up ejecting your module.]
2. If you’re injecting a DLL but not hooking any functions, it may be useful to simply set up a Vectored Exception Handler, then set protected memory chunks right before and right after your module.  Assuming Warden would scan through memory in ~0×1000 byte chunks, an exception will be thrown whenever it’s getting close to your module, allowing you to handle that exception and then uninject / crash WoW so that you don’t get detected.  Of course, Exception Handlers are probably detectable by themselves, so you might want to research that, as well.  I’ve never used this method so I’m sorry that I cannot give you more information.
3. If you’re injecting a DLL and hooking game routines, for God’s sake don’t use the Microsoft Detours library (either v1.5 or v2.1).  This library is notorious for being used in game hacks and a very simple scan+hash can be used to determine whether it resides inside the client or not.  Seriously, write your own detour library and keep it private or randomize it in some way if you’re going to detour/hook game routines.
4. Randomize the title, classname, CRC, and process name of your main hack window.  Part of what Warden does is scan open windows and processes and it’d be stupid to get caught for using something that is on its blacklist when these things are so easy to change.  [Kynox also pointed out that the current version of Warden doesn't scan anywhere outside of WoW.exe, so this is probably less than helpful as well... still, so easy it couldn't hurt just in case Warden starts doing this again, I suppose (which, personally, I doubt, since they've taken so much flak over scanning open windows in the past).]

Also, if you’re planning to inject a DLL, know that WoW seems to hook CreateRemoteThread (from what I’ve read, only, as I’ve never attempted to use CreateRemoteThread with WoW), so that method of DLL injection is out.  What I would suggest is to create a small, harmless DLL with a generic windows hook in it (search google or codeproject.com for SetWindowsHookEx injection) that, when it detects it has been loaded into the WoW client, simply calls LoadLibrary from within the client memory space to load your actual hacking DLL.  Then the harmless DLL can unset the windows hook and disappear into the mists as its job is already done.  [Xarg0 has pointed out that he's capable of injecting his DLL using VirtualAllocEx and CreateRemoteThread, just like normal, so perhaps they've stopped doing this.  I read this on gamedeception.net and, as stated, have never tried, so I don't know =p Test it for yourselves]

Alternatively, you could have the harmless DLL simply allocate enough memory and then map your hack dll into memory without using LoadLibrary (less detectable), then create a thread on whatever initialization your hack has to do (detouring functions, etc.).  Circumventing LoadLibrary keeps your module out of the linked module list, also, plus this would be a good time to set protections on the memory region right before and right after your module and set up the Vectored Exception Handler as anti-scanning protection.  Just a thought.

I suppose you could also research some of the undocumented kernel functions that do the actual work when CreateRemoteThread is called and circumvent WoW’s hold on that API, thus injecting your DLL just like any other, but I leave that up to you to research.

My next post will outline how to access the client’s linked-list of game objects, allowing us to see what’s around our player (bot) or access our own game object (teleportation, etc.).

Read my next post in this journal here.