Cheating detection method, device, electronic device and storage medium

Abstract

Embodiments of the present invention relate to a cheat detection method, apparatus, electronic device, and storage medium, comprising: identifying multiple suspicious threads to be tested for cheating; monitoring whether each of the suspicious threads triggers a docking event, wherein the docking event indicates that the suspicious thread is docked to a target program; upon detecting that the suspicious thread triggers the docking event, determining the frequency with which the suspicious thread triggers the docking event within a predetermined collision period; and determining whether the suspicious thread is a cheat thread based on the frequency. This method enables comprehensive cheat detection with high detection efficiency.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computers, and in particular to a cheat detection method, device, electronic device, and storage medium. Background Art

[0002] With the advancement of computer technology and the iterative upgrades of operating systems, patching to prevent cheating is no longer applicable to the now ubiquitous 64-bit Windows system. Therefore, technicians have adopted the technique of handle privilege reduction to prevent cheating in 64-bit Windows systems. For example, in the case of gaming programs, handle privilege reduction involves frequently traversing the system's handles that access gaming programs. Once cheating is detected, the handle's permissions are lowered, for example, to the lowest level. This prevents the handle from reading or writing data to the gaming program, thus preventing cheating.

[0003] However, there are major technical flaws in handle demotion. Specifically, the implementation of handle demotion relies on a whitelist, and once the whitelist is used by a plug-in thread, it will lose its effectiveness in detecting plug-in threads. In addition, the concept of handles does not exist in the driver layer (i.e., the kernel layer). Therefore, the above-mentioned technical means of handle demotion are not suitable for countering plug-in threads in the driver layer (i.e., the kernel layer).

[0004] It can be seen from this that there is an urgent need for a plug-in detection method that is universal and highly compatible. Summary of the Invention

[0005] In view of this, in order to solve the technical problem that the cheat detection method in the prior art is extremely limited and has low applicability, the embodiments of the present invention provide a cheat detection method, device, electronic device and storage medium.

[0006] In a first aspect, an embodiment of the present invention provides a cheat detection method, the method comprising:

[0007] Identify multiple suspicious threads for cheat detection;

[0008] Monitoring whether each of the suspicious threads triggers a docking event, wherein the docking event is used to indicate that the suspicious thread is docked to a target program;

[0009] Under the condition that the suspicious thread triggers the anchoring event, determining the frequency of the suspicious thread triggering the anchoring event within the preset collision period;

[0010] Determine whether the suspicious thread is a plug-in thread based on the frequency.

[0011] In one possible implementation, determining multiple suspicious threads to be detected for cheating includes:

[0012] Determine the activity of each live thread in the system;

[0013] The surviving thread whose activity meets the set condition is determined as a suspicious thread to be detected for cheating.

[0014] In one possible implementation, determining the activity of each surviving thread in the system includes:

[0015] For each live thread in the system, perform the following steps:

[0016] Obtaining the swapcontext value of the surviving thread according to a set period until a set number of the swapcontext values are obtained; and

[0017] Starting from the second cycle, the swapcontext values obtained in the previous and next cycles are subtracted to obtain a swapcontext difference value; the swapcontext difference value is positively correlated with the activity of the surviving thread;

[0018] For each surviving thread in the system, determining the surviving thread whose activity meets a set condition as a suspicious thread to be detected for cheating includes:

[0019] Sort the swapcontext differences of the surviving threads obtained in order of acquisition time to obtain a swapcontext difference sequence of the surviving threads;

[0020] If the swapcontext difference sequence is an increasing sequence, the surviving thread is determined as a suspicious thread to be subjected to cheat detection.

[0021] In a possible implementation, monitoring whether each suspicious thread triggers a docking event includes:

[0022] For each suspicious thread, the following steps are executed in a loop within a set time period:

[0023] Obtaining data content at a specified offset address in the suspicious thread kernel object;

[0024] Determining whether the data content is a kernel object address of the target program;

[0025] If yes, stop the loop and determine that the suspicious thread triggers a docking event;

[0026] If not, the process continues to loop until the set time is reached and it is determined that the suspicious thread has not triggered a docking event.

[0027] In a possible implementation, monitoring whether each suspicious thread triggers a docking event includes:

[0028] Grouping the plurality of suspicious threads according to the activity, wherein the activity of the suspicious threads in the same group is within the same set activity range, and the set activity ranges corresponding to different groups do not overlap;

