Site n00b.. (A leecher if I've been here for more than a month and can't earn 5 rep)
Rep Power: 1
Reputation: 1
Posts: 8
Join Date: Mar 2008
How to read events? -
07-22-2008
hi..
Ive been trying to find some pointer to the events that occur in wow. At the moment I have the pointer to the COMBAT_LOG_EVENTs, but what im really looking for is a way to read to read all of the events, especially UNIT_SPELLCAST_SENT, UNIT_SPELLCAST_START and UNIT_SPELLCAST_DELAYED. The reason that I want to read these events is that I want to make program that can spam shadow bolts and take lag into account, somewhat like the add-on [Only registered and activated users can see links. ] does.
The pointer to the list with COMBAT_LOG_EVENTs is 0x00BA577C if someone is interrested.
If you cant be assed with a .dll for it, (since you'll be wanting a GUI anyway, right?) I'd reccomend wedging a codecave in there...
I've used them to read events in other games, basically by doing a findwindow(my_app) , and sendmessage(my_app, wm_user+x, wparam,lparam),
or a wm_copydata sruct...
It's hellishly easy , and a good way to read suff from the stack, since both sendmessage/copydata wait for a reply before continuing the thread..
So, i'm thinking, if you run a couple traces to see what's going on, what registers/stack is imporant etc (at the broadcast funcion cypher menioned), your app can read and process it all.. etc...
For the record he OpenGL.dll is a good place to put your own code, since.. well.. when the hell's that gonna be used? And the version check doesn't check here.
(Excuse me if this is badly worded/completely out of context, it's like 8am and I can' sleep right now, lol.)
If you cant be assed with a .dll for it, (since you'll be wanting a GUI anyway, right?) I'd reccomend wedging a codecave in there...
I've used them to read events in other games, basically by doing a findwindow(my_app) , and sendmessage(my_app, wm_user+x, wparam,lparam),
or a wm_copydata sruct...
It's hellishly easy , and a good way to read suff from the stack, since both sendmessage/copydata wait for a reply before continuing the thread..
So, i'm thinking, if you run a couple traces to see what's going on, what registers/stack is imporant etc (at the broadcast funcion cypher menioned), your app can read and process it all.. etc...
For the record he OpenGL.dll is a good place to put your own code, since.. well.. when the hell's that gonna be used? And the version check doesn't check here.
(Excuse me if this is badly worded/completely out of context, it's like 8am and I can' sleep right now, lol.)
Errr, injected DLLs can have GUIs. You can do it in DirectX, use an existing system like CEGUI, or use WoW's LUA engine like I do. All of those approaches are much better than a GUI hosted externally because you get the advantage of tighter integration without the need to alt+tab to control the GUI.
heh, i guess it's just comes down to preference/comfort then...
No intentions of ever learning lua, or creating a pretty directx overlay and sorting out interaction..
Also, it just seems a lot easier than constantly injecting/removing your .dll(s) and recompiling etc, and for catching errors that would otherwise be a bit of a nuissance.
And err, on the plus side, I leave my proggies running with the debuggers on the other screen, hehe
heh, i guess it's just comes down to preference/comfort then...
No intentions of ever learning lua, or creating a pretty directx overlay and sorting out interaction..
Also, it just seems a lot easier than constantly injecting/removing your .dll(s) and recompiling etc, and for catching errors that would otherwise be a bit of a nuissance.
And err, on the plus side, I leave my proggies running with the debuggers on the other screen, hehe
just more comfortable with that approach =)
"Constantly injecting/removing your dlls" takes just as long as injecting code into a code cave.... Also, I don't know what you mean about 'catching errors', debugging is easier with a DLL than with a code cave because you have full access to symbolic information for the dll in your debugger. Also, you don't need to 'learn directx', CEGUI does 99% of the work for you, the rest you need can be found on GameDeception.
"Constantly injecting/removing your dlls" takes just as long as injecting code into a code cave"
-Heh, nah, I like doing it on the fly with the debugger, I work faster that way.
"what you mean about 'catching errors', debugging is easier"
-I'm meaning basic arithmetic errors that for example would crash WoW to the debugger, pain in the ass to recover, and relog if there's a certian part annoying you, whereas the delphi IDE will take you there faster..
Don't get me wrong, I've written a packet monitor/modifier/dumper with gui in .dll form, but, I just really prefer storing/sorting as much as possible externally =)
And for the record, i didn't say "learn directx" i said LUA, but I'll deffinitely check out CEGUI!
"Constantly injecting/removing your dlls" takes just as long as injecting code into a code cave"
-Heh, nah, I like doing it on the fly with the debugger, I work faster that way.
"what you mean about 'catching errors', debugging is easier"
-I'm meaning basic arithmetic errors that for example would crash WoW to the debugger, pain in the ass to recover, and relog if there's a certian part annoying you, whereas the delphi IDE will take you there faster..
Don't get me wrong, I've written a packet monitor/modifier/dumper with gui in .dll form, but, I just really prefer storing/sorting as much as possible externally =)
And for the record, i didn't say "learn directx" i said LUA, but I'll deffinitely check out CEGUI!
Doing it 'only the fly with the debugger' would take about 10x as long as running my loader which pretty much instantly injects the DLL into the
process and (if you choose) unload any already injected copies.
As for your "basic arithmetic errors that crash WoW" i have noooo idea what you're on about.
Trust me, if you prefer having your GUI external and injecting code by hand you've obviously never had a proper setup before.
Site n00b.. (A leecher if I've been here for more than a month and can't earn 5 rep)
Rep Power: 1
Reputation: 1
Posts: 8
Join Date: Mar 2008
07-25-2008
Thanks for the replies. I hoped that I could do this without injection, but it seems that this is the easiest way to do it. I tried to go to gameDeception.net and download the WoWXbase by Bobbysing. I got it compiled and running, but after 1 or 2 mins I got disconnected and couldnt log in. The same thing happend once more when I tried it on an other trail-acount. The WoWX I downloaded was for 2.4.1, that might be why my accounts got closed. Any idear how to get arround this problem?.. maybe there is some newer release of WoWX.
Doing it 'only the fly with the debugger' would take about 10x as long as running my loader which pretty much instantly injects the DLL into the
process and (if you choose) unload any already injected copies.
As for your "basic arithmetic errors that crash WoW" i have noooo idea what you're on about.
Trust me, if you prefer having your GUI external and injecting code by hand you've obviously never had a proper setup before.
Lol, i know how easy it is to loadlib/unloadlib... still don't like it =)
Akh:
Might be a silly question, but did you remember to change any telltale strings/classes that might have tipped warden off?
Lol, i know how easy it is to loadlib/unloadlib... still don't like it =)
Akh:
Might be a silly question, but did you remember to change any telltale strings/classes that might have tipped warden off?
Errr, as long as your DLL isn't made public there are no 'telltale strings'. If you're publicizing your DLL you'll want to hook functions like Module32Next etc to unlink your moule from the lists, or use ManualMapping.
You'll want to make sure you null your PE Header after its loaded, otherwise warden will still scan it by finding its Header in the Section List.
[/color]
How about i null YOUR BRAIN! Wait, that was already null.