Simple Warden Check

[DarkLinux]

Simple Warden Check


This is going to be a simple tutorial on how to see if an address is being scanned by warden. This is not an efficient way of doing things because it’s all manual and it takes some time. This tutorial will apply to any version of wow. I could automate it with hardware brake point, but that for another day. As you know it’s no one’s job to keep mmowned up to date with the latest Warden scans. This could give you an edge if your coding your own private hack.


You will need:

~World of warcraft (I am using 4.2.0)
~Cheat Engine (I am using 6.1)
~An address you would like to scan
~An address you know is scanned by warden
~And about $5 -10 to help me pay for my internet bill… (Highly recommended, Satisfaction Guaranteed)


1)
We are going to find an address that we know is scanned by warden, so we are going to take a look at the info dump thread.
http://www.mmowned.com/forums/world-...mp-thread.html
Side Note:
If you are looking to code a hack this is the place to be. Blizzard scans address that are used in hacks. So all you need to do is jump on a trail account and test each offset to see what is does. Then you can work around that scanned address to achieve the same results.
One of the downsides to this method, is that you need 1 address.
I am going to use this address

0x05FA926 Length: 5

I know that this is the old address for the fly hack, warden scans this address. Hacks like EVO work around address like that.
Side Note: I am not going to show you how to work around an address
So this is my new address I use to work around warden scan. But who knows, Blizz could update warden. So this is going to be the address that we will see if warden is scanning.

0x5FA91F

We need the address scanned by warden b/c warden is never in the same place. It is loaded into the heap. You can’t have a static address to warden. So every time you load wow you will need to repeat step #2.

2)
I recommend doing this all on a trial account just because.
We are going to start up wow and log into the game.
We are then going to start up cheat engine.
Attach CE to wow
We are going to enter both addresses into CE

Wow.exe + 05FA926
Wow.exe + 5FA91F

[spoiler]

[/spoiler]


3)
We are going to right click on the warden scanned address and select “Find out what access this address”
This can take from 1 sec to 5min
Do not pick an address that will be called without you moving.
[spoiler]

[/spoiler]

4)
The address is easy to see because it is being called from the heap, addresses in the heap are really big, for the most part.
The address some times will not be the same but they will be really close.
[spoiler]

[/spoiler]
After 2min warden scanned the address, seen above.

5)
Lets lake a closer look
[spoiler]

[/spoiler]
If it looks something like the about image, you should be good.


6)
Let’s take a look and see if our other address is being scanned by warden.
[spoiler]

[/spoiler]
This screenshot was taken after 30min, therefore warden does not scan that address.

[Sychotix]

I had heard that blizzard is less secure with trial accounts, due to the fact that people use them to test hacks, and thus get their main account banned.

[lanman92]

Wouldn't it be easy to dump warden after the hardware breakpoint was hit? Trace through the memory with NtQueryVirtualMemory or something and dump memory when you get to the region where warden is loaded?

[sitnspinlock]

hehe maybe they will toss in their anti-debug features again, not that it wont be cracked ;p

right now at the login sequence battle.net throws random rogue interrupt vectors, ntqueryinformationprocess is called twice from the
wow.exe module, also a few calls to ntsetinformationthread. battle.net checks the code bytes at those locations too lol.
also, if you try and hook these from the ntdll EAT they are still called, so they obviously store the offset to them.. lawl.

Im confused as to why they only have this 'system' in place for the login sequence and not full scale.

[_Mike]

Eek, to much manual work
Just use one of the public scanners, or if you really must insist on doing it yourself..

1) attach windbg
2) copy and paste: (red text is any known scanned offset)

bc *; ba r1 wow+11EA "bd 0; ba e1 @eip \".if(@esi>=wow){.if((@esi-wow)<0xC98000){.printf \\\"address: %N length %N\\\", \@esi-wow, \@edx; .echo}}; g\";g"

3) press f5 and wait

not extensively tested, might contain typos or cause undeads riding raptors riding sharks with lasers to spawn in your backyard.

[-Ryuk-]

You can’t have a static address to warden. So every time you load wow you will need to repeat step #2.

Not strictly true.

What you are looking is what I call the "Memory Scan Function" which is part of the Warden Tool Set. (Warden is a name for a collection of diffrent functions, or thats how I see it atleast)

Anyway, Rival posts a address called Anti-Warden in his address dump.

Using this we can find the Warden Class like so: (((Address) + 0x0) + 0x0)

This will not find the function that you are talking about, only the start of the class.

---------- Post added at 06:55 PM ---------- Previous post was at 06:53 PM ----------

I had heard that blizzard is less secure with trial accounts, due to the fact that people use them to test hacks, and thus get their main account banned.

Ive never heard this before, you could be write... But I always use trial account with my Warden stuff and ive always been fine.

[Ion78]