[0029] For each of the groups, batch monitoring is performed to determine whether the suspicious threads in the group trigger a docking event.

[0030] In a possible implementation, after batch monitoring of whether the suspicious threads in the group trigger a docking event, the method further includes:

[0031] Under the condition that any of the suspicious threads in the group is monitored to trigger a hang event, it is again monitored whether any of the suspicious threads triggers a hang event.

[0032] In a possible implementation, determining whether the suspicious thread is a plug-in thread based on the frequency includes:

[0033] comparing the frequency to a set threshold;

[0034] If the frequency is greater than the set threshold, the suspicious thread is determined to be a plug-in thread;

[0035] If the comparison shows that the frequency is less than the set threshold, it is determined that the suspicious thread is not a plug-in thread.

[0036] In a second aspect, an embodiment of the present invention provides a cheat detection device, the device comprising:

[0037] A first determination module is used to determine multiple suspicious threads to be detected for cheating;

[0038] A second determining module is configured to monitor whether each of the suspicious threads triggers a docking event, wherein the docking event is used to indicate that the suspicious thread is docked to a target program;

[0039] A third determining module is configured to determine a frequency of triggering the anchoring event by the suspicious thread within a preset collision period under the condition that the suspicious thread triggers the anchoring event;

[0040] A fourth determining module is configured to determine whether the suspicious thread is a plug-in thread based on the frequency.

[0041] In a possible implementation manner, the second determining module is specifically configured to:

[0042] For each suspicious thread, the following steps are executed cyclically without delay within a set time period:

[0043] Obtaining data content at a specified offset address in the suspicious thread kernel object;

[0044] Determining whether the data content is a kernel object address of the target program;

[0045] If yes, stop the loop and determine that the suspicious thread triggers a docking event;

[0046] If not, the process continues to loop until the set time is reached and it is determined that the suspicious thread has not triggered a docking event.

[0047] In a third aspect, an embodiment of the present invention provides an electronic device, comprising: a processor and a memory, wherein the processor is configured to execute a cheat detection program stored in the memory to implement the cheat detection method described in any one of the first aspects.

[0048] In a fourth aspect, an embodiment of the present invention provides a storage medium, which stores one or more programs, and the one or more programs can be executed by one or more processors to implement the plug-in detection method described in any one of the first aspects.

[0049] The technical solution provided by the embodiment of the present invention determines multiple suspicious threads to be detected for plug-in, monitors whether each suspicious thread triggers a docking event, and when it is monitored that the suspicious thread triggers a docking event, determines the frequency of the suspicious thread triggering the docking event within a preset collision period, and determines whether the suspicious thread is a plug-in thread based on the frequency, thereby realizing the detection of plug-in threads. Specifically, in the above technical solution, by first determining multiple suspicious threads to be detected for plug-ins, and then only performing plug-in detection on the suspicious threads, compared with comprehensively performing plug-in detection on the surviving threads in the system, the efficiency of plug-in detection can be improved, and the consumption of device computing resources and the impact of plug-in detection on device performance can be reduced; because for plug-in threads, triggering a docking event is a necessary operation, and the frequency of triggering a docking event can also be regarded as an inherent characteristic of the plug-in thread, therefore, plug-in detection through the frequency of thread triggering a docking event can be applicable to a variety of plug-ins and a variety of scenarios (including detection of plug-in threads at the driver layer). It can be seen that the above technical solution has higher applicability and compatibility than the handle demotion in the existing technology, and can more comprehensively realize the detection of a variety of plug-in threads.

[0050] Furthermore, in the technical solution provided by the embodiment of the present invention, when monitoring whether a suspicious thread triggers a docking event, based on the inspiration of the close-packed array system used on warships, multiple detection threads are called to cyclically perform plug-in detection on the suspicious thread. This is equivalent to the interception principle of the close-packed array system used on warships, and can realize intensive and high-frequency plug-in detection of suspicious threads. Therefore, even if the docking and undocking operations of the plug-in thread are completed instantly, it is possible to capture with a high probability that the plug-in thread has triggered a docking event, providing a solid foundation for the detection of plug-in threads. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 This is a flow chart of an embodiment of a cheat detection method according to an embodiment of the present invention;

[0052] Figure 2 This is a flow chart of another cheat detection method according to an embodiment of the present invention;

[0053] Figure 3 This is a block diagram of an embodiment of a cheat detection device according to an embodiment of the present invention;

