Exploiting Warden Behaviour to Create Hacks

Warden is an anti-cheat system present in World of Warcraft. Whilst trying to figure out how it worked, I found a way to take advantage of Warden to actually help me easily create hacks that I would otherwise have had a much harder time with.

In a nutshell, the concept is:

1. Find a memory address which we can get ourselves banned with.
2. Locate the Warden scanner using our new memory address.
3. Hook and dump the parameters of the scanner.
4. Reverse engineer the code pointed to by the addresses we find - Other cheats use them for a reason.
5. Make our own cheats based around those addresses whilst avoiding the scanned locations.

A Bit About Warden

Warden is effectively a memory scanner that exists in a game process and is present in World of Warcraft. The purpose of Warden is to ensure that the game client is free of modifications and that the game process has not been altered by any (cheating) software.

One of the most useful features of Warden in my opinion is that it provides an interface accessible to the game server through which it can request information about game memory. For example, the game server could ask Warden to tell it what the byte at 0xDEADBEEF contains and Warden will send that information back. The game server can then determine whether or not this is valid; if the game server determines that the byte(s) at the requested address are known to be malicious, then the game server will issue a ban to the player.

Warden also provides other functionality (such as detecting known malicious DLLs) but this is not relevant here and it's quite easy to find information about it online.

Idea

If the game server sends requests to the client to retrieve data from certain memory addresses, then surely the memory addresses it asks for have something special about them? If we can figure out what code actually does the scanning, we can also find a way to dump the addresses it looks at and therefore find out where all the interesting code is.

Cheats can be quite hard to make. Something like a noclip hack can be hard because it involves learning about the physics engine and such. You'd have to figure out the exact code that determines whether or not the collision took place and it will be hard to debug. Other reverse engineers have managed it though. Other people have managed to find out exactly what code would cause the noclip effect when modified. Lots of public cheating tools exist which make use of this knowledge and modify collision checks so that you can run through walls and such. As a result, Warden is configured to detect those exact modifications and it will try to scan the important addresses. Let's just steal those useful addresses from the Warden scanner and use them to make our own cheats!

1 - Locating the Warden Scanner

The first thing we need to do is identify the code Warden uses to scan memory. The most obvious way to do this would be to reverse engineer the Warden DLL, but obtaining access to it via dumping and then pulling it apart in IDA or something would take a lot of time. I figured out that the simplest way to find scanning functionality would be to first find something that Warden would want to scan for, then do some debugging and locate whatever code attempts to scan it.

What would Warden want to scan, though? Well, any variable which modifies someting game-breaking such as the global gravity or player jump height would be of interest to an anti-cheat system like this. It's relatively hard to find these values though without much knowledge of the client.

The thing I chose to use for this was the Lua protection that's built into the client. WoW uses Lua internally and exposes an API for developers to make custom interfaces and such. Lots of functions such as MoveForwardStart() or InteractUnit() tend to be blocked and only available to Blizzard scripts due to a protection in the game client. There is a check that happens in the client at address 0x494a57 which cheating software and bots tend to like to remove. After some testing, I confirmed that modifying this address will trigger a ban.

I decided to use Cheat Engine for this but any tool with similar functionality will work - Be careful though because WoW can detect debugging and will ban you for it.

For this example I'm going to stick with the Lua protection address, but any address that Warden is interested in will work. Open up the Memory View (bottom left corner), make sure that the hex view is focused, and then press Ctrl + G to go to address 494a57:

The hex view at the bottom is now pointed at the code that performs the Lua protection check. The top-left byte code here is 0x494a57 which is what we're interested in. We are going to add a memory breakpoint with Cheat Engine so that anything that accesses this code will trigger it. Remember, 0x494a57 is located within executable memory and it won't be getting accessed by anything that isn't a scanner. This is better than if it was a variable such as jump height because such variables would be getting accessed by more than just warden - We don't have to worry about that here.

Right click on 0x494a57 and add a Data Access breakpoint.

After adding this breakpoint, you should see it trigger soon (whenever the game server decides to ask Warden to scan something). In my experience this can take between a couple seconds and a minute.

The breakpoint was hit! Cheat Engine shows that instruction 0x6a5142d has accessed our 0x494a57 address which we marked just now. This repe movsb instruction is responsible for copying the bytes from the memory addresses requested from the server. We have identified the scanner! Note how on the right, the ESI register is 0x494a58 - This is going to be important later because it contains the address that is being scanned.

