Basically, WoW seems to keep all character names stored in memory in a linked-list that contains the player GUID, some other random information, and the player’s name.  In order to find and display a player’s name, WoW iterates through this linked list, comparing each GUID in the list with the GUID of the player whose name it wants.  Well, why not do exactly the same thing?

Here’s a link to the code that I use. It should be pretty easy to convert to just about any language out there.  If it’s not, drop me a line either here or at mmowned.com’s WoW Memory Editing forums and I’ll help as best as I can.

I apologize for the really short article, today.  Might have something better next time.

I hope you’ve all read up on how to access WoW’s linked-list of game objects.  If not, search around mmowned.com and forum.gamedeception.com, or read my article on the subject.

First, here’s the best resource for structs, enumerations, and offsets that I’ve found, as far as object information gathering goes: bobbysing’s WoWXBase Defines.h.  His full source is readily available here.

Now then, what do all of these things mean?  These enumerations are offsets for different fields of information held inside each game object in memory.  If you know the base address for an object and what type of object it is (you read its type from baseaddress+0×14), then you can access all of the data listed in these enumerations.

For all of the information except ePlayerFields, the pointer to the start of the information struct is found at (baseaddress+0×120).  Say that you read memory at MobBaseAddress+0×120 and it tells you the mob’s information struct is held at address 0×1230000.  Now, look at the eUnitFields enumeration in Defines.h: you can see that UNIT_FIELD_HEALTH = 0×40.  So, if you now read memory from 0×1230040, you have that mob’s health.  Same goes for GameObjects, DynamicObjects, and Corpses (scroll down about 2/3rds of the way through Defines.h to find the object type enumeration).

Players, however, are slightly different.  Each player has all of the same information as a unit/mob at (baseaddress+0×120), but it ALSO has all the information in ePlayerFields, with a pointer to the start of that structure at (baseaddress+0×1198).

Also, for both units/mobs and players, you can find its positional information at (baseaddress+0xBF0).  X coordinate is +0xBF0, Y is +0xBF4, Z is +0xBF8, and Facing is +0xBFC (all are float type values).  Lastly, for your local player, and I’m not entirely sure about this one, there seems to be an __int64 GUID of whatever you are currently auto-attacking at (baseaddress+0xF08)–very useful for checking if you’re currently auto-attacking: +0xF08 is zero if you’re not, non-zero if you are.

There you go, that should at least get you started on gathering information.  Hope it helped.

Suffice it to say that the table of virtual functions associated with a class object–a class object might be a GameObject, a GameUnit, a GamePlayer, etc., as it applies to World of Warcraft–are things that can be called almost as a part of the object.  For instance, instead of calling a function like Interact(GameObject obj), you’d simply call it like obj.Interact(), which, in my opinion, simplifies things greatly.

Anyway, you should all know, by now, how to find the base address of whatever object you want to interact with (generally it will be either a mob or a mining/herbalism/quest node).  Loop through whatever objects you find until you find the one you want to kill, target it, walk up to it, call it.Interact() and, voila, you’re attacking it.  So, once you have the base address of the object, read the VERY FIRST pointer, at offset zero.  ReadDword(WoWhProcess, objectbaseaddress); This will be a pointer to its virtual table of functions associated with that class object.

The virtual table consists of pointers to subroutines associated with the object.  In other words, each entry in the table is a DWORD pointing to the start address of a function that can be used with–or as a part of–the object.  If you want to call obj.Interact(), you need only know which place in the virtual table .Interact() occupies.  Well, here: it occupies position number 34.  That, by the way, is credit, ONCE AGAIN, to bobbysing’s WoWX hack base, so think of him and anyone else that helped him find the information when you use it–I did literally nothing to find it except page through his source code.