[0054] Figure 4 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0055] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0056] The following describes the cheat detection method provided by the present invention with reference to specific embodiments in conjunction with the accompanying drawings. The embodiments do not limit the embodiments of the present invention.

[0057] See also Figure 1 , is a flow chart of an embodiment of a cheat detection method according to an embodiment of the present invention. Figure 1 As shown, the process may include the following steps:

[0058] Step 101: Determine multiple suspicious threads to be detected for cheating.

[0059] In practice, there are thousands of surviving threads in the system (usually more than 3,000). Faced with thousands of surviving threads, if plug-in detection is performed on each surviving thread, it will undoubtedly consume a large amount of computing resources and affect the performance of the device. In this regard, the embodiment of the present invention proposes: when performing plug-in detection, first determine some threads suspected of plug-in (hereinafter referred to as suspicious threads) from multiple surviving threads in the system, and then only perform plug-in detection on the suspicious threads. It can be understood by those skilled in the art that, compared with performing plug-in detection on thousands of surviving threads in the system, only performing plug-in detection on suspicious threads can reduce the consumption of computing resources of the device by plug-in detection and reduce the impact of plug-in detection on device performance. The following is an example of how to determine suspicious threads from the surviving threads in the system:

[0060] In practice, cheat threads typically perform read and write operations on target programs (such as game programs) based on the two system API functions, ReadMemory and WriteMemory, thereby achieving cheating capabilities. Furthermore, cheat threads have very high real-time performance, triggering at least 3,000 to 50,000 read / write operations per second. In other words, from the perspective of thread activity, cheat threads are abnormally active threads, and over time, the activity of cheat threads tends to increase or maintain. In contrast, normal threads are inactive or moderately active, and over time, the activity of normal threads is irregular.

[0061] Based on this, as an embodiment, live threads in the system can be preliminarily screened and filtered based on activity to obtain suspicious threads. Specifically, the activity of each live thread in the system is determined, and live threads whose activity meets the set conditions are identified as suspicious threads to be detected for cheating.

[0062] As an optional implementation, determining the activity of each surviving thread in the system includes: calling the corresponding system API function according to a set period to obtain the swapcontext value of the surviving thread until a set number of swapcontext values are obtained. At the same time, for each surviving thread, starting from the second period, the swapcontext values obtained in the previous and next periods are subtracted to obtain a swapcontext difference. The swapcontext difference is positively correlated with the activity of the thread, that is, the larger the swapcontext difference, the more active the thread is, and conversely, the smaller the swapcontext difference, the less active the thread is. Therefore, the swapcontext difference of a surviving thread can be used to represent the activity of the surviving thread.

[0063] Based on this, as an optional implementation, threads whose activity meets set conditions are identified as suspicious threads for cheating detection. This includes sorting the swapcontext differences of each surviving thread in the system in chronological order of acquisition to generate a sequence of swapcontext differences for the surviving threads. If the swapcontext difference sequence is increasing, it means that the activity of the thread is increasing over time. Based on the above description, the surviving thread can be identified as a suspicious thread for cheating detection.

[0064] For example, every 1 second (that is, the set period mentioned above), the corresponding system API function is called to obtain the swapcontext value of the surviving thread, until the swapcontext value of the surviving thread is obtained 5 times in 5 consecutive set periods. According to the above description, for each surviving thread, starting from the second period, the swapcontext values obtained in the two periods before and after are subtracted in turn to obtain a total of 4 swapcontext difference values. Afterwards, the 4 swapcontext difference values are sorted in the order of the acquisition time to obtain the swapcontext difference sequence of the surviving thread. If the swapcontext difference sequence is an increasing sequence, it means that the activity of the thread is increasing over time. According to the above description, the surviving thread can be determined as a suspicious thread to be detected for plug-ins.

[0065] In addition, it should be noted that if the swapcontext difference is 0, it means that the thread is inactive. Therefore, before sorting the swapcontext differences of the surviving threads, the inactive surviving threads can be filtered out based on the swapcontext differences.

[0066] Step 102: Monitor whether each suspicious thread triggers a docking event, where the docking event is used to indicate that the suspicious thread is docked to the target program.

