Blizzard and hacker war 3: hacker counterattack

Blizzard added the hack detection mechanism in patch 1.10, which directly led to the split of the originally harmonious d2x game hacking community. Some of them stop updating their work, such as d2hackit, out of concerns about the detection mechanism. The other part starts charging for their anti-detection functions, such as d2maphack and d2jsp; some hackers started to make these paid hacks alternatives, such as d2hackmap, C3PO, and d2bs. Some hackers even cracked these paid hacks.

As mentioned in the previous article, blizzard added packet 1.10 detection to 64/65. Jhj was the first to announce that packet 64 was used for hack detection. Of course, mousepad knew this before jhj, but he was planning to charge maphack. Anti-detection is a major selling point, so it was not published yet. After jhj published his findings, I checked the relevant code and found that packet 65 was also used for hack detection.

For example, in the previous analysis, the memory probe method is used for packet 64/65 detection. How should memory probe be handled? A simple idea is to intercept packet 64/65 detection on the client and prevent it from returning the detection results. The idea of intercepting packet 64/65 is correct, but not returning the detection result is actually a kind of information. Blizzard may determine based on this that you are using hacks and will kick you offline in the worst case, obviously not a good practice. A better way to deal with memory probe is to forge the detection results. This requires interception of packet 64/65 detection, and then the data before the address is modified (if it has been modified) is returned Based on the memory address to be detected. No matter which address is detected, the detection results are the same as those when hacks is not used.

There are about three implementation methods.

One is that when installing the bypass, hack first saves the original data so that the data before the patch can be known during detection. D2maphack and d2jsp are used in this method. This method is the simplest, easy to implement, and takes up little extra memory. The disadvantage is that you can only protect yourself, not other hacks.

The second method is implemented by jhj. The principle is to back up the important DLL used in the game before loading any hack, so as to obtain the clean copies of these DLL. Then, the packet 64/65 detection entry is intercepted and the corresponding data is returned from the clean copy based on the detection address. This is the antidetection. dll released by jhj in the 1.10 period. The biggest advantage of this method is its universality. It can protect other hacks-other hack and avoid detection without any anti-detection measures. However, this implementation also has many drawbacks. One is that it must be loaded before all other hack, otherwise, you cannot obtain a clean copy.-If you cannot obtain a clean copy, this method is completely meaningless.-in some cases, this is not easy to do, such as an unattended bot. Second, all important DLL files need to be backed up, which consumes a lot of extra memory, which has a great impact on players with poor machine configuration or multiple bots. The third is that antidection. dll only backs up the DLL that it deems important, rather than all the DLL. In this way, if the DLL modified by some hack is not protected by it, it may still be caught.

The third method is implemented by me, which is called module re-construction. It is first implemented in d2hackmap. Later, Abin asked me to help implement the Anti-detection module when upgrading d2hackit, so I integrated it into d2hackit 2.00. The idea of this method is to intercept the packet 64/65 detection entry (obviously all anti-detection methods need this step) and determine the target Module name and its path to the hard disk file based on the detection address, then, re-create a clean copy from the hard disk file of the module, and return the corresponding data from the clean copy. This method does not consume additional memory when no activity is detected (in fact, packet 1.10 is rarely detected in the 64/65 period), it can protect all DLL and does not require preemptive loading. I personally think it is an ideal method. Of course, the difficulty of the module reconstruction method is how to re-create a copy from a DLL file that is exactly the same as that before the loaded module is modified (in fact, the code segment is exactly the same as the read-only data segment, it doesn't matter if you read and write data segments. This will be introduced in future articles.

In addition to packet 64/65 detection, do not forget the version-checking.dll and extrawork. dll mechanisms that have been present before 1.10. Although they were never used for hack detection in the first 1.10 period, blizzard had to defend against hacks because it had to do so. Recall the two mechanisms. Because both DLL files are stored on the server, they must be sent to the client for running and return results. It is obviously impossible to prevent them from running. Obviously, their detection methods are infinite and unknown, and counterfeit detection results are not feasible. What should we do?

A more effective way to deal with this approach is to intercept and store as many DLL files from the server as possible, analyze them one by one, and Mark safe and insecure ones, create a signature for each DLL ). In this way, each time the client receives the DLL, it calculates its signature and compares it with all the DLL signatures that have been analyzed in advance, in this way, you can know that the DLL is not secure (that is, whether to detect my hack). If it is secure, you can run it. If it is not secure, hack uninstalls it by itself, then let the DLL run. In this way, it will not be caught. In addition, for an unknown module (that is, the DLL signature is not in the list), save it for later analysis, and uninstall it to ensure security, after further analysis, mark it as secure or insecure. Of course, for insecure modules, we should further study the anti-detection method and mark it as a security module. D2maphack and d2jsp adopt this strategy. D2hackmap since I didn't have much energy to manually analyze these modules, I only set the switch variable in the configuration file, it instructs d2hackmap how to deal with these modules (three options are ignored, uninstalling itself, saving module files, and uninstalling itself ). As for the antidetection. dll of jhj, there is no anti-protection in this aspect. It turns out that this strategy is more effective. One possible reason is that due to design limitations, this DLL sending detection mechanism is not capable of Rapid Deformation and frequent operation.

In summary, the confrontation between Blizzard and hackers ended in the victory of hackers during the 1.10 period. Throughout the 1.10 period, I did not remember the large-scale ban CD-key and account blocking events.