Program integrity verification method and device, equipment and storage medium

Abstract

The invention provides a program integrity verification method and device, equipment and a storage medium, and relates to the technical field of computers. The program integrity verification method comprises the following steps: when detecting that a first process is started, positioning a first program file corresponding to the first process; when the first program file meets a preset condition, generating a first metric value of the first program file; generating a second metric value of the first program file after the first program file is modified by the process of the super user permission; when the first metric value is matched with the second metric value, determining that the first program file passes integrity verification and the process is a trusted process; and when the first metric value is not matched with the second metric value, determining that the integrity verification of the first program file is not passed and the first process is an untrusted process. According to the method and the device, the untrusted risk of program integrity caused by unauthorized modification of the program file content can be subjected to security detection, and program running with potential safety hazards can be avoided.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a program integrity verification method, device, equipment and storage medium. Background Art

[0002] With the development of mobile Internet and the intelligence of electronic devices, users can load applications for network devices (such as routers, switches, servers) or personal electronic devices (such as mobile phones and tablets) according to their own needs. At the same time, these applications are at risk of being tampered with and attacked during the loading and running process. For example, attackers can tamper with applications, such as implanting malicious code, to destroy the integrity of the application, causing abnormal use of network devices or personal electronic devices, malicious attacks and information leakage, or affecting the normal operation of computers.

[0003] Improper program permission settings during the operation and maintenance phase, or system vulnerability attacks can cause the content of non-writable files to be modified without authorization, destroying the integrity of the program. In related technologies, a command whitelist can be added for some special programs, and an alarm will be issued when the process corresponding to the special program executes commands outside the whitelist. However, the command whitelist corresponding to special programs can only be effective for common special programs, such as dudo, su, pkexec, etc. For special programs customized due to business needs, the command whitelist cannot fully cover business scenarios due to the diversity of business needs. At the same time, the command whitelist is also prone to false alarms and is easy to be bypassed. Summary of the invention

[0004] The embodiments of the present application provide a program integrity verification method, apparatus, device and storage medium, which can perform security detection on the risk of untrustworthy program integrity caused by unauthorized modification of program file contents, which is helpful to avoid the operation of programs with security risks.

[0005] In a first aspect, a program integrity verification method is provided, comprising:

[0006] When detecting that a first process is started, locating a first program file corresponding to the first process;

[0007] When the first program file meets a preset condition, generating a first metric value of the first program file;

[0008] After the first program file is modified by a process with superuser privileges, generating a second metric value of the first program file;

[0009] When the first metric value matches the second metric value, determining that the first program file passes the integrity check and the first process is a trusted process;

[0010] When the first metric value and the second metric value do not match, it is determined that the integrity check of the first program file fails and the first process is an untrusted program.

[0011] In a second aspect, a program integrity verification device is provided, comprising:

[0012] A first detection unit, configured to locate a first program file corresponding to a first process when detecting that the first process is started;

[0013] a generating unit, configured to generate a first metric value of the first program file when the first program file meets a preset condition;

[0014] The generating unit is further configured to generate a second metric value of the first program file after the first program file is modified by a process with super user privileges;

[0015] a determining unit, configured to determine, when the first metric value matches the second metric value, that the first program file passes the integrity check and the first process is a trusted process;

[0016] The determining unit is further configured to determine that the integrity check of the first program file fails and the first process is an untrusted program when the first metric value and the second metric value do not match.

[0017] In a third aspect, an electronic device is provided, comprising: a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory to execute the method of the first aspect or its various embodiments.

[0018] In a fourth aspect, a computer-readable storage medium is provided for storing a computer program, wherein the computer program enables a computer to execute the method in the first aspect or its various embodiments.

[0019] According to a fifth aspect, a computer program product is provided, comprising computer program instructions, wherein the computer program instructions enable a computer to execute the method according to the first aspect or its various embodiments.

[0020] In summary, the embodiment of the present application detects the behavior of the process file, locates the program file corresponding to the process when the process starts, and determines the first metric value of the corresponding program file when the program file corresponding to the process meets the preset conditions, and matches the first metric value with the second metric value of the program file. The second metric value is generated after the program file is modified by the process with super user privileges. Therefore, when the first metric value matches the second metric value, it can be determined that the program file corresponding to the current process passes the integrity check and the current process is a trusted process. When the first metric value does not match the second metric value, it can be determined that the program file corresponding to the current process does not pass the integrity check and the current process is an untrusted process. Therefore, the embodiment of the present application can perform security detection on the untrustworthy risk of program integrity caused by improper program permission settings or malicious tampering of the program by an attacker, which is conducive to avoiding the operation of programs with security risks.

[0021] In addition, the embodiments of the present application perform integrity verification on special programs that meet preset conditions, and can target special programs customized due to needs rather than just specific programs, which is conducive to better covering business scenarios and meeting the diverse characteristics of business needs.

[0022] Furthermore, the embodiment of the present application implements program integrity verification by determining whether the measurement value of a special program matches the measurement value generated after the program file is modified by a process with superuser privileges when a special process associated with the special program is started, thereby avoiding the problem of bypassing the whitelist by exploiting the limitations of the instruction whitelist. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0024] Figure 1 A schematic diagram of the structure of a computer system applicable to an embodiment of the present application;

[0025] Figure 2 A schematic diagram of a program integrity verification system provided in an embodiment of the present application;

[0026] Figure 3 A schematic flowchart of a program integrity verification system deployment process according to an embodiment of the present application;

[0027] Figure 4 is a schematic flow chart of a program integrity verification process according to an embodiment of the present application;

[0028] Figure 5 A schematic flowchart of a program integrity verification method provided in an embodiment of the present application;

[0029] Figure 6 A schematic flowchart of another program integrity verification method provided in an embodiment of the present application;

[0030] Figure 7 A schematic diagram of the structure of a program integrity verification device provided in an embodiment of the present application;

[0031] Figure 8 It is a schematic block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0032] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0033] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0034] First, the relevant terms involved in the embodiments of the present application are introduced.

[0035] Special programs: Programs with special permissions, such as Set User Identification (SUID) programs or programs with setuid cap. SUID is a special type of file permission given to files. In Linux / Unix, when a program is run, the program inherits permissions from the logged-in user. SUID is defined as giving a user temporary (program / file) owner permissions to run a program / file. In short, when a user executes a program / file / command, he or she will obtain the permissions of the file owner and the owner's User Identification (UID).

[0036] Root permission: a type of system permission, also called superuser permission, root permission, etc., without limitation. Root is the super administrator user account in the Linux system. This account has the highest permissions of the entire system and can easily perform all operations of adding, deleting, modifying and checking any file in the system (including system files).

[0037] Program: A computer program or software program is a set of instructions that tell a computer what to do. It is usually written in a programming language and runs on a target architecture. A program is a static binary file.