[0067] Currently, Windows stipulates that when a thread performs cross-process reading and writing (that is, reading and writing data from processes other than its own process), it must first attach to the other process (hereinafter referred to as the target program). After the read and write operations are completed, it can then detach from the target program. As mentioned above, a plug-in thread can trigger at least 3,000 to 50,000 read / write operations per second, which means that the plug-in thread can trigger attachment events 3,000 to 50,000 times per second. This shows that for plug-in threads, the frequency of triggering attachment events is relatively high.

[0068] Furthermore, when a thread is attached to a target program, the target program's kernel object address is stored at a specified offset in the thread's kernel object, for example, offset 0xb8. After the thread is detached from the target program, the data at the specified offset is changed from the target program's kernel object address to the kernel object address of the thread's process. Therefore, each time a thread triggers an attachment event, the data at the specified offset in its kernel object changes.

[0069] Based on the above description, an embodiment of the present invention proposes: capturing whether a thread triggers a docking event by acquiring data content at a specified offset address in a thread kernel object.

[0070] However, although the frequency of the plug-in thread triggering the docking event is relatively high, that is, the frequency of the data content at the specified offset address in the thread kernel object changing to the kernel object address of the target program is relatively high, the docking operation and the undocking operation are completed instantly, that is, the data content at the specified offset address in the thread kernel object is the kernel object address of the target program in a flash. Therefore, how to capture the thread triggering the docking event has become a technical pain point.

[0071] In this regard, the embodiment of the present invention is inspired by the Phalanx system used on warships: supersonic missiles are launched very quickly, but the Phalanx system that launches 20,000 interceptor missiles per second can still intercept supersonic missiles. The following implementation method for determining whether a suspicious thread has triggered a docking event is proposed, specifically as follows: Figure 2 As shown in the process. Figure 2 As shown, the following steps are included:

[0072] Step 201: Obtain the data content at the specified offset address in the suspicious thread kernel object.

[0073] Step 202 : Determine whether the acquired data content is the kernel object address of the target program; if so, execute step 203 ; if not, execute step 204 .

[0074] Step 203: Determine whether a suspicious thread triggers a docking event.

[0075] Step 204 , determine whether the set time has been reached; if so, execute step 205 ; if not, return to execute step 201 .

[0076] Step 205: Determine whether the suspicious thread has triggered a docking event.

[0077] As can be seen from steps 201 to 205, in an embodiment of the present invention, for each suspicious thread, the data content at the specified offset address in the kernel object of the suspicious thread is obtained cyclically without delay within a set time period (for example, 1 second). In this way, the data content at the specified offset address in the kernel object of the suspicious thread is obtained at a high frequency. After each time the data content at the specified offset address in the kernel object of the suspicious thread is obtained, it is determined whether the obtained data content is the kernel object address of the target program. If so, it can be determined that the suspicious thread has triggered a docking event and the loop is exited; if not, the above steps can be continued to be executed cyclically without delay until the set time period is reached. When the set time period is reached, if the data content obtained each time is not the kernel object address of the target program, it can be determined that the suspicious thread has not triggered a docking event. Here, no delay means that there is no time interval between each two executions of the above-mentioned acquisition of the data content at the specified offset address in the kernel object of the suspicious thread.

[0078] exist Figure 2 In the process shown, high-frequency plug-in detection is performed on suspicious threads, which is equivalent to the interception principle of the close-quarters array system used on warships, realizing intensive and high-frequency plug-in detection of suspicious threads. Therefore, even if the docking and undocking operations of the plug-in thread are completed instantly, it is possible to capture the plug-in thread triggering the docking event with a high probability.

[0079] In addition, it should be noted that in order to improve the efficiency and accuracy of cheat detection, the embodiment of the present invention proposes to batch execute the following steps for the multiple suspicious threads determined in step 101: Figure 2 The process shown is to perform plug-in detection on multiple suspicious threads in batches.

[0080] Specifically, an embodiment of the present invention proposes to group multiple suspicious threads according to their activity levels, wherein the activity levels of the suspicious threads in the same group are within the same set activity range, and the set activity ranges corresponding to different groups do not overlap. Then, for each group, batch monitoring is performed to determine whether the suspicious threads in the group trigger an attachment event.

[0081] For example, based on the swapcontext difference value that can represent activity, suspicious threads with a swapcontext difference value greater than 1000 are grouped into one group, suspicious threads with a swapcontext difference value greater than 200 and less than 1000 are grouped into another group, and suspicious threads with a swapcontext difference value less than 200 are grouped into yet another group, resulting in three groups. Then, for each group, the suspicious threads in the group are monitored in batches to see if they trigger a docking event. Here, the swapcontext difference value used for grouping is the last swapcontext difference value obtained according to the set period.