2 - Finding the Scanner Signature

Finding the Warden scanner is quite easy but it would be really tedious to do this every time. Fortunately, the first step was only necessary when you're trying to identify the scanner. Once the scanner is identified, you can create a signature of the function and scan for that next time.

Right click the repe movsb instruction you found in the last step and choose “select function”. This will help to show us the entire function so that we can create a signature:

For reasons that will be come apparent later, I want the signature to start at address 0x6a5142d. This isn't necessary but it makes things simpler and quicker to do in the next step. I found that the 5 bytes f3 a4 5f 5e c3 are unique within game memory and scanning for those bytes at any one point in time will always locate the Warden code. Warning: Warden is only loaded upon login so these bytes won't be found beforehand!

3 - Automatically Find the Scanner

Cheat Engine exposes a Lua engine so that this process can be automated. From the Memory View, you can press Ctrl + L to bring up the Lua engine.

Through the use of a simple script, we can easily scan for our function signature and find the repe movsb instruction with the click of a button:

4 - The Fun Part

Now that we've got a reliable way to find the scanning code every time we run the game, we can use it to dump all of the addresses it scans.

There are a few different ways to do this. One way to do it would be to use a ‘trampoline hook’ and overwrite the Warden code to jump to our own code cave which dumps the ESI register somehow and then jumps back as if nothing happened. I found that you can do the same thing with a debugger though, and this version of WoW doesn't detect Cheat Engine's debugger so there's no reason to complicate things. Adding a breakpoint on the repe movsb instruction works good but it's annoying to have to step through all of the different calls, so we'll automate that.

We can expand on the script we made earlier to add a breakpoint to the address of repe movsb. This is why I made the signature begin at the instruction of interest - We can just directly set a breakpoint to it rather than messing with adding offsets to it or something:

The addresses in the output of this script point directly to pieces of memory that Warden doesn't want you to mess with which may be variables or pieces of code. This is valuable information because you can now jump to these addresses and mess with the relevant code to create your own hacks - Warden has told you where the code of interest is!

Bypassing Detection

After following along with the previous sections, you now have a list of fun memory addresses that other cheat developers have been messing with. You can't just begin using these addresses, though; you'll get banned. The reason that you have these addresses is because Warden already knows about them. Using these addresses to cheat with is guaranteed to get you banned.

The main use of these addresses is to point you directly to code of interest so that you can modify that code too, but in a different way that Warden doesn't know about.

Let's say you visit a memory address 0xDEADBEEF which you've gathered from your list of scans. If you see that the instruction at 0xDEADBEEF is test eax, eax, you can be confident that the conditional here (or one very closeby) does something interesting that Warden doesn't want you to mess with. In this particular example, Warden wants to verify that the code at this address contains test eax, eax. Maybe Warden knows of an existing cheat which will replace it with something else and cause the function to behave differently?

Let's go back to looking at the Lua protection code from earlier because that may be something you're now familiar with. We know that Warden is scanning at this particular address because some other cheat was found to be modifying the bytes there to unlock Lua. If we look at the code at around 0x494a57, we can determine that this instruction falls at the beginning of a function. It is placed right after a test eax, eax and the result of this comparison will determine whether or not execution will be blocked. All we have to do to bypass Warden's scan is to manipulate the result without touching the code that's scanned. In this particular case, replacing the test eax, eax with an xor eax, eax will stop the Lua protection from happening when we invoke things. I don't really know why Warden isn't scanning this memory address because it seems like the easiest one to modify but the important thing is that it doesn't show up in a scanner.

Note: You can double check if an instruction is scanned the same way as we did to find the Warden scanner - I advise that you do this first before you wind up banned for modifying something you didn't know was scanned.

To demonstrate this better, I made a short YouTube video where the above should become clear:

The technique used in the video will apply to all of the addresses you just dumped too, but I won't detail the necessary asm modifications because otherwise there will be servers full of cheaters… It's really simple to do though.

Caveats

The main downside to this technique is that you most likely have no idea what you are modifying when you do so unless you do a little bit of reversing around the function in question. This results in some trial and error with the things you mess with - Did your modification change something obvious, or do you have to wait until your character is supposed to be damaged before it will become clear? Of course you can clarify this a little by doing something like hooking the containing function of this instruction. If the function is called at fixed rate like 60 times per second and seems to be independent of framerate, this could very well be a physics calculation for example.