[General Question][C#] WinAPI Hooking / Mouse Simulation

[DrakeFish]

Hi there. I've searched and read on MSDN, CodeProject, Google for a few hours but couldn't find much talking about this, or explaining the basis of it. I want to simulate mouse clicks to WoW (or any other program; but I'm currently targeting WoW) and after doing a couple of tests, I found that WoW will still use the current mouse position even when receiving specific Mouse/Cursor WindowsMessages. It will do a GetCursorPos() WinAPI call whenever it receives a Mouse message. That's why in my tests, I could send a mouse click, but only at the real mouse position and not at a specified one.

tl;dr: WoW doesn't use the position value specified in the WM, it will call the GetCursorPos() function to get it.

As I don't want my "bot" to use the global mouse - which would make user unable to do something else on their computer while it is active - I've been searching a way to create either a second mouse using a Driver (or anything else for it) or hook the WinAPI to modify the values that are returned to WoW when it calls the GetCursorPos() function. I know that WinAPI hooking requires injection (unless there's something I didn't read about), and I don't mind about using it.

I've seen a couple of posts that were confirming that using 2 mouses (with 2 different cursors) on the same computer was possible; and this is what makes me think that simulating a second mouse could be a good idea.

Did anyone try something like this before? I'm requesting any link/info that could be useful in my project.

P.S: I'm mainly using C#, but I'm ready to use C++ for the DLL if needed.

[JuJuBoSc]

You are going to need a kernel hook if you don't want to modify anything inside Wow.exe.

[DrakeFish]

You are going to need a kernel hook if you don't want to modify anything inside Wow.exe.

Thanks for the reply. I searched for Kernel Hooking and found one "tutorial" about it. I'm wondering if you have any additional link/post/info about it so I can start reading about it. Thanks.

Edit: So far, I found this thread that included a reference to another one: Windows NT System-Call Hooking
I also found http://www.codeproject.com/KB/system...t_hooking.aspx , but I'm not sure if this is what I'm looking for.
Is that System-Call hooking guide what I'm looking for? Has the method changed since those infos were written?

[jjaa]

I've never done kernel hooks. However i'm pretty sure that you would need to make a Driver. I highly doubt that WinApi hooking in WoW.exe would ever be scanned. Well if its public they may scan for a specific hook, but not a general one. Isn't there legitimate reason to hook those anyway? multiboxing ect.

EDIT: RootKit books would prob be a good source for that stuff

[Cypher]

Don't even bother trying to do a kernel-mode hook imo. Unless it's just for your own personal use an you ONLY use x86 builds of Windows.

Under x64 builds of Windows the kernel is protected by driver signing requirements, and Kernel Patch Protection (aka PatchGuard). The former restriction can be bypassed by self-signing the driver and booting into test mode, however that's obviously only appropriate if the driver is for your own personal use. The latter restriction can be bypassed too, however unless you're a kernel expert you're unlikely to get very far. Yes, there's currently public code out there to bypass the current version of PatchGuard (v3??), but what happens when Microsoft update it? You're ****ed.

Btw, before anyone says that you can just buy a cert for your driver.... You can't in this case. The only reason you'd buy a cert is if you wanted to make your driver public, and Microsoft will have certificates revoked if they're used in a driver which violates KPP.

Just do it in usermode, and add some basic protection. Unless you're doing this for a public bot, you have nothing to worry about.

If you ARE doing this for a public bot, you have two choices:
1. Compromise your security
2. Develop some kind of Tripwire system (though, as history shows, they're never perfect)

EDIT:

Just re-read your post and noticed what you said about "creating a second mouse". I've not looked into that, my post was referring to hooking the cursor APIs in kernelmode like Glider did. Not sure whether or not spoofing an input device from the kernel is a viable alternative... You may want to look into that further.

[DrakeFish]

Thanks Cypher for the reply. As I were waiting for a reply, I worked on a simple detour to the GetCursorPos() function. I'm wondering if this is safe though. I know that for a public bot it would require to setup a TripWire, like you said. But for a private application is it something that is already watched and that would get me flagged as soon as used? Do Blizzard watch the WinAPI for detours?

[Cypher]

No, API hooking in a private bot/hack won't get you 'flagged'.

Think about the amount of software that are known to 'legitimately' (where 'legitimately' means for uses other than for cheating at the game) use API hooks in some form or another:
* AV software
* Ad blockers
* Video recorders
* Malware
* Binary analysis tools
* Debuggers
* In-game overlays

There's more, that's just a few examples.

At any rate, even if you were to 'flag' people for API hooking, you couldn't ban for it, you could only really kick for it (unless you hash the hook stub and detect a known cheating hook -- i.e. what Warden does currently). PB for example kicks if you hook certain APIs, however you will NOT be banned for this. It's simply a warning. Warden is nowhere near as aggressive as PB though, so you realistically don't even need to worry about that.

Tl;dr: You're safe as long as you're private. Go nuts. They can't ban you simply for hooking an API, as you could be doing something totally legitimate.

EDIT:

To clarify...

Warden DOES have the ability to detect API hooks, however it's implemented by hashing your detour, so if you're private you're safe. If you're paranoid though you could even use VEH to hook the API. Just dump an INT3 at the top of the function and use VEH to do the control-flow redirection. That way Warden can't resolve the address of your detour.

[jjaa]

BattleNet.dll (the one used in the login process) does have anti hw breakpoint protection. afaik it tries to register its own handler above yours and checks the state of the debug registers. All of which can be countered. Honestly, if its a private hack. Hooking the warden tick and scan data functions, and removing and reapplying is probably all the protection you will ever need (its what i do).

[Cypher]

The HWBP protection in BNet exists solely to protect BNet, if you apply your HWBPs after the login process (or just remove them during the login process) you won't have any problems. Alternatively, you could bypass it, but that's unnecessary in 99% of cases.

But that wasn't what I was talking about anyway. I was talking about using an INT3, an invalid instruction, etc to trigger an exception which can be caught using VEH. e.g. Lets say this is the start of the function user32!GetCursorPos:
push ebp
mov ebp, esp

The typical way to hook would be to replace the start of the function with:
JMP 0xDEADBEEF

Where 0xDEADBEEF is your (relative) address.

I'm talking about replacing the start of the function with something like this:
INT 3

That will trigger an exception which can be caught using VEH/VCH. There's no limit to the amount of functions you can do this on, so as long as you don't mind modifying the target's code (which in this case is not an issue because we're hooking the Win32 API, not WoW itself) it's a much better alternative than HWBPs.

Of course, you don't need to use an INT3, that just happens to be the interrupt for a 'breakpoint', which is easy because it's a single-byte instruction (0xCC) and it's very easy to catch in your VEH.

You can use an invalid instruction if you want, or cause an access violation, or attempt to do something else that will raise an exception. Doesn't really matter. All that matters is that you raise an exception somehow so you can redirect control flow from your VEH.