How to Work Around Anti-Debugging

[SuperKiwi98]

Hi all,

To start, I'm fully acknowledging I am way in over my head here going through hundreds of posts trying to get even the slightest direction towards memory editing with games in general. I am very new to this and am really just struggling to find good guidance.

I'm stuck trying to attaching a debugger to to WoW at the moment, and was wondering if anyone could point me towards an answer to prevent WoW from crashing on me when I attach the debugger.

If anyone else has any other good tips or resources that can guide me in finding out more information I would greatly appreciate it.


(Using CrySearch for tracing pointers in memory)

[Jadd]

WoW has a lot of methods for detecting debuggers as well as detecting attempts to remove those measures. If you are very new and 'way in over your head' then you should probably start with a different game.

[ynyzyfy]

A lot of debuggers check functions (All are confused.Like DbgBreakPoint byte check) are called in every frame.If you are debugging for a long time, the program will also crash.

[Azarchius]

This has been asked many times, but I'd like to add another plea to the pile for someone to perhaps answer this problem. My skills aren't good enough to figure out Blizzard's anti-debugging measures, and I at least personally don't care about Warden as I operate a humble RP and modding-centric private server, and I'm trying to break past the limit imposed by Blizzard on the number of item appearances. My only concern is being able to add a breakpoint to WoW and stop it during a certain function so that I can analyze what it does and how best to modify it to achieve my goals. No matter how many subroutines and variables and offsets I document, I cannot glean enough information about the function to be able to determine what to change without doing any runtime analysis. Maybe I'm just not smart enough.

I really need to be able to inspect the variables in functions like DressUpModel::TryOn or PlayerModel::SetItemAppearance in order to be able to make the changes I'm looking to make. I cannot make heads or tails of how to change the way they determine the displayid of an item, and the latest binary with debugging symbols is 15662, before ItemAppearances became a thing.

OverwatchDumpFix appears to indeed correct the changes Blizzard did to ntdll's DbgBreakPoint, but it does not appear to be enough for World of Warcraft, as WoW throws a couple of exceptions after resuming post-attach and then crashes (an interrupt located in nvwgf2umx.dll, followed by an illegal instruction in the main wow module). I understand that this is a competitive environment where people are constantly trying to keep ahead of Blizzard, I wouldn't dream of asking for something for BFA, but if anyone perhaps has an old patcher for 7.3.5 to break anti-debugging protection, I would be indebted.

[Icesythe7]

Step 1: Use something like HXD to find/replace all string containing "cheat engine" in cheat engine
Step 2: Use some dll injector and inject the "vehdebug-x86_64" dll in your cheat engine folder into wow
Step 3: Open CE and change the debug options to use veh debugger
Step 4: attach to wow and enjoy debugging

[Azarchius]

Step 1: Use something like HXD to find/replace all string containing "cheat engine" in cheat engine
Step 2: Use some dll injector and inject the "vehdebug-x86_64" dll in your cheat engine folder into wow
Step 3: Open CE and change the debug options to use veh debugger
Step 4: attach to wow and enjoy debugging

Thank you so much for the reply! Other than my futile attempts to use ScyllaHide, OverwatchDumpFix and xdbg plugins to bypass Blizzard protection with x64dbg, on CheatEngine I've tried using VEH and replacing all occurrences of 'cheat engine' with 'cheat engime' and 'Cheat Engine' with 'Cheat Engime' inside cheatengine-x86_64.exe, as well as injecting vehdebug-x86_64.dll into the process and setting VEH Debugger. I've also tried using hardware, int3, and page exceptions as breakpoint methods. I also tried just replacing 'cheat engine' and just replacing 'Cheat Engine' individually. In all cases however, the debugger attach times out. Do you perhaps know why?

[zys924]

