A method and apparatus for detecting a cheating application

Abstract

This specification discloses a method and apparatus for detecting cheating applications. By creating a child process corresponding to the main process based on a secondary identifier that is different from the main identifier of the target application's main process, the child process further calls the system's file query interface to query the core files of the cheating application. As can be seen from the above method, since the identifier of the child process is different from that of the main process, even if a framework-type cheating application obtains root privileges, it cannot modify the file query results of the child process, thereby ensuring the accuracy of the cheating application detection results and improving the detection effect on framework-type cheating applications that have obtained root privileges.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and apparatus for detecting cheating applications. Background Technology

[0002] Currently, with the development of computer technology, cheating applications are also constantly evolving. Especially for open-source systems, cheating applications can more easily gain administrator privileges, making the system vulnerable to attacks. Android, as one of the most commonly used operating systems on mobile devices, is also susceptible to attacks by cheating applications.

[0003] One common type of cheating application in the Android system is that it installs a framework-based cheating application in the terminal and creates an independent partition to run modules under the framework (such as a virtual location module) when the system starts up, thereby bypassing the system partition's self-check and traditional anti-cheating detection methods.

[0004] When detecting cheating applications using frameworks, existing technologies require the application (App) to call the system's file query interface after startup to check if the core files of the framework exist in the system, in order to determine whether the framework is installed in the system.

[0005] However, because framework-based cheating applications gain root privileges, once it's determined which apps need to be prevented from being detected, root privileges can be used to pre-modify the file query results returned by the system interface to those apps, causing them to receive incorrect query results through the system's file query interface. In other words, even if the framework app is installed on the system, it will be unable to query the core files. Therefore, the existing technology has a serious flaw, resulting in poor detection effectiveness against framework-based cheating applications that have gained root privileges. Summary of the Invention

[0006] This specification provides a cheating application detection method and apparatus, which at least partially solves the problems existing in the prior art.

[0007] The following technical solution is adopted in this specification:

[0008] This specification provides a method for detecting cheating applications, including:

[0009] Create the main process of the target application based on the target application's main identifier;

[0010] A child process corresponding to the main process is created based on a secondary identifier that is different from the main identifier.

[0011] The subprocess calls the system's file query interface to query the core files of the cheating application.

[0012] Through inter-process calls with the child process, the main process obtains the query results and determines the detection result of the cheating application based on the query results.

[0013] Optionally, a child process corresponding to the main process is created based on a secondary identifier that is different from the main identifier, specifically including:

[0014] When it is determined that the account login task of the target application has been completed, or when a detection request is received from the server corresponding to the target application, a secondary identifier different from the primary identifier is determined;

[0015] Based on the secondary identifier, create a child process corresponding to the main process.

[0016] Optionally, a child process corresponding to the main process is created based on a secondary identifier that is different from the main identifier, specifically including:

[0017] A child process corresponding to the main process is created based on a secondary identifier that is different from the main identifier and environment parameters that are different from the main process.

[0018] Optionally, the system's file query interface can be invoked to query the core files of the cheating application, specifically including:

[0019] Based on the preset information parameters of the core file of the cheating application and the functions for calling the file query interface stored in the system function library, the calling function is determined and the function is run to query whether the core file of the cheating application is stored in the system.

[0020] Optionally, the system's file query interface can be invoked to query the core files of the cheating application, specifically including:

[0021] Obtain the function for calling the file query interface from the function library of the target application;

[0022] Based on the preset information parameters of the core file of the cheating application and the function of calling the file query interface, the calling function is determined and the function is run to query whether the core file of the cheating application is stored in the system.

[0023] Optionally, determining the detection result of the cheating application based on the query result specifically includes:

[0024] Determine the filenames and storage addresses included in the query results;

[0025] Based on the preset cheating application file path, determine whether there is a storage address in the query results that matches the file path;

[0026] If it exists, then the cheating application is confirmed to exist in the system;

[0027] If it does not exist, then the cheating application does not exist in the system.

[0028] Optionally, the method further includes:

[0029] The detection results are sent to the child process via inter-process calls;

[0030] The detection results are returned to the server corresponding to the target application through the subprocess.

