EVENTS in 3.3.5.12340

[maphack122]

I have a problem with events. For example, when i hook BroadcastEvent and recieve CHAT_MSG_SAY i got 13 args

%s%s%s%s%s%s%d%d%s%d%d%s%u

.
Got this by

void BroadcastEvent( DWORD dwEventID, const char * pszFmt, void *... )
{
	OutputDebugString(pszFmt);
/// CODE + restore stack
oBroadcastEvent( dwEventID, pszFmt );
}

The event looks like

[6064] %s%s%s%s%s%s%d%d%s%d%d%s%u
[6064] 0 field: CHAT_MSG_SAY
[6064] 1 field: 0н›ьл›\/Ь˜ь›ИЂкяћ
[6064] 2 field: <э›ЪЁP
[6064] 3 field: ѓД<_^[‹е]Г3яйqяяяММММММММММММММU‹мS3Ы9шпј
[6064] 4 field: 
[6064] 5 field: %s%s%s%s%s%s%d%d%s%d%d%s%u
[6064] 6 field: say 
[6064] 7 field: 60550140 
[6064] 8 field: 148647772  
[6064] 9 field:   
[6064] 10 field: 418021576  
[6064] 11 field: 10360063  
[6064] 12 field:   
[6064] 13 field:

6 Field : the message i have typed in chat.

The normal event is

("message", "sender", "language", "channelString", "target", "flags", unknown, channelNumber, "channelName", unknown, counter)

Arguments:

•message - The message thats received (string) 
•sender - The sender's username. (string) 
•language - The language the message is in. (string) 
•channelString - The full name of the channel, including number. (string) 
•target - The username of the target of the action. Not used by all events. (string) 
•flags - The various chat flags. Like, DND or AFK. (string) 
•unknown - This variable has an unkown purpose, although it may be some sort of internal channel id. That however is not confirmed. (number) 
•channelNumber - The numeric ID of the channel. (number) 
•channelName - The full name of the channel, does not include the number. (string) 
•unknown - This variable has an unkown purpose although it always seems to be 0. (number) 
•counter - This variable appears to be a counter of chat events that the client recieves. (number)

What could be the source of problem?

[Robske]

I have the same problem.

Flipped a bool and switched back to a lua callback to get event data untill I can gather enough care to look closer into it.

[caytchen]

Well, what is your problem? Except that your stack handling might be ****ed up and that you got a string encoding problem, none of which we can help you solve by what you provided.

Flipped a bool and switched back to a lua callback to get event data untill I can gather enough care to look closer into it.

Might just stay at that. Hooking BroadcastEvent seems like a honeypot yearning to be scanned.

[maphack122]

Well, what is your problem? Except that your stack handling might be ****ed up and that you got a string encoding problem, none of which we can help you solve by what you provided.



Might just stay at that. Hooking BroadcastEvent seems like a honeypot yearning to be scanned.

So i need to hook LUA SignalEvent ? (I do not need to make hack warden-proof.) (Sorry for my english, i am not a native speaker)

[Cypher]

I have the same problem.

Flipped a bool and switched back to a lua callback to get event data untill I can gather enough care to look closer into it.

Using a LUA callback is a much better method anyway imo.

[Robske]

Using a LUA callback is a much better method anyway imo.

They both have their advantages and disadvantages I suppose. Personally I prefer detouring Framescript__SignalEvent.

Lua in this case can be compared to a retarded infant who needs monitoring and special attention. (As you have to keep your Lua frame object and event callback alive)
Then again, the detour code for Framescript__SignalEvent in C# can be compared to something you'd 'man the harpoons' for. (I know of no elegant way to detour a variadic function in C#)

In the end, both implementations require a function detour to work and the LUA version has more ways to be detected and causes (minimal) overhead.

So, why do you prefer Lua?

[Cypher]

Because it doesn't require a function detour. You're doing it wrong.

Also, keeping your Lua crap alive is fairly easy. From memory you can just put this in your OnFrame handler:
if (pPlayerPrev != GetActivePlayer()) { RegisterLuaShit(); }

Btw, the 'overhead' you're referring to is negligible in all the tests I've performed.

[caytchen]

Because it doesn't require a function detour. You're doing it wrong.

Also, keeping your Lua crap alive is fairly easy. From memory you can just put this in your OnFrame handler:
if (pPlayerPrev != GetActivePlayer()) { RegisterLuaShit(); }

Btw, the 'overhead' you're referring to is negligible in all the tests I've performed.

Do you register a new function? I'm detouring an existing lua function, one that is rarely (read: never) called and even if it was I can seperate a legitimate call from an event one, since the legitimate one won't have any arguments.
Not quite sure which is the best way here. You'll need a code cave for registering a new function (okay, not that big of a problem), plus it's been done by public hacks previously.

