Security software unloading method and device, equipment and storage medium

Abstract

The invention discloses a security software unloading method, device and equipment and a storage medium, and relates to the technical field of computer security, the method comprises the following steps: before preset security software is unloaded, obtaining a calling function of the preset security software, the calling function representing a function called after the security check of the preset security software is passed; modifying a target jump address of a jump function in the resident memory into a call function, wherein the jump function in the resident memory is used for specifying a target jump address corresponding to each system call address in a system call address set; and unloading the preset security software. Before the security software is uninstalled, the target jump address of the jump function in the resident memory applied in advance is modified into the calling function of the preset security software, so that invalid memory is prevented from being generated, after the security software is uninstalled, the system can access the system function through the target jump address in the system calling address set, and the safety of the system is improved. And the normal operation of the system is ensured.

Description

Technical Field

[0001] The present application relates to the field of computer security technology, and in particular to a method, apparatus, device, and storage medium for secure software uninstallation. Background Art

[0002] To protect operating systems from virus attacks, security software often needs to hook application function calls, obtain their input parameters and return results, and monitor their behavior. A common approach involves hooking the system call table (e.g., hooking the Windows System Services Descriptor Table or the Linux sys_call_table), hijacking the application's behavior. When an application calls an operating system system call function, it will first jump to a function pre-placed by the security software. This allows the security software to obtain the parameters used by the application to perform a check. If no illegal activity is detected, the application is then allowed to call the underlying system function to complete the call. Upon return, the security software can also examine the return result of the system call for further security checks. This hooking technology facilitates security software's monitoring of application behavior. However, if a computer host has at least two security software programs installed, both of which utilize this hooking technology, uninstalling the security software could cause other programs to access invalid memory, leading to system crashes and service interruptions. Summary of the Invention

[0003] The main purpose of this application is to provide a method, device, equipment and storage medium for uninstalling security software, aiming to solve the technical problem that security software using hook technology generates invalid memory after uninstallation, causing system crashes.

[0004] To achieve the above objectives, the present application proposes a method for safely uninstalling software, the method comprising: When an uninstall instruction of the preset security software is detected, obtaining a calling function of the preset security software, wherein the calling function represents a function called to access a system function after the preset security software passes a security check; Modifying the target jump address of the jump function in the resident memory to the calling function, wherein the resident memory records the jump function and the target jump address, and the jump function is used to specify the target jump address corresponding to each system call address in the system call address set; Uninstall the preset security software.

[0005] In one embodiment, before the step of obtaining the calling function of the preset security software when the uninstall instruction of the preset security software is detected, the method further includes: Set the jump function corresponding to each system call address in the system call address set in the resident memory; Setting the target jump address in the jump function to the address of the preset security software; The system call address in the system call address set is modified to the address of the jump function.

[0006] In one embodiment, the step of setting a jump function corresponding to each system call address in the system call address set in the resident memory includes: Determine whether there is a memory address of the resident memory in the temporary storage module, where the information stored in the temporary storage module is discarded after the operating system is restarted; If the memory address exists, performing a consistency check on the memory address; If the consistency check passes, the step of setting the jump function corresponding to each system call address in the system call address set in the resident memory is performed.

[0007] In one embodiment, after the step of performing a consistency check on the memory address if the memory address exists, the method further includes: If the memory address does not exist or the consistency check fails, apply for resident memory; Saving the memory address of the resident memory to the temporary storage module; Execute the step of setting the jump function corresponding to each system call address in the system call address set in the resident memory.

[0008] In one embodiment, the temporary storage module includes a memory file system or a registry; The step of saving the memory address of the resident memory to the temporary storage module includes: When the operating system type is a Linux operating system, the memory address of the resident memory is saved in a memory file system; In the case where the operating system type is a Windows operating system, a registry is created, and the memory address of the resident memory is saved in the registry.

[0009] In one embodiment, if the memory address exists, the step of performing a consistency check on the memory address includes: Obtaining the application identification information and identification location in the resident memory; Check whether the identification information of the identification part in the memory address is consistent with the application identification information.