[0082] In practice, the number of threads with higher activity in Windows systems is relatively small compared to the number of threads with lower activity (generally speaking, threads with higher activity account for less than 10%). Therefore, in the above-mentioned multiple groups, the higher the activity corresponding to the group, that is, the larger the swapcontext difference, the fewer threads in the group. Furthermore, within the same set time, the fewer threads are monitored in batches, the more times each thread is monitored, and thus the higher the monitoring hit rate. This can improve the accuracy of plug-in detection.

[0083] In addition, when a suspicious thread that triggers a hang event is captured through batch monitoring, the suspicious thread that triggers the hang event captured during the batch monitoring process can be determined as a high-risk thread. Afterwards, the high-risk thread is separately monitored to see if it triggers a hang event. That is, in an embodiment of the present invention, under the condition that any suspicious thread in the above group is monitored to trigger a hang event, the suspicious thread is again separately monitored to see if it triggers a hang event. It can be seen that in an embodiment of the present invention, by combining batch detection with separate detection, the accuracy of the plug-in detection results can be improved while taking into account the efficiency of plug-in detection.

[0084] Step 103: Under the condition that a suspicious thread triggers a docking event, determine the frequency of the suspicious thread triggering the docking event within a preset collision period.

[0085] It can be understood that when a suspicious thread is monitored to trigger a hanging event, it means that the suspicious thread is likely to be a plug-in thread. In order to further determine whether the suspicious thread is a plug-in thread, an embodiment of the present invention proposes to determine the frequency of the suspicious thread triggering the hanging event within a preset collision period under the condition that a suspicious thread is monitored to trigger a hanging event.

[0086] Specifically, in an embodiment of the present invention, the following steps can be performed for the suspicious thread that triggers the hanging event, that is, the above-mentioned high-risk thread, within a preset collision period, for example, 0.1 seconds (here, the setting of 0.1 seconds is mainly considered to reduce the impact of the implementation of the technical solution of the present invention on users, such as game players): obtain the data content at the specified offset address in the kernel object of the high-risk thread, determine whether the obtained data content is the kernel object address of the target program, and if so, add 1 to the mark value used to characterize the number of times the suspicious thread is detected to trigger the hanging event. Then, at the end of the preset collision period, the number of times the suspicious thread is detected to trigger the hanging event during the preset collision period can be obtained, and based on this number, the frequency of the suspicious thread triggering the hanging event can be obtained.

[0087] It should be noted that the preset collision period here may be the same as or different from the set duration described in the above step 102, and the embodiment of the present invention does not impose any limitation on this.

[0088] Step 104: Determine whether the suspicious thread is a plug-in thread based on the frequency.

[0089] As one example, the frequency of a suspicious thread triggering a hang event is compared with a set threshold. If the comparison shows that the frequency is greater than the set threshold, it means that the suspicious thread triggers hang events at a relatively high frequency. Combined with the above description that "the frequency of a hang event triggered by a hang thread is relatively high," the suspicious thread can be determined to be a hang thread. Conversely, if the comparison shows that the frequency is less than or equal to the set threshold, it means that the suspicious thread triggers hang events at a moderate frequency, and therefore, the suspicious thread can be determined not to be a hang thread.

[0090] It should be noted that, in practice, the above-mentioned threshold settings are not static, that is, users can adjust the threshold settings based on actual business needs or prior experience, and can also intelligently adjust the threshold settings based on historical plug-in detection results through artificial intelligence algorithms. The embodiments of the present invention do not impose any restrictions on this.

[0091] It should also be noted that the frequency-based method described in the above embodiment is merely an optional implementation method. In practice, other implementation methods are also possible. For example, multiple suspicious threads can be sorted in descending order of frequency, and the top N suspicious threads in the sorted result can be determined as cheat threads. The embodiments of the present invention do not limit the specific implementation method for determining whether a suspicious thread is a cheat thread based on frequency.