So, you’ve got your pointer to the virtual table by reading at the base address of the object, and now you read from (virtualtablepointer + (34 * 4)) in order to find the address of the .Interact() function associated with the object (yes, it’s a different address for GameObjects and GameUnits, so you really do have to read its address from the virtual table associated with the object each time you call it).  Remember, it’s in position 34, and each position consists of a DWORD (4-byte) pointer to a function, so, to read from position 34, we read from VTable+(34*4).  Hope that’s clear.

If we’re calling a class method from an external thread–and we are–then we have to make sure our thread is as close as possible to resembling the thread that NORMALLY would call the method.  We pretty much all, at this point, use the TLS method for iterating through loaded objects, so I hope this is not new to anyone who needs to know how to target a unit–in other words, if you’re reading this post and hoping to apply it to your bot/tool, you should probably understand what I’m talking about.  A pointer to the linked-list of objects in the WoW client is held in the TIB, or Thread Information Block, of the calling thread.  Since we are creating an external thread, as in my last article, to call this method, we need to modify our thread’s TIB to emulate WoW’s.  A few simple ASM instructions and one memory write should do the trick!

Get your pointer to the s_curMgr ready, you’re going to need it.  Currently, you can get a pointer to the s_curMgr with two memory reads: [[0xD495B0]+0×2218].  This is what we’re going to use to update the TIB of our thread.

At this point, you’re going to want to make sure you’ve read my SelectUnit article because much of what I’m going to breeze through right now is covered there, with code examples.  We’re going to have to allocate memory, inject code, and call CreateRemoteThread, just as outlined in the SelectUnit article.

So, allocate your chunk of memory using VirtualAllocEx.  It doesn’t have to be huge, but making it a full 0×1000 byte chunk won’t hurt for our purposes.  For this example, assume your code injects at address 0×1230000; here is the ASM we will be injecting:

MOV EDX,DWORD PTR DS:[DEADBEEF] ;DEADBEEF==placeholder for our s_curMgr pointer
MOV EAX,DWORD PTR FS:[2C]       ;start accessing our TIB
MOV EAX,DWORD PTR DS:[EAX]      ;do it like WoW does it
ADD EAX,08                      ;same
MOV DWORD PTR DS:[EAX],EDX      ;move the s_curMgr pointer into our TIB
MOV ECX,DWORD PTR DS:[DEADBEEF] ;ECX = the base address of the object we're interacting with
CALL WoW.DEADBEEF               ;DEADBEEF = placeholder for the address of the virtual function
RETN                            ;always return so we don't crash

So, like before, we have to patch a few relative moves and calls.  First, remember that pointer to the s_curMgr you read from memory?  Write it to CodeCave+2 (in this example, 0×1230002).  Now, write the base address of the object with which you wish to interact to CodeCave+0×100 (0×1230100) and patch the second occurence of DEADBEEF (CodeCave+21) with the value of CodeCave+0×100 (this will tell it to move the value at address 0×1230100 into ECX on line 6).  Lastly, patch your relative Interact call on line 7 by writing (interactfunction – (CodeCave + 30)) to CodeCave+26.  When it’s all injected, and you look at it in OLLYDBG, it should look normalized, with all the addresses correct and no more DEADBEEF (spoiled meat stinks anyway).

Now you just CreateRemoteThread on it and watch as your player loots it, attacks it, mines it, or gathers it.  Magic.

As is my usual practice, here’s a bit of code on which to chew.

Until we meet again.

That said, the SelectUnit function that I’m using is ripped directly from bobbysing’s WoWX framework, right down to the pattern that I use to find it.  Instead of screwing with patterns–if you want to screw with patterns, you can find the pattern in bobby’s Patterns.xml, labeled SelectUnit–I’ll just provide you with the address of the function we’re talking about: 0x006D8760.  This function has one parameter: the 64-bit integer representing the unit’s GUID (read from UnitBase+0×30).