[0010] In one embodiment, before the step of obtaining the calling function of the preset security software when the uninstall instruction of the preset security software is detected, the method further includes: In a case where the calling function of the preset security software is a function of other security software, determining the starting address and ending address of the system kernel module according to the address of the calling function, and the other security software is software installed before the preset security software; Determine the module name corresponding to the address of the calling function according to the starting address and the ending address; Obtain the driver object corresponding to the address of the calling function according to the module name; Increment the reference count of the driver object.

[0011] In addition, to achieve the above-mentioned purpose, the present application also proposes a secure software uninstallation device, which includes: an information acquisition module, configured to, upon detecting an uninstall instruction for the preset security software, acquire a calling function of the preset security software, wherein the calling function represents a function called to access a system function after the preset security software passes a security check; an address modification module, configured to modify a target jump address of a jump function in a resident memory to the calling function, wherein the resident memory records a jump function and a target jump address, and the jump function is used to specify a target jump address corresponding to each system call address in a system call address set; The software uninstallation module is used to uninstall the preset security software.

[0012] In addition, to achieve the above-mentioned purpose, the present application also proposes a secure software uninstallation device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program is configured to implement the steps of the secure software uninstallation method as described above.

[0013] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium. A computer program is stored on the storage medium, and when the computer program is executed by the processor, the steps of the security software uninstallation method described above are implemented.

[0014] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the steps of the security software uninstallation method as described above.

[0015] The present application provides a method for uninstalling security software. When detecting an uninstall instruction for the preset security software, the method obtains a calling function of the preset security software, where the calling function represents a function of the first installed security software or a function called to access a system function after the security check of the preset security software passes; modifies the target jump address of the jump function in the resident memory to the calling function, where the resident memory records the jump function and the target jump address, and the jump function is used to specify the target jump address corresponding to each system call address in the system call address set; and uninstalls the preset security software. The present application avoids generating invalid memory by modifying the target jump address of the jump function in the pre-applied resident memory to the calling function of the preset security software when uninstalling the security software. After the present security software is uninstalled, the system can access the system function through the target jump address in the system call address set, thereby ensuring the normal operation of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0018] Figure 1 A flowchart illustrating the first embodiment of the method for uninstalling secure software in this application; Figure 2 This is a diagram of the calling relationship of the system call table that has not been hooked by security software; Figure 3 This is a diagram of the calling relationship after the first security software hooks the system call table; Figure 4 This is a diagram of the calling relationship after the second security software hooks the system call table; Figure 5 A diagram showing the calling relationship of the preset security software after installation; Figure 6 This is a diagram of the calling relationship after the preset security software is uninstalled; Figure 7 A flowchart illustrating the second embodiment of the method for uninstalling secure software in this application is provided; Figure 8 A flowchart of the third embodiment of the method for uninstalling secure software provided in this application; Figure 9This is a schematic diagram of the module structure of the secure software uninstallation device according to an embodiment of the present application; Figure 10 This is a schematic diagram of the device structure of the hardware operating environment involved in the security software uninstallation method in the embodiment of the present application.

[0019] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0020] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0021] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of the embodiment of the present application is: when an uninstall instruction of the preset security software is detected, the calling function of the preset security software is obtained, and the calling function represents the function called to access the system function after the security check of the preset security software is passed; the target jump address of the jump function in the resident memory is modified to the calling function, and the jump function and the target jump address are recorded in the resident memory, and the jump function is used to specify the target jump address corresponding to each system call address in the system call address set; and the preset security software is uninstalled.

[0023] To protect operating systems from virus attacks, security software often needs to hook application function calls, obtain their input parameters and return results, and monitor their behavior. A common approach is to hook the system call table, hijacking the application's behavior. When an application calls an operating system system call function, it will first jump to a function pre-placed by the security software. This allows the security software to obtain the parameter information used by the application to perform a check. If no illegal activity is detected, the application is then allowed to call the underlying system function to complete the call. Upon return, the security software can also examine the return result of the system call for further security checks. This hooking technology facilitates security software's monitoring of application behavior. However, if a computer host has at least two security software programs installed, both of which utilize hooking technology, uninstalling the security software could cause other programs to access invalid memory, causing a system crash and disrupting business operations.

