[Question] Warden Scanner and hooking

[daCoder]

Hi,

i try to understand how a warden scanner works and playing around to build one.
My frist attempt was hooking the NetClient and look into the incoming packets to find the bytes others posted as warden scans, but it failed. Later i've read, that this packets are encrypted additionally, don't know if this is true.

My question is, which functions can be hooked to build a warden scanner? Maybe WardenClient_Process?
How does the data structure look like? Something like int size, int addr, void* bytestoscan ?

Cheers,
daCoder

[Jadd]

The whole Warden client is sent to the user after logging in and is loaded using LoadLibrary API. You won't find it in any static memory.

Place a read breakpoint on a scanned address and you'll get your address scan function. There's also some API hook scans and DLL scans but in most cases with private hacks/bots you won't need to worry about these.

[daCoder]

Thank you very much, i've extracted the warden client. It has a BLL2 header and with a size of 40KB.
There is one accesspoint in the client, which is a selfmade memcpy(buffer, readaddr, size) function at 0x10C5.

Is there some kind of protection, or is it safe to set hooks in the warden client?

If yes, warden can be fooled by copying the original values into the buffer using our code I guess there is some pitfall, can't be that easy.


Update:

I monitored the value inside the memcpy function, which is also used for internals usage, like string copy. Anyways, i set a filter on the source address to be inside the .text segment, which results now in 47 unique entries collected in about an hour. Same count as the list in the infodump thread, i didn't check if the offsets are the same, but i guess so.
Wardenscans for 5.0.4.16016

Offset: 06FCF4  Length: 7 Bytes: E8 E7 49 1F 00 8B 0D 
Offset: 07060A  Length: 7 Bytes: 83 C4 08 85 C0 74 EF 
Offset: 0755BD  Length: 5 Bytes: 8B 4D 10 89 0D 
Offset: 3F9270  Length: 9 Bytes: 55 8B EC 83 EC 18 56 8B F1 
Offset: 3FAE30  Length: 9 Bytes: 55 8B EC 83 EC 10 53 56 8B 
Offset: 423260  Length: 9 Bytes: 55 8B EC 8B 45 0C 83 EC 08 
Offset: 447950  Length: 10 Bytes: 55 8B EC 81 EC B8 00 00 00 8B 
Offset: 448CB2  Length: 7 Bytes: E8 F9 0D D2 FF 8B F0 
Offset: 487910  Length: 10 Bytes: 8B 81 08 08 00 00 25 00 00 80 
Offset: 4A84CB  Length: 4 Bytes: 85 DB 74 1F 
Offset: 4A84CD  Length: 4 Bytes: 74 1F 8B 06 
Offset: 4EB371  Length: 7 Bytes: 0F 2F 44 08 08 72 06 
Offset: 4EE605  Length: 7 Bytes: A9 00 00 00 04 74 24 
Offset: 4EE60A  Length: 7 Bytes: 74 24 A9 00 00 10 00 
Offset: 4EEDA9  Length: 9 Bytes: F7 41 38 00 02 00 20 75 34 
Offset: 4F26F3  Length: 11 Bytes: 01 7E 74 8B CE E8 43 A6 FF FF 8B 
Offset: 52C243  Length: 4 Bytes: 7E 0B 8B CE 
Offset: 56C964  Length: 4 Bytes: 78 47 05 C0 
Offset: 573F51  Length: 6 Bytes: 8B EC 83 3D E8 FC 
Offset: 573F62  Length: 7 Bytes: 74 65 83 F9 1C 77 60 
Offset: 580615  Length: 5 Bytes: 77 34 FF 24 85 
Offset: 5989F0  Length: 12 Bytes: 55 8B EC B8 A0 42 00 00 E8 83 06 20 
Offset: 598E94  Length: 5 Bytes: 74 13 83 F8 10 
Offset: 598EA7  Length: 9 Bytes: 75 0A 8B 4D 10 C7 41 04 00 
Offset: 59C0D0  Length: 12 Bytes: 55 8B EC 81 EC 20 0E 00 00 6A 0A E8 
Offset: 6EB778  Length: 5 Bytes: 74 2A F6 40 34 
Offset: 714E61  Length: 4 Bytes: 75 0B 5F 5E 
Offset: 714E89  Length: 13 Bytes: 0F 85 4E 02 00 00 8D 55 DC 52 8D 45 CC 
Offset: 76316E  Length: 8 Bytes: F7 C3 00 00 F0 00 74 28 
Offset: 763174  Length: 5 Bytes: 74 28 8B 4D 18 
Offset: 76319E  Length: 8 Bytes: F7 C3 F0 00 03 00 74 1D 
Offset: 7631A4  Length: 5 Bytes: 74 1D 8B 4D 18 
Offset: 7631CE  Length: 8 Bytes: F7 C3 00 01 00 00 74 13 
Offset: 7631D4  Length: 5 Bytes: 74 13 8B 4D 18 
Offset: 7631E9  Length: 5 Bytes: F6 C3 0F 74 21 
Offset: 7631EC  Length: 5 Bytes: 74 21 8B 4D 18 
Offset: 796C90  Length: 9 Bytes: 55 8B EC 8B 45 0C 8B 4D 08 
Offset: 8B5BEF  Length: 9 Bytes: F7 41 38 00 00 10 01 74 65 
Offset: 8B5BF6  Length: 5 Bytes: 74 65 D9 41 50 
Offset: 8B96C0  Length: 7 Bytes: A9 00 00 00 10 74 07 
Offset: 8B9700  Length: 5 Bytes: 75 3E F6 46 3C 
Offset: 8B9E53  Length: 12 Bytes: 81 66 38 FF FF 9F FF 8B 4E 3C 8B 46 
Offset: 8C1330  Length: 9 Bytes: 55 8B EC 51 53 56 8B 75 08 
Offset: 933DB0  Length: 8 Bytes: 2F 54 9A 41 43 4D 69 73 
Offset: 937B7C  Length: 4 Bytes: BB 8D 24 3F 
Offset: A0B3B0  Length: 8 Bytes: D8 93 FE C0 48 8C 11 C1 
Offset: A725BC  Length: 6 Bytes: 04 00 00 00 2C FC