I don’t know about you, but my bot doesn’t select units all that often; it’s not something done multiple times a second, anyway.  SelectUnit, kill unit (takes some time, depending on level and class), loot unit, find next unit, SelectUnit.  For that reason, I’m okay with the added overhead for creating a new thread each time I want to select a unit, solely because it keeps me from having to inject a DLL into the client (which I’d like to avoid doing, for now).  Basically, the way I’m doing it goes a little like this:

• Allocate a chunk of memory for my codecave
• MemoryWrite ASM opcodes that push the 64-bit integer GUI onto the stack (you need two push commands, seeing as you can only push 4 bytes per command and a 64-bit integer is 8 bytes long)
• MemoryWrite ASM opcodes that will call SelectUnit, clean up the stack, and return
• MemoryWrite the 64-bit integer GUID at an address I know (that pointed to by my two pushes)
• Use CreateRemoteThread API to create a thread that executes my injected code
• Use WaitForSingleObject to wait until the thread returns

In pseudo-c, it might look a little like this (remember, ASM CALLs are relative, so you have to transform the static SelectUnit address into a relative call).

DWORD dwSelectUnit = 0x006D8760;
__int64 GUID = 0; //clears target

//Allocate with address NULL and it will give us the first available chunk
LPVOID lpCodeCave= VirtualAllocEx(hProcess, NULL, 0x100, MEM_COMMIT, PAGE_READWRITE);
//ASM with two pushes and a call (relative pushes and calls are represented by 0s temporarily)
byte[21] bInject = { 0xFF, 0x35, 0, 0, 0, 0, 0xFF, 0x35, 0, 0, 0, 0, 0xE8, 0, 0, 0, 0, 0x83, 0xC4, 0x08, 0xC3 };
//inject code
WriteProcessMemory(hProcess, lpCodeCave, bInject, sizeof(bInject), NULL);

//transform relative call address and patch
dwSelectUnit = dwSelectUnit - ((DWORD)lpCodeCave + 17);
WriteProcessMemory(hProcess, (void *)((DWORD)lpCodeCave + 13), dwSelectUnit, 4, NULL);

//patch PUSH opcodes to point to correct places
WriteProcessMemory(hProcess, ((DWORD)lpCodeCave + 2), ((DWORD)lpCodeCave + 0x504), 4, NULL);
WriteProcessMemory(hProcess, ((DWORD)lpCodeCave + 8), ((DWORD)lpCodeCave + 0x500), 4, NULL);

//write the GUID to be selected to memory
WriteProcessMemory(hProcess, ((DWORD)lpCodeCave + 0x500), GUID, sizeof(GUID), NULL);

//create the thread that executes our injected code
HANDLE hThread = CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)lpCodeCave, 0, 0, NULL);
WaitForSingleObject(hThread, INFINITE);
CloseHandle(hThread);

Easy enough?  I hope so.

As always, here’s a link to the next article in this journal.

As I understand it, there are two ways of measuring rotation: degrees and radians.  As you should all know, there are 360 degrees in a circle (with 0 degrees and 360 degrees meeting at north, 90 degrees being west, 180 degrees being south, and 270 degrees being east… counter-clockwise, if you will).  What many of you may not know is that there is π*2 radians in a circle.  That’s pi multiplied-by two, or 3.1415.. + 3.1415.. (which turns out to be approximately 6.3).  A radian is exactly 180/π degrees, or about 57.2958 degrees.  57.2958 * 3.1415 * 2 == 360.  There’s the math you need to know.  To go from radians (which is how we will read Object.Facing from WoW’s memory) to degrees, you need to multiply by 180 and divide by pi.  I hope that’s clear.  If not, perhaps this will help:

Also mentioned in the above picture is something many of you may not have encountered yet, atan or atan2.  The atan/atan2 function allows us to determine the arctangent between two coordinates, or the measurement, in radians, which we SHOULD be facing in order to face directly at a given point, knowing our own coordinates.  Thankfully, whatever programming language–in my case, C#–we’re using should be doing most of the work.  In C#, System.Math.Atan2 will give you the cake you’re so eagerly awaiting.  But, wait!, what if it returns a negative facing value?  WoW only deals with positive facing values!  Simple: add this negative facing value to Math.PI * 2, thus normalizing it.