[0024] The present application provides a solution. When detecting an uninstall instruction for the preset security software, the calling function of the preset security software is obtained. The calling function represents a function of the first installed security software or a function called to access a system function after the security check of the preset security software passes. The target jump address of the jump function in the resident memory is modified to the calling function. The resident memory records the jump function and the target jump address. The jump function is used to specify the target jump address corresponding to each system call address in the system call address set. The preset security software is uninstalled. The present application avoids the generation of invalid memory by modifying the target jump address of the jump function in the pre-applied resident memory to the calling function of the preset security software when uninstalling the security software. After the present security software is uninstalled, the system can access the system function through the target jump address in the system call address set, thereby ensuring the normal operation of the system.

[0025] It should be noted that the execution entity of the method of this embodiment can be a computing service device with security software uninstallation, network communication, and program execution functions, such as a tablet computer or personal computer, which has an operating system installed. It can also be a security software uninstallation device with the same or similar functions. This embodiment and the following embodiments will be described using a security software uninstallation device as an example.

[0026] Based on this, the embodiment of the present application provides a method for uninstalling secure software. Figure 1 , Figure 1 This is a flowchart of the first embodiment of the security software uninstallation method of this application.

[0027] In this embodiment, the security software uninstallation method includes steps S10 to S30: Step S10, when an uninstall instruction of the preset security software is detected, obtaining the calling function of the preset security software, the calling function represents the function of the first security software called after the security check of the preset security software passes or the function called by accessing the system function, and the first security software is installed before the preset security software.

[0028] It's important to note that hooking, also known as hooking, is a computer programming term that refers to various techniques used to modify or extend the behavior of an operating system, application, or other software component by intercepting function calls, message passing, and event transmission between software modules. The code that handles intercepted function calls, events, and messages is called a hook. The system call table (SCT) is a table consisting of function pointers to kernel functions that implement various system calls. This table can be indexed based on the system call number to locate the function address and complete the system call. In Windows, this is called the System Services Descriptor Table, and in Linux, it's called the sys_call_table.

[0029] It can be explained that the calling relationship of the system call table that has not been hooked by security software can be referred to Figure 2 As shown in the figure, the system call table is an array that stores the entry points for each system call function. When an application invokes a system call, the parameter carries the system call number, which is equivalent to the index of the array in the system call table. The operating system retrieves the function address of the corresponding system call from the system call table based on the system call number and jumps to that address to execute the system function. For example, if an application calls the fopen system function, the parameter carries the system call number 5 and parameter information related to file operations. The operating system determines the corresponding system function address (perhaps sys_open) in the system call table based on the system call number, jumps to sys_open to execute the system function, and finally returns the execution result.

[0030] It is worth mentioning that when the first security software is installed on the system, the original system function address sys_open in the system call table is saved first, and then the system call table is hooked. The sys_open in the system call table is replaced with hk1_open. The calling relationship after the first security software hooks the system call table can be referred to Figure 3 As shown. When the application calls the fopen function, it first jumps to hk1_open to execute the security check code of the first security software. The first security software can perform a security check on the call parameters. After the check is completed, it jumps to the original system call address, that is, sys_open, to execute the real system call. When the first security software is uninstalled, it first replaces the previously saved system call address back to the system call table, that is, replaces hk1_open in the system call table with sys_open, and restores it to Figure 2 The calling relationship.

