Info for people writing "out-of-process" bots

[Xeranor]

One could still use CTM without any injection at all, just use a WorldtoScreen transform function to get the pixel coordinates of a certain world coordinate in WoW and click it, well ofcourse you'd have to check if the world coordinate is within the current viewport and turn the camera if needed, but you can still do it without injection.
It might sound like a lot of work, but in the end it's the easiest way to move your charakter from out of process, as you avoid a lot of obstacles like setting your facing angle correctly without injection.

rofl no its much easyer to read the playerrotation and set it with a and d key presses than this method xD my setRotation function is ~30lines long and works perfect³

[kynox]

rofl no its much easyer to read the playerrotation and set it with a and d key presses than this method xD my setRotation function is ~30lines long and works perfect³

You completely missed his point. He was talking specifically about CTM, not keyboard turning.

[Shynd]

rofl no its much easyer to read the playerrotation and set it with a and d key presses than this method xD my setRotation function is ~30lines long and works perfect³

****ing perfect cubed! That's like genius-at-work programming! Good God, man, where do you find the time to talk to we little people!?

[Cypher]

One could still use CTM without any injection at all, just use a WorldtoScreen transform function to get the pixel coordinates of a certain world coordinate in WoW and click it, well ofcourse you'd have to check if the world coordinate is within the current viewport and turn the camera if needed, but you can still do it without injection.
It might sound like a lot of work, but in the end it's the easiest way to move your charakter from out of process, as you avoid a lot of obstacles like setting your facing angle correctly without injection.

Of course you can, however you'd need to not only do a WorldToScreen, but also do ray tracing to ensure you're not 'clicking' trees or other obstacles that obscure the 'true' click point. I haven't tried but I'd assume they would interfere.

At any rate, I was obviously referring to the people who implement CTM via memory writing. And I made explicit what I considered to be 'in-process' in an explanation to a person who brought up the 'ambiguity' of my definition.

The difference, in my mind, between out-of-process and in-process bots is not contained wholly in what is manipulated or not manipulated but, rather, in where the thread of logic is executed. An out-of-process bot can inject into a process to execute certain procedures, but its thread is mainly external so it cannot be considered wholly in-process.

The line does tend to blur, in some cases, and one should not consider one type specifically more or less risky than another, depending on implementation. A lot of confusion would be abated if the general level of knowledge was raised just one iota, but that's wishful (and inevitably ridiculous) thinking.

The fact that the thread is "external" (the correct term being "remote") is irrelevant. A stack trace doesn't distinguish between threads, and that is the way you would detect function calls.

Naturally the line is blurry, however I believe the explanation I gave to be wholly accurate in a technical sense when it comes to what counts as 'in' or 'out' of process. Keep in mind we're discussing it from an anti-cheat point of view, not an academic point of view. If the anti-cheat can detect it 'in-process' than it counts as 'in-process' imo. Unless your bot is 100% free of 'in-process' activities, then you are not 'out-of-process'.

At any rate, most of the confusion is caused by "developers" (I use that word the same way I use the word "*******s") who don't have any real low-level programming knowledge, and hack together a bot using libraries and offsets copied from various public sources, then slap a price tag on it and sell it to the public. I see so many stupid statements from the current bot developers and their 'staff' (a perfect example being the WoWRobot thread that was linked by someone in the discussion about FrameScript__Execute).

Anyway, kinda veered off topic.

In summary:
I stand by my original explanation, as imo it's technically accurate and written from the only point of view which is relevant in the given context.

[Xarg0]

Of course you can, however you'd need to not only do a WorldToScreen, but also do ray tracing to ensure you're not 'clicking' trees or other obstacles that obscure the 'true' click point. I haven't tried but I'd assume they would interfere.

At any rate, I was obviously referring to the people who implement CTM via memory writing. And I made explicit what I considered to be 'in-process' in an explanation to a person who brought up the 'ambiguity' of my definition.

