Crazy question about execute non-protected lua.

[Torpedoes]

It's easier if you ask me. No worries about speeds, and you are working directly with the source you want to access. In which way is it less flexible?

I may be completly wrong here but a couple reasons:

1) If you mess up, you crash the game
2) 3D rendering requires hooking DX
3) Larger footprint to mess up and get banned
4) In-game user interfaces vs dedicated frameworks (like WPF, Qt, etc.)

All in all I'd rather write a good caching system than have to worry about the extra protections I'd have to implement.

I agree all the way. RPM can be made to acceptable levels. There are cases where it is an issue though. What if you want to make a hyper responsive "chicken" based on a large set of dynamic conditions, and since it is a chicken caching the values will not be any good. In this case, the only solution is to actually read the current data on each game tick. If you have 10 ms, you can imagine how easily that could become a mess.

Could you please elaborate on what you mean by "chicken"?

P.S. I'm strictly talking bots here (DPS bots, fishing bots, AH bots, gathering bots, etc.) Not hacks (wall hacks, fly hacks, etc.)

[lolp1]

Larger footprint to mess up and get banned

Explain how a manual mapped module that only accesses direct memory (which is what using RPM is doing) increases the chance of a ban compared to RPM? Why do you need to implement extra protections for that?

[Torpedoes]

Explain how a manual mapped module that only accesses direct memory (which is what using RPM is doing) increases the chance of a ban compared to RPM? Why do you need to implement extra protections for that?

Well, let's start with the fact that Blizzard also has direct access to their memory. They can monitor memory allocations and the creation of new threads to find your code, from there you're a signature scan away from being detected. Only thing they get access to in OOP is the window title, the executable, the process list, the fact that your have a handle open to their process, all of which could be masked.

Furthermore, if you're injecting something for the ability to run or hook WoW functions then you're basically screwing yourself. Sooner or later they'll get you. Whether it be scanning their own code, checking the call stack and so on. Warden isn't even involved in that so you'd have no way of knowing.

But anyways, the extra protection is just one reason injected isn't that great. I listed three other reasons. We can have this debate all night but you have yet to convince be how injected is at all worth looking into at all for serious development. The RPM thing is a valid concern but way overblown, I've proven on more than one occasion that it's fast enough for most practical purposes.

[lolp1]

I could care less about all of the other stuff listed is why I did not respond to the other points, it is not actually important to me personally if its harder to hook DX to draw stuff than it is to make an external-overlay. I am more interested in this quote:

All in all I'd rather write a good caching system than have to worry about the extra protections I'd have to implement.

What precautions would be needed? How do you purpose a mapped module strictly accessing memory values (as RPM does) is easier to ban for than an external process calling RPM to obtain the memory values?

You seem to be comparing a process using strictly RPM to an injected dll hooking game functions and doing lots of other things. It's apples and oranges. It's like comparing detection between an external RPM only based hack to another external hack using memory patches and assembly injection/createremotethread. There is to requirement for a .dll to hook functions anything else the same as there no requirement for an external hack to use assembly injection/createremotethread/patchs.

[Torpedoes]

What precautions would be needed? How do you purpose a mapped module strictly accessing memory values (as RPM does) is easier to ban for than an external process calling RPM to obtain the memory values?

I already explained why it's easier to detect, it's because you're in Blizzard's world:

They can monitor memory allocations and the creation of new threads to find your code, from there you're a signature scan away from being detected.

Manual mapping is a good idea but it's still injecting code into memory and launching a thread. Manual mapping only hides the fact that a DLL was injected, it doesn't change that fact that it was injected and is doing everything an injected app would do.

You seem to be comparing a process using strictly RPM to an injected dll hooking game functions and doing lots of other things. It's apples and oranges. It's like comparing detection between an external RPM only based hack to another external hack using memory patches and assembly injection/createremotethread. There is to requirement for a .dll to hook functions anything else the same as there no requirement for an external hack to use assembly injection/createremotethread/patchs.

You misread what I wrote. I said "If" you're hooking functions. Above still applies even if you're just reading.