[0038] Process: The execution process of a program, that is, a running program. A process is a running activity of a program in a computer on a certain data set. It is the basic unit for resource allocation in the system and the basis of the operating system structure. In a computer structure designed for processes, a process is the basic execution entity of a program; in a computer structure designed for threads, a process is a container for threads. A program is a description of instructions, data and their organizational form, and a process is the entity of a program.

[0039] Fanotify: is a file system monitoring mechanism provided by the Linux kernel that can monitor file system operations and send notifications to user space. Fanotify can monitor file read, write and execute operations, as well as directory creation, deletion and renaming operations.

[0040] CVE-2016-519: A system vulnerability. An attacker can exploit the Linux kernel vulnerability to modify the contents of non-writable files with ordinary user privileges. A common attack method is for an attacker to modify the contents of a SUID program with ordinary user privileges and inject a backdoor. Ultimately, an attacker with ordinary user privileges can execute any root privilege instructions by starting a tampered SUID process.

[0041] Application integrity check is used to determine whether the application has been illegally tampered with, such as checking the application to determine whether the application has been modified by a normal user (such as a non-root user). If the application has been illegally tampered with, the computer can refuse to run the application.

[0042] Improper setting of program permissions during the operation and maintenance phase, or system vulnerability attacks may cause the content of non-writable files to be modified without authorization, destroying the integrity of the program and posing a security risk to the program. For example, improper setting of program permissions during the operation and maintenance phase mainly refers to the operation and maintenance personnel setting special program permissions to be writable by users with any permissions. System vulnerability attacks mainly refer to attackers exploiting system vulnerabilities (such as the CVE-2016–519 vulnerability) to forcibly tamper with the content of non-writable files with ordinary user permissions.

[0043] In the related art, in order to avoid the operation of applications with potential security risks, an instruction whitelist can be added to some special programs, and an alarm is issued when the process corresponding to the special program executes instructions outside the whitelist. However, the instruction whitelist corresponding to the special program can only take effect on common special programs, such as dudo, su, pkexec, etc. For special programs customized due to business needs, the instruction whitelist cannot fully cover the business scenarios because of the diversity of business needs. At the same time, the instruction whitelist is also prone to false positives. For example, the conventional function of sudo / pkexec is to execute any instruction executed by the user with root privileges. The program design conflicts with the instruction whitelist mechanism. Once a normal user executes an instruction outside the whitelist, a false positive will be generated. In addition, the instruction whitelist is easy to be bypassed. For example, the conventional use of sudo is to use sudo bash to start the bash program with root privileges, so the protection system designer must set the bash program to the instruction whitelist of the sudo process. But for an attacker, if he has the ability to tamper with the content of the sudo program, he only needs to remove the password verification mechanism that comes with sudo, and then the attacker can start the bash process with root privileges without a password when executing the sudo bash program, thereby achieving privilege escalation.

[0044] In view of this, the embodiments of the present application provide a program integrity verification method, apparatus, device and storage medium, which can perform security detection on the risk of untrustworthy program integrity caused by unauthorized modification of program file contents, which is helpful to avoid the operation of programs with security risks.

[0045] Specifically, when it is detected that the first process is started, the first program file corresponding to the first process is located; when the first program file meets a preset condition, a first measurement value of the first program file is generated; after the first program file is modified by a process with super user privileges, a second measurement value of the first program file is generated; when the first measurement value and the second measurement value match, it is determined that the integrity check of the first program file passes and the first process is a trusted process; when the first measurement value and the second measurement value do not match, it is determined that the integrity check of the first program file fails and the first process is an untrusted process.

[0046] The embodiment of the present application detects the behavior of the process file, locates the program file corresponding to the process when the process starts, and determines the first metric value of the corresponding program file when the program file corresponding to the process meets the preset conditions, and matches the first metric value with the second metric value of the program file. The second metric value is generated after the program file is modified by the process with super user privileges. Therefore, when the first metric value matches the second metric value, it can be determined that the program file corresponding to the current process passes the integrity check and the current process is a trusted process. When the first metric value does not match the second metric value, it can be determined that the program file corresponding to the current process does not pass the integrity check and the current process is an untrusted process. Therefore, the embodiment of the present application can perform security detection on the untrustworthy risk of program integrity caused by improper program permission settings or malicious tampering of the program by an attacker, which is conducive to avoiding the operation of programs with security risks.

[0047] Programs that meet preset conditions can be called special programs. Specifically, when a process with super-user privileges modifies a special program, the measurement value of the special program is updated and saved; when a special process associated with a special program is started, it is determined whether the measurement value of the special program matches the saved measurement value of the special program. In this way, in one possible scenario, when a special program is modified by a process with super-user privileges, its measurement value is updated and saved. When the special program is started, the current measurement value of the special program matches the saved measurement value, the program integrity check passes, and the special process is a trusted process. In another possible scenario, when a special program is tampered with by a user with ordinary privileges, the measurement value of the special program will not be updated. When the special program is started, the current measurement value of the special program does not match the saved measurement value of the special program. The program integrity check fails, and the special process is an untrusted program. In this case, the alarm will not generate a false alarm.

[0048] Exemplarily, the measurement values ​​of a special program may be stored in a whitelist, which is not limited in this application.

[0049] Exemplarily, the program file that meets the preset conditions may be a special program, such as a SUID program or a program with a Setuid cap, or a program customized for business needs, which is not limited in this application.

[0050] Exemplarily, the metric value of the program file may include a hash value of the program file. As an example, a corresponding tool or command may be used to generate a hash value of the program file, which is not limited in this application.

[0051] In addition, the embodiments of the present application perform integrity verification on special programs that meet preset conditions, and can target special programs customized due to needs rather than just specific programs, which is conducive to better covering business scenarios and meeting the diverse characteristics of business needs.

[0052] Furthermore, the embodiment of the present application implements program integrity verification by determining whether the measurement value of a special program matches the measurement value generated after the program file is modified by a process with superuser privileges when a special process associated with the special program is started, thereby avoiding the problem of bypassing the whitelist by exploiting the limitations of the instruction whitelist.

[0053] The following combination Figure 1 and Figure 2 Describe the system architecture applicable to the embodiments of the present application.

[0054] Figure 1 Schematic diagram of the structure of a computer system applicable to the embodiment of the present application. Figure 1 As shown, the computer system includes a communication module 110 , a sensor 120 , a user input module 130 , an output module 140 , a processor 150 , an audio and video input module 160 , a memory 170 and a power supply 180 .

[0055] The communication module 110 may include at least one module that enables the computer system to communicate with other computer systems. For example, the communication module 110 may include one or more of a wired network interface, a broadcast receiving module, a mobile communication module, a wireless Internet module, a local area communication module, and a location (or positioning) information module. These various modules are implemented in various ways in the prior art, and this application will not describe them one by one.

[0056] The sensor 120 may sense the current state of the system, such as an open / closed state, a position, whether there is contact with a user, a direction, and acceleration / deceleration, and the sensor 120 may generate a sensing signal for controlling the operation of the system.