[0031] This manual provides a cheating application detection device, including:

[0032] The main creation module is used to create the main process of the target application based on the main identifier of the target application.

[0033] The sub-process creation module is used to create a sub-process corresponding to the main process based on a sub-identifier that is different from the main identifier;

[0034] The query module is used to call the system's file query interface through the subprocess to query the core files of the cheating application;

[0035] The acquisition module is used to enable the main process to acquire the query results through inter-process calls with the child process, and to determine the detection result of the cheating application based on the query results.

[0036] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described cheating application detection method.

[0037] This specification provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described cheating application detection method.

[0038] The above-mentioned technical solutions adopted in this specification can achieve the following beneficial effects:

[0039] The cheating application detection method provided in this specification creates a child process corresponding to the main process based on a secondary identifier that is different from the main identifier of the target application's main process. The child process then calls the system's file query interface to query the core files of the cheating application.

[0040] As can be seen from the above method, since the identifier of the child process is different from that of the main process, even if the framework-based cheating application obtains root privileges, it cannot modify the file query results of the child process, thereby ensuring the accuracy of the cheating application detection results and improving the detection effect on framework-based cheating applications that have obtained root privileges. Attached Figure Description

[0041] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0042] Figure 1 This is a flowchart illustrating a cheating application detection process provided in this manual.

[0043] Figure 2 This document provides a schematic diagram of inter-process access.

[0044] Figure 3 This is a schematic diagram of a cheating application detection device provided in this specification;

[0045] Figure 4 This is a schematic diagram of an electronic device that implements a cheating application detection method as provided in this specification. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative effort are within the scope of protection of this application.

[0047] Android is an open-source operating system primarily used in mobile phones, tablets, and other terminal devices. From a security perspective, terminals restrict user permissions, which are divided into user permissions and root permissions. Root permissions are the highest level of access on the terminal, allowing users to perform CRUD operations on any file in the system, including system files. Because of the power of root permissions, enabling them would pose significant security risks to the terminal; therefore, terminals generally only allow user permissions. User permissions, while ensuring terminal security, also restrict the resources that apps on the terminal system can access.

[0048] Framework-based cheating applications (such as the Magisk framework) can also achieve their illegal purposes by obtaining root privileges. For example, suppose a user of this framework is a delivery driver. If the driver wants to grab orders with shorter or more convenient delivery routes, their device can obtain root privileges through the framework and run modules within the framework to modify system data, bypassing the order refresh speed set by the food delivery app to quickly place orders. These modules can then rapidly select and grab orders based on preset delivery destinations. Alternatively, if the driver wants to be pushed orders to a specific delivery address, their device can obtain root privileges through the framework and modify their system location. This makes the delivery app perceive the driver's location as more suitable for push notifications, increasing the probability of orders to that address being pushed to that driver. These methods can cause losses to both the delivery platform and customers.

[0049] Currently, the detection process for framework-based cheating applications involves the app first calling the system file query interface to obtain the query results for the framework's core files, thereby determining whether the framework is installed on the system. However, with the evolution of framework-based cheating applications, the framework can now counter-detection by the app itself. Specifically, when an app attempts to detect the framework, the framework can modify the file query results for the app's process using the app's user identification (uid) in the Android system. Therefore, from the app's perspective, calling the system interface will not reveal the framework's core files. In other words, from the app's perspective, the framework's core files either do not exist on the system or have been "uninstalled."

[0050] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0051] Figure 1 This is a flowchart illustrating a cheating application detection method described in this specification, which specifically includes the following steps:

[0052] S100: Create the main process of the target application based on the main identifier of the target application.

[0053] In practical applications, for a terminal with an Android system installed, when an app installed on the terminal starts up, the terminal's system can determine the system resources allocated to it based on the app's main identifier, that is, the app's UID. Each app has its own main identifier.

[0054] Based on this, in one or more embodiments of this specification, the terminal can create the main process of the target application based on the main identifier of the target application. The mapping between the installed apps and their UIDs on the terminal is persistently stored; even if an app is updated or uninstalled and reinstalled, the system will still assign it the original UID. The main process refers to the process that the system allocates to the app by default when it starts.