[0031] It is understandable that when the system installs the second security software to execute the hook, it will also save the original address in the system call table first. Since the system call table has been hooked by the first security software, the saved address is hk1_open. After the hook, the address saved in the system call table is hk2_open. The calling relationship after the second security software hooks the system call table can be referred to Figure 4 As shown. In this case, if the second security software is uninstalled first and the first security software is uninstalled later, and the system call table is restored in sequence, there will be no compatibility issues. If the first security software is uninstalled first and the system call table is restored, the first security software's program code will then be removed from memory. Since the second security software is unaware that the first security software's code has been removed, it may continue to call the hk1_open function, accessing invalid memory, causing a system crash and business interruption. At the same time, the first security software is unaware that the second security software has saved the first security software's code address (that is, the program that hooks first does not know that its code has been referenced by the program that hooks later). In this case, the uninstall operation cannot be performed.

[0032] It should be noted that the preset security software of this solution can be installed before the first security software. For a more comprehensive explanation, here we take the installation between the two as an example, that is, the preset security software is installed later than the first security software and before the second security software. This application ensures that when the preset security software is uninstalled, the subsequent hooked program will not access invalid memory by means of resident memory; by locking the memory module, it ensures that the program code that is hooked before the preset security software cannot be removed from the memory in advance, avoiding access to invalid memory. The calling relationship after the preset security software is installed in the middle can be referred to Figure 5 shown.

[0033] It's worth noting that upon detecting an uninstall instruction for the pre-installed security software, there's no need to release resident memory; instead, only the pre-installed security software's calling function needs to be retrieved. If the first security software is installed before the pre-installed security software, the calling function for the pre-installed security software is hk1_open. If the pre-installed security software is installed first (i.e., the first security software doesn't exist), the calling function for the pre-installed security software is sys_open, the system function implementation function called when accessing system functions after the pre-installed security software passes security checks.

[0034] Step S20, modifying the target jump address of the jump function in the resident memory to the calling function, wherein the resident memory records the jump function and the target jump address, and the jump function is used to specify the target jump address corresponding to each system call address in the system call address set.

[0035] It should be noted that after obtaining the call function of the preset security software, assuming that the call function is hk1_open, the target jump address of the jump function jmp_open in the resident memory is modified to hk1_open. In this way, the program of this solution is uninstalled before the second security software, and invalid memory access will not occur. The system call address set can be a system call table stored in the form of an array, or a set of function pointers of kernel functions used to represent various system calls stored in other forms such as key-value pairs.

[0036] Step S30: uninstall the preset security software.

[0037] It is understandable that after the target jump address of the jump function in the resident memory is modified to call the function hk1_open, the preset security software can be uninstalled. The calling relationship after uninstallation is as follows: Figure 6 When the application calls the fopen function, the operating system will first jump to hk2_open according to the system call table. After the second security software completes the security check, it calls the underlying function, that is, jumps to jmp_open. Since the target address in jmp_open has been modified, it jumps to hk1_open instead of the previous xxx_open. In this way, the system will not crash due to accessing invalid memory.

[0038] This embodiment provides a method for uninstalling security software. Upon detecting an uninstall instruction for the preset security software, the method obtains a call function of the preset security software, where the call function represents a function of the first installed security software or a function called to access a system function after the preset security software passes a security check. The method also modifies the target jump address of a jump function in the resident memory to the call function, where the resident memory records the jump function and the target jump address, and the jump function is used to specify the target jump address corresponding to each system call address in a system call address set. The method then uninstalls the preset security software. This embodiment avoids generating invalid memory by modifying the target jump address of the pre-applied jump function in the resident memory to the call function of the preset security software when uninstalling the security software. After the security software is uninstalled, the system can access system functions through the target jump address in the system call address set, thereby ensuring normal system operation.

[0039] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 7 Before step S10, the security software uninstallation method further includes steps S01 to S03: Step S01: setting a jump function corresponding to each system call address in a system call address set in a resident memory.

[0040] It should be noted that in this embodiment, a permanent memory is first applied for to store temporary jump code (this memory will not be released when the security software is subsequently uninstalled). By not releasing the permanent memory, it is ensured that when the security software is uninstalled, the subsequent hooked program will not access invalid memory, thus avoiding system crashes. After the preset security software is installed, the jump function corresponding to each system call address in the system call address set can be set in the permanent memory (or only a portion of the system calls can be set). For example, for the system call addresses such as sys_open, sys_read, sys_write, and sys_close in the system call address set, the corresponding jump functions such as jmp_open, jmp_read, jmp_write, and jmp_close are set respectively.