[0057] The user input module 130 is used to receive input digital information, character information or contact touch operation / contactless gesture, and receive signal input related to user settings and function control of the system, etc. The user input module 130 includes a touch panel and / or other input devices.

[0058] The output module 140 includes a display panel for displaying information input by the user, information provided to the user, or various menu interfaces of the system. Optionally, the display panel can be configured in the form of a liquid crystal display (LCD) or an organic light-emitting diode (OLED). In some other embodiments, a touch panel can be covered on the display panel to form a touch display screen. In addition, the output module 140 can also include an audio output module, an alarm, and a tactile module.

[0059] The audio and video input module 160 is used to input audio signals or video signals. The audio and video input module 160 may include a camera and a microphone.

[0060] The power supply 180 may receive external power and internal power under the control of the processor 150 and provide power required for the operation of various components of the system.

[0061] The processor 150 may indicate one or more processors. For example, the processor 150 may include one or more central processing units, or include a central processing unit and a graphics processor, or include an application processor and a coprocessor (such as a microcontroller unit or a neural network processor). When the processor 150 includes multiple processors, the multiple processors may be integrated on the same chip or may be independent chips.

[0062] The memory 170 stores computer programs, including an operating system program 172 and an application program 171, etc. Typical operating systems include Windows, MacOS, etc., which are used for desktops or notebooks, and Linux / Unix-based Android systems, etc., which are used for mobile terminals.

[0063] For example, this article uses Figure 1 The embodiment disclosed in this application is described by taking the operating system of the computer system as the Linux system as an example. It should be noted that the embodiments disclosed in this application are not limited to the Linux system, and other systems can also use the method disclosed in the embodiments of this application to perform program integrity verification.

[0064] The memory 170 may be one or more of the following types: flash memory, hard disk type memory, micro multimedia card type memory, card memory (such as SD or XD memory), random access memory (RAM), static random access memory (SRAM), read only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable ROM (PROM), magnetic memory, magnetic disk or optical disk. In some other embodiments, the memory 170 may also be a network storage device on the Internet, and the system may perform operations such as updating or reading the memory 170 on the Internet.

[0065] The processor 150 is used to read the computer program in the memory 170 and then execute the method defined by the computer program. For example, the processor 150 reads the operating system program 172 to run the operating system and implement various functions of the operating system on the system, or reads one or more application programs 171 to run applications on the system.

[0066] The memory 170 also stores other data 173 besides the computer program, which is not limited in the embodiment of the present application.

[0067] Figure 1 The connection relationship between the modules is only an example. The method provided in any embodiment of the present application can also be applied to systems with other connection methods, such as all modules being connected through a bus, and the embodiments of the present application are not limited to this.

[0068] The above-mentioned computer system can be a terminal device, and a terminal device refers to a type of device with rich human-computer interaction methods, the ability to access the Internet, usually equipped with various operating systems, and strong processing capabilities. The terminal device can be a mobile phone, a television, a computer, a car terminal, a player game terminal, an intelligent voice interaction device, a smart home appliance, etc., but is not limited to this. The above-mentioned computer system can also be a system device, such as a server. The server can be any independent physical server, or it can be a cloud server that provides basic cloud services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, and big data and artificial intelligence platforms. It can also be a server cluster or distributed system composed of multiple physical servers, and the embodiments of this application do not limit this. Exemplarily, the server can be a computing device such as a rack server, a blade server, a tower server, or a cabinet server, without limitation.

[0069] Figure 2 A schematic diagram of a program integrity verification system provided by an embodiment of the present application is shown. The program integrity verification system can be deployed in an operating system, such as an Android system based on Linux / Unix. Figure 2 As shown, the program integrity verification system 200 includes a process behavior detection module 210 and a process startup detection module 220 .

[0070] When the program integrity verification system 200 is started, the process behavior detection module 210 can be used to detect whether a program file that meets the preset conditions has been modified by a process with superuser privileges. Exemplarily, the program file that meets the preset conditions can be a SUID program file or a program with Setuid capability, without limitation. When a program file that meets the preset conditions is modified by a process with superuser privileges, the process behavior detection module 210 can update and save the measurement value (such as a hash value) of the program file. Exemplarily, the process behavior detection module 210 can detect in real time whether a special program file has been modified by a process with superuser privileges, and update the saved hash value of the special program in real time. Exemplarily, the updated measurement value of the program file can be saved in a whitelist.

[0071] At the same time, the process startup detection module 220 detects whether the process is started, and locates the program file corresponding to the process when the process is started. For program files that meet the preset conditions, the process startup detection module 220 verifies its measurement value after detecting that the process is started, that is, matches its measurement value with the measurement value of the program file saved in the (white list), and verifies the integrity of the program file. When its measurement value matches the measurement value of the program file saved in the (white list), the program file passes the integrity check, and the current process is a trusted program. When its measurement value does not match the measurement value of the program file saved in the (white list), the program file integrity check fails, and the current process is an untrusted program. For trusted programs, the computer system can allow the corresponding process to continue to execute; for untrusted programs, the computer system can refuse to execute the corresponding process.

[0072] Optionally, when the program file integrity check fails, the program integrity check system 200 (such as the process startup detection module 220) can also send an alarm message to the endpoint detection and response (EDR) to indicate that the current process is an untrusted process. Exemplarily, the EDR can be deployed on the integrity check system 200, or on the operating system of the terminal device, without limitation. After obtaining the alarm information, the DER can display the alarm information to the user.

[0073] In some embodiments, see Figure 2 The above-mentioned program integrity verification system 200 can execute the following steps S1 to S5 to perform program integrity verification.

[0074] S1, loader integrity verification system.

[0075] Exemplarily, the program integrity verification system may be loaded when a user logs into a device, wherein the user is a normal user A, and the device is a Linux server or a Linux desktop distribution device, or an Android smartphone, without limitation.

[0076] S2: The process is detected to modify the special program file behavior.

[0077] Exemplarily, the process behavior detection module 210 can detect and discover the process's behavior of modifying a specific program file.

[0078] S3, if the current process is a superuser privilege process, the metric value of the modified program is calculated and the whitelist is updated.

[0079] Exemplarily, if the current process is a super user privilege process (such as a root process), the process behavior detection module 210 may calculate a hash value of the modified special program and update the hash value to a corresponding whitelist.

[0080] S4, it is detected that the process corresponding to the special program is starting.

[0081] Exemplarily, the process start detection module 220 may detect and find that a process corresponding to a special program is being created, that is, the process corresponding to the special program is being started.

[0082] S5, calculate the metric value corresponding to the special program and match it with the whitelist.

[0083] Exemplarily, if the metric value corresponding to the special program exists in the whitelist, that is, the metric value calculated in step S5 matches the metric value in the whitelist updated in step S3, then the integrity check of the special program passes, and the process in step S4 is trustworthy. If the metric value corresponding to the feature program does not exist in the whitelist, that is, the metric value calculated in step S5 does not match the metric value in the whitelist updated in step S3, then the integrity check of the special program fails, and the process in step S4 is not trustworthy.