There shouldn't be any obstacles in the los from one waypoint to another, if that's the case your pathing system fails.
And I can't think of a possible camera angla where the target waypoint is within the viewport but under an obstacle when there's no obstacle from your current location to the target location.

And ofcourse I do know what kind of click2move you were refering to, so I decided to present an alternative way of using click2move .

[xzidez]

There shouldn't be any obstacles in the los from one waypoint to another, if that's the case your pathing system fails.
And I can't think of a possible camera angla where the target waypoint is within the viewport but under an obstacle when there's no obstacle from your current location to the target location.

And ofcourse I do know what kind of click2move you were refering to, so I decided to present an alternative way of using click2move .

A very easy example is where you are running under a bridge. And your destination is under the bridge. From your toons pov there is no obstacles. But if your camera is above the toon you cant see the very ground where you want to run. And a click would result on the bridge instead of under the bridge.

But if you only use clicks a few yards in front of your toon this shouldnt be any major problem...

[Cypher]

A very easy example is where you are running under a bridge. And your destination is under the bridge. From your toons pov there is no obstacles. But if your camera is above the toon you cant see the very ground where you want to run. And a click would result on the bridge instead of under the bridge.

But if you only use clicks a few yards in front of your toon this shouldnt be any major problem...

Yes. I was thinking more along the lines of trees, but this is an even better example. Buildings would be another.

[Xarg0]

A very easy example is where you are running under a bridge. And your destination is under the bridge. From your toons pov there is no obstacles. But if your camera is above the toon you cant see the very ground where you want to run. And a click would result on the bridge instead of under the bridge.

But if you only use clicks a few yards in front of your toon this shouldnt be any major problem...

just zoom in the camera completly, then you've no problem with that.

[Cypher]

just zoom in the camera completly, then you've no problem with that.

Have you ever actually tried doing what you're proposing? I've given it some thought and I still think you'd run into LoS issues.

[xzidez]

Have you ever actually tried doing what you're proposing? I've given it some thought and I still think you'd run into LoS issues.

You could always use an extreme example where you would run up a hill.. And the hill is a "curve".. Any obstacle just above the ground would los the destination. A tree, building, bridge.. etc etc.

but if you only click like 5 yards in front of your toon this will probaly work.

Unless there is any player or mob in front of you

[Xarg0]

checking for mobs and player's shouldn't be a problem at all, and yes you'll need to set up your "waypoints" close enough to each other so you don't have los problems.

And to answer your question Cypher, no I didn't try it, yet it seems easier to me than to mess with mouse moving speeds to turn your char correctly, yet writing true out of process bots is gay and since I never planned to sell anything I don't intent to write one

[suicidity]

If you're calling a function in a process apart from yours, you're basically outsourcing the work and is obviously no longer passive; Now memory editing and getting caught are 2 whole others things.

Memory editing can be passive in my opinion, if done from an external process.

[Ellesar1]

just overwrite ds:[0x133d7cc] with 0xffffffff and your account will be banned within 5 minutes regardless of whether you have written it by an external process or via a DLL.

"Passive" = memory reads
"Active" = memory writes

For those who are curious: ds:[0x133d7cc] stores the virtual address of the end of the WoW main module.

[suicidity]

just overwrite ds:[0x133d7cc] with 0xffffffff and your account will be banned within 5 minutes regardless of whether you have written it by an external process or via a DLL.

"Passive" = memory reads
"Active" = memory writes

That's something Completely different, Getting caught for something that they can check for no matter what doesn't decide whether you're out of process or in-process. It just means you were dumb enough to get caught for changing you shouldn't have.

[Cypher]

That's something Completely different, Getting caught for something that they can check for no matter what doesn't decide whether you're out of process or in-process. It just means you were dumb enough to get caught for changing you shouldn't have.

Once you can be detected by an "in-process" check you are by definition "in-process" imo. The fact that your bot is private and the chances of getting caught are greatly lowered is irrelevant. The fact of the matter is that it's still very possible.