Obtaining WoW Events

[amadmonk]

1. I can understand and appreciate that. But your alternative is using DR hooks? o.O

2. And what if they push out a silent check for DR hooks?

Just sayin'...

Well, how else do you hook without actually changing the checksum of the code you're hooking? VM protection based hooks like guard pages seemed kinda fragile to me, and just as detectable (aha, the VM flags on this page aren't the same as we set them, so that's naughty!)

With DR, sure they can detect that the DR's are set and pointing to their code. But so what? That could just mean you're debugging WoW, which (AFAIK) they're still not banning for. Plausible deniability ftw :P

Of course, all of this paranoia talk is just sort of "what if you get hit by lighting" stuff. The reality is that at the time, I wanted to play around with DR-based hooking and refresh my memory on how VEH worked. That's actually what drives 99% of my bot design -- curiousity, not necessarily always the best architecture choices.

I mean if I were just trying to be all pragmatic and efficient, I wouldn't even bother with botting (I have a number of end-game characters already, so what's in it for me?)

But... it's FUN... Hence when you look at my code base you get thing like DR hooks instead of plain vanilla detours, and a combo in-proc/out-of-proc approach to the "brain" instead of a simple (and already working) pure in-proc brain. Again, it's the fun factor that drives me... the challenge... not just the design choices of "making the best app."

That -- pragmatic software design and architecture decisions -- is what I do at work. That's WORK.

[Cypher]

Well, how else do you hook without actually changing the checksum of the code you're hooking? VM protection based hooks like guard pages seemed kinda fragile to me, and just as detectable (aha, the VM flags on this page aren't the same as we set them, so that's naughty!)

With DR, sure they can detect that the DR's are set and pointing to their code. But so what? That could just mean you're debugging WoW, which (AFAIK) they're still not banning for. Plausible deniability ftw :P

Of course, all of this paranoia talk is just sort of "what if you get hit by lighting" stuff. The reality is that at the time, I wanted to play around with DR-based hooking and refresh my memory on how VEH worked. That's actually what drives 99% of my bot design -- curiousity, not necessarily always the best architecture choices.

I mean if I were just trying to be all pragmatic and efficient, I wouldn't even bother with botting (I have a number of end-game characters already, so what's in it for me?)

But... it's FUN... Hence when you look at my code base you get thing like DR hooks instead of plain vanilla detours, and a combo in-proc/out-of-proc approach to the "brain" instead of a simple (and already working) pure in-proc brain. Again, it's the fun factor that drives me... the challenge... not just the design choices of "making the best app."

That -- pragmatic software design and architecture decisions -- is what I do at work. That's WORK.

I'm trying to say, you don't actually need to hook anything to register a callback.

Think about it. You're already using VEH, and you're trying to register a function pointer. The only check WoW does is that it's inside WoW's code segment.

Surely you can figure out a way to abuse that to register a function inside WoW.exe, but can still be redirected to your custom code.

[Cypher]

Who still hacks this game?