[0084] As an example, the normal sudo process started by the normal user A mentioned above, the hash of the program corresponding to the current sudo process has been saved in the hash whitelist, and the current process is a normal process.

[0085] As another example, attacker B tampers with the sudo program content. Since attacker B is not a root user, the hash value of the tampered sudo program is not updated to the hash whitelist. Attacker B starts the process corresponding to the sudo program. At this time, the hash value of the current sudo program is not found in the hash whitelist. Therefore, the integrity check of the current sudo program fails and the current process is untrusted.

[0086] Optionally, the program integrity check system can also report the failure of this special program integrity check to the EDR, and the EDR will display the alarm information to the user. By linking with the EDR, when the process threat behavior occurs, it can provide real-time feedback to the EDR, providing users with visual threat behavior alarms.

[0087] Therefore, the embodiment of the present application detects the process file behavior, locates the program file corresponding to the process when the process starts, and determines the metric value of the program file when the process corresponds to the special program, and matches the metric value with the metric value of the program file in the whitelist. Since the metric value in the whitelist is generated after the program file is modified by the process with super user privileges and added to the whitelist, when the currently calculated metric value matches the metric value in the whitelist, it can be determined that the program file corresponding to the current process has passed the integrity check and the current process is a trusted process. Therefore, the embodiment of the present application can realize the combination of detecting process file behavior and whitelist mechanism, and perform security detection on the untrustworthy risk of program integrity caused by improper program permission setting or malicious tampering of the program by attackers, which is conducive to avoiding the operation of programs with security risks.

[0088] Figure 3 FIG. 1 is a schematic flow chart of a program integrity verification system deployment process according to an embodiment of the present application. Figure 3 As shown, the process includes steps 310 to 340.

[0089] 310, the detected user authority is administrator.

[0090] For example, when a user logs in to the terminal system as an administrator, the system can detect that the user's authority is an administrator. Administrator authority is super user authority. For example, the terminal system may include Figure 1 The system architecture is shown.

[0091] 320, configure the program integrity verification system.

[0092] For example, a program integrity check system may be configured in the terminal system, such as deploying a process behavior check module 210 for process behavior check and a process start check module 220 for process behavior creation check. Figure 2The description in will not be repeated here.

[0093] 330, perform process behavior detection.

[0094] Exemplarily, the administrator may start the process behavior detection module 210 so that the process behavior detection module 210 performs process behavior detection to detect the modification of the program file that meets the preset conditions by the process with the super user privilege.

[0095] In some embodiments, see Figure 3 , the loading process of the process behavior detection mechanism may include the following steps 331 to 333.

[0096] 331, traverse system files and search for special program files.

[0097] Exemplary, system files, i.e., operating system files, such as Figure 1 The files in the operating system 170 stored in the memory 170 are not limited in this application.

[0098] Exemplarily, a special program file is a program file that meets preset conditions, such as a SUID program file or a program with Setuid capability, or a program customized for business needs, which is not limited in this application.

[0099] 332, configure file modification detection for special program files.

[0100] Exemplarily, a fanotify-based process behavior detection can be configured for a special program file to detect whether a process has modified a special program file. Fanotify is a native process behavior detection framework for Linux. At this time, the process behavior detection mechanism can be referred to as a fanotify-based process behavior detection mechanism, which is not limited in this application. After setting file modification detection for a special program file, the process behavior detection module 210 can detect in real time whether a special program file has been modified by a process with superuser privileges.

[0101] 333, obtain a whitelist including a measurement value of each special program file.

[0102] Exemplarily, the measurement value of each special program file can be generated, and these measurement values ​​are uniformly stored in a whitelist file to obtain a whitelist. At this time, the whitelist is an initial whitelist, including the initial measurement value of each special program file.

[0103] Exemplarily, the measurement value of the program file may include a hash value of the program file. For example, the hash value of the program file may be obtained by using a tool or command, which is not limited in the present application.

[0104] Optionally, when it is detected in step 332 that a process with superuser privileges modifies a special program file, the metric value of the special program file in the whitelist may be updated. For example, the metric value of the special program file may be regenerated, and the initial metric value of the special program file in the whitelist may be replaced with the newly generated metric value.

[0105] 340, perform process creation behavior detection.

[0106] Exemplarily, the administrator may start the process start detection module 220 so that the process start detection module 220 may perform process creation behavior detection to detect the process creation behavior in the system.

[0107] In some embodiments, see Figure 3 , the loading process of the process creation behavior detection mechanism may include the following steps 341 to 344.

[0108] 341, load the system driver and complete the hook function for system call.

[0109] Exemplarily, a Linux system driver can be loaded, and a system call table replacement technique can be used to complete a hook function for an exec system call. By using the kernel hook technique, process creation behavior detection can be started in any kernel version.

[0110] Specifically, the target of the hook function is the exec system call, that is, when the user uses the exec system call to create a process, it can trigger the collection of the target program file information corresponding to the process to determine whether the target program file is a special program file. Among them, the exec system call is a system call that executes another program in the context of the current process.

[0111] Among them, the system call table is a table composed of function pointers pointing to kernel functions that implement various system calls. The table can be indexed based on the system call number to locate the function address and complete the system call. The mount driver can hook the commonly used processing functions by modifying the function address of the system call table, thereby achieving the purpose of filtering and detecting some core system actions. The hook function is part of the system message processing mechanism. By setting a "hook", the application can filter all messages and events at the system level and access messages that cannot be accessed under normal circumstances. The essence of a hook is a program used to process system messages, which is hooked into the system through system calls.

[0112] 342, locate the target program file corresponding to the current process when the system call is triggered.

[0113] Exemplarily, when a user uses an exec system call to create a new process, that is, when the exec system call for creating a new process is triggered, the corresponding program file currently being processed can be located, that is, the target program file can be located.

[0114] 343, determine whether the target program file is a special program file.

[0115] Exemplarily, after locating the target program file, the target program information can be collected, and then based on the target program information, it can be determined whether the target program file is a SUID program, or a program with a Setuid cap, or a program customized for business needs, etc., which is a program file that meets preset conditions. This application does not limit this.

[0116] 344, determine whether the measurement value of the target program file exists in the white list.

[0117] Exemplarily, when the target program file is a special program file, step 344 can be executed to further determine whether the measurement value of the target program file exists in the whitelist, that is, to perform a measurement value check on the target program file. Specifically, the process startup detection module 220 can generate a measurement value of the target file and determine whether the generated measurement value exists in the whitelist. When the measurement value exists in the whitelist, the target program file passes the integrity check, and the current process is a trusted process. When the measurement value does not exist in the whitelist, the target program file does not pass the integrity check, and the current process is an untrusted process.

[0118] Optionally, when the target program file is not a special program file, the operation of step 344 may not be performed. Optionally, when the target program file is not a program file that meets the preset conditions, the computer system may determine that the integrity of the target program file is credible, that is, the process may be executed.