[0055] The term "terminal" in this manual refers to a mobile phone, tablet computer, or other terminal device that has the Android operating system installed. The "target application" refers to any application on the terminal system that requires cheating application detection. For ease of explanation, the following description focuses solely on the terminal as the execution subject. Based on this, by applying the cheating application detection method provided in this manual, applications on the terminal system can detect, while running, whether any framework-based cheating applications are installed on the terminal system. For example, a food delivery app can detect whether any framework-based cheating applications that obtain root privileges are installed on the terminal system.

[0056] S102: Create a child process corresponding to the main process based on a secondary identifier that is different from the main identifier.

[0057] In one or more embodiments of this specification, after creating a main process for the target application, the terminal, in order to prevent cheating applications from altering the query results of the core files of cheating applications in the main process and its corresponding child processes through the target application's UID, can determine a secondary identifier that is different from the main process's primary identifier. Then, based on this secondary identifier, a child process corresponding to the main process is created. This child process is then used in subsequent steps to query whether the core files of a framework-type cheating application exist in the terminal's system.

[0058] Specifically, in the Android system, when assigning a UID to an app, the system can assign a UID according to a preset numerical range (e.g., 10000-19999). In this specification, the terminal can, within an available range outside this range, randomly determine a secondary identifier different from the main identifier of the target application according to the Android system's UID naming rules. This secondary identifier is then used as the UID of the child process, and a child process corresponding to the main process of the target application is created. For example, the range 30000-39999 is selected as a random range, and a value is randomly chosen from within it as the secondary identifier, i.e., the UID of the child process. Then, the child process corresponding to the main process is created based on this UID.

[0059] Of course, there are many other ways to determine a secondary identifier that is different from the primary identifier, which will not be illustrated in detail here.

[0060] Furthermore, since the main process and child processes generally run in the same environment—that is, their contexts are identical—cheating applications that have obtained root privileges can identify the child process corresponding to the main process of the target application based on the process's environment parameters. Therefore, to prevent this, in one or more embodiments of this specification, when creating a child process, the terminal can also create a child process corresponding to the main process based on a different sub-identifier and different environment parameters than the main process. Environment parameters may include process contexts such as Security-Enhanced Linux context (SELinux context). Of course, there are many other types of environment parameters for process execution, which will not be elaborated upon here. As the child process is created based on a different uid and a different SELinux context than the main process, although logically the child process in this specification is a child process of the main process, from the system level perspective, due to the difference in uid and SELinux context, the child process is unrelated to the main process.

[0061] S104: The subprocess calls the system's file query interface to query the core files of the cheating application.

[0062] Generally, after gaining root privileges, a framework-based cheating application can access the mount namespace of the process corresponding to the target app's UID (i.e., the UID of the target app). It then unmounts all files or directories modified by the framework (e.g., the framework's core files). Mount namespaces isolate the file directory view of a process; each mount namespace has its own file directory list, and different processes within different mount namespaces can see or manipulate different file directory views. Therefore, when the framework enters the mount namespace of the process corresponding to the target app's UID and unmounts all files or directories modified by the framework, the target app's process cannot find the framework's core files by calling system interfaces. In other words, from the target app's perspective, the framework's core files either do not exist in the system or have been "unmounted."

[0063] After step S102, the terminal can create a child process with a different UID than the main process of the target application. Therefore, the anti-detection methods of the cheating application cannot modify the file query results of the child process based on its UID. That is, the child process can obtain the correct query results for the core files of the cheating application by calling the system's file query interface. Thus, in one or more embodiments of this specification, the terminal can use the child process to call the system's file query interface to query the core files of the cheating application, thereby determining whether a cheating application is installed on the system.

[0064] Specifically, when querying the core file of a cheating application, the terminal can determine and run the calling function based on the preset information parameters of the core file of the cheating application, such as the name of the core file and the function of calling the file query interface stored in the system function library, and obtain the query result.