Was that a lot to deal with?  Yeah, and I’m sorry.  There’s more, too: what if we want to determine which way we should turn in order to spend the least amount of time turning?  Well, we need to calculate how many radians (or degrees, if you wish) we’d need to turn to the left and how many radians we’d need to turn to the right, then compare the two.

Basically, you set up two if..then statements, and calculate the radians needed to turn depending on which situation you’re in for each direction.  If your current facing is greater than where you want to face, you’re going to have to turn past north if you turn left but you won’t have to turn past north if you turn right; conversely, if your current facing is lesser than the point you wish to be facing, you’re going to have to rotate past north if you turn to the right, but not if you turn to the left.

If you’re turning past north–which is sometimes shorter–you have to calculate the radians between your current facing and north… then between north and your goal… then add those two together to get your total needed rotation.  If you’re facing at 5.3 and you want to face 1.0, you’ll need to turn from 5.3 to north (6.3), or 1 radian, and then from north (also 0) to 1, or another 1 radian.  So, turning to the left from 5.3 to 1.0 is 2.0 radians, whereas turning to the right would be 5.3 – 1.0, or 4.3 radians.  It’s obvious which turn is shorter.

This is what mine looks like.

Anyway, you should all know, by now, that you can find a unit’s positional information–which includes facing direction–by reading from baseaddress+0xBF0.  +0xBF0 is XCoordinate, +0xBF4 is YCoordinate, +0xBF8 is ZCoordinate, and +0xBFC is FacingDirection.  Once you know your own facing direction, and the coordinates of yourself plus whatever object (or way point) you want to face, you should have no trouble, now, figuring out which way to turn and when to stop turning.  As always, I’ll post some source along with my article, which should make things just that much easier.  Here it is, in a .rar format. (Again, you’ll need my MemoryLib C# class library, and you’ll need to add that as a reference to your project.)

Until next time!

Click here to read the next post in this journal.

As of the current patch, 2.4.2, the class method for CObject->GetUnitReaction(CObject obj) is at address 0x005D4AB0 (can be found in WoWOffsets.h in the download posted by Kynox in the above link).  Basically, when it’s called, the two units’ factions are compared and a value representing their reaction is returned (1 for hostile, 3 for neutral, 4 for friendly, etc.). [Note: 1 is actually "extremely hostile" and 3 is actually "hostile", but 1 is fundamentally equivalent to aggressive and 3 is fundamentally equivalent to neutral]

You’ll notice that there’s not two arguments passed to this function; you don’t call it like GetUnitReaction(unit1, unit2).  That is because it is a class method.  You don’t have to specify unit1 because it is being called as a part of unit1.  It’s actually called like so: unit1->GetUnitReaction(unit2).  Therefore, in ASM, the ECX register is set to equal the base address of unit1, and the base address of unit2 is passed as an argument.  This allows the function to compare the two.  Just thought I’d point that out for those of you who are reverse-engineering the client to see the inner-workings, so to speak (all two of you!).

Now then, how does it compare the two factions: ay, there’s the rub.  That’s what everyone wants to know.  Well, let’s start off with how it finds the factions of the two units.

A unit’s faction is held at [[unitBase + 0x120]+0×74].  That’s two memory reads.  In C#, it looks like so:

int Faction = Memory.ReadUInt(hProcess,(Memory.ReadUInt(hProcess, (curObj + 0x120)) + 0x74));

Next question: once you get the faction of both units, what do you do? Well, what the WoW client does is pass unit1′s faction and unit2′s base address to the subroutine at address 0x005D1AE0. For instance, if you’re a Tauren (tauren faction == 6) and you’re comparing your faction to the unit at base 0x1DF00008, it’d look like this: CompareUnitFaction(6, 0x1DF00008); CompareUnitFaction (temporary name until someone comes up with something better) then grabs the unit’s faction at [[0x1DF00008+0x120]+0×74] and compares it with 6.  How does it compare it?  Well, that’s taken me hours and hours of reverse-engineering to figure out, so I’ll save you the time and explain it (as I understand it, which may be wrong).

CompareUnitFaction takes the factions of each unit and gets the address of that particular faction’s data struct in memory.  It does this by doing something like the following (pseudo code):

int startIndex = *0x93E80C;
DWORD factionPointer = *0x93E818;
DWORD totalFactions = *0x93E808;
DWORD hash1, hash2;
if (unit1.Faction >= startIndex && unit1.Faction < totalFactions && unit2.Faction >= startIndex && unit2.Faction < totalFactions)
{
hash1 = (factionPointer + ((unit1.Faction - startIndex) * 4))
hash2 = (factionPointer + ((unit2.Faction - startIndex) * 4))
return CompareFactionHash(hash1, hash2);
}

So, what’s CompareFactionHash(hash1, hash2) do?  Well, it looks through the client’s faction data struct and compares flags depending on which factions are being compared.  Here’s a link to the ASM subroutine. Here’s a link to my C# implementation of that ASM subroutine (should be understandable, I would think).

I’ve only tested it under the most contained of circumstances, but all tests came back positive.  It seems to be a pretty good way of determining whether a unit is Hostile, Neutral, or Friendly towards you without injecting any code.

Here’s my full C# code; you’re welcome to convert it to whatever you want, redistribute it, etc., as long as credit is given.

More to come, as always!

Click here to read the next article in this journal.

WoW stores its game objects inside what’s called its Thread Local Storage (hereafter referred to as TLS).  There’s pointers to pointers to its linked-list of game objects (hereafter referred to as the object manager) but, thanks to Kynox, we can make it VERY easy to access the object manager inside WoW’s TLS.  Seriously, any time you have the opportunity, thank Kynox.  This method is so much easier than any of the others I’ve come across.

So, as of the current patch on June 14th, 2008, (2.4.2 I think?), there is a pointer to the object manager at [0x00D495B0]+0×2218.  See this thread on how I access the object manager in my application.  Basically, if you are content with your tool only working for the current version of the client and you don’t mind having to manually update for new client versions, just read from memory like so:

• Define a DWORD variable named g_clientConnection and read from 0x00D495B0 into it.
• Define another DWORD variable named s_curMgr and read from ( g_clientConnection + 0×2218 ) into it.
• s_curMgr is now your pointer to the object manager.

Now that we have our object manager, we can start reading objects from the linked-list.  I now turn you over to Kynox’s WoW Object Dumper so you can peruse its source, which I will also outline in just a second.

Once you have your object manager pointer, you can read from ( s_curMgr + 0xC0 ) and gain your localGUID (it’s an int64, not a DWORD).  Save this so you can compare it to the GUIDs in the linked-list and determine which is your own (useful for teleportation hacks, setting your facing direction by writing to memory, etc.).

Read from ( s_curMgr + 0xAC ) for a pointer to the start of the linked-list.  Each object in the linked-list contains a pointer to the next object, so we’re going to need two DWORD variables here: curObj and nextObj. We’ll loop through the list, reading information from curObj, including a pointer to nextObj, determine if nextObj is valid, and then setting our current object (curObj) to the next one in the list (nextObj) and doing it all over again, only stopping when nextObj is null.  This is all a part of Kynox’s WoW Object Dumper, but I will show you my C# source for the same exact thing here.  You can find the Memory library in use in that example here.

This allows you access to the positional data on all of the loaded objects.  This is as far as I have currently gotten, but I will be pushing on very, very soon.  Stay tuned.

Read my next post in this journal here.

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.

In the next few posts, I will try to recount the steps I have already taken towards the goal so that you will have a good starting point.  I hope the journey for all involved is a learning experience.

Read my next post in this journal here.