Document directory
- I-Introduction
- II-check of loaded modules
- III-hooks, patches, and CRC checks
- IV-Summary
- V-Appendix
This is an article published on rootkit.com to discuss how to circumvent the warden detection mechanism. The original Article is here. The author darawk is a hacker of D2. Previously, blizzard used module32first/module32next to crack down on plug-ins in D2 1.11 for the first time. Many players who used plug-ins, especially Netter's easymap, suffered heavy losses. Hackers began to think about the anti-Warden issue. This article is an attempt in this regard. Later, with the help of darawk, Netter implemented anti-warden in easymap/easyplay. The methods proposed in this article are gradually used in several versions of easymap/easyplay, but these versions are still caught later. However, the several ideas described here are of great reference significance. For example, the use of debugging registers to hook functions has been applied in some plug-ins of wow.
The link addresses of several source code files provided by the author in the appendix have expired and can be downloaded from here if necessary. -------------------------------------------- I-some of you may already know that many gaming companies have recently taken severe measures against "hackers. They implement a comprehensive detection mechanism based on the user State (userland), from very simple to extremely complex. I have spent a lot of time over the past few weeks trying to find a common method to avoid detection. In a sense, the situation we face is very similar to that of gaming companies: you only need to find a weakness in their gaming systems to take advantage of them, and they must design their systems without any loopholes; similarly, when we hide ourselves from their detection code, they only need to find a mistake to catch us, and we need to design and implement the system perfectly. The following is my attempt in this regard. It is certainly not complete or perfect, but I think this is the first step towards this goal. II-check of loaded modules
Let's assume that we want to load a module to the target (Most plug-ins or bot practices ). We must differentiate two different cases, which may cause malicious modules to be detected. These two situations are: injection time and other times (when the plug-in is loaded and the plug-in is working ).
Basically, each DLL injection method calls loadlibrary somewhere. Therefore, if you want to capture a module, a simple detection method is to intercept loadlibrary (or ldrloaddll, or a more underlying native API ).
There are two solutions to this problem. The first and simplest method is to randomize the module name. Many legitimate software inject DLL (Trillian, aim, hotkey software, etc.) into all processes in the system ), A reasonable detection system does not use the "whitelist" design (this detection method confirms that only verified modules can be loaded, think of all those that are not listed in the White List as malicious modules), so they can only use the blacklist, which makes the Randomization Module name a perfect and feasible solution to deal with such detection.
Another method I implement is to inject DLL in another way, which I call manual mapping ). First glance, simulating windows PE Loader is frustrating-it's hard for you to make everything right. But in fact it is not that difficult. I use the manualmap (appendix) code. I know that manualmap can also be improved a lot-in fact, I have a version that is greatly improved-this is just a proof concept.
After the module is injected into a running process, there are two ways to detect it. The first is to scan the module linked list or call getmodulehandle for modules that you think are plug-ins to see if getmodulehandle returns NULL ). You can use tools such as cloakdll (appendix) to remove your modules from the linked list. Or use manualmap, so that your module will not be added to the linked list from the very beginning. I think the second approach is better, but they are almost the same. The second method for detecting loaded modules is much more intelligent. It is used to enumerate all memory pages in the system (the Memory Page is 1024 bytes aligned, so it is easy to do) and then check the signature of bad code. The countermeasure is to make an improved DLL loader, and randomize the boundary of the memory page to the starting offset of the actual data, that is, do not load the DLL at the page boundary, but there is a random offset from the boundary ). However, I think the better way is to create two new blank pages to wrap your module, and then use virtualprotect to set the page_guard flag for the two pages. An exception is thrown when access to the bucket marked with page_guard is detected. You can use the unhandled exception filter and vectored exception handling) or the kiuserexceptiondispatcher hook (I recommend the latter) captures these exceptions, so that you will have the opportunity to do some processing when you encounter a scan to prevent the detection code from capturing you. The III-hooks, patches, and CRC checks are useful for people to use plug-ins to basically modify game code in some way. However, modification to the code is very easy to detect, and no one has been able to propose a feasible and general solution to this problem. I am afraid I do not dare to claim that I have completely solved this problem, but I have found a way to make it tame. I have proposed a method to hook functions without modifying any target Process Code. The only drawback is that you can only hook four functions at the same time. My approach is to use the debug register (that is, the hardware breakpoint), you can see my implementation in the Chook class in the appendix. Because the debugging register is quite easy to detect, anyone who calls getthreadcontext with context_debug_registers can find it. Any exception handling routine will get a context structure containing the debugging register ), and so on. The solution is to hook ntgetcontextthread, ntsetcontextthread, and kiuserexceptiondispatcher. Of course, you must use some patches to hook these Apis. Some anti-virus, anti-advertising, and firewall software also hook these functions to "enhance the overall security of the system ", therefore, if you modify these system DLL, it is unlikely that you cheat. This means you can hook these four functions securely without worrying about being detected. Even though they may not catch you just because they find these hooks in the system module, they leave a clue for detection-they can locate your hooks in the system module, analyze the patch jump command to see where it jumps, and then perform a CRC operation on the hook processing process to recognize you. There are two solutions. One is to use the INT 3 breakpoint command for Hook, and then catch exceptions (if you read it carefully, you will find it is also implemented in my Chook class) and redirect the exception to the appropriate hook processing process-you need to use the standard JMP patch to hook kiuserexceptiondispatcher (this is somewhat in conflict with our goal ), or one of the two standard seh forms. There is another way. I think it is much better, though it is a bit difficult to implement. In fact, there is nothing to worry about. It is to write a deformation engine for the hook processing process, and fill in NOP equivalent commands between actually useful commands (NOP equivalent commands refer to mov eax, eax and other commands.: Push eax, pop eax ). In this way, the CRC check on your function will not work. I haven't done this yet, but I may write some POC code in the future ). The easiest way is from shellcode. I'm sure you all know that shellcode is usually encrypted to avoid using IDs signatures (annotation, IDS = intrusion-detection system) and carries a loader with dynamic decryption. It is very easy to write a simple deformation engine for the decryption code during the runtime. By placing NOP commands between different commands, the keys are randomly changed during each encryption and decryption, you can make any attempt to create a signature very difficult-even if it is not impossible, it will not sacrifice much performance. The debugging register is also very useful in many other aspects. You can use it to hook memory read/write and read commands, this means you can make a callback function for memory modifications (ideal for memory data monitoring, which means you no longer need to round-robin ). The complete description of the debug register can be found in the appendix. Another thing to consider is that they may not detect your API hooks. Simply using the raw data patch can invalidate your hooks. It is not difficult to implement this method, and there is enough portability-because the first few bytes of most APIs in Different Windows versions will not change frequently-this is possible for gaming companies. To solve this problem, we must realize that before writing code segments of the process image, we must call virtualprotect to temporarily change its page attributes. Therefore, intercepting ntprotectvirtualmemory can prevent them from easily overwriting your hard work. IV-to sum up, it is possible to inject a module and set four hooks that cannot be detected (at ring3 level. There may be vulnerabilities in some places, but the basic principle I mentioned should be able to achieve this effect. The above are all my attempts to create an anti-detection system in the user State. I know that you must be able to add your own opinions on the basis of my description. I sincerely hope that you will do this. This solution is not a secret security system as many people who are engaged in game hacking think. It is also different from the practices of closed-source software developers. Game hackers know more than others, and you should know this because all of you are engaged in reverse engineering. You live to defeat system security that is achieved through obscure means... Do not fall into the same trap. V-appendix manualmap: http://www.darawk.com/Code/ManualMap.cpp debug register: http://pdos.csail.mit.edu/6.828/2005/readings/i386/s12_02.htm cloakdll: http://www.darawk.com/Code/CloakDll.cpp Chook:
Http://www.darawk.com/Code/CHook.h
Http://www.darawk.com/Code/CHook.cpp