Ive never heard this before, you could be write... But I always use trial account with my Warden stuff and ive always been fine.

Pirox community made a raid on gmi a few days ago...

They talk to the gm and make jokes and blablaba...

Fazit: 20 trialaccs banned,16 mainaccs banned ,hack down, ‪Piroxbots Community GM Insel Raid xD‬‏ - YouTube

[Jens]

Pirox community made a raid on gmi a few days ago...

They talk to the gm and make jokes and blablaba...

Fazit: 20 trialaccs banned,16 mainaccs banned ,hack down, ‪Piroxbots Community GM Insel Raid xD‬‏ - YouTube

That was because they were morons, had nothing to do with trial accounts

[BoogieManTM]

I had heard that blizzard is less secure with trial accounts, due to the fact that people use them to test hacks, and thus get their main account banned.

Blizzard has been known to not enforce bans on trial accounts. However, when I was testing this I saw mixed results. Some things they still banned instantly for, others, not so much. When I was doing my trials, Warden was always on even on trial accounts and it was always doing the same scans - you just didn't necessarily get banned for things right away (if at all)

[DarkLinux]

Lols, Warden does scan trail accounts. For the most part I dont think they ban trail account for it. I have been using the same account from the day Blizz removed 10day trails. I have written to scanned addresses almost ever day lols. But when the jump hack still worked I got kicked in minutes for jumping in the starting zone. And they dont ban trail accounts they delete them.

That video is so funny. They think they are hackers. oooh thats going to get Blizz lols

[Sychotix]

That video is so funny. They think they are hackers. oooh thats going to get Blizz lols

It was more to troll blizzard than anything i think =P

[Dysphorie]

hehe maybe they will toss in their anti-debug features again, not that it wont be cracked ;p

right now at the login sequence battle.net throws random rogue interrupt vectors, ntqueryinformationprocess is called twice from the
wow.exe module, also a few calls to ntsetinformationthread. battle.net checks the code bytes at those locations too lol.
also, if you try and hook these from the ntdll EAT they are still called, so they obviously store the offset to them.. lawl.

Im confused as to why they only have this 'system' in place for the login sequence and not full scale.

the NtQueryInformationProcess is just checking the debugger presence. It uses a few documented ProcessDebugObjectHandle (0x1E) flag asking to return the handle of the attached debugger if present or return an error if no debugger is attached.

Acutally login in with a debugger attached can be done easily:
- modify the PEB flag
- hook the NtQueryInformationProcess, modifying the export table of ntdll works (at least if done before login, that is before battle.net.dll is loaded).
- use a debugger which can handle rogue exceptions. 3 kind of exceptions are thrown: int3 breakpoint, single step instruction breakpoint and access violation. IDA debugger manage this very well, oly also i believe, visual studio is crappy.


Once logged, battle.net.dll performs again the same checks if the main thread is paused for a certain amount of time.
This is why we have no problem while the debugger is 'passive'. And get in trouble when we breakpoint wow for several minutes.

[sitnspinlock]

the NtQueryInformationProcess is just checking the debugger presence. It uses a few documented ProcessDebugObjectHandle (0x1E) flag asking to return the handle of the attached debugger if present or return an error if no debugger is attached.

Acutally login in with a debugger attached can be done easily:
- modify the PEB flag
- hook the NtQueryInformationProcess, modifying the export table of ntdll works (at least if done before login, that is before battle.net.dll is loaded).
- use a debugger which can handle rogue exceptions. 3 kind of exceptions are thrown: int3 breakpoint, single step instruction breakpoint and access violation. IDA debugger manage this very well, oly also i believe, visual studio is crappy.


Once logged, battle.net.dll performs again the same checks if the main thread is paused for a certain amount of time.
This is why we have no problem while the debugger is 'passive'. And get in trouble when we breakpoint wow for several minutes.

thanks for the info. I was under the impression that they directly copied the assembly of the nt call and mapped it to some arbitrary location in memory, then made a function pointer to it. Which is a viable method to prevent an EAT hook if they stored the absolute offset to it somewhere within WoW.

therefore no real need for getprocaddress or any custom form of getprocaddress would really be needed. I took the time to write a driver to detour the syscall instead ;p

also, it seems from my analysis anyway, that they only used the PEB flag check (isdebuggerpresent) AFTER bnet already detected a debugger to use OutputDebugString (sorry bnet may not be run under a debugger etc.) You can check that by turning off that byte in the PEB struct, and then attempt to logon under a debugger. It will just crash instead of post that message.

[Amrok]

I wonder what would happen if you just replace the scan opcodes with 0x90 - nop ...?

EDIT: just tested it.. and just nothing happens... modified several scanned offsets.. on trial acc ofc... no scan & no ban so far

okay worked.. all the time.. just write 0x90 to scan offset+0x2 and 0x90 to scan offset+0x3