[Unkn0wn0x]

Do you register a new function? I'm detouring an existing lua function, one that is rarely (read: never) called and even if it was I can seperate a legitimate call from an event one, since the legitimate one won't have any arguments.
Not quite sure which is the best way here. You'll need a code cave for registering a new function (okay, not that big of a problem), plus it's been done by public hacks previously.

And you need to detour FrameScript__UnregisterFunction() , because WoW unloads your self registered function on a (for me) random time.

[Cypher]

Do you register a new function? I'm detouring an existing lua function, one that is rarely (read: never) called and even if it was I can seperate a legitimate call from an event one, since the legitimate one won't have any arguments.
Not quite sure which is the best way here. You'll need a code cave for registering a new function (okay, not that big of a problem), plus it's been done by public hacks previously.

Yes I register a new function. Obviously that has its own caveats (Warden could check the callback list for consistency), but tbh I'm not really worried about that. Warden is primarily (almost exclusively) aimed at detecting public bots/hacks/etc, and just can't see Blizzard implementing such an 'aggressive' feature like that given Warden's current state (read: highly targeted).

For example, it would be trivial for Warden to scan the entire .text and .rdata section, but it doesn't. I have no idea why it doesn't, but that's just the way it is. All the scans are very targeted.

Hijacking an existing function is an interesting approach, but probably about the same as registering a new function in terms of detectability (they can no longer detect you via callback list consistency checks, but they can detect you via calling the function or looking for your hook).

How are you hooking the function btw? Just a normal code hook? Debug registers? Guard page (or similar page attribute attack)?

P.S. You don't need a 'code cave' for registering a new function. You don't even need to hook anything. Just register a function pointer that is 'valid' as far as WoW is concerned, but actually raises an exception when it's called, then you can catch that exception using VEH and perform redirection to the 'real' callback.

EDIT:

Whoops, said 'private' when I meant 'public'. Thanks Rob.

[Robske]

Because it doesn't require a function detour. You're doing it wrong.

Also, keeping your Lua crap alive is fairly easy. From memory you can just put this in your OnFrame handler:
if (pPlayerPrev != GetActivePlayer()) { RegisterLuaShit(); }

Btw, the 'overhead' you're referring to is negligible in all the tests I've performed.

Oh that would do it. I was using one of the *_RegisterScripts() functions.

[caytchen]

How are you hooking the function btw? Just a normal code hook? Debug registers? Guard page (or similar page attribute attack)?

Normal code hook. You said it already, they don't scan all of .text and .rdata but only hash a few bytes at prominent places to catch some public hack, so I couldn't care less. It's my only hook besides EndScene, and they will never ban for the EndScene one.
I might switch to other means of hooking (VEH or even hardware breakpoints), though, since detecting those would mean implementing an 'aggressive' feature. Just in case they change their mind on hashing everything.

[Cypher]

Normal code hook. You said it already, they don't scan all of .text and .rdata but only hash a few bytes at prominent places to catch some public hack, so I couldn't care less. It's my only hook besides EndScene, and they will never ban for the EndScene one.
I might switch to other means of hooking (VEH or even hardware breakpoints), though, since detecting those would mean implementing an 'aggressive' feature. Just in case they change their mind on hashing everything.

Yep. That's what I'd do. If you swap to a 'stealthier' hooking method then you're pretty much 'Warden-proof' in the practical sense, as they'd have to be 'aggressive' to detect you.

[MaiN]

They both have their advantages and disadvantages I suppose. Personally I prefer detouring Framescript__SignalEvent.

Lua in this case can be compared to a retarded infant who needs monitoring and special attention. (As you have to keep your Lua frame object and event callback alive)
Then again, the detour code for Framescript__SignalEvent in C# can be compared to something you'd 'man the harpoons' for. (I know of no elegant way to detour a variadic function in C#)

In the end, both implementations require a function detour to work and the LUA version has more ways to be detected and causes (minimal) overhead.

So, why do you prefer Lua?

Psst. Hook the function at 0x81AC90 instead of the real FrameScript::SignalEvent (like I told you on MSN). It has the signature sub_81AC90(DWORD event, const char* fmt, va_list args) - which means the third argument is a pointer to the stack (usually) of args. You can just get them by memory reading. This is the function I call to signal events from my lua wrapper.

[Robske]

Psst. Hook the function at 0x81AC90 instead of the real FrameScript::SignalEvent (like I told you on MSN). It has the signature sub_81AC90(DWORD event, const char* fmt, va_list args) - which means the third argument is a pointer to the stack (usually) of args. You can just get them by memory reading. This is the function I call to signal events from my lua wrapper.

As I said on msn, that's the very function I'm having troubles with.