[0119] Therefore, the embodiments of the present application can combine the detection of process file behavior with the whitelist mechanism, and perform security detection on the untrustworthy risks of program integrity caused by improper program permission settings or malicious tampering of the program by attackers, which is helpful to avoid the operation of programs with security risks.

[0120] Figure 4 FIG. 1 is a schematic flow chart of a program integrity verification process according to an embodiment of the present application. Figure 4 As shown, the process includes steps 401 to 411.

[0121] 401, detecting that the user logs into the terminal system.

[0122] For example, the user can log in to the terminal system as an administrator or other ordinary user, which is not limited in this application. Figure 3A terminal system in which a program integrity verification system is deployed.

[0123] 402, the special program file was detected to be modified.

[0124] For example, after logging into the terminal system, the user can choose to modify the content of a special program file. Accordingly, the program integrity check can detect that the special program file has been modified. Specifically, when the user modifies the content of a special program file, the modification behavior is detected. Figure 3 The process behavior detection module 210 deployed in the process detects and starts the whitelist update mechanism. At this time, the process behavior detection module 210 can perform the following steps 403 to 405.

[0125] 403, determine the process permissions for modifying the content of a special program file.

[0126] 404, determine whether the process permission is super user permission.

[0127] Specifically, when a super user (such as the root user) modifies the content of a special program file, the current process permissions of the special program file are modified to super user permissions; when an attacker modifies the content of a special program file, the attacker has ordinary user permissions, so the current near process permissions of the special program file are modified to non-super user permissions (i.e., ordinary user permissions).

[0128] 405, Update whitelist.

[0129] Specifically, when it is determined that the process permission is a superuser permission, step 405 is executed to update the metric value of the special program file in the whitelist. Exemplarily, the hash value of the modified special program file can be calculated, and the hash value of the special program file in the whitelist is replaced with the newly generated hash value.

[0130] When it is determined in step 404 that the process permission is not a super permission, such as a common user permission, the process ends.

[0131] Through the above steps 401 to 405, it is possible to update the measurement value of the special program file in the whitelist when a user with super user privileges modifies the content of the special program file; when a user with ordinary privileges (i.e., an attacker) modifies the content of the special program file, the measurement value of the special program file in the whitelist is not updated. In other words, the whitelist will only be updated when a process with super user privileges modifies the content of the special program file. In this way, the measurement value of the special program file created or modified by the user with super privileges is always saved in the whitelist. Optionally, since the whitelist includes the hash value of the program file modified by the super privilege, the hash value can also be called a legal hash value.

[0132] For example, in the above steps 402 to 405, the process behavior detection module 210 can detect the process behavior in real time, for example, by Figure 3 Steps 332 and 333 are used to update the whitelist when a root-authority process modifies a special program file.

[0133] 406, User process is created.

[0134] For example, after logging into the terminal system, the user can choose to execute instructions on the terminal to create a user process. Accordingly, the terminal device system creates a user process. When the user process is created, the process creation behavior is Figure 3 The process startup detection module 220 deployed in the process startup detection module 220 detects and starts the whitelist verification mechanism. At this time, the process startup detection module 220 can perform the following steps 407 to 411.

[0135] 407, locate the target program file corresponding to the user process.

[0136] 408, whether the target program file is a special program file.

[0137] Exemplarily, the program information of the target program file can be collected to determine whether the target program file is a special program file. As an example, when the target program file is a SUID file, or has a Setuid cap, it can be determined that the target program file is a special program file.

[0138] 409, determine whether the current measurement value of the target program file exists in the whitelist.

[0139] When the target program file is a special program file, step 409 is executed. Specifically, the current metric value of the target program file may be generated, and the metric value may be matched with the metric value in the whitelist to determine whether the target program file exists in the current whitelist.

[0140] For example, in the above steps 406 to 409, the process start detection module 220 can detect the process creation behavior in real time, for example, by Figure 3 Steps 342 to 344 are used to verify whether the metric value of the special program file exists in the whitelist when the process corresponding to the special program file is started.

[0141] 410, determine that the program integrity check passes.

[0142] In one possible case, when the target program file is not a special program file, it is determined that the target program integrity check passes. That is, when the target program file is a non-special program, the current process is a trusted process. For example, a normal user starts a normal process, and the normal process corresponds to a non-special program file, so the current process is a trusted process.

[0143] In another possible situation, when the target program file is a special program file and the current measurement value of the target program file exists in the whitelist, it is determined that the target program integrity check has passed. Since the measurement values ​​of special program files created or modified by users with super user privileges are always saved in the whitelist, it can be determined that the target program file is a special program file created or modified by users with super user privileges, that is, the integrity of the target program file is credible and the current operation is credible. In other words, when the special program file is executed, the measurement value of the special program file must exist in the whitelist.

[0144] For example, a normal user starts a process corresponding to a normal SUID program (an example of a special program), that is, the SUID program corresponding to the process is a special program file. When the hash value of the SUID program is calculated, the hash value exists in the whitelist, and the current process is a trusted process.

[0145] For another example, a normal user starts a process corresponding to a normal program with Setuid cap (an example of a special program), and the program with Setuid cap corresponding to the process is a special program file. When the hash value of the SUID program is calculated, the hash value exists in the whitelist, and the current process is a trusted process.

[0146] 411, Determined that the program integrity check failed.

[0147] When the target program file is a special program file and the current measurement value of the target program file does not exist in the whitelist, it is determined that the target program integrity check fails. Since the whitelist always stores the measurement values ​​of special program files created or modified by users with super user privileges, when the current measurement value of the target program file does not exist in the whitelist, it can be determined that the target program file has been modified by a user with ordinary privileges, that is, the integrity of the target program file is untrustworthy and is currently untrustworthy.

[0148] For example, an attacker starts a process corresponding to a special program (such as a SUID program or a program with Setuid cap) that has been injected with a backdoor, that is, the program corresponding to the process is a special program file. When the hash value of the SUID program is calculated, the hash value does not exist in the whitelist, and the current process is an untrusted process.

[0149] In some embodiments, when a process is untrustworthy, the program integrity verification system finds that an attacker is carrying out an attack on the system, and can send an alarm message to the EDR. The EDR can convey the alarm to the system administrator to refuse to execute the process.

[0150] Therefore, the embodiment of the present application updates the whitelist when only a process with super user privileges modifies the content of a special program file, and the measurement value of the special program file must exist in the whitelist when the special program file is executed. This can ensure that improper settings of special program file permissions during the operation and maintenance phase, or attackers attacking system vulnerabilities, are captured in a timely manner without generating false alarms.

[0151] Figure 5 A schematic flow chart of a program integrity verification method 500 provided in an embodiment of the present application is shown. The program integrity verification method 500 can be executed by any electronic device with data processing capability. For example, the electronic device can be implemented as a server, or as a terminal device. For example, the electronic device can include Figure 1 or Figure 2 The system architecture in .