Thank you so much for the reply! Other than my futile attempts to use ScyllaHide, OverwatchDumpFix and xdbg plugins to bypass Blizzard protection with x64dbg, on CheatEngine I've tried using VEH and replacing all occurrences of 'cheat engine' with 'cheat engime' and 'Cheat Engine' with 'Cheat Engime' inside cheatengine-x86_64.exe, as well as injecting vehdebug-x86_64.dll into the process and setting VEH Debugger. I've also tried using hardware, int3, and page exceptions as breakpoint methods. I also tried just replacing 'cheat engine' and just replacing 'Cheat Engine' individually. In all cases however, the debugger attach times out. Do you perhaps know why?

VEH debugging definitely requires memory write but WoW process is by default locked out for any user mode memory write (unless you do the region unmap tricks). So your "timeout" is definitely normal while I highly doubt this method would ever work. You should only resort to DBVM.

[Icesythe7]

VEH debugging definitely requires memory write but WoW process is by default locked out for any user mode memory write (unless you do the region unmap tricks). So your "timeout" is definitely normal while I highly doubt this method would ever work. You should only resort to DBVM.

obviously u need to remap memory first and it works fine been using it for awhile now

[Azarchius]

obviously u need to remap memory first and it works fine been using it for awhile now

Could you possibly explain what you mean by remapping memory?

[aeo]

Could you possibly explain what you mean by remapping memory?

Force-Page-Protection/memory.cpp at master . changeofpace/Force-Page-Protection . GitHub

[Azarchius]

Force-Page-Protection/memory.cpp at master . changeofpace/Force-Page-Protection . GitHub

I've found some time to read about this matter. Just to be sure, we are talking about a technique that involves unmapping the executable image and rewriting its contents in memory, that is to say, process hollowing? (http://www.autosectools.com/process-hollowing.pdf) Is this because the client checks the source image to make sure the process has not been tampered with? I'm trying to research what you're referring to--I'm being told of a 'trick' but I don't know what that 'trick' aims to do so I have no idea what I'm searching for. I'm under the impression that this particular x64dbg plugin was sourced as an example function rather than the tool to use, since I understand x64dbg to be unable to perform any kind of non-intrusive attachment, so using this plugin would surely cause a crash. Or am I wrong? Either way, I have no idea what 'region unmap trick' entails.

However, the example given of 'remapping memory' in that particular repo appears to be the removal of page protection (taking a section, copying it without protection, and then supplanting the original section). Is this the goal, the removal of page protection will allow VEHDebugging to work? Am I overthinking it, and this is something achievable with a common tool like Process Hacker or Cheat Engine itself? I've found it's indeed possible for Process Hacker, but I've no idea what I'm supposed to make writable.

It's also worth mentioning that, regarding DBVM, when used, World of Warcraft crashes upon entering the game world. It appears attaching with DBVM works fine--seemingly, so long as I haven't entered a character. Upon entering a character, though, the game closes, and even after closing Cheat Engine the game continues to terminate on login until a system reboot or 'Kernelmodeunloader' is run. This seems clearly to me an issue with Cheat Engine being detected--to no surprise, as while running DBVM it is impossible to modify the CE binary or DBVM will refuse to run.

Regardless: For VEHDebugger's case, WoW exits within a second or two. For DBVM's case, WoW exits once the game world loads.