Wardenscans for 5.0.5.16048 (same functions on new offsets)

Offset: 0006FA74 Length: 7 Bytes: E8 87 48 1F 00 8B 0D 
Offset: 0007038A Length: 7 Bytes: 83 C4 08 85 C0 74 EF 
Offset: 0007536D Length: 5 Bytes: 8B 4D 10 89 0D 
Offset: 003F7F10 Length: 9 Bytes: 55 8B EC 83 EC 18 56 8B F1 
Offset: 003F9AE0 Length: 9 Bytes: 55 8B EC 83 EC 10 53 56 8B 
Offset: 00421F20 Length: 9 Bytes: 55 8B EC 8B 45 0C 83 EC 08 
Offset: 004466C0 Length: 10 Bytes: 55 8B EC 81 EC B8 00 00 00 8B 
Offset: 00447A22 Length: 7 Bytes: E8 09 1D D2 FF 8B F0 
Offset: 00486230 Length: 10 Bytes: 8B 81 08 08 00 00 25 00 00 80 
Offset: 004A714B Length: 4 Bytes: 85 DB 74 1F 
Offset: 004A714D Length: 4 Bytes: 74 1F 8B 06 
Offset: 004EA311 Length: 7 Bytes: 0F 2F 44 08 08 72 06 
Offset: 004ED2E5 Length: 7 Bytes: A9 00 00 00 04 74 24 
Offset: 004ED2EA Length: 7 Bytes: 74 24 A9 00 00 10 00 
Offset: 004EDA89 Length: 9 Bytes: F7 41 38 00 02 00 20 75 34 
Offset: 004F13D3 Length: 11 Bytes: 01 7E 74 8B CE E8 33 A6 FF FF 8B 
Offset: 0052AE53 Length: 4 Bytes: 7E 0B 8B CE 
Offset: 0056B574 Length: 4 Bytes: 78 47 05 C0 
Offset: 00572B71 Length: 6 Bytes: 8B EC 83 3D E8 FF 
Offset: 00572B82 Length: 7 Bytes: 74 65 83 F9 1C 77 60 
Offset: 0057F445 Length: 5 Bytes: 77 34 FF 24 85 
Offset: 00597810 Length: 12 Bytes: 55 8B EC B8 A0 42 00 00 E8 23 13 20 
Offset: 00597CB4 Length: 5 Bytes: 74 13 83 F8 10 
Offset: 00597CC7 Length: 9 Bytes: 75 0A 8B 4D 10 C7 41 04 00 
Offset: 0059AEF0 Length: 12 Bytes: 55 8B EC 81 EC 20 0E 00 00 6A 0A E8 
Offset: 006EB0E8 Length: 5 Bytes: 74 2A F6 40 34 
Offset: 007148B1 Length: 4 Bytes: 75 0B 5F 5E 
Offset: 007148D9 Length: 13 Bytes: 0F 85 4E 02 00 00 8D 55 DC 52 8D 45 CC 
Offset: 00762BEE Length: 8 Bytes: F7 C3 00 00 F0 00 74 28 
Offset: 00762BF4 Length: 5 Bytes: 74 28 8B 4D 18 
Offset: 00762C1E Length: 8 Bytes: F7 C3 F0 00 03 00 74 1D 
Offset: 00762C24 Length: 5 Bytes: 74 1D 8B 4D 18 
Offset: 00762C4E Length: 8 Bytes: F7 C3 00 01 00 00 74 13 
Offset: 00762C54 Length: 5 Bytes: 74 13 8B 4D 18 
Offset: 00762C69 Length: 5 Bytes: F6 C3 0F 74 21 
Offset: 00762C6C Length: 5 Bytes: 74 21 8B 4D 18 
Offset: 00796750 Length: 9 Bytes: 55 8B EC 8B 45 0C 8B 4D 08 
Offset: 008B576F Length: 9 Bytes: F7 41 38 00 00 10 01 74 65 
Offset: 008B5776 Length: 5 Bytes: 74 65 D9 41 50 
Offset: 008B91D0 Length: 7 Bytes: A9 00 00 00 10 74 07 
Offset: 008B9210 Length: 5 Bytes: 75 3E F6 46 3C 
Offset: 008B9963 Length: 12 Bytes: 81 66 38 FF FF 9F FF 8B 4E 3C 8B 46 
Offset: 008C0E40 Length: 9 Bytes: 55 8B EC 51 53 56 8B 75 08 
Offset: 00933E20 Length: 8 Bytes: 2F 54 9A 41 43 4D 69 73 
Offset: 00937B74 Length: 4 Bytes: BB 8D 24 3F 
Offset: 00A0B3C8 Length: 8 Bytes: D8 93 FE C0 48 8C 11 C1 
Offset: 00A725BC Length: 6 Bytes: 04 00 00 00 1C FC