[0041] Step S02: setting the target jump address in the jump function to the address of the preset security software.

[0042] It is understandable that the target jump address in the jump function is set to the address of the preset security software. For example, if the preset security software is installed after the first security software, the target jump address in the jump functions such as jmp_open, jmp_read, jmp_write, and jmp_close is set to the function addresses xxx_open, xxx_read, xxx_write, and xxx_close of the preset security software, respectively. In addition, the function address called in the xxx_open function of the preset security software is set to the function address in the system call table before the preset security software is installed (if the first security software has a hook, then the first security software's function address is hk1_open; otherwise, the system's original function address is sys_open).

[0043] Step S03: Modify the system call address in the system call address set to the address of the jump function.

[0044] It should be understood that the system call addresses in the system call address set are also modified accordingly. That is, the system call addresses in the system call table are modified to the addresses of jump functions in resident memory. For example, the function address hk1_open corresponding to the system call "open" in the system call table is replaced with jmp_open (the system call table originally had sys_open, and the first security software replaced it with hk1_open). Assuming that the second security software is installed after the pre-installed security software, the addresses of the system calls "open", "read", "write", and "close" in the system call table are modified to hk2_open, hk2_read, hk2_write, and hk2_close, respectively.

[0045] Here we take the application calling the open function as an example to illustrate. For details, please refer to Figure 5 When the application calls the fopen function, the operating system first jumps to the hk2_open function of the second security software according to the system call table. After completing the security check, it jumps to jmp_open, which calls the xxx_open function of the default security software for a security check. After the default security software completes the security check, it calls the hk1_open function of the first security software for another security check. After performing the security check, the first security software calls the underlying function sys_open that implements the system function.

[0046] In a feasible implementation, step S01 may include steps S011 to S013: Step S011, determining whether there is a memory address of a resident memory in the temporary storage module, wherein the information stored in the temporary storage module is discarded after the operating system is restarted.

[0047] It's worth noting that applying for resident memory ensures that after the pre-installed security software is uninstalled, the post-hook module won't access invalid memory. However, considering that applying for resident memory each time the pre-installed security software is installed, repeated memory requests during installation and uninstallation can lead to system memory leaks. To avoid memory leaks, this embodiment reuses the previously applied resident memory.

[0048] Specifically, it can be determined whether there is a memory address of the resident memory in the temporary storage module. The information stored in the temporary storage module is discarded after the operating system is restarted, thereby confirming whether the resident memory has been applied for and avoiding repeated memory application.

[0049] Step S012: If the memory address exists, perform a consistency check on the memory address.

[0050] It is understandable that if the memory address exists, the memory address can be read from the volatile storage, and then the memory address can be checked for consistency. If the check passes, the memory can be reused. If the check fails, the resident memory can be re-applied.

[0051] In a feasible implementation, step S012 may further include steps S0121 and S0122: Step S0121, obtaining the application identification information and identification location in the resident memory.

[0052] It should be understood that during verification, application identification information resident in the memory may be obtained, such as version number information, tag data information, memory length information, and other application identification information. Furthermore, the location of the application identification information in the resident memory may be determined, such as the head or tail of the memory.

[0053] Step S0122: Check whether the identification information of the identification part in the memory address is consistent with the application identification information.

[0054] It is understandable that during verification, the version number information, tag data information, and memory length information are checked according to the identification location to see if they are consistent. If they are consistent, the memory is reused; otherwise, a new resident memory is requested and the memory address is written to the volatile storage system. This ensures that invalid memory is not accessed during software installation and uninstallation, and also prevents memory resource leaks.

[0055] Step S013, when the consistency check passes, executing the step of setting the jump function corresponding to each system call address in the system call address set in the resident memory.

[0056] In a feasible implementation manner, after step S012, steps S014 to S016 may also be included: Step S014: If the memory address does not exist or the consistency check fails, apply for resident memory.

