State of the Warden module

[Ultimate Empire]

Here are a couple of open questions to the D2 hacking community:
-Does Blizzard still actively employ the Warden anti-hacking module with D2/WoW/SC2?
---It is hard to find 'current' information about Warden, since most of the research that is out there is from 2006-2009. My guess is that it rarely gets new dynamic updates for D2.

-Have warden updates (in the past) checked for 'specific' or 'generic' types of code. For example, has it been known to detect only 'specific' injections/modifications/client desyncing scenarios....or does it look for 'generic' techniques, such as any 3rdparty dll injection, etc.
---Understandably, the people writing the dynamic updates for the Warden code could employ either of these sets of techniques.

-Has there been any public effort to RE any of the warden's dynamic updates?
---I would be interested in knowing whether they have previously utilized shared game-state inside the status response message they send, to confirm to the server that Warden is alive and kicking.

 

[T3h Sorrow]

pretty much what happens, or is speculated to happen, for diablo 2 is on reset they will ban everyone that is flagged for hacks.

i've been using a bot/MH for a month so far and nothing, knock on wood.

 

[Wing Zero]

the valve approach to anti hacking

 

[Ultimate Empire]

Found this over at blizzhackers, released a week ago by gonzoj:

motoko v0.1.0
motoko is a plugin based therefore extensible, multithreaded clientless automation system for Diablo II, written in C and licensed under the GPL v3. It utilizes libwardenc, a library designed to handle warden communication (also written in C and licensed under the GPL v3), which is part of this project and included in the release.

What is this libwardenc mentioned earlier?

libwardenc is a shared library which is contained as a separate package within this release that programs can use to handle warden communication, at least warden's latest implementation, to be precise. It exports only a handful of functions, so dealing with warden is very convenient. After initializing the library all you have to do is passing received warden packets to the appropriate function and the library takes care of decryption, compression, loading and initializing modules as well as compiling responses. The built-in function for generating a response to 0x02 is a simple replay mechanism which loads request-response-pairs from a config file. However, you can provide a custom function for handling 0x02 requests during initialization. Furthermore, the libwardenc package also features a program called wardendump that can be attached to a running copy of Diablo II in order to dump D2GS traffic, including warden communication, generating a config file which can be used for libwardenc's built-in 0x02 handler and testing custom 0x02 handlers. Unfortunately libwardenc has a few limitations. For one thing, libwardenc provides only a selection of WINAPI functions that warden modules may depend on. Due to their calling convention a call to an unsupported WINAPI function by a warden module will most likely lead to a crash. This can be solved by specifying a custom function to resolve WINAPI references of warden modules during the library's initialization, however, depending on the modules, this might be quite a bit of work. For another thing, if Blizzard decides to change the protocol, this library will most likely need some sort of rework.

Looks like would be a very handy library to re-use in order to offensively check warden code.

After checking out the code, its written for linux. It uses <sys/ptrace.h> for the D2 process/memory/breakpoint handling which is 'very-much' linux. For a port to Windows, you'd need to use Windows functions like DebugActiveProcess, ReadProcessMemory, WriteProcessMemory.

Obviously since this a clientless (no D2 install needed) botting application, the choice of linux versus windows was up to the original dev.

 

[Ultimate Empire]

Forgot to include the link. This tar only contains source.

motoko 0 1 0 tar bz2