Facing value... client-controlled!

[bad6oy30]

I've been running into problems where the unit field-value for facing (UNIT_FIELD_R = 0x8A8 for 4.0.3) has sometimes returned strange results. Here's what I've found, and it's kinda crazy:

If I approach a mob from behind (facing the same direction as them), and start attacking without them reacting to me first, their R-value is the same as mine. However, when the stun wears off, and they face me, they still have the same R-value as before. If I kill them, they appear to be facing me, but their R-value still says facing away (unchanged).

Crazy part: I log out, log back in, the corpse has rotated 180 degrees, graphically representing what their R-value said all along... facing away from me.

Now during the fight, the R-value saying facing away, if I do a move that's "facing dependent", like Gouge (they must be facing me), gouge succeeds, and their R-value instantly updates to reflect their graphical appearance.

It appears my client, depending on if I do a facing-dependent move or not, changes the server-side facing value of the mob. It's like a quantum effect... it doesn't change values unless you do something that tests it.

So, all that said, does anyone know of a different facing field-value for units? One that represents what the client thinks, and not what the server thinks?

[caytchen]

Did you think of the kind of obvious GetFacing virtual function?

[bad6oy30]

I'm out-of-process... I'm aware of that function, so I was ready for a snotty reply regarding it. Honest to God, I was expecting it, so thanks for that

Anyhoo, for anyone who wants it, the client-side facing field is at 0xB70

[caytchen]

So reverse it? When is this "I'm out-of-process" bullshit going to stop, its been shown to not provide any real extra security and is at best barely practicable for anything that requires you to do something beyond reading memory. Its no excuse for not using IDA and actually reverse-engineering the game, either.

[bad6oy30]

"Even if you're out of process, you could still debug the function to find the field"... yeah, I knew you'd say that too. So predictable, I had this all typed out and ready to send the instant I saw your response. How 'bout that?

s'ok, I think you're wicked smaaaht.

---------- Post added at 09:15 PM ---------- Previous post was at 09:13 PM ----------

Oh post timestamps called it lol!

Anyhoo how you think I found the address? Wicked smaaht.

[Megamike55]

So... Let's get this straight. You posted a question, knowing full well Exactly what the reply would be from the contributors / users of this forum, just so that you could give them an in-your-face inflammatory and rude reply within a few seconds of their post.


Just stop using this forum if you are so "smaaht"

[bad6oy30]

That's not accurate... I have positive expectations from the contributors of this forum, otherwise I wouldn't post. Out of those positive contributions, I expected a rude reply. I'm sorry if you're reading more into it... I'm simply responding to a rude poster, nothing more.

[psyf4]

1) Repost ( http://www.mmowned.com/forums/world-...-oddities.html ).
2) They are right. What else do you expect? What is an acceptable comment? Clearly the offset isn't what you want to look at since it only gets updated following an action. While I find that to be interesting because fellow players also need to get their facing values updated when tanks switch, I'm surprised their R value may not be right (good to know?).
3) If you have the client-side facing offset, what are you asking for?

I'm not trying to make a snyde comment, but to avoid troll wars why not includ expected answers in your initial post so as to point out you aren't looking for them?

[suicidity]

Look like OP posted an observation, replied to a comment attempting to derail OP's intentions in a cocky way, then provided how to retrieve proper information out of process.

Pretty standard to me.

[draco1219]

So reverse it? When is this "I'm out-of-process" bullshit going to stop, its been shown to not provide any real extra security and is at best barely practicable for anything that requires you to do something beyond reading memory. Its no excuse for not using IDA and actually reverse-engineering the game, either.

Is the statement really true about being out of process and only doing reads on the memory not much more safe than being in process and writing to memory and hooking functions?

I ask because I'm going through all hoops and barrels to get movement working correctly and targeting. Tab targeting is a nightmare right now and I'm still struggling to get it to work correct.

[Evieh]

Is the statement really true about being out of process and only doing reads on the memory not much more safe than being in process and writing to memory and hooking functions?

