Facing value... client-controlled!

[draco1219]

Warden can't really work off a module "whitelist" (a list of known-valid modules); it works off of a module "blacklist" (a list of known-invalid modules). The reason is that there are MANY types of software that inject modules into other processes, through many different methods (during process create, injection via CreateThread, Windows hooks, AppCompat stuff, and more). The vast, vast majority of these modules in any given process are benign (if annoying), and if Warden triggered off of every "non-WoW module," just about everyone in the world would get insta-banned. Thus, it's simply not-practical to look for "unknown" modules; instead, Warden can only (and, in fact, DOES -- according to the folks here who know Warden better than me ) look for "known bad" (ie, bot/hack) modules.

As for looking for behavioral capabilities (as your "Create Thread" question implies), this type of heuristic scanning is beyond Warden; indeed, it's beyond most antivirus software (which is far, far more effective at detecting malware than Warden). You can restrict ACL's to prevent certain things like process debugging, but this can be overcome simply by running your injector as admin. And there's nothing inherently suspicious or "bot-like" about running a process as admin; indeed, many processes on any given machine already ARE running this way.

So the Warden guy (gal?) is in a pickle; you can't really search for anything except "known good" modules/threads/code, because in a normally-operating system, this type of whitelist scan will quickly overload you with false positives (for fun, load notepad.exe and debug it; look at the 50-100 DLL's loaded into notepad.exe and find out how many of those are linked by the import table vs. how many are dynamically injected at runtime by other system components; MOST software running in any given process is NOT explicitly loaded by that process!). All that's left is to scan for "known bad" modules -- so please, don't name your library "Glider.dll" -- "known bad" code signatures, and blocks of code that must never change (the monitored blocks of code in the other thread). In short, Warden only looks for "red flags;" it's not an artificial intelligence, and it's not a beat cop who's sniffing out crime. It's just a relatively sophisticated, dynamically-updatable pattern matching library. As long as you don't touch the handful of known code blocks and you take care to compile all your own code (thus not matching any known signatures), the odds of you EVER getting caught are incredibly slim. About the only other thing that will get you reliably banned is packet hacking stuff (move/speed/wall hacks, etc.) And any bot writer worth his/her salt shouldn't need hacks or exploits to write a world-class bot.

amadmonk,

I appreciate you taking the time to respond to this. Your response was very helpful. I did not fully understand the limitations of warden and what it can and cannot detect.

I hate to hijack a thread, but a lot of my learning started with code I got years ago from a bot called WoWSharp. The author released his code after stopping development. I am trying to re-create the functionality for the DLL in C# and up until now I was trying to mostly stay out of process.

As I mentioned earlier, the functionality I am trying to do in process is LeftClick, RightClick, CastSpellByID, and Movement.

The code from WoWSharp did this in process by hooking the RenderWorld/EndScene.

My question is, if I were to port this logic, is the logic the same? This was done when WoW was at version 2.0X I believe.

1) For LeftClick and RightClick there were functions called directly which you passed the GUID of the object you wanted to click.
These used to be: CGGameUI__RightClick and CGGameUI__LeftClick (Is this still the preferred method?)
2) For CastSpellById, there was/is? a function called Spell_C_CastSpellByID. Based on your email I supposed the best way to do this now is through LUA script?
3) Lastly, I do not believe WoWSharp used CTM. Rather it used a function such as:
CGInputControl__SetControlBit
CGInputControl__GetActive

Which set the movement bit for a set number of time.

For movement, is it still possible to set movement using SetControlBit?

Lastly, in order to call the functions mentioned above, do you "have to" detour the EndScene hook in order to do it, or can you call the methods directly?

Thank you again!