[0065] For example, if the core file name of a cheating application is "xxx", then "xxx" can be determined as the information parameter of the core file of the preset cheating application based on the core file name. Then, the function to call the file query interface is determined from the system function library, and the information parameter of the core file is passed to the determined calling function. The calling function traverses the files in the system according to the passed core file information parameter, and searches for a file with the name "xxx" in the system. If a file with the name "xxx" is found in the system, then that file may be the core file of the cheating application. Finally, all files with the name "xxx" can be obtained.

[0066] In subsequent steps, the child process can send the filenames and storage addresses of these files to the main process, which will then determine whether these files are core files of the cheating application and thus obtain the detection results.

[0067] In addition, to prevent cheating applications from modifying the system's file query interface functions and thus altering the query results of the system's functions for the cheating application's core files, the target application can also implement its own file query interface functions in its function library.

[0068] In this scenario, specifically, when the terminal queries the core files of a cheating application, it can obtain the function for calling the file query interface from the target application's function library. Based on the preset information parameters of the cheating application's core files and the function for calling the file query interface, the terminal determines and executes the function to query whether the cheating application's core files are stored in the system. This prevents the cheating application from modifying the system's file query interface function, thus avoiding detection failure.

[0069] For example, the function for calling the file query interface can be obtained from the function library of the target application. Then, when the core file name of a cheating application is determined to be "xxx", "xxx" can be used as the information parameter of the core file of the preset cheating application. Then, the information parameter of the core file is passed into the obtained calling function, and the calling function is run to obtain the query result.

[0070] S106: Through inter-process calls with the child process, the main process obtains the query results and determines the detection result of the cheating application based on the query results.

[0071] The query results obtained above are only in the child process, so the terminal needs to use inter-process communication (IPC) with the child process to enable the main process to obtain the query results. Therefore, after obtaining the query results, the main process can determine the detection result of the cheating application based on the query results.

[0072] Furthermore, the core files retrieved above may contain incorrect query results (i.e., files with the same name but not the core files of the cheating application). Therefore, the terminal needs to determine the detection result of the cheating application through the main process based on the query results. Specifically, when determining the detection result of the cheating application based on the query results, the filenames and storage addresses of the files included in the query results can be determined first. Then, based on the preset cheating application file path, it is determined whether there is a storage address in the query results that matches the file path. If it exists, it is determined that the cheating application exists in the system. If it does not exist, it is determined that the cheating application does not exist in the system. In other words, it is determined whether the retrieved file is the core file of the cheating application, thereby avoiding the possibility of misjudgment.

[0073] For example, when a cheating application framework is installed on a terminal's system, a file path ` / sbin / xxx` will appear at the system level, where "xxx" is the core file name of the cheating application. Therefore, using ` / sbin / xxx` as a preset file path, all query result file storage addresses are matched against this preset path one by one. If the storage address of a query result matches the preset file path ` / sbin / xxx`, it means that this query result is the core file of the cheating application, and thus the cheating application exists on the system. If none of the query result file paths match the preset file path, it means that none of the query results are the core file of the cheating application; they are all just files with the same name, and thus the cheating application does not exist on the system. Of course, if the query result is empty, it can also be directly determined that the cheating application does not exist on the system.

[0074] Using the above method, it is possible to effectively determine whether there are core files of cheating applications in all query results, thereby ensuring the accuracy of detection.

[0075] based on Figure 1 The cheating application detection method shown above, when detecting cheating applications, creates a child process corresponding to the main process based on a secondary identifier that is different from the main identifier of the target application's main process, and further calls the file query interface in the system through the child process to query the core files of the cheating application.

[0076] As can be seen from the above method, since the identifier of the child process is different from that of the main process, even if the framework-based cheating application obtains root privileges, it cannot modify the file query results of the child process, thereby ensuring the accuracy of the cheating application detection results and improving the detection effect on framework-based cheating applications that have obtained root privileges.

[0077] Furthermore, in one or more embodiments of this specification, the terminal may also determine that the target application's account login task has been completed before executing step S102, that is, determining a secondary identifier different from the target application's primary identifier and executing subsequent detection steps. Generally, an app needs to log in to its account before it can further use its user functions. Therefore, if the user is not logged in, the cheating application can be left undetected. For example, a food delivery app requires the delivery person to log in before they can accept, receive, or deliver orders. Therefore, the target application can execute subsequent detection steps only after confirming that the user's account login is complete. Thus, detection is only performed when necessary, avoiding unnecessary detection and thus preventing the consumption of system resources.