I ask because I'm going through all hoops and barrels to get movement working correctly and targeting. Tab targeting is a nightmare right now and I'm still struggling to get it to work correct.

If your bot is private being in process will make your life alot easier, I myself have always been in process and never gotten any suspension/ban for it because Warden shouldn't do anything unless you write somewhere Warden scans at or if your bot is public etc.

[amadmonk]

For private bots (meaning: you write all your own code and don't include other people's libs as binaries, etc.), as long as you follow some common sense rules (don't spam packets, don't bot around other players too much, don't "look too bottish"), and as long as you avoid writing to the handful of Warden-monitored functions, it's pretty much just as safe to be in-process as to be passive, and you'll find that it makes your life much, much easier.

I think that the real reason most people run out of process is because they are too lazy/ignorant to do the necessary research to figure out how to inject/hoist the CLR/etc. (despite that information being freely and easily available on this forum, among other places).

To the OP: looks like you're dealing with stale data. Use the VFunc to get live data.*

* Yes, I know you said that you expected that response, but you're getting that response because... it's the correct response. If you don't LIKE that response, that's not my problem.

[bad6oy30]

caytchen, sorry I poked you
psyf4, yes repost, I should have followed up on my original thread

The whole picture is that my out-of-process bot is over 4 years old, and is fairly complex (at least by my standards, it's entirely designed for pvp), and started long before I knew this place existed. Warden was perceived at the time to be a lot harsher, and my skill set was (and still is) limited to reversing network protocols and memory, not asm.

I haven't needed any new information from wow in a very long time... but I've started a Rogue, so here I am looking for any perspectives on the facing offset. All said, interaction with wow is about 5% of my system, and given the particularly wide decision-tree of a Rogue in pvp, I'll see more benefits focusing on behavior and simulation efficiency rather than how I get a float from wow.

If I lost everything somehow, and had to start from scratch, then I'd go endscene.

[draco1219]

For private bots (meaning: you write all your own code and don't include other people's libs as binaries, etc.), as long as you follow some common sense rules (don't spam packets, don't bot around other players too much, don't "look too bottish"), and as long as you avoid writing to the handful of Warden-monitored functions, it's pretty much just as safe to be in-process as to be passive, and you'll find that it makes your life much, much easier.

I think that the real reason most people run out of process is because they are too lazy/ignorant to do the necessary research to figure out how to inject/hoist the CLR/etc. (despite that information being freely and easily available on this forum, among other places).

Thank you for the great response. I guess my question is, is that why doesn't warden monitor the CTM functions or the "Set Target" function? Wouldn't it be easy for Warden to figure out if another process had "Create Thread" capabilities or wouldn't it be theoretically possible for warden to have a collection of "known modules" and search itself for modules which aren't loaded and thus find the alien module?

Some things that are difficult for me out of process:

1. Casting a spell by ID.
2. CTM
3. Selecting a target.

With the above mentioned, it seems like it would be so easy for them to monitor the functions that provide the above functionality, I just wonder why they don't.

Thanks again guys!

[amadmonk]

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.

As for casting a spell by ID, there is already a Lua function to do this! They have a little protected execution thing in place to keep normal (user) Lua scripts from doing this, but their own API uses it quite heavily, so it's going to be difficult, again, for them to sort out "valid" versus "invalid" calls to the Lua cast spell function.

CTM changes ALL the time; aside from constantly polling the values and comparing against their own cached "known good" data, how are they going to know if it's good or bad? Remember that if they put something in place and it starts flagging lots of innocent users due to lag or something (thinking about how I'd implement a check, here), that's going to be a HUGE PR nightmare for Blizzard; probably not worth it. Besides, there are many other methods of movement.

Target selection has the same limitations as CTM; it is by nature a highly dynamic value, so not really a good choice for a detection heuristic.

Note that none of this means that they won't EVER detect you; if you bot, you're playing a cat-and-mouse game, period. There's no guarantee that Blizzard won't ban your account at any time, for any reason. But the ODDS are extremely slim, right now, if you follow some basic guidelines.