There are other ways to do the same thing; but they too can cause issues. Not to mention that the way I do it, I'm 100% sure that my functions are being registered on top of WoW's (if in the odd case that I need/want to to override one of WoW's Lua funcs), since the local player's pointer can be non-null before the WoW reregisters everything. (The 'InGame' bool is also set before WoW registers stuff last I checked.)

Give me one situation where you'd actually want to override an existing Lua function...

EDIT:

At any rate, I'd rather just re-register every frame than waste a hook on something so pointless.

[Apoc]

Give me one situation where you'd actually want to override an existing Lua function...

EDIT:

At any rate, I'd rather just re-register every frame than waste a hook on something so pointless.

Redirecting the print func, or some other 'odd' func as I stated. There really aren't any that I can think of at the moment; but it's something to keep in mind anyway.

Keep in mind it is private; so I'm not really running any risk of detection for now, so it's not exactly on my list of 'shit to watch out for'.

[Cypher]

Redirecting the print func, or some other 'odd' func as I stated. There really aren't any that I can think of at the moment; but it's something to keep in mind anyway.

Keep in mind it is private; so I'm not really running any risk of detection for now, so it's not exactly on my list of 'shit to watch out for'.

It's still a risk, even if it's private.

DR hooks on engine functions is highly suspicious.

[RoKFenris]

It's still a risk, even if it's private.

DR hooks on engine functions is highly suspicious.

I haven't looked hard (yet) into DR hooks, but shouldn't you be able to protect the debug registers from being tampered (or even being read) from a non-privileged process? The white paper I read did say something to the tune that unprivileged processes should not expect being able to read them.

Besides, DR registers are used also for performance counters, and it seems there is some work in process to offer them from the Linux kernel with an easier to use interface (and, most important, clash avoidance).

[Cypher]

I haven't looked hard (yet) into DR hooks, but shouldn't you be able to protect the debug registers from being tampered (or even being read) from a non-privileged process? The white paper I read did say something to the tune that unprivileged processes should not expect being able to read them.

Besides, DR registers are used also for performance counters, and it seems there is some work in process to offer them from the Linux kernel with an easier to use interface (and, most important, clash avoidance).

What the **** are you talking about? Can someone step in and translate for me please?

Anyway...

All Warden needs to be able to do in order to see your DR hooks is read the main thread's context. Something which does not require any special privileges, because it's coming from the process that owns the thread. Heck, Warden even runs in the main thread, making it even easier (and making EH based detection a much more likely possibility).

Sure, you can TRY to hide your DR hooks, but you need a minimum of three API hooks in order to do that reliably (NtGetContextThread, NtSetContextThread, and KiUserExceptionDispatcher). Not to mention that implementing those hooks in a reliable and 'safe' manner (safe as in hard to detect) is a huge pain in the ass.

Not to mention that even with those hooks there are still methods for retrieving the values of the DR registers that are unhookable from usermode unless you attack Warden itself (rather than the Windows API).

In short: Yes, they're probably safe for now, as the Warden guy is a lazy ****. But I personally wouldn't want to rely on them, as they're very dangerous and it wouldn't be hard for DR hook scans to be added to Warden.

[amadmonk]

In short: Yes, they're probably safe for now, as the Warden guy is a lazy ****. But I personally wouldn't want to rely on them, as they're very dangerous and it wouldn't be hard for DR hook scans to be added to Warden.

I wouldn't say that they're "safe" in the sense that no in-process code is "safe." BUT, the debate was "is a DRx hook safeR than a registered Lua function." And the answer HAS to be "it depends."

When I'm thinking about "safety" I'm not just thinking about detectability, I'm thinking about plausible denial. In other words, if there's a genuine and valid and non-bannable use for the technology, I think that it's *unlikely* that Blizzard will ban on detection of the technology alone, since they might ban "innocent" users, which would be Very Bad PR. They might still ban if they find that, say, your DR hooks are being caught by naughty in-process code, but that's the other code's fault, not the hooks' fault. Again, I think you have to be careful to differentiate between technologically detectable/blockable and what's actually likely to happen in the real world.

In the real real world, as many of us have said, if you're writing custom code and not sharing it, you're probably pretty unlikely to be banned, unless you're unlucky enough to touch a handful of places specifically watched by Warden. Since their scanning is, right now, based almost (?) entirely on signature scanning, if you don't match the signature, you won't get caught. This means that most of this entire discussion is moot.

Now, suppose that were to change, and they started scanning based upon other factors, such as "are DR0-3 set and enabled and pointing to something in the text segment." Yes, that is EASILY detectable, and yes, it is a major pain in the ass to try to hide it. But since that case is precisely what it would look like if you had a debugger attached and were debugging the WoW process, and since as far as I know, they're specifically not banning you for debugging WoW, it seems exceedingly unlikely that simply having a debug register pointing to the text segment would be bannable. They'd catch anyone debugging the app who was unlucky enough to use hardware breakpoints!

On the other hand, what are the valid, "non cheating" use cases for registering your own Lua function? As far as I know, there aren't any. Only Blizzard is supposed to be able to do this. And the list of Lua functions that gets registered is static (heck it's easily searchable in the binary), so it would be a matter of a moment to check the registrations versus the "known good" registrations and, what's more, you can be sure that any "extra" registrations indicate that someone is actively cheating, which you DON'T know for sure with the debug registers case.

