DoString Trouble

[lanman92]

So patch 0x46EDD1 with a xor eax,eax/leave somehow? While on this topic, how does warden know when to scan?

[Cypher]

So patch 0x46EDD1 with a xor eax,eax/leave somehow? While on this topic, how does warden know when to scan?

Wtf?

It just scans every 15 seconds. It's not event driven, it doesn't get notified when a memory modification occurs. It just picks a random scan every 15 seconds and executes it.

[lanman92]

Oh. That's retarded. Couldn't they do something more intelligent? lol

[Cypher]

Oh. That's retarded. Couldn't they do something more intelligent? lol

.....

How do you propose to write a system that's event driven? The OS doesn't send out notifications to usermode applications whenever memory is read or written.

Even if you could catch all memory writes, it would be horribly inefficient, and still doesn't solve the problem that the rest of the scans can't be made event based either.

Besides, even if you solve all those problems with a magic CPU and operating system, then what? All the hacker has to do is hook an OS API at the usermode level and their memory modifications are invisible.

Not exactly stellar security.

Warden is a decent piece of software, it's just underutilized. It's far from "retarded".

[tanis2000]

Wtf?

It just scans every 15 seconds. It's not event driven, it doesn't get notified when a memory modification occurs. It just picks a random scan every 15 seconds and executes it.

So is there any way of knowing when warden is going to do exactly the scan that we want to avoid? Patching that code, executing my function and repatching it to how it was before while crossing fingers the scan is not happening in the meanwhile doesn't sound good.

It would be nice to be able to know which scan warden is performing before patching the code and eventually wait if it's our turn, just to be safe.

[Cypher]

So is there any way of knowing when warden is going to do exactly the scan that we want to avoid? Patching that code, executing my function and repatching it to how it was before while crossing fingers the scan is not happening in the meanwhile doesn't sound good.

It would be nice to be able to know which scan warden is performing before patching the code and eventually wait if it's our turn, just to be safe.

Just remove all your hooks when Warden executes any of its scans, and restore them afterwards. Much like the checksum hook.

Pseudocode:
void WardenHook()
{
if (!WardenScanning())
return CallOrigWarden();

HookMgr::RemoveAllHooks();
CallOrigWarden();
HookMgr::ReapplyAllHooks();
}

The function you want to hook is called OnFrame so you'll also need to figure out how to tell whether it's been flagged as going to scan. You can remove and reapply all your hooks every frame if you want, but that will cause laaaaaaaaaaaaaaaaaaaaaaaag.

Also, if Warden's data changes and the member you're using to detect whether it's scanning moves then obviously your hook will fail, so it's still very dangerous.

Unless you know what you're doing its probably better just to avoid warden then to actively attack it.

[Cypher]

So is there any way of knowing when warden is going to do exactly the scan that we want to avoid? Patching that code, executing my function and repatching it to how it was before while crossing fingers the scan is not happening in the meanwhile doesn't sound good.

It would be nice to be able to know which scan warden is performing before patching the code and eventually wait if it's our turn, just to be safe.

And oh, you can't do what you're saying.

The check gets called every time the function pointer is used I think, not just when you register it. So the hook needs to stay there indefinitely.

[tanis2000]

Just remove all your hooks when Warden executes any of its scans, and restore them afterwards. Much like the checksum hook.

Pseudocode:
void WardenHook()
{
if (!WardenScanning())
return CallOrigWarden();

HookMgr::RemoveAllHooks();
CallOrigWarden();
HookMgr::ReapplyAllHooks();
}

The function you want to hook is called OnFrame so you'll also need to figure out how to tell whether it's been flagged as going to scan. You can remove and reapply all your hooks every frame if you want, but that will cause laaaaaaaaaaaaaaaaaaaaaaaag.

Also, if Warden's data changes and the member you're using to detect whether it's scanning moves then obviously your hook will fail, so it's still very dangerous.

Unless you know what you're doing its probably better just to avoid warden then to actively attack it.

Yes the check is being called every time you call the function from LUA. But still.. since I am the one calling that function, I could as well make my routine wait until I'm sure warden is not scanning the check function. When everything is clear I patch it, call my LUA function, wait for it to execute (which would still be another problem as I don't know if there's anything telling me if it's done) and then repatch the check code back to how it was originally. It's a lot of stuff going on per call still ofc.


Attacking warden sounds like it's got high chances of failing.. and big time.


