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

[suicidity]

I agree that writing to the memory will always make your bot active, but in some cases I don't think it will make your bot in-process.

That is what I meant, That is what I was trying to make a point of. Does or doesn't it automatically make your bot "in-process" because you changed memory.

So I may have used the word Passive without your technical meaning behind it; but what I was posing was it shouldn't automatically mean that your bot is "in-process" because you change memory by external means. Like writing the angle of your character for example..

[Cypher]

That is what I meant, That is what I was trying to make a point of. Does or doesn't it automatically make your bot "in-process" because you changed memory.

So I may have used the word Passive without your technical meaning behind it; but what I was posing was it shouldn't automatically mean that your bot is "in-process" because you change memory by external means. Like writing the angle of your character for example..

Writing your character's facing would be detectable on the server by looking at movement packets.

[suicidity]

That's not the question, you're missing it again and this is what I said before; Detection and it being in-process should be mixed together.

So for this particular case, Does it put you in process? Earlier you said an in-process check would in your opinion put you "in-process", well this wouldn't be an in-process check so I would imagine that wouldn't hold water anymore?

edit offtopic: I literally JUST woke back up and noticed you posted, that's a scary coincidence.

[Cypher]

That's not the question, you're missing it again and this is what I said before; Detection and it being in-process should be mixed together.

So for this particular case, Does it put you in process? Earlier you said an in-process check would in your opinion put you "in-process", well this wouldn't be an in-process check so I would imagine that wouldn't hold water anymore?

edit offtopic: I literally JUST woke back up and noticed you posted, that's a scary coincidence.

It can still be detected by Warden, it would just be 'easier' to detect on the server.

So no, I'm not changing my opinion. It still puts you in-process.

[suicidity]

So no matter what, if you 'can be/was' detected you're automatically in-process?

[Cypher]

So no matter what, if you 'can be/was' detected you're automatically in-process?

I've already friggin explained this. You're taking the entire thing in circles.

http://www.mmowned.com/forums/wow-me...ml#post1708923

[suicidity]

Was just confirming before I drew conclusions.

[Cypher]

Was just confirming before I drew conclusions.

Your original question was a strawman though. It has nothing to do with whether you can be detected, it has to be with HOW you can be detected.

[Robske]

Not aimed at the above discussion.

I'm wondering how others think about (.NET) CLR hosting and the infamous EndScene hook. There's no argue here that both are examples of in-process tampering. But how do they stand against WoW? (and it's anti-cheat software, Warden) Both can be used in perfectly legal applications such as AV and benchmarking software.

According to what Cypher said in the first post (quoted below), Can a library/application that relies only on CLR hosting and an EndScene hook be seen as "out-of-process"? (This means no calls to engine functions, no WriteProcMem etc)
Edit: Same thing other wording: Can a library/application that relies on CLR hosting and an EndScene hook be detected by warden other than module enumeration (without the risk of false positives)?

The whole point of an out-of-process bot is that you stay 100% passive so that you can't be detected unless Warden starts doing its out-of-process scans again.

[Cypher]

Not aimed at the above discussion.

I'm wondering how others think about (.NET) CLR hosting and the infamous EndScene hook. There's no argue here that both are examples of in-process tampering. But how do they stand against WoW? (and it's anti-cheat software, Warden) Both can be used in perfectly legal applications such as AV and benchmarking software.

According to what Cypher said in the first post (quoted below), Can a library/application that relies only on CLR hosting and an EndScene hook be seen as "out-of-process"? (This means no calls to engine functions, no WriteProcMem etc)
Edit: Same thing other wording: Can a library/application that relies on CLR hosting and an EndScene hook be detected by warden other than module enumeration (without the risk of false positives)?

Sorry but it seems ridiculous to me to throw away their memory hashing scans, that's how they'd most likely detect it.

However they still have their API hook scans, so they could just hash your hook sub.

So in answer to your question:
Yes, they can.

[kynox]

Not aimed at the above discussion.

I'm wondering how others think about (.NET) CLR hosting and the infamous EndScene hook. There's no argue here that both are examples of in-process tampering. But how do they stand against WoW? (and it's anti-cheat software, Warden) Both can be used in perfectly legal applications such as AV and benchmarking software.

According to what Cypher said in the first post (quoted below), Can a library/application that relies only on CLR hosting and an EndScene hook be seen as "out-of-process"? (This means no calls to engine functions, no WriteProcMem etc)
Edit: Same thing other wording: Can a library/application that relies on CLR hosting and an EndScene hook be detected by warden other than module enumeration (without the risk of false positives)?

The executable is in memory, and as such, so are the CLR opcodes. Memory hashing would work just fine in this instance.

However they still have their API hook scans, so they could just hash your hook sub.

Except the hook stub is actually a jump into the .NET runtime

[abuckau907]

seems semi relevant:

I know you'd have to debug a lot of shit, and I don't expect a full answer, but in terms of general ..catchability: if I use mouse_event API is that catchable? I mean...to wow.exe it should look 100% same as if you pushed the keys yourself, right? No not detectable..but what about the API call??

[lanman92]

That should work fine, but it will hog your computer. Possibly best(if you know what you're doing) solution is to hook GetCursorPosition at a kernel level. I do NOT recommend hooking it in user-mode, as warden is scanning it.. Mimic... Sigh. Ruining hope.

[amadmonk]

Actually sendinput is technically catchable, because it sets an "injected" flag on the input event in the kernel (I shit you not. I've traced this into the kernel). Fixing this would require a custom driver, and might well be technically infeasible from Vista onwards.

But that's just theoretical; the reality is that EVERYTHING uses sendinput; it's how, for instance, most macro keyboards work. So, they won't ban on just detection of the injected input flag.

As almost all things relating to bannability, the answer is "it depends." There are a zillion things they could, theoretically, ban you for, but almost certainly won't. And then there are things that are more... problematic. Without stepping into the whole "Cypher and suicidity show" I think that I wouldn't worry about what's in process; I'd worry about what's bannable. And that requires a lot more than just understanding the technology (which most people don't, to begin with). You have to see who ELSE uses the technology, if it has "legitimate" uses, how difficult it is to identify, and so on.

As an aside: Cypher, it would be possible with a single-render-thread app like WoW to class break stack tracing once and for all. Simply call the engine methods via a thread context EIP/ESP swap and set a hardware breakpoint on the RA. Do a little anti-anti to hide the use of the debug hook, and you're golden... as long as the code isn't reentrant

I'm all for class breaks.