[0092] The technical solution provided by the embodiment of the present invention determines multiple suspicious threads to be detected for plug-in, monitors whether each suspicious thread triggers a docking event, and when it is monitored that the suspicious thread triggers a docking event, determines the frequency of the suspicious thread triggering the docking event within a preset collision period, and determines whether the suspicious thread is a plug-in thread based on the frequency, thereby realizing the detection of plug-in threads. Specifically, in the above technical solution, by first determining multiple suspicious threads to be detected for plug-ins, and then only performing plug-in detection on the suspicious threads, compared with comprehensively performing plug-in detection on the surviving threads in the system, the efficiency of plug-in detection can be improved, and the consumption of device computing resources and the impact of plug-in detection on device performance can be reduced; because for plug-in threads, triggering a docking event is a necessary operation, and the frequency of triggering a docking event can also be regarded as an inherent characteristic of the plug-in thread, therefore, plug-in detection through the frequency of thread triggering a docking event can be applicable to a variety of plug-ins and a variety of scenarios (including detection of plug-in threads at the driver layer). It can be seen that the above technical solution has higher applicability and compatibility than the handle demotion in the existing technology, and can more comprehensively realize the detection of a variety of plug-in threads.

[0093] Corresponding to the above-mentioned embodiment of the cheat detection method, the present invention also provides an embodiment of a cheat detection device. The cheat detection device provided by the present invention is described below with reference to the accompanying drawings using a specific embodiment:

[0094] See also Figure 3 , is a block diagram of an embodiment of a cheat detection device shown in an embodiment of the present invention.

[0095] like Figure 3 As shown, the device includes:

[0096] A first determining module 31 is configured to determine a plurality of suspicious threads to be detected for cheating;

[0097] A second determining module 32 is configured to monitor whether each of the suspicious threads triggers a docking event, wherein the docking event is used to indicate that the suspicious thread is docked to a target program;

[0098] A third determining module 33 is configured to determine a frequency of triggering the anchoring event by the suspicious thread within a preset collision period under the condition that the suspicious thread triggers the anchoring event;

[0099] The fourth determining module 34 is configured to determine whether the suspicious thread is a plug-in thread based on the frequency.

[0100] In a possible implementation, the first determining module 31 includes (not shown in the figure):

[0101] Activity determination submodule, used to determine the activity of each surviving thread in the system;

[0102] The suspicious thread determination submodule is configured to determine the surviving thread whose activity satisfies a set condition as a suspicious thread to be detected for cheating.

[0103] In one possible implementation, the activity determination submodule is specifically configured to:

[0104] For each live thread in the system, perform the following steps:

[0105] Obtaining the swapcontext value of the surviving thread according to a set period until a set number of the swapcontext values are obtained; and, starting from the second period, subtracting the swapcontext values obtained in the previous and next periods to obtain a swapcontext difference value; the swapcontext difference value is positively correlated with the activity of the surviving thread;

[0106] The suspicious thread determination submodule is specifically used to:

[0107] For each surviving thread in the system, sort the swapcontext differences of the surviving threads obtained in the order of acquisition time to obtain a swapcontext difference sequence of the surviving threads;

[0108] If the swapcontext difference sequence is an increasing sequence, the surviving thread is determined as a suspicious thread to be subjected to cheat detection.

[0109] In a possible implementation manner, the second determining module 32 is specifically configured to:

[0110] For each suspicious thread, the following steps are executed in a loop within a set time period:

[0111] Obtaining data content at a specified offset address in the suspicious thread kernel object;

[0112] Determining whether the data content is a kernel object address of the target program;

[0113] If yes, stop the loop and determine that the suspicious thread triggers a docking event;

[0114] If not, the process continues to loop until the set time is reached and it is determined that the suspicious thread has not triggered a docking event.

[0115] In a possible implementation manner, the second determining module 32 is specifically configured to:

[0116] Grouping the plurality of suspicious threads according to the activity, wherein the activity of the suspicious threads in the same group is within the same set activity range, and the set activity ranges corresponding to different groups do not overlap;

[0117] For each of the groups, determine in batches whether the suspicious threads in the group trigger a docking event; wherein, different groups correspond to different set durations, and an upper limit value of the set activity range corresponding to the group is positively correlated with the set duration.

[0118] In a possible implementation manner, the second determining module 32 is further configured to:

[0119] Under the condition that any of the suspicious threads in the group is monitored to trigger a hang event, it is again monitored whether any of the suspicious threads triggers a hang event.

[0120] In a possible implementation, the fourth determining module 34 is specifically configured to:

[0121] comparing the frequency to a set threshold;

[0122] If the frequency is greater than the set threshold, the suspicious thread is determined to be a plug-in thread;

[0123] If the comparison shows that the frequency is less than the set threshold, it is determined that the suspicious thread is not a plug-in thread.