[0078] Furthermore, in one or more embodiments of this specification, the terminal may also execute step S102 upon receiving a detection request from the server corresponding to the target application, determining a secondary identifier different from the primary identifier of the target application, and then executing subsequent detection steps. Although generally, an app requires account login before it can further utilize its user functions, it cannot be guaranteed that a user will perform potentially fraudulent operations after logging in. For example, a delivery person logging into a food delivery app might only view orders or modify personal information. Therefore, the server corresponding to the target application can initiate a fraudulent application detection request to the terminal's target application when the user performs an potentially fraudulent operation. Upon receiving the detection request from the server corresponding to the target application, the target application then executes subsequent detection steps. Thus, by more accurately determining the conditions for performing detection, the ineffective use of system resources can be further reduced.

[0079] Furthermore, in one or more embodiments of this specification, to prevent cheating applications from modifying the detection results returned to the corresponding server by the main process of the target application using the target application's UID, the terminal can also send the detection results from the main process to the child process via inter-process calls, and the child process can then return the detection results to the server corresponding to the target application. This avoids cheating applications from modifying the detection results returned to the corresponding server by the main process of the target application using the target application's UID.

[0080] Furthermore, in one or more embodiments of this specification, the child process that is different from the target application's main identifier can be implemented using an isolated process in the Android system. The terminal device installed in this specification with the Android system can be a terminal device with a system having an Android kernel installed.

[0081] It's important to note that once a framework-based cheating application gains root privileges, it can access the mount namespace of the process corresponding to the target application's UID and unload all files or directories modified by the framework. Therefore, under normal circumstances, the target application's main process and its corresponding child processes cannot detect the framework's core files, meaning they cannot detect the framework itself.

[0082] In addition, this manual also provides diagrams illustrating the inter-process calls during the detection of cheating applications, such as... Figure 2 As shown.

[0083] Figure 2 As can be seen, the child process is created based on a different UID (i.e., a secondary identifier B different from the main identifier A) and different environment parameters (i.e., environment parameter D different from environment parameter C). Therefore, cheating applications of this framework class cannot perform anti-detection on the child process described in this specification based on the target application's UID (i.e., the stored main identifier A), nor can they identify the child process based on the process's environment parameters. In other words, the terminal can detect the core file of the framework through this child process, thereby determining that a cheating application of this framework class exists in the terminal system. Figure 2 The arrow pointing from the main process to the cheating application indicates that the main process queries core files via the system's API. The arrow pointing from the cheating application to the main process indicates the query results returned by the system after the cheating application has been uninstalled. The "×" symbol on this arrow indicates that the returned query results are incorrect. The arrow pointing from the cheating application to the child process indicates that the child process can obtain the correct query results. The child process and the main process can use inter-process calls to send the query results obtained by the child process to the main process, allowing the main process to confirm the detection results.

[0084] The above describes one or more embodiments of cheating application detection methods provided in this specification. Based on the same idea, this specification also provides corresponding cheating application detection devices, such as... Figure 3 As shown.

[0085] Figure 3 This specification provides a schematic diagram of a cheating application detection device, including:

[0086] The main creation module 300 is used to create the main process of the target application based on the main identifier of the target application;

[0087] The sub-process creation module 302 is used to create a sub-process corresponding to the main process based on a sub-identifier that is different from the main identifier;

[0088] The query module 304 is used to call the file query interface in the system through the subprocess to query the core files of the cheating application;

[0089] The acquisition module 306 is used to enable the main process to acquire the query result through inter-process calls with the child process, and to determine the detection result of the cheating application based on the query result.

[0090] Optionally, when the sub-creation module 302 determines that the account login task of the target application has been completed, or receives a detection request sent by the server corresponding to the target application, it determines a sub-identifier that is different from the main identifier, and creates a sub-process corresponding to the main process based on the sub-identifier.

[0091] Optionally, the sub-creation module 302 creates a sub-process corresponding to the main process based on a sub-identifier that is different from the main identifier and environmental parameters that are different from the main process.