Another way could be identifying a piece of .text that contains code that is never used and inject my DLL in there.. but I would need to find something unused, that is big enough and that is not scanned.. and of course if there's any checksum on the whole .text it would still trigger warden.


I'm sort of stuck. I can't come up with something that can circumvent warden and still be efficient.. damn!

[Cypher]

Yes the check is being called every time you call the function from LUA. But still.. since I am the one calling that function, I could as well make my routine wait until I'm sure warden is not scanning the check function. When everything is clear I patch it, call my LUA function, wait for it to execute (which would still be another problem as I don't know if there's anything telling me if it's done) and then repatch the check code back to how it was originally. It's a lot of stuff going on per call still ofc.

If you bot relies heavily on LUA that would become horribly inefficient.

Attacking warden sounds like it's got high chances of failing.. and big time.

Yup.

Another way could be identifying a piece of .text that contains code that is never used and inject my DLL in there.. but I would need to find something unused, that is big enough and that is not scanned.. and of course if there's any checksum on the whole .text it would still trigger warden.

Err. What?

You don't get to "choose" where your DLL is injected. You can set a preferred base address for your DLL and disable image randomization and relocations, but its still not to the granularity level you're implying.

Also, to inject an entire module you'd need a VERY large empty section, chunks of unused data that size simply don't exist (because they don't need to be, it's a waste of space).

All you really need is to find 5 bytes (theres LOTS of gaps around that size), then inject an unconditional jump to your module there. Then, register that address as your callback.

You won't pass the client consistency check, but that's only on login and bypassing that has already been documented in another thread.

Warden currently only does targetted scans. Likely so that it doesn't raise false positives from things like classic PE file infectors that do the infection in memory at runtime rather than on-disk. In that situation you'd pass the login checksum (assuming you got infected while WoW was already running), but then you'd get hit by Warden's scan.

The worst they could do for a full .text or .rdata scan is a server kick or a flag and investigation, they couldn't do an automated ban, its too dangerous.

I'm sort of stuck. I can't come up with something that can circumvent warden and still be efficient.. damn!

Just do what I said.

Find 5 bytes, write a JMP to your module there, and register that as your callback. Unless the Warden guy gets off his ass and does some work (unlikely) you're fairly safe (but as always, still at risk).

[kynox]

Wtf?

It just scans every 15 seconds. It's not event driven, it doesn't get notified when a memory modification occurs. It just picks a random scan every 15 seconds and executes it.

tut. I figured you would have actually looked at my emulator source

Warden IS event driven, every 15s it receives a request from the server containing specific scans with specific data pertaining to those scans.

It then replies to the server with a packet constructed from the order of the scans requested.

[Cypher]

tut. I figured you would have actually looked at my emulator source

Warden IS event driven, every 15s it receives a request from the server containing specific scans with specific data pertaining to those scans.

It then replies to the server with a packet constructed from the order of the scans requested.

CLIENT SIDE event driven. Event driven in the context it was implied in the original post I was replying to. You silly tard.

[kynox]

CLIENT SIDE event driven. Event driven in the context it was implied in the original post I was replying to. You silly tard.

It is not random, there is specific ordering to the scans.

The context was "How does warden know when to scan?", It's told to by the server and is thus event driven.

[Cypher]

It is not random, there is specific ordering to the scans.

It doesn't matter you nub. The fact is that you can't implement the system lanman was referring to. The os doesn't notify software and say "hey, 8 bytes at 0xDEADBEEF just got modified", there's simply no callback system available for that type of functionality.

[Apoc]

It is not random, there is specific ordering to the scans.

The context was "How does warden know when to scan?", It's told to by the server and is thus event driven.

He was talking about something like this;

Modify address 0xXXXX -> Tell warden to scan.
Call function x -> Tell warden to scan.

Not having an instruction from the server telling warden to scan. (That wouldn't really be 'client side'. Even though it does involve the client being told when/what to scan.)

Hardly event driven IMO. (I don't can packet receiving as event driven btw)

[Cypher]

He was talking about something like this;

Modify address 0xXXXX -> Tell warden to scan.
Call function x -> Tell warden to scan.

Not having an instruction from the server telling warden to scan. (That wouldn't really be 'client side'. Even though it does involve the client being told when/what to scan.)

Hardly event driven IMO. (I don't can packet receiving as event driven btw)

I think Kynox forgot to take his brain medicine today.