Taking a look at Warden

[lilteapot]

Hi folks,

First off, wonderful site and thanks so much for all the useful information!

I thought it would be interesting to get some first hand experience and take a look at Warden, but I'm getting some unexpected results:

1. Found warden via some magic bytes in WinDBG

s 0 L?7fffffff 56 57 FC 8B 54 24 14

2. The function is, char *__cdecl copyBytesForScan(char *dest, const char *source, unsigned int len), so I threw in a helpful breakpoint:

bp address_from_search_above ".printf \"copyBytesForScan(0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c); g"

3. The output is a little weird though. The length is always zero, and it always

1. scan some heap address, place results on the stack
2. scan the stack address the was the previous destination

Here's some output:

copyBytesForScan(0x00edd35c, 0x12a0b740, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)
copyBytesForScan(0x00edd35c, 0x37ed8190, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)
copyBytesForScan(0x00edd35c, 0x37ed82f0, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)
copyBytesForScan(0x00edd35c, 0x37ed8770, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)
copyBytesForScan(0x00edd35c, 0x37ed85d0, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)
copyBytesForScan(0x00edd35c, 0x37ed8930, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)
copyBytesForScan(0x00edd35c, 0x37ed1f30, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)
copyBytesForScan(0x00edd35c, 0x39b107b0, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)
copyBytesForScan(0x00edd35c, 0x39b10790, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)
copyBytesForScan(0x00edd35c, 0x39b10710, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)
copyBytesForScan(0x00edd35c, 0x39b10810, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)
copyBytesForScan(0x00edd35c, 0x39b106f0, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)
copyBytesForScan(0x00edd35c, 0x39b10790, 0x00000000)
copyBytesForScan(0x2944cf28, 0x00edd35c, 0x00000000)

I used the magic bytes to start off with because I wasn't having much luck setting a break on read based off of "known addresses checked by warden" (the lists I was finding were super old).

The information for monitoring the warden addresses seems to be really old as well, so maybe the technique / process has changed?

Anyways, I was hoping to find a good starting place to start looking at Warden and see what it was scanning, any help is much appreciated!

Thanks!

[verysimplenick]

del stupid answer :)

[Jadd]

You're hooking Warden's memcpy function. It's not always used by the scan function.

Look at where s_moduleInterface leads to. It's a really interesting pointer. The "real" copyBytesForScan function (I call it WardenInterface::ReadRelativeAddress) is called like so:

mov ebx, [s_moduleInterface]
mov ebx, [ebx+00000228h]
mov edx, [ebx]
call [edx+0Ch]

The function prototype looks like so:

int __stdcall WardenInterface::ReadRelativeAddress(char *dest, uintptr_t baseAddr, uintptr_t addr, size_t len)

It is only ever used when scanning for modified memory. FYI memory scanning is currently disabled (I guess they don't have updated offsets of common hacks yet,) so this function is not currently being called, ever. That's also why you're *only* getting garbage results with your current hook.

[-Ryuk-]

Another option would be to hook the function you already have and filter the results to ensure they are within the space they should be.
That's how I used to do it.

[xiathys]

You're hooking Warden's memcpy function. It's not always used by the scan function.

Look at where s_moduleInterface leads to. It's a really interesting pointer. The "real" copyBytesForScan function (I call it WardenInterface::ReadRelativeAddress) is called like so:

mov ebx, [s_moduleInterface]
mov ebx, [ebx+00000228h]
mov edx, [ebx]
call [edx+0Ch]

The function prototype looks like so:

int __stdcall WardenInterface::ReadRelativeAddress(char *dest, uintptr_t baseAddr, uintptr_t addr, size_t len)

It is only ever used when scanning for modified memory. FYI memory scanning is currently disabled (I guess they don't have updated offsets of common hacks yet,) so this function is not currently being called, ever. That's also why you're *only* getting garbage results with your current hook.

Ah, thanks so much! I don't have your version of the ReadRelativeAddress function, but trying all the possible registers gave me a similar function:



It isn't being executed at all though. I see it's part of a *massive* switch statement, and case 53 has to be taken to hit it. With the occasional exception, case 9 is the main one getting hit for me.

However, it's a few days later now and I'm seeing the previous function get hit with more interesting addresses:

...
[wow+0x002cbf53] size: 10 count:  9
[wow+0x00956bc6] size:  9 count:  9
[wow+0x002afdcb] size:  8 count:  9
[wow+0x001e202e] size:  8 count: 10
[wow+0x002ccc4c] size:  7 count: 10
[wow+0x005ade51] size:  8 count: 10
[wow+0x0010d9af] size:  9 count: 10
[wow+0x002c89c2] size:  5 count: 10
[wow+0x002d94fa] size: 13 count: 10
[wow+0x003b707c] size: 15 count: 11
[wow+0x002afd50] size:  5 count: 11
[wow+0x000c057b] size:  5 count: 11
[wow+0x000f0fa9] size:  5 count: 11
...

I've only had it running for 10-15 minutes, but it's already seen 89 unique addresses. Many of which are comparisons to constant or enum values ( 0x1100000 seems to be popular), some jumps, etc. Clearly values and points of interest



So it seems this memcpy function is being hit, but not the ReadRelativeAddress (assuming my slightly different version is in fact yours). And clearly they have offsets they are interested in based on the "memcpy" results above. Is it odd not to hit that switch statement, and then hit the ReadRelativeAddress if they have valid addresses being memcpy'd?

And I'm looking into s_moduleInterface, I'm seeing 5 xrefs so I'll check those out

Thanks!

-- edit, pictures weren't showing up, had to try again