Warden as a module is a myth?

[PizzaSlut]

I'm trying to discover how Warden works, so I've hooked dozens of Windows API functions to monitor the behavior of Wow. I have investigated every form of shellcode or module injection that is popular mostly looking at the functions they will have to use in order to get to the point of execution. There are a bunch of Dll's that load during runtime that my prober catches, but Warden itself seems more unconventional. I do see a pattern of allocation and freeing that seems consistent with what is already known about Warden.
After login, I detect allocation with read/write/execute flags. This happens more than a dozen times, then it begins freeing those libraries and the process repeats. What is stumping me is that I never see use of the memory writing/mapping functions that are common to execute code (either the normal ones or Nt variants).

Whenever a suspicious address pops up that happens to point to a module base, I dump that module. However, 100% of the time those modules have been things like kernel32, kernelbase, ntdll, or other known modules. I'm beginning to suspect that Wow just uses mostly ntdll to do all of it's "Warden" stuff. I'm no red team expert, so it's just as likely I'm not looking in the right place. I even blocked the creation of Agent.exe and VoiceProxy to rule those out as potential external loaders but no dice.

Any information leading to the apprehension or quarantine of this suspected module would be greatly appreciated. I have a feeling the Warden stuff is just happening inside Wow.exe or I'm just not trying hard enough.

[Aceolus]

They use direct syscalls most of the time. Your hooks wont catch them unless they are kernel level. Have a look at something like inifintity hook or kaspersky hook options.

[Hazzbazzy]

</snip so no sue>

[doityourself]

They use direct syscalls most of the time. Your hooks wont catch them unless they are kernel level. Have a look at something like inifintity hook or kaspersky hook options.

That is actually not true at all. Most of their calls are done through the ntdll variants and you can work on warden fully from user mode.

[Aceolus]

That is actually not true at all. Most of their calls are done through the ntdll variants and you can work on warden fully from user mode.

My misunderstanding then. I haven't looked at it in while. Id probably trust King more though

[charles420]

def there and active nothing too new tho

[hz331215]

when the wow.exe open ,my inifintity hook has been broken by wow,i Use kernel Api NtTraceControl() to Open my inifintity hook,and when i hook this API,i found Wow.exe Use this api to close inifintity hook. So, Is this Wardan?or is just a static anti cheating.by hook NtAllocateVirtualMemory,i found wow.exe alloc so many kernel memry, in my opinion,warden may worked in kernel.but,i hooked NtLoadDriver,I can't found any wow driver use NtLoadDriver to go to kernel

[doityourself]

when the wow.exe open ,my inifintity hook has been broken by wow,i Use kernel Api NtTraceControl() to Open my inifintity hook,and when i hook this API,i found Wow.exe Use this api to close inifintity hook. So, Is this Wardan?or is just a static anti cheating.by hook NtAllocateVirtualMemory,i found wow.exe alloc so many kernel memry, in my opinion,warden may worked in kernel.but,i hooked NtLoadDriver,I can't found any wow driver use NtLoadDriver to go to kernel

everything fully usermode and also dumpable on user mode and bypassable on user mode .

There are some checks that send data outside of warden in wow too. warden itself without modules or packets that are sent for scanning things isn't doing thaat much

[charles420]

descried better then i can

[hz331215]

everything fully usermode and also dumpable on user mode and bypassable on user mode .

There are some checks that send data outside of warden in wow too. warden itself without modules or packets that are sent for scanning things isn't doing thaat much

So,warden is just a memery checking for wow self,and some usermode checking for process,windows,modules,handles? By the way, i noticed Wow use KeStackAttch() attach to it self every few minutes.Just a Usermode anti cheating,it should not ban my robot,i'm sure just usermode can't find any code of my robot.Perhaps my robot is ban by real GM? i'm not sure

[doityourself]

So,warden is just a memery checking for wow self,and some usermode checking for process,windows,modules,handles? By the way, i noticed Wow use KeStackAttch() attach to it self every few minutes.Just a Usermode anti cheating,it should not ban my robot,i'm sure just usermode can't find any code of my robot.Perhaps my robot is ban by real GM? i'm not sure

It can't use KeStackAttach. That's a kernel function...
And I'm sure your code is not hard to find (even if it is, it's possible from user mode)

[hz331215]

It can't use KeStackAttach. That's a kernel function...
And I'm sure your code is not hard to find (even if it is, it's possible from user mode)

what i want is just how to reduce ban. here is the way of my robot working:
I switch cr3 register in kernel ,then i can read wow memory directly,no handles,no attach.
Then i use a real USB drive hardware for mouse and keyboard,what can be control by my code,to control my robot.not some mouse/keyboard API or hook.It's a real mouse/keyboard hardware .
My code is injected in explore.exe ,haven't window ,use socket2.h connect to my master computer.i can control every robot remotely with robot's local system haven't any extra moudles,any extra windows,any extra process whitout wow.exe,agent.exe, wowprocy.exe.And i don't apply any wow handles,don't inject any code or hook in wow.So, how to find my code?use crc checking for explore.exe?

Before february this year,my robot can work one mouth 12 hours per day before it be ban.some robots can work so long time.After february this year, the Microsoft buy the Blizzard,my robot can't work continuity pass two days.if work less than two days,it will be transfered before it be ban. so there is what i think:
1.the main way of anti cheating is not warden,is some new code from the Microsoft.
2.the way of ban is not just to find code.there are also behavior detection, so some real players has been ban too.
3.wow.exe can't attach to it self in usermode ,but other anti cheating what working in kernel can attach to wow.exe.there are two possibility: if i have attached to wow,then anti cheating's attach can't work.If the anti cheating's attach worked,it can check wow.exe's memory by another kernel thread,not form wow inside.
I use kthread->eprocess+0x390:ProcessPathName to judge current thread is form wow.exe or agent.exe,and i catch some kernel Api call form wow.exe,agent.exe,wowprocy.exe indeed.

[charles420]

there's server side detection or as your say behavior detection as for what no one really knows for example not sure x amount ah posted x amount hrs played same path taken same rotation etc list gos on how they can check and auto ban i know botting dung was auto banned based off triggers idn what else tho

[hz331215]

i'm not sure they use what kind of behavior detection,In my case,i must to care about online time.i guess they use some math method,not only collect player rotation,perhaps they made some mathematical models,collect what kind of data depending on their mathematical models.In my case,i guess they use this way to ban my robot:this player stay at Slave fence more than two days, and this player had been reported,so GM can ban this player directly.if this player stay at Slave fence less than two days,and this player had been reported,so GM must test(transfer) this player before ban this player.the way of ban of classic seems like Season of Mastery now, power of GM seems had been Improved.