[0124] Figure 4 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. Figure 4 The electronic device 400 shown includes: at least one processor 401, a memory 402, at least one network interface 404 and another user interface 403. The various components in the electronic device 400 are coupled together via a bus system 405. It is understood that the bus system 405 is used to achieve connection and communication between these components. In addition to including a data bus, the bus system 405 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, the bus system 405 is not shown in FIG. Figure 4 Various buses are labeled as bus system 405 .

[0125] The user interface 403 may include a display, a keyboard, or a pointing device (eg, a mouse, a trackball, a touchpad, or a touch screen).

[0126] It is understood that the memory 402 in the embodiment of the present invention may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM bus random access memory (DRRAM). The memory 402 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0127] In some embodiments, the memory 402 stores the following elements, executable units or data structures, or a subset thereof, or an extended set thereof: an operating system 4021 and application programs 4022 .

[0128] The operating system 4021 includes various system programs, such as a framework layer, a core library layer, and a driver layer, for implementing various basic services and handling hardware-based tasks. Application programs 4022 include various application programs, such as a media player (MediaPlayer) and a browser (Browser), for implementing various application services. Programs implementing the methods of the embodiments of the present invention may be included in application programs 4022.

[0129] In an embodiment of the present invention, by calling a program or instruction stored in the memory 402, specifically, a program or instruction stored in the application 4022, the processor 401 is configured to execute the method steps provided in each method embodiment, for example, including:

[0130] Identify multiple suspicious threads for cheat detection;

[0131] Monitoring whether each of the suspicious threads triggers a docking event, wherein the docking event is used to indicate that the suspicious thread is docked to a target program;

[0132] Under the condition that the suspicious thread triggers the anchoring event, determining the frequency of the suspicious thread triggering the anchoring event within a preset collision period;

[0133] Determine whether the suspicious thread is a plug-in thread based on the frequency.

[0134] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits in processor 401 or by software instructions. The above processor 401 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The methods, steps, and logic block diagrams disclosed in the embodiments of the present invention can be implemented or executed. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in conjunction with the embodiments of the present invention can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software units in the decoding processor. The software units can be located in storage media well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory 402 , and the processor 401 reads the information in the memory 402 and completes the steps of the above method in combination with its hardware.

[0135] It is understood that the embodiments described herein may be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSP devices, DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or a combination thereof.

[0136] For software implementation, the technology described herein can be implemented by a unit that performs the functions described herein. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

[0137] The electronic device provided in this embodiment may be Figure 4 The electronic device shown in FIG. 1 can perform the following operations: Figure 1-2 All steps of the cheat detection method in the Figure 1-2 For details on the technical effects of the cheat detection method shown, please refer to Figure 1-2 For the sake of brevity, the relevant description will not be repeated here.

[0138] An embodiment of the present invention further provides a storage medium (computer-readable storage medium). The storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and the memory may also include a combination of the aforementioned types of memory.

[0139] When one or more programs in the storage medium can be executed by one or more processors, the above-mentioned cheat detection method executed on the electronic device side can be implemented.

[0140] The processor is configured to execute a cheat detection program stored in the memory to implement the following cheat detection method steps performed on the electronic device side:

[0141] Identify multiple suspicious threads for cheat detection;

[0142] Monitoring whether each of the suspicious threads triggers a docking event, wherein the docking event is used to indicate that the suspicious thread is docked to a target program;

[0143] When it is detected that the suspicious thread triggers the docking event, determining a frequency of the suspicious thread triggering the docking event within a preset collision period;

[0144] Determine whether the suspicious thread is a plug-in thread based on the frequency.

[0145] Professionals should also be further aware that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0146] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0147] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A cheat detection method, characterized in that: The method comprises: Identify multiple suspicious threads for cheat detection; Monitoring whether each of the suspicious threads triggers a docking event, wherein the docking event is used to indicate that the suspicious thread is docked to a target program; Under the condition that the suspicious thread triggers the anchoring event, determining the frequency of the suspicious thread triggering the anchoring event within a preset collision period; Determining whether the suspicious thread is a plug-in thread based on the frequency; The step of determining multiple suspicious threads to be detected for cheating includes: Determine the activity of each live thread in the system; Determine the surviving thread whose activity satisfies a set condition as a suspicious thread to be detected for cheating; Determining the activity of each surviving thread in the system includes: For each live thread in the system, perform the following steps: Obtaining the swapcontext value of the surviving thread according to a set period until a set number of the swapcontext values are obtained; and Starting from the second cycle, the swapcontext values obtained in the previous and next cycles are subtracted to obtain a swapcontext difference value; the swapcontext difference value is positively correlated with the activity of the surviving thread; The step of determining the surviving thread whose activity satisfies a set condition as a suspicious thread to be detected for cheating includes: For each surviving thread in the system, sort the swapcontext differences of the surviving threads obtained in the order of acquisition time to obtain a swapcontext difference sequence of the surviving threads; If the swapcontext difference sequence is an increasing sequence, the surviving thread is determined as a suspicious thread to be subjected to cheat detection.