[0092] Optionally, the query module 304 determines and runs a function to query whether the core file of the cheating application is stored in the system, based on the preset information parameters of the core file of the cheating application and the function of the file query interface stored in the system function library.

[0093] Optionally, the query module 304 obtains a function for calling the file query interface from the function library of the target application, determines the calling function based on the preset information parameters of the core file of the cheating application and the function for calling the file query interface, and runs the function to query whether the core file of the cheating application is stored in the system.

[0094] Optionally, the acquisition module 306 determines the file name and file storage address included in the query result, and determines whether there is a storage address in the query result that matches the file path according to the preset cheating application file path. If it exists, it is determined that the cheating application exists in the system; otherwise, it is determined that the cheating application does not exist in the system.

[0095] The sending module 308 is used to send the detection result to the child process through an inter-process call, and then the child process returns the detection result to the server corresponding to the target application.

[0096] This specification also provides a computer-readable storage medium storing a computer program that can be used to execute the above-described... Figure 1 The provided cheating application detection method.

[0097] This instruction manual also provides Figure 4 The diagram shows the structure of the electronic device. Figure 4 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for the business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to achieve the above-mentioned functions. Figure 1 The method for detecting cheating applications.

[0098] Of course, in addition to the software implementation method, this specification does not exclude other implementation methods, such as the combination of hardware and software XOR logic devices, etc. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0099] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0100] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0101] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0102] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0103] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0104] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0105] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0106] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0107] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0108] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0109] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0110] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0111] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0112] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0113] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0114] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A method of detecting a cheat application, characterized by, include: Create the main process of the target application based on the target application's main identifier; Based on a secondary identifier that is different from the primary identifier and environment parameters that are different from the primary process, a child process corresponding to the primary process is created; The subprocess retrieves the function for calling the file query interface from the function library of the target application. Based on the preset information parameters of the core file of the cheating application and the function of calling the file query interface, determine the calling function and run the function to query whether the core file of the cheating application is stored in the system; Through inter-process calls with the child process, the main process obtains the query results and determines the detection result of the cheating application based on the query results; The detection results are sent to the child process via inter-process calls; The detection results are returned to the server corresponding to the target application through the subprocess.

2. The method as described in claim 1, characterized in that, Based on a secondary identifier different from the primary identifier and environment parameters different from the primary process, a child process corresponding to the primary process is created, specifically including: When it is determined that the account login task of the target application has been completed, or when a detection request is received from the server corresponding to the target application, a secondary identifier different from the primary identifier is determined; Based on the secondary identifier, create a child process corresponding to the main process.

3. The method as described in claim 1, characterized in that, Obtain the function for calling the file query interface from the function library of the target application, specifically including: Based on the information parameters of the core file of the cheating application and the functions of the file query interface stored in the system function library, the calling function is determined and the function is run to query whether the core file of the cheating application is stored in the system.

4. The method as described in claim 1, characterized in that, The detection result of the cheating application is determined based on the query results, specifically including: Determine the filenames and storage addresses included in the query results; Based on the preset cheating application file path, determine whether there is a storage address in the query results that matches the file path; If it exists, then the cheating application is confirmed to exist in the system; If it does not exist, then the cheating application is determined to be absent from the system.

5. A cheating application detection device, characterized in that, include: The main creation module is used to create the main process of the target application based on the main identifier of the target application. The sub-process creation module is used to create a sub-process corresponding to the main process based on a sub-identifier that is different from the main identifier and environment parameters that are different from the main process. The query module is used to obtain, through the subprocess, the function that calls the file query interface from the function library of the target application; Based on the preset information parameters of the core file of the cheating application and the function of calling the file query interface, determine the calling function and run the function to query whether the core file of the cheating application is stored in the system; The acquisition module is used to enable the main process to acquire query results through inter-process calls with the sub-process, and to determine the detection result of the cheating application based on the query results; The sending module is used to send the detection result to the child process via inter-process calls; The return module is used to return the detection results to the server corresponding to the target application through the subprocess.

6. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1 to 4.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method described in any one of claims 1 to 4.

Images