I've already started to disassemble and analyse the client functions. I my statement above is correct, than all we have to do is to hook the warden client and watch for the overwritten offsets and warden is no more

[Jadd]

Good job. It's the first question I've seen in a while where a grey member actually solved their own problem rather than just asking for a handout

If yes, warden can be fooled by copying the original values into the buffer using our code I guess there is some pitfall, can't be that easy.

Never overestimate Blizzard!

[sitnspinlock]

I've already started to disassemble and analyse the client functions. I my statement above is correct, than all we have to do is to hook the warden client and watch for the overwritten offsets and warden is no more

yes. think of warden as a hackme obstacle in your course of learning. however warden anti-cheat is flawed from the get-go. it is quite possibly thee poorest attempt at code integrity i have ever witnessed. sometimes I am honestly not even sure if warden is actually just a joke for shits and giggles - one cannot be sure.

but the fact that warden does not even attempt to modify debug registers prior to accessing a page for an integrity check is always your best method of locating it.

[_Mike]

yes. think of warden as a hackme obstacle in your course of learning. however warden anti-cheat is flawed from the get-go. it is quite possibly thee poorest attempt at code integrity i have ever witnessed. sometimes I am honestly not even sure if warden is actually just a joke for shits and giggles - one cannot be sure.

but the fact that warden does not even attempt to modify debug registers prior to accessing a page for an integrity check is always your best method of locating it.

