A method for preventing online games hacking using memory monitoring
2020; Electronics and Telecommunications Research Institute; Volume: 43; Issue: 1 Linguagem: Inglês
10.4218/etrij.2019-0427
ISSN2233-7326
AutoresChang Seon Lee, Huy Kang Kim, Hey Rin Won, Kyounggon Kim,
Tópico(s)Network Security and Intrusion Detection
ResumoETRI JournalVolume 43, Issue 1 p. 141-151 ORIGINAL ARTICLEFree Access A method for preventing online games hacking using memory monitoring Chang Seon Lee, Trust & Safety of Cyber Security Center, LINE Corporation, Tokyo, JapanSearch for more papers by this authorHuy Kang Kim, School of Cybersecurity, Korea University, Seoul, Rep. of KoreaSearch for more papers by this authorHey Rin Won, Department of Information Security, Seoul Women’s University, Seoul, Rep. of KoreaSearch for more papers by this authorKyounggon Kim, Corresponding Author anesra@korea.ac.kr orcid.org/0000-0002-5675-4253 School of Cybersecurity, Korea University, Seoul, Rep. of Korea Correspondence Kyounggon Kim, School of Cybersecurity, Korea University, Seoul, Rep. of Korea. Email: anesra@korea.ac.krSearch for more papers by this author Chang Seon Lee, Trust & Safety of Cyber Security Center, LINE Corporation, Tokyo, JapanSearch for more papers by this authorHuy Kang Kim, School of Cybersecurity, Korea University, Seoul, Rep. of KoreaSearch for more papers by this authorHey Rin Won, Department of Information Security, Seoul Women’s University, Seoul, Rep. of KoreaSearch for more papers by this authorKyounggon Kim, Corresponding Author anesra@korea.ac.kr orcid.org/0000-0002-5675-4253 School of Cybersecurity, Korea University, Seoul, Rep. of Korea Correspondence Kyounggon Kim, School of Cybersecurity, Korea University, Seoul, Rep. of Korea. Email: anesra@korea.ac.krSearch for more papers by this author First published: 08 December 2020 https://doi.org/10.4218/etrij.2019-0427AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onEmailFacebookTwitterLinked InRedditWechat Abstract Several methods exist for detecting hacking programs operating within online games. However, a significant amount of computational power is required to detect the illegal access of a hacking program in game clients. In this study, we propose a novel detection method that analyzes the protected memory area and the hacking program's process in real time. Our proposed method is composed of a three-step process: the collection of information from each PC, separation of the collected information according to OS and version, and analysis of the separated memory information. As a result, we successfully detect malicious injected dynamic link libraries in the normal memory space. 1 INTRODUCTION Online game hacking is typically used to level up a player's character faster than in normal game play. Additionally, gold-farming groups, which are malicious groups that use game hacking programs to gain illegal financial profits, are formed to monopolize in-game items and money [1]. A gold farmer in an online game aims to harvest virtual money using automated programs (eg, game bots and macros) or hired low-cost laborers [2]. Real Money Trading (RMT) in online games is often associated with other criminal activities, such as money laundering and identity theft [3, 4]. Online game hacking can be classified into three types: automatic play using a macro, memory modification, and denial of service. In this study, we focus on detecting memory modification programs. To modify the memory of an online game client, hackers often employ security solution bypassing, dynamic-link library (DLL) injection, and memory modification techniques. As in an arms race, hackers continuously identify new methods to bypass the security measures used by online game companies, while the companies rely only on signature-based detection and heuristics. The most widely adopted methods to detect game hacking tool are signature-based or heuristic-based detection, whereas in this study, we propose a method to detect users who use memory injection techniques. Our proposed method is lightweight and can achieve high accuracy. The organization of the rest of this paper is as follows. In Section 2, we describe well-known techniques to attack online games, and review the literature. In Section 3, we present the main algorithm of the proposed detection method. In Section 4, we present the experimental result. Finally, in Section 5, we conclude this paper and suggest directions for future research. 2 BACKGROUNDS Online game hacking can be performed in many ways, such as auto mouse, macro, map, and speed hacks [5]. In particular, this section explains attack methods using security solution bypassing, memory forgery and alternation, and DLL injection, which is a representative memory hacking technique. The most common way to block a DLL injection is to use a game security solution. However, because game security solutions operate in the same PC environment, it is possible to bypass the attacker by analyzing the security solution; thus, the defense using only the security solution in the user's PC is limited. 2.1 Security solution bypassing Some of the current security solutions for online games include GameGuard and XignCode. These security solutions feature the detection of client forgeries, as presented in Table 1. However, a PC owner can become an attacker and can be circumvented through analysis. Table 1. Online game security solutions and security features Solution Security features GameGuard Server Authentication: prevents bypass by game server and GameGuard mutual authentication. Hack Tool Blocker: blocks hacking tools using game auto macros, mouse, and graphics. File forgery and manipulation prevention: file comparison analysis to prevent game file forgery and alteration, malicious debugging, and disassembly prevention. Client Reporting: real-time detection and blocking of process memory tampering. File protection with self-encryption algorithm. Antivirus and Spyware: detects malware using signature algorithms and file format analysis and diagnoses new and modified malware that is difficult to detect with existing antivirus engines. Updates: real-time, regular, and urgent updates. Reports: Real-time errors, hacking tools, and statistical analysis reports XignCode Non-client bot detection using “one-time executable code” patent. Block general purpose hacking tool and variant hacking tool using “Win32 API call pattern and frequency” patent. Block illegal users (control game operators). Emergency pattern generation tool provided (game operator control available). Detect and block VPN access (control game operator). DirectX tampering and illegal call detection. Speed nuclear detection. DLL injection detection. Nuking hack and drop nucleus detection. Software and hardware macro detection. Multi-running detection. Game resource tampering detection. Stealth process/module/driver detection. Kernel and user mode debugging detection. Virtual environment execution detection Therefore, security solutions are not the best way to safeguard games. When a security solution is bypassed, DLL injection and code injection are possible using several techniques. 2.2 Memory forgery and alteration If the security solution is bypassed, the attacker can then analyze the online game client and attempt to attack based on the analysis. One of the methods of attack is memory forgery and alteration. Memory forgery and alteration changes some options and values used by the game client on the operating system to make the game easier and faster. Memory forgery and alteration uses the process illustrated in Figure 1. Figure 1Open in figure viewerPowerPoint Memory forgery and alteration process flow: (1) Handle permission of the target process is obtained, (2) properties and values used in the game are examined, and (3) properties and values are changed The attack method depicted in Figure 1 uses the Cheat Engine program to modify the memory, and the modified value is reflected in the Minesweeper game. By simply changing these values, the attacker can achieve the desired result in the game. In online games, this simple method of attack is not possible; however, a simple online game client running on a user's PC is vulnerable to a forgery attack. 2.3 DLL injection A “DLL” refers to modules and programs with functionalities that can be shared by other applications [6]. Because a DLL is a module developed program, it can be updated and reused more easily than application programs. When a DLL is loaded into the memory address space, the application can access it at any time to take advantage of its functionality, thereby reducing memory overhead. Among the modularized DLLs, there are some DLLs essential for use in the Windows environment. KERNEL32.DLL, USER32.DLL, and GDI32.DLL are among the DLLs that must be included in the application development process. KERNEL32.DLL is a DLL that provides functions to control memory, processes, and threads. USER32.DLL is a DLL used to control user interfaces (UIs). If a UI exists in an application, USER32.DLL must always be used. Finally, GDI32.DLL is used to draw graphic images and display text. Similar to USER32.DLL, if a UI, text, or image is used, GDI32.DLL must be included in the application. DLLs are categorized into import functions and export functions. Import functions are used only inside a DLL and cannot be used in external applications, whereas export functions can be used externally. 2.3.1 Load-time dynamic linking One of the important processes when an application runs is to import a list of DLLs for use. Because the application does not contain all the code in the DLL, the DLL must exist in the specified path. Otherwise, the application will not run. When Windows loads a DLL, it allocates a virtual memory space and maps the DLL to the allocated memory. The section part of an application program shows the DLL information that is mapped to the memory. When the memory mapping process is completed, the application's name and memory address can be verified inside the application. Additionally, if an application error occurs, an environment can be used to analyze the source of the error. 2.3.2 Run-time dynamic linking This process explicitly loads the required DLL and then calls it, if there is a desired symbol, when the application runs. A thread inside the process decides whether to call a function inside the DLL, and the thread loads the DLL into the process' address space and enables the function inside the DLL to be called. The thread can load the DLL using the following function (LoadLibrary() or LoadLibraryEx()): The LoadLibrary and LoadLibraryEx functions use a specific search order to identify DLL files on the system. These functions are then used to map the file image of the identified DLL to the address space of the calling process. The virtual memory address to which the file image is mapped is identified when returned from the HMODULE function. When injection occurs, it affects the behavior of the application in memory in a way that the user does not expect or intend. There are two modes of dynamic DLL injection, each of which is performed by an attacker in a series of steps. A. Remote thread injection Remote thread injection is used to create a thread in the target process to load a malicious DLL and then call the LoadLibrary function. In this way, LoadLibrary can be used to load malicious DLLs. An attacker cannot easily control a thread from a process that is not created at first; thus, it must create a new thread to access the target process. As a result, creating a thread gives the attacker control over the application. For this purpose, the CreateRemoteThread function is used. Listing 1 is the declaration for the CreateRemoteThread function in Windows [7]. Listing 1 CreateRemoteThread function. Figure 2 depicts the method that can be used by malware to inject a malicious DLL into other processes. First, the malware opens the process using the OpenProcess function, which returns an open handle that is responsible for checking the process privileges; this handle is used to grant the right access to the target process. Second, the malware allocates memory using the VirtualAllocEx function to specify the correct path for the malicious DLL. Third, it writes the DLL path using the WriteProcessMemory function. Once the path has been created, the malware initiates the CreateRemoteThread function to create a thread on the target process, instructing the thread to load the malicious DLL remotely. As a result, the malware attaches the malicious DLLs on the target process and can compromise critical data on the victim’s machine. Figure 2Open in figure viewerPowerPoint Remote thread injection process flow B. Windows registry DLL injection The remote thread injection technique dynamically injects a DLL that contains the attack code for an attacker developing or using an injection program. In contrast, there is a method to force a DLL to be loaded into any program while Windows is running. When using the registry key “AppInit_DLLs” provided by Windows, DLL_PROCESS_ATTACH is called when the User32.dll library is mapped to a newly created process. When the call is processed, User32.dll calls LoadLibrary for each DLL specified in the AppInit_DLLs key. The entire library is loaded, and the DllMain function associated with the library is called with fdwReason set to DLL_PROCESS_ATTACH. 2.4 Binary code injection The binary code injection approach is similar to that of DLL injection. In binary code injection, an attacker sets the remote address of the injected binary code segment as the thread routine and creates a remote thread to execute the injected binary code. This method injects into the target process without an additional DLL stored in the system. Considering the steps of binary code injection, this method seems easier than DLL injection. However, the key point is the construction of the binary code. The injected binary code cannot be initialized as a DLL mapped into the address space of the target process. Although the binary code can be implemented as a function in the malicious process, there are still complications. First, the binary code uses absolute addresses to reference variables or call functions; however, these are the actual addresses in the address space of the malicious process. Thus, the injected binary code cannot retrieve the same data or call the same functions at these addresses in the target process. It would be easier to combine all the subroutines into a large function, unless an injection into each subroutine and a pass of their remote addresses to the injected binary code are desired. A further complication is that the binary code is relocated in the malicious process. The target process does not relocate the injected binary code. Most commonly, operators crash the target process when a remote thread is created to execute the injected binary code. Inline assembly can be used to construct the binary code. Although this is considerably complicated to implement, there is no need to manage the relocation of the injected binary code. Furthermore, the binary code can be much more easily controlled and is more reliable if assembly language is used to implement the whole malicious process. Binary code injection is much more complicated and riskier than DLL injection. Additionally, it provides the flexibility to inject without an additional DLL. 2.5 Related work Only the client’s environment was detected by monitoring through hooking in previous studies [8–10]. These detection methods are necessary to enable the monitoring of hooking on the client side and its bypassing by blocking the hooking. Furthermore, the false-positive rate of hooking increases because each PC environment is different. If the client can identify the server-side environment and the user-specific PC environment, detection is expected to be more effective than in previously studied methods. In [11], Jelena and others categorized detection methods for malware into static and dynamic analysis, and the authors focused on the dynamic method. They identified malware families using memory and CPU usage. Moreover, to detect malware in mobile devices, features extracted from CPU and memory were tested. Zhixing and others [12] suggested a framework for detecting malware using monitoring and classification of memory access pattern with a machine learning technique. The authors checked for malicious code that attempted to change the control flow and access the program memory. Additionally, they used a machine learning techniques to analyze various rootkits, such as avg-coder and AFkit, which modify the system call table. Rami and others [13] investigated various memory analysis methods, such as static, dynamic, and hybrid techniques. Memory analysis is a state-of-the-art technique and is widely using in the forensic field [14, 15]. In the survey paper, many researchers use API function calls to detect malware. Furthermore, they analyzed memory using machine learning techniques, such as support vector machines and K-nearest neighbors. Existing papers have proposed static, dynamic, and hybrid methods, as well as the use of machine learning to detect malware in user PCs. However, our study focuses on detecting models for each service, and our method is not a dynamic detection method. 3 PROPOSED METHOD We propose the game hack module detection method, as depicted in Figure 3. Our proposed method is a three-step process. The first step is the collection of information from each PC. The second step is the separation of the collected information according to OS and version. The third step is the analysis of the separated memory information. Figure 3Open in figure viewerPowerPoint Game hack module detection method 3.1 Information collection stage First, we collect information from online game clients. With the knowledge of the OS and service pack being used, it can be determined as to whether a hacking tool is running on the same base. Information regarding the memory of the environment in which the game is played can be obtained after collecting information about the memory, and the DLL information employed by the game clients can be used to transfer the collected information to the server. Figure 4 depicts a graphical representation of the collection process. Figure 4Open in figure viewerPowerPoint Information collection stage: (1) OS and version information for each client is collected, (2) collected information is transferred to the server, and (3) statistical operations on the monitoring server are performed Information collected from a user PC is classified based on the OS and OS version through the next step, the separation step. There are two methods for collecting information. The first method of information collection is to check the registered DLL information on the client and the memory state. This method blocks any DLL that is not in the corresponding loading list. However, a simple file name lookup is easy to bypass; thus, the cyclic redundancy check (CRC) logic must have a vast CRC table of DLLs. This is because if Windows is updated, a patching process occurs, and the DLL list must be managed by the version of Windows, making it inconvenient to manage. The second method that we propose is the collection of a memory state list. If a program changes into a process environment, various changing areas of memory exist, including available and unavailable areas, readable areas, and writable areas. Monitoring and managing these memory areas can effectively identify an invasive hacking module. Listing 2 presents code that verifies the memory protection constant for memory scanning from a hacking tool or module. Because the attributes of such accessible memory are limited, monitoring is possible. Listing . Checking memory protection constant for memory scanning. 3.2 Analysis stage Malware uses APIs that are different from the APIs used by non-malware, and memory is also used differently [16]. An API used by malware has a different model from an API used by non-malware. Therefore, when analyzing APIs that are not used by non-malware, it is necessary to load the DLLs that provide APIs in memory. Similarly, game hacking programs must use the DLLs and APIs that are not used by the online game client, which adds unused memory areas, resulting in a structure that is different from the normal online game client memory map. In the collection and separation of information steps, a check is performed to confirm that the memory map structure is in place according to each OS and version. As presented in Table 2, by using each address's count of the memory, a different user is selected from the existing client environment. Assuming that 10 users play the game, it is highly likely that hack module has penetrated if 1-4 new memory areas are added among those 10 users. Therefore, users of unusual environments are judged using the hack module through a game history check. However, it is problematic if previously unused memory areas exist, because of the definition of memory usage provided by Windows. Table 2. Analysis table for collected data (Windows 7 Enterprise Service Pack 1) Address State Constant Count 00000000-00010000 MEM_FREE - 10 00010000-00020000 MEM_COMMIT PAGE_READWRITE 10 … … … 00121000-0013000 MEM_FREE PAGE_READWRITE 9 777D000-777D1000 MEM_COMMIT PAGE_EXECUTE_READ 1 … … … 7EFD8000-7EFDB000 MEM_COMMIT PAGE_READWRITE 10 A detailed description of the memory access and usage is provided by Microsoft MSDN. As presented in Table 3, according to the memory protection constant, various rights are granted, including accessible memory addresses, inaccessible addresses, accessible but only readable addresses, and readable but not writable addresses. Therefore, a hacking tool and hacking module first check the memory where PAGE_READWRITE, PAGE_WRITECOPY, PAGE_EXECUTE_READWRITE, and PAGE_EXECUTE_WRITECOPY privileges exist. Therefore, we monitor the constants used in the hacking tool. Figure 5 depicts the result, based on a study of the state by memory addresses in the actual process. Table 3. Memory protection constants [17] Constant Value Monitoring Description PAGE_EXECUTE 0 × 10 X Enables execute access to the committed region of pages. An attempt to write to the committed region results in an access violation. This flag is not supported by the CreateFileMapping function PAGE_EXECUTE_READ 0 × 20 X Enables execute or read-only access to the committed region of pages. An attempt to write to the committed region results in an access violation. Windows Server 2003 and Windows XP: This attribute is not supported by the CreateFileMapping function until Windows XP with SP2 and Windows Server 2003 with SP1 PAGE_EXECUTE_READWRTIE 0 × 40 O Enables execute, read-only, or read/write access to the committed region of pages. Windows Server 2003 and Windows XP: This attribute is not supported by the CreateFileMapping function until Windows XP with SP2 and Windows Server 2003 with SP1 PAGE_EXECUTE_WRITECOPY 0 × 80 O Enables execute, read-only, or copy-on-write access to a mapped view of a file mapping object. An attempt to write to a committed copy-on-write page results in a private copy of the page being made for the process. The private page is marked as PAGE_EXECUTE_READWRITE, and the change is written to the new page. This flag is not supported by the VirtualAlloc or VirtualAllocEx functions. Windows Vista, Windows Server 2003, and Windows XP: This attribute is not supported by the CreateFileMapping function until Windows Vista with SP1 and Windows Server 2008 PAGE_NOACCESS 0 × 01 X Disables all access to the committed region of pages. An attempt to read from, write to, or execute the committed region results in an access violation. This flag is not supported by the CreateFileMapping function PAGE_READONLY 0 × 02 X Enables read-only access to the committed region of pages. An attempt to write to the committed region results in an access violation. If Data Execution Prevention is enabled, an attempt to execute code in the committed region results in an access violation PAGE_READWRITE 0 × 04 O Enables read-only or read/write access to the committed region of pages. If Data Execution Prevention is enabled, attempting to execute code in the committed region results in an access violation PAGE_WRITECOPY 0 × 08 O Enables read-only or copy-on-write access to a mapped view of a file mapping object. An attempt to write to a committed copy-on-write page results in a private copy of the page being made for the process. The private page is marked as PAGE_READWRITE, and the change is written to the new page. If Data Execution Prevention is enabled, attempting to execute code in the committed region results in an access violation. This flag is not supported by the VirtualAlloc or VirtualAllocEx functions Figure 5Open in figure viewerPowerPoint Memory state in the actual process The availability in the protection constant state is defined in Table 4. As presented in Table 4, the “MEM_FREE” state denotes an unused free area, and “MEM_RESERVE” denotes an area where only addresses are assigned and where the “MEM_COMMIT” virtual memory and physical memory are used. Accordingly, hacking tools can inject code in the “MEM_FREE” and “MEM_COMMIT” states. Thus, monitoring mainly proceeds for “MEM_FREE” and “MEM_COMMIT.” Table 4. The state of the pages in the region [18] State Value Monitoring Description MEM_COMMIT 0 × 1000 O Indicates committed pages for which physical storage has been allocated, either in memory or in the paging file on disk. MEM_FREE 0 × 10 000 O Indicates free pages not accessible to the calling process and available to be allocated. For free pages, the information in the AllocationBase, AllocationProtect, Protect, and Type members is undefined. MEM_RESERVE 0 × 2000 O Indicates reserved pages where a range of the process's virtual address space is reserved without any physical storage being allocated. For reserved pages, the information in the Protect member is undefined. MEM_IMAGE 0 × 1 000 000 X Indicates that the memory pages within the region are mapped into the view of an image section. MEM_MAPPED 0 × 40 000 X Indicates that the memory pages within the region are mapped into the view of a section. MEM_PRIVATE 0 × 20 000 X Indicates that the memory pages within the region are private (ie, not shared by other processes). There is a memory area set to “MEM_PRIVATE” although it is set to “MEM_COMMIT” in Figure 6. Monitoring needs to proceed without the “MEM_PRIVATE” area because the “MEM_PRIVATE” area is blocked from the access of other processes. If the above conditions are met, the memory map can be verified, as depicted in Figure 7. Figure 6Open in figure viewerPowerPoint Protection constants inside the process Figure 7Open in figure viewerPowerPoint Memory to monitor 3.3 Memory hacking protection through monitoring The entire monitoring process is illustrated in Figure 8. Figure 8Open in figure viewerPowerPoint Monitoring stage: (1) information regarding the OS, version, and memory map from each client is collected, (2) collected information is delivered to the game servers, (3) collected information is separated, (4) memory map with low frequency is selected from separate information, and (5) the corresponding user is prohibited from using it We collect the memory addresses for each country, OS, and service version. If there is a suspicious user based on the monitored memory status, an investigation of that user is initiated. Each investigated memory address is transferred to the server and stored. Then, we proceed with statistics regarding the memory addresses that have been recorded, and memory addresses with low counts are investigated. The reason for selecting the monitoring item is that the WinAPI used in a DLL and code injection process calls the VirtualAllocEx API internally to reserve and confirm memory usage, as shown in Listing 3. Listing . VirtualAllocEx function. In this process, malware sets the state value for those marked “O” in the monitoring columns, as presented in Table 3 and Table 4. It is an API that is used to inject code into other processes and malware; thus, when monitoring the value of the set argument, external processes can check the code insertion after access. We select memory addresses that have read and write permissions for monitoring. The reason is that online hacking tools and malware need space to read and write their modules into memory. If malware repeats writing or reading from other memory, it causes the program to crash and either hang or produce the “blue screen of death.” Therefore, an online game hacking tool is programmed to secure and operate the weakness to be used in the tool's module. 4 EXPERIMENTAL RESULT We strove to identify a structure that can collect information from existing client environments and manage and detect the information detected from a central server. Because the memory structure of each service is known to the game developer, it is possible to check the used and unused areas in the situation wherein the service is running. Additionally, because used and unused modules can also be checked, our experiment is expected to reduce the number of false negatives occurring in the process of detecting existing unknown malware. The experiment was conducted under the following conditions. The Client.exe program on a Win
Referência(s)