Edit: I have successfully attached VEHDebugger. No matter what contents within the exe I change, the results are the same (no changes at all, or just 'Cheat Engine 6.8.3' -> 'Cheat Engime 6.8.3', all 'Cheat Engine', all 'cheat engine', or even all of them (Cheat engine, cheat Engime, cheatengine, CheatEngine, etcetera). It appears the crash is avoidable by unticking 'Override existing breakpoints when setting breakpoints'. It appears, moreover, that setting a breakpoint causes the game to immediately terminate--which brings us back, I think, to remapping? Page breakpoints don't work at all, int3 and hardware bps cause wow to terminate. The only place where page breakpoints work appear to be on... actual int3 calls (eg setting the breakpoint on wow+18295E)

Alternatively, I might be on a wild goose change and this whole thing is because I am not editing the CE binary correctly, as indeed the step at this point seems seems to have no effect. What string match, precisely, am I supposed to change, or is this step indeed superfluous...? Since *just* 'cheat engine' -> 'cheat engime' has no effect, or any other combination.

Note for others: It appears VEHDebugger does some one-time work when the dll is injected. VEHDebugger should only be injected once in the game world, for the same reasons why the dump for static analysis requires it.

[Azarchius]

After continued analysis, I believe I understand the issue. Region remap is required for page breakpoints (so set your CE to use them under Debugging settings). It is not normally possible to set page breakpoints in that region because it is a mapped memory region to the disk, so it is read or execute only. Using the classes found at the above github to cut corners (memory & ntapi--thanks changeofpace!), I've added to my injector the task of suspending all threads, remapping region matching size 23068672 (7.3.5) to protection 0x40 (page rwx), and then resuming them. This will allow you to use Cheat Engine to debug Legion 7.3.5 with VEHDebugging.

However, there's a different matter. When a breakpoint is reached, I am met with a critical error--that the instruction at 0x0 referenced memory 0x0, and that the memory could not be executed. Using CE's "Find out what addresses this instruction accesses", I'm able to glean some information, until after anywhere between a couple to a few dozen accesses, I'm met once more with a critical error. I'm quite confused, in fact, as to how I'm getting a critical error in the middle of debugging? Is Cheat Engine simply... not suspending the other threads too...? In that case it wouldn't be much of a surprise that the game crashes.

I see some of what's going on. https://i.imgur.com/vJd1YO9.png

It seems that upon setting the breakpoint, the region is split into three? The edited page--the one with the breakpoint--is smack right there in the middle at 4kb. That seems strange to me, but the problem is I don't know what the expected behaviour is. Certainly, on removal of the breakpoint, the region is put back together, so it doesn't seem like some sort of bug, perhaps that's just how CE wants to do it. I'm fumbling in the dark here.

[Azarchius]

I have managed to successfully debug WoW using VEHDebugger. These are the steps you need to take if you wish to also do so:

1. Download Cheat Engine
2. Enable VEHDebugger and set breakpoints to Page debugging, untick 'Override existing breakpoints when setting breakpoints'
3. Launch World of Warcraft
4. Pause all threads.
5. Run an external program or in my case since I have a launcher that injects a number already, inject a DLL that finds the Mapped: Commit memory region that's set to R+X. The way I'm doing it right now is by searching for a region matching a specific size--to find the region for the first time however (so that you can tell what size it is), find a WoW Lua function such as TryOn or SetItemAppearance, and check what region it's in. It is usually a very large one, almost the size of the wow exe (23mb in my case)--it contains much of the WoW program code, including its PE header. If you want, you can use the ntapi and memory classes and make use of RemapViewOfSection found in the above linked GitHub (thanks again changeofpace) and set the page protection to 0x40, which is RWX.
6. Resume all threads.
7. Enter the game world.
8. Inject VEH Debugger dll found in Cheat Engine's main directory.
9. 'Open' the WoW exe using Cheat Engine.
10. Attach Debugger.
11. Optional: Run analysis to run between IDA and CE less.

Worth noting that with page breakpoints it appears stepping is impossible, you must toggle breakpoints for every place you wish to 'step'. Happy debugging.

On critical errors: It appears that Cheat Engine DOES NOT pause all running threads. As you're debugging the main wow code, it is normally fine because the entire game creaks to a halt by doing so. However, my hypothesis is that the critical errors occur when **more than one external thread** is involved in the breakpoint (eg data retrieval from db2s). So for example, if you set a breakpoint on item info retrieval, throwing your mouse very fast and letting it touch more than one item before the program breaks will cause a critical error. This means that to avoid critical errors, you must be careful and be in full control of when the breakpoints may be reached. I'm thinking perhaps the crashes have something to do with Cheat Engine making the new region where the breakpoint is located with protection RW instead of RWX like the region it splits. As I have little experience in this matter, I am not sure of the meaning of this decision by Cheat Engine.

On debugging with a real debugger: By looking at debug events, you can quickly glean exactly where and how Blizzard's annoying INT3s are located and where they head off to, this makes it much more straightforward to patch their annoying anti-debugging measures, which I will look into once I am not so busy.

On breakpoint types: I have had mixed results between page debugging and INT3. They both work, and INT3 will allow you to step. However, I've noticed more crashes with INT3, and it's also worth noting that trying to step into a call most of the time in my experience so far causes a critical error.

[Azarchius]

I received a few PMs asking for source code on how to change page protection--I completely sympathize that it's outside the comfort zone of many programmers that aren't familiar with reverse engineering, like myself, but can't spare the time to read up on how to perform this operation. Instead of sending people it directly, I'll just post the relevant excerpts publicly here. I can't give the actual fully compilable solution as it contains many other things. I've copied and strapped together the relevant code segments.

	STARTUPINFO si;
	PROCESS_INFORMATION pi;

	CreateProcess(_T(".\\EpsilonWoW"), _T("EpsilonWoW -console"), NULL, NULL, false, CREATE_SUSPENDED, NULL, NULL, &si, &pi);

	if (!pi.hProcess)
		return EXIT_FAILURE;

	// remap base image
	bool remapped = false;
	while (!remapped)
	{
		MEMORY_BASIC_INFORMATION mbi;
		unsigned char* p = NULL;

		std::vector<char> old_tail = {};
		for (p = NULL; VirtualQueryEx(pi.hProcess, p, &mbi, sizeof(mbi)) == sizeof(mbi); p += mbi.RegionSize)
		{
			if (mbi.State == MEM_COMMIT && mbi.Type == MEM_MAPPED)
			{
				if (mbi.RegionSize == 23068672) // 7.3.5.26972
				{
					Remap(pi.hProcess, mbi.BaseAddress, mbi.RegionSize, 0x40);
					remapped = true;
					break;
				}
			}
		}
	}

	ResumeThread(pi.hThread);
	CloseHandle(pi.hProcess);
	CloseHandle(pi.hThread);

Here's the remap function. Again, taken from changeofpace's above repository and only slightly modified, and using his memory & ntapi classes.

bool Remap(HANDLE hProcess,
	PVOID regionBase,
	SIZE_T regionSize,
	DWORD newProtection)
{

	DWORD oldProtection = 0;
	if (!VirtualProtectEx(hProcess, PVOID(regionBase), regionSize, newProtection, &oldProtection))
	{
		char buf[100];
		if (!memory::RegionIsMappedView(hProcess, PVOID(regionBase), regionSize))
		{
			sprintf_s(buf, "Error: %p must be in a memory mapped view.", regionBase);
			MessageBoxA(NULL, buf, "Error", MB_ICONERROR);
			return false;
		}

		if (!memory::ViewHasProtectedProtection(hProcess, PVOID(regionBase), regionSize, newProtection))
		{
			sprintf_s(buf, "Error: Unhandled protection scenario.");
			MessageBoxA(NULL, buf, "Error", MB_ICONERROR);
			return false;
		}

		if (!memory::RemapViewOfSection(hProcess, PVOID(regionBase), regionSize, newProtection))
		{
			sprintf_s(buf, "Error: failed to remap the view at %p.", regionBase);
			MessageBoxA(NULL, buf, "Error", MB_ICONERROR);
			return false;
		}
	}
}

Please be advised--I have no idea if this is detected by Warden. I am my own server's owner. Use this solution outside of sandboxes at your own risk.

[doityourself]

Some info about remapping:
- It WILL crash your Wow unless you hook some functions or patch out these crashes.
- IT IS detected (espescially together with patched out crashes) on retail. DO NOT use it there for any of your tools in the future.
- You can remap whenever you want. Doesn't have to be with a suspended startup. Also no need to check region sizes etc. Just remap at the base address.
- After remapping you will face the CRC checks that WILL crash your client too :P