[0057] Step S015: Save the memory address of the resident memory into the temporary storage module.

[0058] Step S016, executing the step of setting the jump function corresponding to each system call address in the system call address set in the resident memory.

[0059] It is understandable that if the memory address does not exist or the consistency check fails, a permanent memory is applied for, and the memory address of the permanent memory is saved in a temporary storage module. By storing it in a volatile storage system, the information saved in the volatile storage system will be lost after the operating system is restarted, so that the invalid memory address retained before the system restart will not be reused. When the security software is installed later, the memory address is first read from the volatile storage, and then a verification is performed. If the verification passes, the memory is reused. If the verification fails, a permanent memory is re-applied, and then the step of setting the jump function corresponding to each system call address in the system call address set in the resident memory is executed. At the same time, in order to support verification, when applying for resident memory for the first time, version number information, tag data information, memory length information and other information can be written at the head and tail of the memory respectively.

[0060] In a feasible implementation, the temporary storage module includes a memory file system or a registry, or other storage media that is discarded when the system is restarted, which is not limited here; step S015 may further include steps S0151 to S0152: Step S0151: When the operating system type is a Linux operating system, the memory address of the resident memory is saved in the memory file system.

[0061] Step S0152: When the operating system type is a Windows operating system, a registry is created, and the memory address of the resident memory is saved in the registry.

[0062] It should be noted that regarding the specific implementation method for saving memory addresses to a volatile storage system, for Linux operating systems, memory addresses can be saved to the in-memory file system (you can use mount -t tmpfs tmpfs path to mount the in-memory file system). For Windows operating systems, memory addresses can be saved to the registry (the REG_OPTION_VOLATILE attribute must be specified when creating the registry path using ZwCreateKey). This way, if the operating system is restarted, the saved information will disappear, and the module in this solution will not access residual invalid information when it is started. If there is no restart, the saved information will remain, and the module in this solution can read the previously saved address information for verification.

[0063] In this embodiment, before executing the hook, the security software in this solution first allocates a permanent memory to store temporary jump code. When hooking the system call table, it replaces the address in the system call table with the address in the permanent memory. When other security software subsequently hooks the system table, it saves the address in the permanent memory in the system table. Therefore, after the security software in this solution is uninstalled, the subsequent security software that hooks will not access invalid memory, thus avoiding system crashes.

[0064] Based on the first embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above introduction and will not be described in detail later. Figure 8 Before step S10, the security software uninstallation method further includes steps S04 to S07: Step S04 : when the calling function of the preset security software is a function of the first security software, determining the starting address and the ending address of the system kernel module according to the address of the calling function.

[0065] It is understandable that when the calling function of the preset security software is a function of other security software (that is, the first security software has been installed before the preset security software is installed), in order to avoid the problem of accessing invalid memory due to the first security software being uninstalled before the preset security software, it is necessary to find the module name corresponding to the address based on the pre-saved address (that is, hk1_open).

[0066] Specifically, you can first enumerate all kernel modules in the system and obtain the name, starting address, and ending address of each module. Specifically, you can call ZwQuerySystemInformation to obtain the names of all driver modules in the system and the starting and ending addresses of driver module loading.

[0067] Step S05: determining the module name corresponding to the address of the calling function according to the starting address and the ending address.

[0068] It should be understood that the module to which the address hk1_open of the calling function belongs can be determined based on the address range of "[module starting address: module ending address]" to obtain the module name.

[0069] Step S06: Obtain the driver object corresponding to the address of the calling function according to the module name.

[0070] It is understandable that the driver object corresponding to hk1_open can be found according to the module name. Specifically, all driver objects in the system can be enumerated, the names of all driver objects can be obtained, and then they can be matched. The driver object with the same name is the target driver object.

[0071] In a specific implementation, the corresponding driver module name can be determined according to the function address, and then the corresponding driver object can be obtained through ObReferenceObjectByName.

[0072] Step S07: increasing the reference count of the driver object.