[0152] like Figure 5 As shown, the program integrity verification method 500 includes steps 510 to 540 .

[0153] 510. When it is detected that the first process is started, locate the first program file corresponding to the first process.

[0154] Exemplarily, the process start detection module 220 can detect the process creation behavior, and determine that the process is started when the process creation behavior is detected. At this time, the process start detection module 220 can also locate the program file corresponding to the process, that is, the first program file. In other words, the first program file in operation is the process. Here, the first program file can be the target program file described above, and this application does not limit this.

[0155] In some embodiments, a hook function can be obtained by using a system call table; the system call table includes function pointers pointing to kernel functions that implement various system calls; and the hook function is run to collect the first program file corresponding to the first process when the system call creates the first process.

[0156] Specifically, after the program integrity check system is deployed, the process startup detection module 220 can be started to detect the process creation behavior. For example, when a user uses the exec system call to create a process, the exec system call can be detected based on the kernel hook mechanism. At this time, the system call is triggered to locate the target program file corresponding to the current process. Specifically, step 510 can be seen above. Figure 3 For a description of step 342, see Figure 4 The relevant description of step 407 is not repeated here.

[0157] 520. When the first program file meets a preset condition, generate a first metric value of the first program file.

[0158] Exemplarily, after locating the first program file, the process startup detection module 220 can collect the first program information, and then determine whether the first program file meets the preset conditions according to the first program information. The program that meets the preset conditions can be a special program or a special program file, which is not limited in this application.

[0159] Optionally, the preset conditions include that the program is a SUID program, or a program with a Setuid cap, or a program customized for business needs, etc., which are program files that meet the preset conditions. This application does not limit this.

[0160] Exemplarily, when the process startup detection module 220 determines that the first program file meets a preset condition, such as being a special program file, it can generate a first metric value of the first program file. Optionally, the first metric value can include a hash value of the first program file. Exemplarily, a tool or command can be used to generate a hash value of the first program file, which is not limited in this application.

[0161] Specifically, step 520 can refer to the above Figure 3 343 and 344, or see Figure 4 The relevant descriptions in steps 408 and 409 are not repeated here.

[0162] 530 , after the first program file is modified by a process with super user privileges, generate a second metric value of the first program file.

[0163] Specifically, the second metric value is generated after the first program is modified by a process with super user privileges, and is stored in a program integrity verification system, such as the process behavior detection module 210. Optionally, the second metric value may also be stored in other modules or units on the terminal device, without limitation. Exemplarily, super user privileges may include root privileges.

[0164] Exemplarily, after generating the first metric value of the first program file, the process startup detection module 220 can search the system for the second metric value corresponding to the first program file. As an implementation, the process startup detection module 220 can obtain a name list, which includes at least one metric value of a second program file that meets a preset condition. Exemplarily, since the name list stores the metric values ​​of program files created or modified by super users, the processes corresponding to these program files can only be executed if the metric values ​​of these program files exist in the name list, so the name list can be called a whitelist, which is not limited in this application. Exemplarily, Figure 3 and Figure 4 The whitelist in may be a specific example of the list.

[0165] In some embodiments, the above-mentioned list can be established after configuring the program integrity verification system and performing process behavior detection, and before generating the second metric value of the first program file. At this time, the list can be, for example, an initial list, such as an initial whitelist. In some embodiments, see Figure 6 The process behavior detection module 210 can establish the above-mentioned list through the following steps 531 and 532.

[0166] 531, traverse the system files to obtain at least one second program file that meets a preset condition; wherein the at least one second program file includes the above-mentioned first program file.

[0167] Exemplary, system files, i.e., operating system files, such as Figure 1 The files in the operating system 170 stored in the memory 170 are not limited in this application.

[0168] Exemplarily, the second program file is a special program file, such as a SUID program file or a program with Setuid capability, or a program customized for business needs, which is not limited in this application.

[0169] Specifically, step 531 can refer to Figure 3 The relevant description of step 331 is not repeated here.

[0170] 532. Obtain a name list, where the name list includes an initial measurement value of the at least one second program file.

[0171] Exemplarily, an initial measurement value of each second program file may be generated, and these initial measurement values ​​may be uniformly stored in a list to obtain an initial list.

[0172] Specifically, step 532 can refer to Figure 3 The relevant description of step 333 is not repeated here.

[0173] In some embodiments, see Figure 6 When the process behavior detection module 210 detects that a process with superuser privileges modifies a special program file (such as the first program file), the metric value of the special program file in the list can be updated. Specifically, taking the first program file as an example, the whitelist can be updated through the following steps 533 and 534.

[0174] 533. When the first program file is modified by a process with super user privileges, generate a second metric value according to the modified first program file.

[0175] For example, after setting file modification detection for a special program file, the process behavior detection module 210 can detect in real time whether the special program file is modified by a process with super user privileges. Figure 3 The relevant description in step 332 is not repeated here. When it is detected that the first program file is modified by a process with super user privileges, the process behavior detection module 210 can generate a second metric value of the modified first program file.

[0176] 534, replace the initial metric value of the first program file in the list with the second metric value.

[0177] Optionally, for the updated list, when the first program file is modified again by a process with superuser privileges, a new metric value may be generated and the metric value of the first program file in the list may be replaced with the new metric value to update the list again.

[0178] That is to say, whether it is the initial list or the updated list, as long as the first program file is modified by a process with super user privileges, a new measurement value is generated for the modified first program file, and the measurement value of the first program file in the list is replaced by the new measurement value to achieve real-time update of the list.

[0179] In some embodiments, when it is detected that the first program file is modified by a process with ordinary user privileges, the metric value (such as the initial metric value or the second metric value) of the first program file in the list is kept unchanged. Figure 4 The relevant descriptions in step 404 and step 405 are not repeated here.

[0180] Therefore, the whitelist is updated only when the content of the special program file is modified by a process with super-user privileges, so that the measurement values ​​of the special program files created or modified by users with super-user privileges are always stored in the whitelist.

[0181] 540. When the first metric value matches the second metric value, determine that the first program file passes the integrity check and the first process is a trusted process.

[0182] Exemplarily, when the measurement value of the first program file exists in the list, the program integrity check of the first program file passes and the current first process (ie, the process when running the first program file) is a trusted process.

[0183] 550. When the first metric value and the second metric value do not match, determine that the integrity check of the first program file fails and the first process is an untrusted program.

[0184] Exemplarily, when the measurement value of the first program file does not exist in the whitelist, the program integrity check of the first program file fails and the current first process (i.e., the process when running the first program file) is an untrusted program, that is, the special program corresponding to the current first process has a security risk. At this time, the current process should not be continued.

[0185] Specifically, the process of determining whether the first metric value and the second metric value match can refer to Figure 3 Step 344, or Figure 4 The relevant descriptions of steps 409 to 411 are not repeated here.