Hence my assessment that DR hooks are "safer" than registered Lua functions. Not technologically speaking, but in the world of reality where Blizzard doesn't just do what's technically possible, but also wants to look like the 'good guy' and not just the asshats who are banning people for running Linux (heh).

Sorry that was long-winded, but I wanted to make my thinking clear. The "DR hooks are safer" assessment I made still stands (at least until Blizz starts banning debuggers, but I suspect that when they do that about half the reversing community will get banned in one fell swoop.)

EDIT: if you don't think that Blizzard cares about PR when making ban choices, just look at what happened to Linux users, and think again. There was a time period when Linux/Wine users were being banned left and right, and Blizzard took major fallout for that, and ended up backing off. I think that like any big company, they're trying to be careful with their reputation so that they look like the "good guys" as much as possible. That knowledge, in turn, affects the choices I make regarding "ban safety."

[Cypher]

I wouldn't say that they're "safe" in the sense that no in-process code is "safe." BUT, the debate was "is a DRx hook safeR than a registered Lua function." And the answer HAS to be "it depends."

You're taking what I said out of context. First off, I said "safe for now", and second, I explicitly said in that same quote that they were dangerous.

I simply meant that for the time being you aren't likely to get banned for using DR hooks.

Anyway...

When I'm thinking about "safety" I'm not just thinking about detectability, I'm thinking about plausible denial. In other words, if there's a genuine and valid and non-bannable use for the technology, I think that it's *unlikely* that Blizzard will ban on detection of the technology alone, since they might ban "innocent" users, which would be Very Bad PR. They might still ban if they find that, say, your DR hooks are being caught by naughty in-process code, but that's the other code's fault, not the hooks' fault. Again, I think you have to be careful to differentiate between technologically detectable/blockable and what's actually likely to happen in the real world.

What kind of "innocent" users are going to have DR hooks set on engine functions? Come on, lets get real. I understand where you're coming from, but I think that the amount of "innocent" users which would be caught by a blanket ban of DR hooks on engine functions would be negligible. The pros far outweigh the cons.

In the real real world, as many of us have said, if you're writing custom code and not sharing it, you're probably pretty unlikely to be banned, unless you're unlucky enough to touch a handful of places specifically watched by Warden. Since their scanning is, right now, based almost (?) entirely on signature scanning, if you don't match the signature, you won't get caught. This means that most of this entire discussion is moot.

Yes, Warden generally takes a 'reactive' rather than a 'proactive' stance when it comes to cheats. But there are exceptions. (For example the speedhack check is proactive not reactive.)

Now, suppose that were to change, and they started scanning based upon other factors, such as "are DR0-3 set and enabled and pointing to something in the text segment." Yes, that is EASILY detectable, and yes, it is a major pain in the ass to try to hide it. But since that case is precisely what it would look like if you had a debugger attached and were debugging the WoW process, and since as far as I know, they're specifically not banning you for debugging WoW, it seems exceedingly unlikely that simply having a debug register pointing to the text segment would be bannable. They'd catch anyone debugging the app who was unlucky enough to use hardware breakpoints!

What type of normal user would be actively debugging WoW and using hardware breakpoints to do so? Seriously...

On the other hand, what are the valid, "non cheating" use cases for registering your own Lua function? As far as I know, there aren't any. Only Blizzard is supposed to be able to do this. And the list of Lua functions that gets registered is static (heck it's easily searchable in the binary), so it would be a matter of a moment to check the registrations versus the "known good" registrations and, what's more, you can be sure that any "extra" registrations indicate that someone is actively cheating, which you DON'T know for sure with the debug registers case.

I understand where you're coming from, however looking for DR hooks is a feature much more likely to be added to Warden imo. Especially since at least one public cheat is using them currently (mine, LuaNinja).

Looking for unknown callbacks just doesn't seem as likely to me...

First off, it's much higher maintenance. And second, DR hooks have a much wider 'scope' and hence checking for them would allow you to catch far more cheaters.

Hence my assessment that DR hooks are "safer" than registered Lua functions. Not technologically speaking, but in the world of reality where Blizzard doesn't just do what's technically possible, but also wants to look like the 'good guy' and not just the asshats who are banning people for running Linux (heh).

