Blizzard and hacker war 5: incomplete technical analysis of Warden

The previous article mentioned the basic working principles of warden. This article describes how warden works in terms of its implementation. The first thing to note is that I didn't spend a lot of effort on warden, but I did not guarantee that I was correct in some incomplete analyses.

When the game client connects to the game server to enter the game (when wow is logged on), the client and server first negotiate a new session key (128-bit RC4) for subsequent warden communication. The negotiate process is also encrypted (Maiev. Mod mentioned above ). The key point here is that the warden data exchange between the client and the server is encrypted, and the key is dynamically generated.

The actual cheating detection module (usually known as warden mod, or later referred to as. mod) is placed on the server. After the warden session is established, the server sends the. Mod to the client using packet AE, and the client uses packet 66 as the response. The format of the response data is as follows. moD is related, not fixed, or simply sending back a yes or no to say there is no cheating, so I want to forge. it is not feasible for all common responses of Mod. In order to be suitable for transmission, blizzard makes. Mod very compact, the format is similar to DLL, which consists of code segment, relocation segment, IAT and other data. Original received by the client. moD data is compressed (usually only a few Kb). After decompression, the client uses the first data pair. moD assembly (similar to DLL loading), and then call. the MOD detection entry function executes the real detection code.

The. Mod Header Format is as follows:

Struct wardenmodheader_t
{
DWORD cballocsize; // + 00
DWORD offsetfunc1; // + 04
DWORD offsetrelocaddresstable; // + 08
DWORD nreloccount; // + 0c
DWORD offsemodentry; // + 10
DWORD _ 2 [2];
DWORD offsetimpaddresstable; // + 1c
DWORD nimportcount; // + 20
DWORD nsectioncount; // + 24
DWORD _ 3 [1014];
// Below follows Code Section
};

Cballocsize indicates the amount of memory allocated to this. Mod (via virtualalloc ). Offsetrelocaddresstable provides the offset of the relocated table. Nreloccount specifies the number of items to be relocated (usually some global variables need to be relocated ). Offsetmodentry is the entry of the. Mod detection function. The client loads the. MOD file and calls this function for detection. The detection result is sent back to the server through packet 66. Offsetimpaddresstable indicates the offset of the IAT table. The IAT table specifies which external functions (generally windows APIs) are used by. Mod ). The first step of the analysis. mod is to observe the IAT table and check the windows API it calls. Sometimes, you can simply judge the behavior of this. Mod. This is part of IAT data that I have intercepted. Mod:

Seg000: 1b7730a0 akernel32_dll dB 'kernel32. dll ', 0
Seg000: 1b7730ad aprocess32first dB 'process32first ', 0
Seg000: 1b7730bc aisbadreadptr dB 'isbadreadptr ', 0
Seg000: 1b7730c9 amodule32first dB 'lele32first', 0
Seg000: 1b7730d7 aprocess32next dB 'process32next', 0
Seg000: 1b7730e5 agetmodulehandl dB 'getlelehandlea', 0
Seg000: 1b7730f6 acreatetoolhelp dB 'createconlhelp32snapshot ', 0
Seg000: 1b77310f amodule32next dB 'lele32next', 0
Seg000: 1b77311c aclosehandle dB 'closehandle', 0
Seg000: 1b773128 alstrcmpia dB 'lstrcmpia ', 0
Seg000: 1b773132 auser32_dll dB 'user32. dll ', 0
Seg000: 1b77313d agetwindowtexta dB 'getwindowtexta ', 0
Seg000: 1b77314c aenumwindows dB 'numwindows ', 0
Seg000: 1b773158 acharupperbuffa dB 'charupperbuffa', 0
Seg000: 1b772137 afind0000wa dB 'find0000wa ', 0

Obviously, for experienced programmers, when they see process32first/process32next, they will know that they want to search the suspicious (plug-in) process. When they see module32first/module32next, they will know that they want to search the suspicious (plug-in) DLL, if you see enumwindows/find0000wa, you will find a specific window. However, it should be noted that all APIs listed in IAT will be used. For example, here it may only use module32first/module32next. In order to make the analysis more difficult, not all the APIs used by. Mod are listed in IAT.

In the early days of warden's appearance, it was often used by the server to use packet AE to upload the list of DLL names to be detected ,. moD uses module32first/module32next to enumerate all DLL files in the game process. If the plug-in you load is on its blacklist, you will be caught. For example, the list may be d2maphack. DLL, d2hackit. DLL, easymap. DLL, So if you use easymap, it will be unlucky. If you use d2hackmap, it will be okay-that is why the complete version of d2hackmap has not been detected and has not been caught for a long time. It is worth mentioning that the DLL list uploaded by the server is not like "d2maphack. DLL, d2hackit. DLL, easymap. DLL, but the hash (SHA-1 hash) of these strings ),. moD compares the DLL with their hash values. That is to say, it is very difficult to use sniffer to capture packets and observe which DLL files it wants to capture.

In wow, early warden caught some plug-ins through process32first/process32next, (Wow! Sharp, etc ). Blizzard's practice has aroused widespread controversy because it detects non-game processes. An article by wow hacker HOGLUND: is the warden spyware? It has been widely reported by overseas media (such as the BBC. This even shocked the famous cryptology Bruce Schneier (author of the classic book "applied cryptography") and commented on it. HOGLUND also wrote a monitoring program specifically for this purpose: the governor-keeping blizzard honest-name is very good, in fact, the thing is very simple, just intercepted several APIs to spray some information.