[0186] In some embodiments, when executing step 550, an alarm message may also be sent to the EDR, where the alarm message is used to indicate that the first program file is modified by a process with ordinary user privileges. When the EDR receives the alarm message, it displays the alarm message to the user. By linking with the EDR, when a process threat behavior occurs, real-time feedback can be provided to the EDR, providing the user with a visual threat behavior alarm.

[0187] In some embodiments, after locating a first program file corresponding to the first process, when the first program file does not meet a preset condition, the first process is determined to be a trusted process.

[0188] That is, when the target program file is not a special program file, the target program integrity is determined to be credible. In other words, when the target program file is a non-special program, the current process is credible. For example, a normal user starts a normal process, which corresponds to a non-special program file, so the current process is a credible process.

[0189] Therefore, the embodiment of the present application detects the behavior of the process file, locates the program file corresponding to the process when the process starts, and determines the first metric value of the corresponding program file when the program file corresponding to the process meets the preset conditions, and matches the first metric value with the second metric value of the program file. The second metric value is generated after the program file is modified by the process with super user privileges. Therefore, when the first metric value matches the second metric value, it can be determined that the program file corresponding to the current process passes the integrity check and the current process is a trusted process. When the first metric value does not match the second metric value, it can be determined that the program file corresponding to the current process does not pass the integrity check and the current process is an untrusted process. Therefore, the embodiment of the present application can realize security detection of the untrustworthy risk of program integrity caused by improper program permission settings or malicious tampering of the program by an attacker, which is conducive to avoiding the operation of programs with security risks.

[0190] Specifically, the embodiment of the present application can update and save the measurement value corresponding to the special program when the process with super-user privileges modifies the special program; when the special process associated with the special program is started, it is determined whether the measurement value of the special program matches the measurement value saved for the special program. In this way, when the special program is modified by the process with super-user privileges, its measurement value is updated and saved. When the special program is started, the measurement value of the current special program matches the measurement value saved, the program integrity check passes, and the special process is a trusted process. When the special program is tampered with by a user with ordinary privileges, the measurement value of the special program will not be updated. When the special program is started, the measurement value of the current special program does not match the measurement value saved for the special program. The program integrity check fails, and the special process is an untrusted program. At this time, the alarm will not generate a false alarm.

[0191] In addition, the embodiment of the present application establishes a whitelist for special programs that meet preset conditions, which can target special programs customized due to needs rather than just specific programs, which is conducive to better covering business scenarios and meeting the diverse characteristics of business needs.

[0192] Furthermore, the embodiment of the present application implements program integrity verification by determining whether the measurement value of a special program matches the measurement value generated after the program file is modified by a process with superuser privileges when a special process associated with the special program is started, thereby avoiding the problem of bypassing the whitelist by exploiting the limitations of the instruction whitelist.

[0193] The specific implementation modes of the present application are described in detail above in conjunction with the accompanying drawings. However, the present application is not limited to the specific details in the above implementation modes. Within the technical concept of the present application, the technical solution of the present application can be subjected to a variety of simple modifications, and these simple modifications all belong to the protection scope of the present application. For example, the various specific technical features described in the above specific implementation modes can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, the present application will not further explain various possible combinations. For another example, the various different implementation modes of the present application can also be arbitrarily combined, and as long as they do not violate the ideas of the present application, they should also be regarded as the contents disclosed in the present application.

[0194] It should also be understood that in the various method embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. It should be understood that these sequence numbers can be interchanged where appropriate, so that the embodiments of the present application described can be implemented in an order other than those shown or described.

[0195] The above describes the method embodiment of the present application in detail. Figures 7 and 8, describe in detail the device embodiments of the present application.

[0196] Figure 7 A schematic diagram of the structure of a program integrity verification device 10 provided in an embodiment of the present application is shown in FIG. Figure 7 As shown, the program integrity verification device 10 may include: a detection unit 11, a generation unit 12 and a determination unit 13.

[0197] A first detection unit 11 is used to locate a first program file corresponding to a process when detecting that the process is started;

[0198] A generating unit 12, configured to generate a first metric value of the first program file when the first program file meets a preset condition;

[0199] The generating unit 12 is further configured to generate a second metric value of the first program file after the first program file is modified by a process with super user privileges;

[0200] A determination unit 13, configured to determine that the first program file passes the integrity check and the process is a trusted process when the first metric value matches the second metric value;

[0201] The determining unit 13 is further configured to determine that the integrity check of the first program file fails and the first process is an untrusted process when the first metric value does not match the second metric value.

[0202] In some embodiments, the apparatus 10 further comprises an establishing unit, configured to:

[0203] Traversing system files to obtain at least one second program file that meets the preset condition; wherein the at least one second program file includes the first program file;

[0204] A name list is created, the name list including the initial metric value of the at least one second program file.

[0205] After the first program file is modified by a process with superuser privileges, generating the second metric value according to the modified first program file;

[0206] The initial metric value of the first program file in the list is replaced by the second metric value.

[0207] In some embodiments, the apparatus 10 further comprises a processing unit configured to:

[0208] After the first program file is modified by a process with ordinary user authority, the second metric value in the list is kept unchanged.

[0209] In some embodiments, the device 10 also includes a sending unit for sending an alarm message to the endpoint detection and response EDR after determining that the integrity check of the first program file fails and the first process is an untrusted program, wherein the alarm message is used to indicate that the first program file has been modified by a process with ordinary user permissions.

[0210] In some embodiments, the determining unit 13 is further configured to: when the first program file does not meet the preset condition, determine that the first program file passes the integrity check and the first process is a trusted process.

[0211] In some embodiments, the first detection unit 11 is specifically used for:

[0212] Obtaining the hook function using a system call table; the system call table includes function pointers pointing to kernel functions that implement various system calls;

[0213] The hook function is run to collect the first program file corresponding to the first process when the system calls to create the first process.

[0214] In some embodiments, the preset condition includes that the program is a SUID program, or a program with the ability to set a user identification, or a program customized for business needs.

[0215] In some embodiments, the first metric value includes a hash value of the first program file, and the second metric value includes a hash value of the first program file.

[0216] It should be understood that the device embodiment and the method embodiment may correspond to each other, and similar descriptions may refer to the method embodiment. To avoid repetition, they will not be described here. Specifically, Figure 7 The program integrity checking device 10 shown can execute Figure 5 The corresponding method embodiment, and the operation and / or function of each module in the program integrity verification device 10 are respectively to achieve Figure 5 For the sake of brevity, the corresponding processes in the corresponding method embodiments are not repeated here.

[0217] The video processing device of the embodiment of the present application is described above from the perspective of the functional module in conjunction with the accompanying drawings. It should be understood that the functional module can be implemented in hardware form, can be implemented by instructions in software form, and can also be implemented by a combination of hardware and software modules. Specifically, the steps of the method embodiment in the embodiment of the present application can be completed by the hardware integrated logic circuit and / or software form instructions in the processor, and the steps of the method disclosed in the embodiment of the present application can be directly embodied as a hardware encoding processor to execute, or a combination of hardware and software modules in the encoding processor to execute. Optionally, the software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, etc. The storage medium is located in a memory, and the processor reads the information in the memory, and completes the steps in the above method embodiment in conjunction with its hardware.