[0073] It's understandable that the reference count of the driver object can be incremented by 1. Increasing the reference count of the driver object by 1 indicates that the number of references to the object is increasing, indicating that more places are using or relying on the object. This prevents the module corresponding to hk1_open from being unloaded from memory, and subsequent calls to the hk1_open function will not result in accessing invalid memory. This is performed once during the initialization of the pre-installed security software; there's no need to repeat the "incrementing the reference count of the driver object" operation.

[0074] In this embodiment, the driver object corresponding to the address of the calling function is obtained and the reference count of the driver object is incremented to indicate that more locations are using or relying on the object. This prevents the corresponding modules of other security software from being unloaded from memory, and subsequent calls to functions corresponding to other security software will not result in accessing invalid memory.

[0075] It should be noted that the above examples are only used to understand this application and do not constitute a limitation on the security software uninstallation method of this application. More simple transformations based on this technical concept are all within the scope of protection of this application.

[0076] This application also provides a safe software uninstallation device, please refer to Figure 9 , the security software uninstallation device includes: An information acquisition module 10 is configured to, upon detecting an uninstall instruction for preset security software, acquire a calling function of the preset security software, wherein the calling function represents a function of first security software that is called after the preset security software passes a security check or a function that is called to access a system function, wherein the first security software is installed before the preset security software; An address modification module 20, configured to modify a target jump address of a jump function in a resident memory to the calling function, wherein the resident memory records a jump function and a target jump address, and the jump function is configured to specify a target jump address corresponding to each system call address in a system call address set; The software uninstallation module 30 is used to uninstall the preset security software.

[0077] The secure software uninstallation device provided in this application utilizes the secure software uninstallation method described in the aforementioned embodiments to resolve the technical problem. Compared to the prior art, the secure software uninstallation device provided in this application achieves the same beneficial effects as the secure software uninstallation method described in the aforementioned embodiments. Other technical features of the secure software uninstallation device are the same as those disclosed in the aforementioned embodiments and are not further elaborated here.

[0078] The present application provides a secure software uninstallation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the secure software uninstallation method in the above-mentioned embodiment 1.

[0079] Reference below Figure 10 , which shows a schematic diagram of the structure of a secure software uninstallation device suitable for implementing embodiments of the present application. The secure software uninstallation device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 10 The secure software uninstallation device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0080] like Figure 10As shown, the secure software uninstallation device may include a processing device 1001 (e.g., a central processing unit, graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory 1002 or programs loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the secure software uninstallation device. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems may be connected to the input / output interface 1006: an input device 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; a storage device 1003 including, for example, a magnetic tape or hard disk; and a communication device 1009. Communication device 1009 can allow the secure software uninstallation device to communicate with other devices wirelessly or wired to exchange data. Although the figure shows a secure software uninstallation device with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented or have alternatively.

[0081] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are performed.

[0082] The secure software uninstallation device provided in this application utilizes the secure software uninstallation method described in the aforementioned embodiment to address the technical issues surrounding secure software uninstallation. Compared to the prior art, the secure software uninstallation device provided in this application achieves the same beneficial effects as the secure software uninstallation method described in the aforementioned embodiment. Other technical features of the secure software uninstallation device are the same as those disclosed in the aforementioned embodiment and are not further elaborated upon here.

[0083] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0084] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0085] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, a computer program) stored thereon, the computer-readable program instructions being used to execute the secure software uninstallation method in the above-mentioned embodiment.

[0086] The computer-readable storage medium provided herein may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including, but not limited to, wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0087] The computer-readable storage medium may be included in the secure software uninstallation device, or may exist independently without being assembled into the secure software uninstallation device.

[0088] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the security software uninstallation device, the security software uninstallation device: when detecting the uninstallation instruction of the preset security software, obtains the calling function of the preset security software, and the calling function represents the function called to access the system function after the security check of the preset security software passes; modifies the target jump address of the jump function in the resident memory to the calling function, and the resident memory records the jump function and the target jump address, and the jump function is used to specify the target jump address corresponding to each system call address in the system call address set; uninstalls the preset security software.