Sorry that was long-winded, but I wanted to make my thinking clear. The "DR hooks are safer" assessment I made still stands (at least until Blizz starts banning debuggers, but I suspect that when they do that about half the reversing community will get banned in one fell swoop.)

EDIT: if you don't think that Blizzard cares about PR when making ban choices, just look at what happened to Linux users, and think again. There was a time period when Linux/Wine users were being banned left and right, and Blizzard took major fallout for that, and ended up backing off. I think that like any big company, they're trying to be careful with their reputation so that they look like the "good guys" as much as possible. That knowledge, in turn, affects the choices I make regarding "ban safety."

I'm not saying they don't care about PR, I'm just saying that the previous 'incidents' really did affect 'normal' users. However banning for DR hooks will not affect any 'normal' user. As soon as you're debugging your game you're no longer 'normal'. You're suspicious.

[amadmonk]

Well, some of this is "you say potato, I say potato" kinda stuff. You think DR hooks look more suspicious than registered callbacks, I disagree. The reasoning is simply that DR hooks have a legitimate use (even if, as you say, it's a potentially frowned-upon use, it's still not technically illegal to debug WoW, even using hardware breakpoints... the VEH in-process would be harder to explain...)

On the other hand, AFAIK, the only use of a non-standard Lua callback is to cheat. So, if you want to weigh "has one, semi-legitimate use-case which might, potentially be used by say an antivirus researcher making sure Warden isn't naughty, or something" versus "has absolutely no known, valid, non-cheating uses," I'll take the one which has a shred of deniability to it. Again -- not safe, but safeR.

Of course, we're still arguing how many angels can dance on the head of a pin. Realistically, I'm not going to be banned because I'll never get on their radar -- I don't sell my bot or give away my code, and DR hooking is just way too unnecessarily complex for what I'm doing -- a simple asm jmp would be far more effective, let alone registering a function. I'm the Macintosh users -- security through obscurity, baby!

As to too much work to maintain... meh. It works. It's never failed. It takes me less than 30 seconds to make it work each patch. It's pretty low-maintenance for me

Edit: I'm sleepy, and I just read the one thing, about LuaNinja. That, I'll have to think about. What's the proportion of hacks using DR hooks vs. Lua registered functions? Anyone know? I should mention that I change the function I'm hooking off of almost every patch, so it's not like they can just look for one particular VALUE of the DR registers. They'd have to blanket ban off of *any* use of debug breakpoints, and that would catch a LOT of people who are not currently, as far as I know, considered "cheaters." I'm not sure I believe that they're willing to catch that wide of a net. But, I could be wrong... it's always a game of cat and mouse.

Edit2: Honestly, if I were the "Warden guy," there are about 3-4 simple checks I could make, today, to catch 90% of the active botters -- myself included. I just think that they don't care, frankly, until the bots get high profile enough to pose a PR problem.

Edit3: Just because I'm paranoid, I started hooking Get/SetThreadContext last night (fairly easy, I just want to make it look like my DR register values aren't there and prevent resetting) and KiUserDispatchException (a little harder to "get right"... still not sure why I need it for safe DR hooking... to keep them from putting a new EH in the chain and subverting mine?) Once I have it working smoothly I'll post in elite.

Edit4: Oh, duh. Because the full "real" thread context is available from the kernel in KiUED, thus circumventing my attempts to spoof it if I don't hook this. Very well...

[nitrogrlie]

Thanks a lot guys, I got it working and it's great. Now I have a whole bunch of handlers to write :P

Sample Log output:

[13:14:56]: [EVENT]: 'ACTIONBAR_UPDATE_STATE' 
[13:14:56]: [EVENT]: 'CURRENT_SPELL_CAST_CHANGED' 
[13:14:56]: [EVENT]: 'COMBAT_LOG_EVENT_UNFILTERED' '<TIME>' 'SPELL_CAST_START' '<MYGUID>' '<MYSELF>' '1297' '0x0000000000000000' 'NULL' '-2147483648' '686' 'Shadow Bolt' '32' 
[13:14:56]: [EVENT]: 'COMBAT_LOG_EVENT' '<TIME>' 'SWING_DAMAGE' '<TARGETGUID>' 'Mindless Zombie' '68136' '<MYGUID>' '<MYSELF>' '1297' '1' '0' '1' 'NULL' 'NULL' 'NULL' 'NULL' 'NULL' 'NULL' 
[13:14:56]: [EVENT]: 'COMBAT_LOG_EVENT_UNFILTERED' '<TIME>' 'SWING_DAMAGE' '<TARGETGUID>' 'Mindless Zombie' '68136' '<MYGUID>' '<MYSELF>' '1297' '1' '0' '1' 'NULL' 'NULL' 'NULL' 'NULL' 'NULL' 'NULL' 
[13:14:56]: [EVENT]: 'COMBAT_TEXT_UPDATE' 'DAMAGE' '1' 
[13:14:56]: [EVENT]: 'UNIT_THREAT_LIST_UPDATE' 'target' 
[13:14:56]: [EVENT]: 'UNIT_HEALTH' 'target' 
[13:14:56]: [EVENT]: 'UNIT_MANA' 'player' 
[13:14:56]: [EVENT]: 'UNIT_SPELLCAST_DELAYED' 'player' 'Shadow Bolt' 'Rank 1' '3' 
[13:14:56]: [EVENT]: 'CRITERIA_UPDATE' 
[13:14:56]: [EVENT]: 'CRITERIA_UPDATE' 
[13:14:56]: [EVENT]: 'COMBAT_LOG_EVENT' '<TIME>' 'SPELL_DAMAGE' '<MYGUID>' '<MYSELF>' '1297' '<TARGETGUID>' 'Mindless Zombie' '68136' '686' 'Shadow Bolt' '32' '17' '0' '32' 'NULL' 'NULL' 'NULL' 'NULL' 'NULL' 'NULL' 
[13:14:56]: [EVENT]: 'COMBAT_LOG_EVENT_UNFILTERED' '<TIME>' 'SPELL_DAMAGE' '<MYGUID>' '<MYSELF>' '1297' '<TARGETGUID>' 'Mindless Zombie' '68136' '686' 'Shadow Bolt' '32' '17' '0' '32' 'NULL' 'NULL' 'NULL' 'NULL' 'NULL' 'NULL' 
[13:14:56]: [EVENT]: 'UNIT_COMBAT' 'target' 'WOUND' '' '17' '32' 
[13:14:56]: [EVENT]: 'CRITERIA_UPDATE' 
[13:14:56]: [EVENT]: 'UNIT_COMBAT' 'target' 'WOUND' '' '4' '4' 
[13:14:56]: [EVENT]: 'COMBAT_LOG_EVENT' '<TIME>' 'SPELL_PERIODIC_DAMAGE' '<MYGUID>' '<MYSELF>' '1297' '<TARGETGUID>' 'Mindless Zombie' '68136' '348' 'Immolate' '4' '4' '0' '4' 'NULL' 'NULL' 'NULL' 'NULL' 'NULL' 'NULL' 
[13:14:56]: [EVENT]: 'COMBAT_LOG_EVENT_UNFILTERED' '<TIME>' 'SPELL_PERIODIC_DAMAGE' '<MYGUID>' '<MYSELF>' '1297' '<TARGETGUID>' 'Mindless Zombie' '68136' '348' 'Immolate' '4' '4' '0' '4' 'NULL' 'NULL' 'NULL' 'NULL' 'NULL' 'NULL' 
[13:14:56]: [EVENT]: 'UNIT_COMBAT' 'player' 'WOUND' '' '1' '1' 
[13:14:56]: [EVENT]: 'SPELL_UPDATE_USABLE' 
[13:14:56]: [EVENT]: 'UNIT_HEALTH' 'player' 
[13:14:56]: [EVENT]: 'SPELL_UPDATE_USABLE' 
[13:14:56]: [EVENT]: 'ACTIONBAR_UPDATE_STATE' 
[13:14:56]: [EVENT]: 'CURRENT_SPELL_CAST_CHANGED' 
[13:14:56]: [EVENT]: 'UPDATE_SHAPESHIFT_FORM' 
[13:14:56]: [EVENT]: 'UNIT_HEALTH' 'target' 
[13:14:56]: [EVENT]: 'SPELL_UPDATE_USABLE' 
[13:14:56]: [EVENT]: 'PET_BAR_UPDATE_USABLE'