[0218] Figure 8 3 is a schematic block diagram of an electronic device 30 provided in an embodiment of the present application. The electronic device may be the program integrity verification device mentioned above.

[0219] like Figure 8 As shown, the electronic device 30 may include:

[0220] The memory 31 and the processor 32, the memory 31 is used to store the computer program and transmit the program code to the processor 32. In other words, the processor 32 can call and run the computer program from the memory 31 to implement the program integrity verification method in the embodiment of the present application. For example, the processor 32 can be used to execute the above-mentioned program integrity verification method according to the instructions in the computer program.

[0221] The program integrity verification method includes:

[0222] When detecting that a first process is started, locating a first program file corresponding to the first process;

[0223] When the first program file meets a preset condition, generating a first metric value of the first program file;

[0224] After the first program file is modified by a process with superuser privileges, generating a second metric value of the first program file;

[0225] When the first metric value matches the second metric value, determining that the first program file passes the integrity check and the first process is a trusted process;

[0226] When the first metric value and the second metric value do not match, it is determined that the integrity check of the first program file fails and the first process is an untrusted process.

[0227] In some embodiments of the present application, the processor 32 may include but is not limited to:

[0228] General-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc.

[0229] In some embodiments of the present application, the memory 31 includes but is not limited to:

[0230] Volatile memory and / or non-volatile memory. Among them, the non-volatile memory can be read-only memory (ROM), programmable ROM (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) or flash memory. The volatile memory can be 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 (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus random access memory (DR RAM).

[0231] In some embodiments of the present application, the computer program may be divided into one or more modules, which are stored in the memory 31 and executed by the processor 32 to complete the method provided by the present application. The one or more modules may be a series of computer program instruction segments capable of completing specific functions, and the instruction segments are used to describe the execution process of the computer program in the electronic device.

[0232] like Figure 8 As shown, the electronic device 30 may further include:

[0233] The transceiver 33 may be connected to the processor 32 or the memory 31 .

[0234] The processor 32 may control the transceiver 33 to communicate with other devices, specifically, to send information or data to other devices, or to receive information or data sent by other devices. The transceiver 33 may include a transmitter and a receiver. The transceiver 33 may further include an antenna, and the number of antennas may be one or more.

[0235] It should be understood that the various components in the electronic device are connected via a bus system, wherein the bus system includes not only a data bus but also a power bus, a control bus and a status signal bus.

[0236] The present application also provides a computer storage medium on which a computer program is stored, and when the computer program is executed by a computer, the computer can perform the method of the above method embodiment. In other words, the present application embodiment also provides a computer program product containing instructions, and when the instructions are executed by a computer, the computer can perform the method of the above method embodiment.

[0237] When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integration. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a digital video disc (digital video disc, DVD)), or a semiconductor medium (e.g., a solid state drive (solid state disk, SSD)), etc.

[0238] It is understandable that in the specific implementation of the present application, when the above embodiments of the present application are applied to specific products or technologies and involve relevant data such as user information, user permission or consent is required, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards.

[0239] Those of ordinary skill in the art will appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel 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 this application.

[0240] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the module is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0241] The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. For example, each functional module in each embodiment of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0242] The above contents are only specific implementation methods of the embodiments of the present application, but the protection scope of the embodiments of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or replacements within the technical scope disclosed in the embodiments of the present application, which should be included in the protection scope of the embodiments of the present application. Therefore, the protection scope of the embodiments of the present application should be based on the protection scope of the claims.

Claims

1. A program integrity verification method, characterized in that: include: When detecting that a first process is started, locating a first program file corresponding to the first process; When the first program file meets a preset condition, generating a first metric value of the first program file; After the first program file is modified by a process with superuser privileges, generating a second metric value of the first program file; When the first metric value matches the second metric value, determining that the first program file passes the integrity check and the first process is a trusted process; When the first metric value and the second metric value do not match, it is determined that the integrity check of the first program file fails and the first process is an untrusted process.

2. The method according to claim 1, characterized in that After the first program file is modified by a process with superuser privileges, before generating a second metric value of the first program file, the method further includes: Traversing system files to obtain at least one second program file that meets the preset condition; wherein the at least one second program file includes the first program file; A name list is created, the name list including the initial metric value of the at least one second program file.

3. The method according to claim 2, characterized in that The step of generating a second metric value of the first program file after the first program file is modified by a process with super user privileges includes: After the first program file is modified by a process with superuser privileges, generating the second metric value according to the modified first program file; The initial metric value of the first program file in the list is replaced by the second metric value.

4. The method according to claim 3, characterized in that After the first program file is modified by a process with super user privileges and a second metric value of the first program file is generated, the method further includes: After the first program file is modified by a process with ordinary user authority, the second metric value in the list is kept unchanged.

5. The method according to claim 1, characterized in that After determining that the integrity check of the first program file fails and the first process is an untrusted program, the method further includes: Send an alarm message to an endpoint detection and response (EDR), where the alarm message is used to indicate that the first program file is modified by a process with ordinary user privileges.

6. The method according to claim 1, characterized in that After locating the first program file corresponding to the first process, the method further includes: When the first program file does not meet the preset condition, it is determined that the first program file passes the integrity check and the first process is a trusted process.

7. The method according to claim 1, characterized in that The step of locating a first program file corresponding to the first process when detecting that the first process is started includes: Obtaining the hook function using a system call table; the system call table includes function pointers pointing to kernel functions that implement various system calls; The hook function is run to collect the first program file corresponding to the first process when the system calls to create the first process.

8. The method according to any one of claims 1 to 7, characterized in that: The preset conditions include that the program is a SUID program, or a program with the ability to set a user identification, or a program customized according to business needs.

9. The method according to any one of claims 1 to 7, characterized in that: The first metric value includes a hash value of the first program file, and the second metric value includes a hash value of the first program file.

10. A program integrity verification device, characterized in that: include: A first detection unit, configured to locate a first program file corresponding to a first process when detecting that the first process is started; a generating unit, configured to generate a first metric value of the first program file when the first program file meets a preset condition; The generating unit is further configured to generate a second metric value of the first program file after the first program file is modified by a process with super user privileges; a determining unit, configured to determine, when the first metric value matches the second metric value, that the first program file passes the integrity check and the first process is a trusted process; The determining unit is further configured to determine that the integrity check of the first program file fails and the first process is an untrusted program when the first metric value and the second metric value do not match.

11. An electronic device, characterized in that: include: A processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to execute the method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein the computer program enables a computer to execute the method according to any one of claims 1 to 9.

13. A computer program product, characterized in that The method comprises a computer program code, and when the computer program code is executed by an electronic device, the electronic device executes the method according to any one of claims 1 to 9.

Images