[0089] Computer program code for performing the operations of the present application may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0090] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0091] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0092] The computer-readable storage medium provided in this application stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned security software uninstallation method, thereby resolving the technical problem. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are similar to those of the security software uninstallation method provided in the aforementioned embodiment, and are not further elaborated here.

[0093] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned secure software uninstallation method when executed by a processor.

[0094] The computer program product provided in this application can solve technical problems. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the secure software uninstallation method provided in the above embodiment, and will not be described in detail here.

[0095] The above description is only part of the embodiments of the present application and does not limit the scope of protection of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the scope of protection of the present application.

Claims

1. A method for uninstalling security software, characterized in that: The method includes: Upon detecting an uninstall instruction for preset security software, obtaining a calling function of the preset security software, where the calling function represents a function of first security software that is called after the preset security software passes a security check or a function called by accessing a system function, the first security software being installed before the preset security software; Modifying the target jump address of the jump function in the resident memory to the calling function, wherein the resident memory records the jump function and the target jump address, and the jump function is used to specify the target jump address corresponding to each system call address in the system call address set; Uninstall the preset security software.

2. The method according to claim 1, wherein Before the step of obtaining the calling function of the preset security software when the uninstall instruction of the preset security software is detected, the method further includes: Set the jump function corresponding to each system call address in the system call address set in the resident memory; Setting the target jump address in the jump function to the address of the preset security software; The system call address in the system call address set is modified to the address of the jump function.

3. The method according to claim 2, wherein The step of setting the jump function corresponding to each system call address in the system call address set in the resident memory includes: Determine whether there is a memory address of the resident memory in the temporary storage module, where the information stored in the temporary storage module is discarded after the operating system is restarted; If the memory address exists, performing a consistency check on the memory address; If the consistency check passes, the step of setting the jump function corresponding to each system call address in the system call address set in the resident memory is performed.

4. The method according to claim 3, wherein After the step of performing consistency check on the memory address if the memory address exists, the method further includes: If the memory address does not exist or the consistency check fails, apply for resident memory; Saving the memory address of the resident memory to the temporary storage module; Execute the step of setting the jump function corresponding to each system call address in the system call address set in the resident memory.

5. The method according to claim 4, wherein The temporary storage module includes a memory file system or a registry; The step of saving the memory address of the resident memory to the temporary storage module includes: When the operating system type is a Linux operating system, the memory address of the resident memory is saved in a memory file system; In the case where the operating system type is a Windows operating system, a registry is created, and the memory address of the resident memory is saved in the registry.

6. The method according to claim 3, wherein If the memory address exists, the step of performing consistency check on the memory address includes: Obtaining the application identification information and identification location in the resident memory; Check whether the identification information of the identification part in the memory address is consistent with the application identification information.

7. The method according to claim 1, wherein Before the step of obtaining the calling function of the preset security software when the uninstall instruction of the preset security software is detected, the method further includes: In a case where the calling function of the preset security software is a function of the first security software, determining the starting address and the ending address of the system kernel module according to the address of the calling function; Determine the module name corresponding to the address of the calling function according to the starting address and the ending address; Obtain the driver object corresponding to the address of the calling function according to the module name; Increment the reference count of the driver object.

8. A security software uninstallation device, characterized in that: The security software uninstallation device comprises: an information acquisition module configured to, upon detecting an uninstall instruction for preset security software, acquire a calling function of the preset security software, wherein the calling function represents a function of first security software that is called after the preset security software passes a security check or a function that is called to access a system function, wherein the first security software is installed before the preset security software; an address modification module, configured to modify a target jump address of a jump function in a resident memory to the calling function, wherein the resident memory records a jump function and a target jump address, and the jump function is used to specify a target jump address corresponding to each system call address in a system call address set; The software uninstallation module is used to uninstall the preset security software.

9. A secure software uninstallation device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the secure software uninstallation method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the security software uninstallation method according to any one of claims 1 to 7 are implemented.

Images