does every Bot like PVPTools or GPBot... (or how they all called) injection or is there only Memorywriting?
Cuz i cant unterstand how i can execute a call W/o injection.
does every Bot like PVPTools or GPBot... (or how they all called) injection or is there only Memorywriting?
Cuz i cant unterstand how i can execute a call W/o injection.
if you're not InProcess, you can't call internal wow functions.
P.S. : GPBot is not injected and doesn't call any wow function.
You can... but you have to inject asm codecaves. See http://www.mmowned.com/forums/world-...lackmagic.html. In your code cave, you can call engine functions. However, some functions require some tls specific data to be set, so you have to hook EndScene to run your code on the render thread.
This is tedious shit for many reasons:
Yeah, now come on and say "Uhh, injecting a library isn't save." - "meh, writing a bootstrap dll is hard and time consuming" etc. I don't really care, because you guys cannot be convinced by anything...
- Clean code. Hardly possible with injecting asm, but most people who prefer this kind of injection aren't attracted by clean code anyway.
- It's hard to run your own functions in wow. You always create one codecave for only one invocation, no chance to run more sophisticated C#/++ code in the wow process.
- Tedious. Consider drawing a triangle in wow. You have to do multiple DirectX API calls in one EndScene "tick". I think you'll end up with about 25 - 30 lines fasm only.
- Not maintainable/debuggable. The only result you'll see if you didn't met all requirements of the calling convention, is a wow error dialog. You don't even know which line of your asm broke and have to mess around with the memory dump of the error dialog. I don't know what you can do in C++, but if you run .net code in wow, you are also able to attach a debugger at runtime. You can debug your code like if it was only run in a managed everyday executable you've written.
- Dumb by itself. In reference to 3.: You can only call wow's functions from within your codecave. There's no chance to get more sophisticated subroutines running other than writing raw asm. Really hard to get it right, see 4..
You can also do your stuff with pure memory writes, like writing to the global ctm struct for movement. This does not require you to inject your code but nevertheless isn't a passive bot.
If you take the way to do memory writes, you can even go a step further and inject a dll from a safety point of view. This was already debated enough.
I don't really know what your mentioned bots do, but i bet they go this way for movement.
The whole "DLL injection is unsafe" thing is ridiculous, but whatever. If you're really that paranoid, just manually map your DLL. Tbh I see no reason to write all your code in ASM out of some stupid (and wrong) notion of it being 'safer'.
I've never understood the "dll injection is unsafe" thing. Nor the "dll injection is hard". From start to getting calls actually working from scratch without help here it took me all of a weekend including reversing a few of the functions I wanted to use.
Yeah you can do some stupid things while injected that make you likely to get caught, but man is it so much slicker than staying out of process. (my code can run either entirely out of process or injected and works fine either way).
Debugging codecaved asm is freaking ridiculous and for the most part the codecaves are barely better than staying entirely out of process, unless you spend ridiculous amounts of time on it. If you're going that far why not just inject the dll? The dll will be far far easier to debug/maintain and keep safe.
cause thousands of RPM calls a second is more fun apparently.
He seems to be referring to the obvious efficiency overhead. Each memory read requires a call to the kernel, which is 'expensive' if your code is performance critical. Extra abstractions and unit tests don't fix that problem. In fact, extra abstractions is only going to INCREASE the overhead.
Don't get me wrong, I'm all for avoiding premature optimization, and if it's "fast enough" then it's fast enough. However, you seem to have missed the point of his post.![]()