Those who don't know what they're doing will get caught, and those who do know will eventually find a way around anything they do so it seems logical that they don't want to spend time and money on making it more advanced. Afaik there is no anti-cheat in existence that hasn't been disabled or circumvented, at least partially.
It seems to me that they are using more targeted methods when/if things really gets out of hand, glider and lua ninja for example, instead of a generic catch them all approach.

But from a "hacker" point of view it would be fun if it was at least a bit more challenging

[Master674]

Anyways, i set a filter on the source address to be inside the .text segment, which results now in 47 unique entries collected in about an hour

What about .rdata? And they also scan a trap in .data!

At first we didn't even get banned when we just redirected all scans to read from the wow.exe binary in our first private hack lol.

[daCoder]

Thank you Jadd!

@everdox: Modifying debug registers wouldn't solve the problem, but could be more challenging I don't think, there is a solution for this problem at all. They have to secure all the way from loading to execution.

@Mike: Agree with you But WoW is challenging me enough atm Was trying to find the path of encryption of the warden packets, but had no luck. I am not even sure, which opcode is a warden package, the count of the incoming packages is huge :/

@Master674: thx for this information, i will have a look, if i can extend it to the whole data section. i am hooking the memcpy function which can result in many false positives outside the .text section. I have to try
You got banned by redirecting the scan to the binary? This means, there is somewhere a integrity check. At the moment i have collecting the warden scans by manipulating the client code directly. I guess the only secure way would be using exec breakpoints, without modifying the code itself.

Generel question: What happens if warden detects a manipulated code? Will it be an instant ban or disconnect? Or will it be some kind of user marking?

[Master674]

Thank you Jadd!

@everdox: Modifying debug registers wouldn't solve the problem, but could be more challenging I don't think, there is a solution for this problem at all. They have to secure all the way from loading to execution.

@Mike: Agree with you But WoW is challenging me enough atm Was trying to find the path of encryption of the warden packets, but had no luck. I am not even sure, which opcode is a warden package, the count of the incoming packages is huge :/

@Master674: thx for this information, i will have a look, if i can extend it to the whole data section. i am hooking the memcpy function which can result in many false positives outside the .text section. I have to try
You got banned by redirecting the scan to the binary? This means, there is somewhere a integrity check. At the moment i have collecting the warden scans by manipulating the client code directly. I guess the only secure way would be using exec breakpoints, without modifying the code itself.

Generel question: What happens if warden detects a manipulated code? Will it be an instant ban or disconnect? Or will it be some kind of user marking?

In most cases Warden will flag you for a ban. The ban can take up to weeks until it finally bans you.
We also take the memcpy function at the moment, if you find a better one would be nice if you could pm / post here.

[sitnspinlock]

Thank you Jadd!

@everdox: Modifying debug registers wouldn't solve the problem, but could be more challenging I don't think, there is a solution for this problem at all. They have to secure all the way from loading to execution.

@Mike: Agree with you But WoW is challenging me enough atm Was trying to find the path of encryption of the warden packets, but had no luck. I am not even sure, which opcode is a warden package, the count of the incoming packages is huge :/

@Master674: thx for this information, i will have a look, if i can extend it to the whole data section. i am hooking the memcpy function which can result in many false positives outside the .text section. I have to try
You got banned by redirecting the scan to the binary? This means, there is somewhere a integrity check. At the moment i have collecting the warden scans by manipulating the client code directly. I guess the only secure way would be using exec breakpoints, without modifying the code itself.

Generel question: What happens if warden detects a manipulated code? Will it be an instant ban or disconnect? Or will it be some kind of user marking?

modifying the debug registers would pose a significant advantage for warden. so many methods of rolling out a code integrity module or even some self modifying code to do the work and the methods of relaying this data between server and client could always easily be changed. but a knocking out a crucial starting point such as memory access breakpoints on interesting pieces of executable code or global data would certainly slow a great deal of even intermediate level reverse engineers down quite a bit.

[Jadd]