2. The method according to claim 1, characterized in that The monitoring of whether each of the suspicious threads triggers a docking event includes: For each suspicious thread, the following steps are executed in a loop within a set time period: Obtaining data content at a specified offset address in the suspicious thread kernel object; Determining whether the data content is a kernel object address of the target program; If yes, stop the loop and determine that the suspicious thread triggers a docking event; If not, the process continues to loop until the set time is reached and it is determined that the suspicious thread has not triggered a docking event.

3. The method according to claim 2, characterized in that The monitoring of whether each of the suspicious threads triggers a docking event includes: Grouping the plurality of suspicious threads according to the activity, wherein the activity of the suspicious threads in the same group is within the same set activity range, and the set activity ranges corresponding to different groups do not overlap; For each of the groups, batch monitoring is performed to determine whether the suspicious threads in the group trigger a docking event.

4. The method according to claim 3, characterized in that After batch monitoring of whether the suspicious threads in the group trigger a docking event, the method further includes: Under the condition that any of the suspicious threads in the group is monitored to trigger a hang event, it is again monitored whether any of the suspicious threads triggers a hang event.

5. The method according to claim 1, wherein The determining whether the suspicious thread is a plug-in thread based on the frequency includes: comparing the frequency to a set threshold; If the frequency is greater than the set threshold, the suspicious thread is determined to be a plug-in thread; If the comparison shows that the frequency is less than the set threshold, it is determined that the suspicious thread is not a plug-in thread.

6. A cheat detection device, characterized in that: The device comprises: A first determination module is used to determine multiple suspicious threads to be detected for cheating; A second determining module is configured to monitor whether each of the suspicious threads triggers a docking event, wherein the docking event is used to indicate that the suspicious thread is docked to a target program; A third determining module is configured to determine a frequency of triggering the anchoring event by the suspicious thread within a preset collision period under the condition that the suspicious thread triggers the anchoring event; a fourth determining module, configured to determine whether the suspicious thread is a plug-in thread based on the frequency; The step of determining multiple suspicious threads to be detected for cheating includes: Determine the activity of each live thread in the system; Determine the surviving thread whose activity satisfies a set condition as a suspicious thread to be detected for cheating; Determining the activity of each surviving thread in the system includes: For each live thread in the system, perform the following steps: Obtaining the swapcontext value of the surviving thread according to a set period until a set number of the swapcontext values are obtained; and Starting from the second cycle, the swapcontext values obtained in the previous and next cycles are subtracted to obtain a swapcontext difference value; the swapcontext difference value is positively correlated with the activity of the surviving thread; The step of determining the surviving thread whose activity satisfies a set condition as a suspicious thread to be detected for cheating includes: For each surviving thread in the system, sort the swapcontext differences of the surviving threads obtained in the order of acquisition time to obtain a swapcontext difference sequence of the surviving threads; If the swapcontext difference sequence is an increasing sequence, the surviving thread is determined as a suspicious thread to be subjected to cheat detection.

7. The device according to claim 6, characterized in that The second determining module is specifically configured to: For each suspicious thread, the following steps are executed in a loop within a set time period: Obtaining data content at a specified offset address in the suspicious thread kernel object; Determining whether the data content is a kernel object address of the target program; If yes, stop the loop and determine that the suspicious thread triggers a docking event; If not, the process continues to loop until the set time is reached and it is determined that the suspicious thread has not triggered a docking event.

8. An electronic device, characterized in that: include: A processor and a memory, wherein the processor is used to execute a cheat detection program stored in the memory to implement the cheat detection method according to any one of claims 1 to 5.

9. A storage medium, characterized in that: The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the cheat detection method according to any one of claims 1 to 5.

Images