In your memory write function, read the bytes at this address and save them in a list. Detour the scan function and if the offset is in the list (or if it's partially in the list), direct it to the original bytes. You'll also need to maintain appending/prepending original bytes to offsets already in the list, etc. Doing so will allow you to write to scanned addresses and make easy hacks - just check out a Warden scan list and start writing to these offsets to see what happens!

Just be careful while doing all of this. One mistake is the difference between a banned and unbanned account

[Empted]

Got strictly same 47 scans now (on my main acc, not trial, if it matters ofcourse) in about 10 minutes, they are scanned quite frequently . Filtered from base to (base+sections length). Also checked if warden scanned any adress inside itself, but it doesn't. So simple detour with several pop/push will do to avoid any scans. Btw isn't that mempcy function located at WardenBase + 0x79D8 ? Didn't find any on 0x10C5.
P.S. WardenBase can be easily found by signature . Adding 0x79D8 will lead to func starting with 'push esi'. That is the one all are talking about.

[daCoder]

I've dumped the warden client only one time. maybe the client itself is changing?
md5sum of the dumped client: 0f784da4dbd7757f37dd834afa7687a8 (40960 Bytes, the whole mapped area)
I am gonna dump the warden client again later, lets see if it changes.

I was busy the whole day with trying to understand, which functions warden wants to protect.
I've compared the windows version disassembly with the mac os x disassembly, which has the symbol names, to get the real functions names and the parameters for better understanding and later use

What i got so far are these functions and two values inside .rdata.

FrameScript_ExecuteBuffer(char  const*,ulong,char  const*,CStatus *,char  const*)
NetClient::HandleData(ulong,void *,int)
NetClient::Send2(CDataStore *,CONNECTION_ID)
CGPlayer_C::CGPlayer_C(ulong,JamCliObjCreate const&)
CMovement_C::ExecuteMovement(ulong,ulong)
MovementIdleMoveUnits(void  const*, void *)
CGUnit_C::UpdateSwimmingStatus(ulong,int)
CMovement_C::GetFacetQueryFlags(void)
World::IsValidPosition(C3Vector const&,float)
CMovement_C::TraceSurface(ulong,uint,float,C2Vector const&)
CGGameUI::UpdatePlayerAFK(ulong,CGPlayer_C *)
CGGameUI::CanPerformAction(UIACTIONTYPE)
CGGameUI::Initialize(void)
CGChat::AddChatMessage(char const*,SLASH_COMMAND_ID,ChatMessageParams *)
Script_SendChatMessage(lua)
World::QueryObjectLiquid(CMapBaseObj *,uint &,float &,int &)
CMovementShared::Jump(int)
CMovementShared::StopSwim(void)
Grunt::ClientLink::PackLogon(CDataStore &,Grunt::ClientLink::Logon const&)
.rdata used in CMovementShared::Jump(int)
.data used in CGlueMgr::DisplayLoginStatus(void)

Functions i couldn't identify are

sub_46FCF0
sub_4705A0
sub_487910 something camera related?
sub_4EB320
sub_B14E40
sub_B630B0
sub_CB5BB0  CMovement_C::something

933DB0 .rdata
937B7C .rdata

I am wondering, which kind of hacks they want to protect. Which is obvious is Waterwalk, Flyhack, network packet functions, afk hack.
But i don't know, why they are protecting the chat related stuff.


And i extended my filter to collect everything from 0x0 to .data END and didn't get any false positives. Still the same 47 results.

@Jadd: Suspending on detection, stopping hack and restoring the original bytes and letting it scan? This sounds like a laggy or buggy hack, warden scans many times in a minute. Do you think this is practicable? My original idea was not letting him scan the address itself. Since we can control memcpy, we can do something like "if (addr_to_scann == myaddr) cpy(destination, orgbytes)". I am not sure how and if they are controlling this function, but according to Masters post, he got banned doing something like this.

Update:
Changed .rdata used in CGlueMgr:isplayLoginStatus(void) to .data
Thx to Jadd for pointing out this.

[Master674]

If warden is loaded they set some value to 1 in .data, this value is scanned later in the memcpy function... so ITS A TRAP!! D:
Or maybe not... Well they could detect redirecting to binary really easy with something like this.

[Empted]

Mine md5 is 4F2D38212F90116C2868758C39BCD662. Seems like it differs. But still memcpy func is always at offset 0x79D8. Checked several time already If we are talking about the same func ofc.
@Master674: Didn't see any scanned adresses in .data. For more than hour.