Security software uninstalling method, device and equipment and storage medium

Abstract

The application discloses a safe software uninstalling method and device, equipment and storage medium, relates to the computer security technical field, and the method comprises the following steps: before uninstalling the preset security software, the calling function of the preset security software is acquired first, the calling function represents the function called after the security check of the preset security software passes; the target jump address of the jump function in the resident memory is modified as the calling function, the jump function in the resident memory 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. According to the application, the target jump address of the jump function in the resident memory is modified as the calling function of the preset security software before uninstalling the security software, so that invalid memory is avoided, and after the security software is uninstalled, the system can access system functions through the target jump address in the system call address set, thereby guaranteeing the normal operation of the system.

Description

Technical Field

[0001] This application relates to the field of computer security technology, and in particular to a method, apparatus, device and storage medium for uninstalling secure software. Background Technology

[0002] To protect operating systems from virus attacks, security software often hooks application function calls to obtain input parameters and return results, enabling monitoring of application behavior. A common practice is to hook the system call table (e.g., Windows' System Services Descriptor Table or Linux's sys_call_table), hijacking application behavior. When an application calls an operating system function, it is redirected to a pre-substituted function by the security software. This allows the security software to obtain and check the parameters of those system calls. If no illegal behavior is detected, the application is then allowed to call underlying system functions to complete the system function. Upon return, the security software can further examine the system call's return result for further security checks. While this hooking technique facilitates monitoring of application behavior, if at least two security software programs are installed on a computer, and both use hooking techniques, uninstalling one could lead to other programs accessing invalid memory, causing system crashes and business interruptions. Summary of the Invention

[0003] The main purpose of this application is to provide a method, apparatus, device and storage medium for uninstalling security software, which aims 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, this application proposes a method for uninstalling secure software, the method comprising:

[0005] When an uninstallation command for the preset security software is detected, the calling function of the preset security software is obtained. The calling function represents the function called by the system function after the security check of the preset security software passes.

[0006] 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.

[0007] Uninstall the preset security software.

[0008] In one embodiment, before the step of obtaining the calling function of the preset security software when an uninstallation command of the preset security software is detected, the method further includes:

[0009] Set the jump function corresponding to each system call address in the system call address set that resides in memory;

[0010] Set the target jump address in the jump function to the address of the preset security software;

[0011] Modify the system call addresses in the system call address set to the address of the jump function.

[0012] In one embodiment, the step of setting the jump function corresponding to each system call address in the system call address set in resident memory includes:

[0013] Determine whether there is a resident memory address in the temporary storage module. The information stored in the temporary storage module is discarded after the operating system restarts.

[0014] If the memory address exists, then a consistency check is performed on the memory address;

[0015] If the consistency check passes, execute the step of setting the jump function corresponding to each system call address in the system call address set in resident memory.

[0016] In one embodiment, after the step of performing a consistency check on the memory address if it exists, the method further includes:

[0017] If the memory address does not exist or the consistency check fails, then request resident memory.

[0018] The memory address of the resident memory is saved to the temporary storage module;

[0019] Perform the step of setting the jump function corresponding to each system call address in the system call address set in resident memory.

[0020] In one embodiment, the temporary storage module includes a memory file system or a registry;

[0021] The step of saving the memory address of the resident memory to the temporary storage module includes:

[0022] If the operating system is Linux, the memory address of the resident memory is saved to the memory file system;

[0023] If the operating system type is Windows, a registry is created, and the memory address of the resident memory is saved to the registry.

[0024] In one embodiment, the step of performing a consistency check on the memory address if it exists includes:

[0025] Obtain the application identification information and identification location of the resident memory;

[0026] Verify whether the identifier information in the identifier portion of the memory address is consistent with the application identifier information.

[0027] In one embodiment, before the step of obtaining the calling function of the preset security software when an uninstallation command of the preset security software is detected, the method further includes:

[0028] When the function called by the preset security software is a function of other security software, the start address and end address of the system kernel module are determined according to the address of the function called, wherein the other security software is software installed before the preset security software;

[0029] The module name corresponding to the address of the called function is determined based on the start address and the end address;

[0030] Obtain the driver object corresponding to the address of the called function based on the module name;

[0031] Increase the reference count of the driving object.

[0032] Furthermore, to achieve the above objectives, this application also proposes a security software uninstallation device, which includes:

[0033] The information acquisition module is used to acquire the calling function of the preset security software when an uninstallation command of the preset security software is detected. The calling function represents the function called by the preset security software to access system functions after the security check of the preset security software has passed.

[0034] The address modification module is used to modify the target jump address of the jump function in the resident memory 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.

[0035] The software uninstallation module is used to uninstall the preset security software.

[0036] In addition, to achieve the above objectives, this application also proposes a secure software uninstallation device, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the secure software uninstallation method as described above.

[0037] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the security software uninstallation method described above.

[0038] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the security software uninstallation method described above.

[0039] This application provides a method for uninstalling security software. Upon detecting an uninstallation command for pre-installed security software, the method obtains the calling function of the pre-installed security software. This calling function represents a function of the first installed security software or a function called to access system functions after the security check of the pre-installed security software has passed. The method modifies the target jump address of a jump function in resident memory to the calling function. The resident memory records the jump function and the target jump address, with the jump function specifying the target jump address corresponding to each system call address in the system call address set. The method then uninstalls the pre-installed security software. By modifying the target jump address of a pre-allocated jump function in resident memory to the calling function of the pre-installed security software during uninstallation, this application avoids invalid memory usage. After the security software is uninstalled, the system can access system functions through the target jump address in the system call address set, ensuring the normal operation of the system. Attached Figure Description

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

[0041] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a flowchart illustrating an embodiment of the security software uninstallation method of this application.

[0043] Figure 2This is a diagram illustrating the call relationships in a system call table that has not yet been hooked by security software.

[0044] Figure 3 This is a diagram illustrating the call relationships after the first security software hooks the system call table.

[0045] Figure 4 This is a diagram illustrating the call relationships following the system call table hooked by the second security software.

[0046] Figure 5 This diagram illustrates the calling relationship of the pre-installed security software after installation.

[0047] Figure 6 This is a diagram illustrating the call relationships after the security software is uninstalled.

[0048] Figure 7 This is a flowchart illustrating Embodiment 2 of the security software uninstallation method of this application;

[0049] Figure 8 This is a flowchart illustrating Embodiment 3 of the security software uninstallation method of this application;

[0050] Figure 9 This is a schematic diagram of the module structure of the security software uninstallation device according to an embodiment of this application;

[0051] Figure 10 This is a schematic diagram of the device structure of the hardware operating environment involved in the security software uninstallation method in this application embodiment.

[0052] 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 Implementation

[0053] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0054] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0055] The main solution of this application embodiment is as follows: when an uninstallation command for preset security software is detected, the calling function of the preset security software is obtained, wherein the calling function represents the function called to access system functions 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, wherein the resident memory records the jump function and the target jump address, wherein 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.

[0056] To protect operating systems from virus attacks, security software often hooks application function calls to obtain input parameters and return results, enabling monitoring of application behavior. A common practice is to hook the system call table, hijacking application behavior. When an application calls an operating system function, it is redirected to a pre-substituted function by the security software. This allows the security software to obtain and check the parameters of the system calls. If no illegal behavior is detected, the application is then allowed to call underlying system functions to complete the system function. Upon return, the security software can further examine the system call's return result for further security checks. While this hooking technique facilitates monitoring of application behavior, if at least two security software programs are installed on a computer, and both use hooking techniques, uninstalling one could lead to other programs accessing invalid memory, causing system crashes and business interruptions.

[0057] This application provides a solution that, upon detecting an uninstallation command for pre-installed security software, obtains the function call of the pre-installed security software. This function call represents a function of the first installed security software or a function called to access system functions after the pre-installed security software passes a security check. The target jump address of a jump function in resident memory is modified to match the call function. The resident memory stores the jump function and the target jump address, with the jump function specifying the target jump address for each system call address in the system call address set. The pre-installed security software is then uninstalled. This application avoids invalid memory generation by modifying the target jump address of a pre-allocated resident function to the pre-installed security software's call function during uninstallation. After the security software is uninstalled, the system can access system functions through the target jump address in the system call address set, ensuring normal system operation.

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

[0059] Based on this, the embodiments of this application provide a method for uninstalling secure software, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the security software uninstallation method of this application.

[0060] In this embodiment, the security software uninstallation method includes steps S10 to S30:

[0061] Step S10: When an uninstallation command for the preset security software is detected, the calling function of the preset security software is obtained. The calling function represents a function of the first security software or a function called to access system functions after the security check of the preset security software has passed. The first security software is installed before the preset security software.

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

[0063] It can be noted that the call relationships of system call tables that have not yet been hooked by security software can be referenced. Figure 2 As shown, the system call table is an array that stores the entry addresses of various system call functions. When an application calls a system call, it carries the system call number as a parameter. This system call number is equivalent to an index in the corresponding array of the system call table. The operating system uses the system call number to obtain the address of the corresponding system call function from the system call table and jumps to that address to execute the system function. For example, when an application calls the system function `fopen`, the system call number it carries is 5, along with file operation-related parameters. The operating system uses the system call number to determine the address of the corresponding system function (which could be `sys_open`) from the system call table, jumps to `sys_open` to execute the system function, and finally returns the execution result.

[0064] It's worth noting that when the first security software is installed, it first saves the original system function address `sys_open` in the system call table. Then, it hooks the system call table, replacing `sys_open` with `hk1_open`. The call relationships after the first security software hooks the system call table can be found in [reference needed]. Figure 3As 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 security checks on the call parameters. After the check is completed, it jumps back to the original system call address, which is sys_open, to execute the actual system call. When the first security software performs uninstallation, it first replaces the previously saved system call address back in the system call table, that is, it replaces hk1_open back with sys_open in the system call table, restoring the original system call table. Figure 2 The calling relationship.

[0065] Understandably, when the second security software is installed and performs a hook, it will first save the original address in the system call table. Since the system call table has already been hooked by the first security software, the saved address is hk1_open. After the hook, the system call table will save hk2_open. The call relationships after the second security software hooks the system call table can be found by referring to... Figure 4 As shown. In this scenario, if the second security software is uninstalled first, followed by the first, and the system call table is restored sequentially, no compatibility issues will occur. However, if the first security software is uninstalled first, and the system call table is restored, its code will be removed from memory. Since the second security software is unaware that its code has been removed, it might continue to call the `hk1_open` function, leading to access to invalid memory, causing a system crash, and resulting in service interruption. Furthermore, the first security software is unaware that the second security software has stored its code address (meaning the program that hooked first is unaware that its code is being referenced by the program that hooked later). In this case, the uninstallation operation cannot be performed.

[0066] It should be noted that the default security software in this solution can be installed before the first security software. For a more comprehensive explanation, this example uses an installation between the two, meaning the default security software is installed after the first security software but before the second security software. This application ensures that when the default security software is uninstalled, the subsequently hooked program will not access invalid memory by maintaining it in memory; and by locking memory modules, it ensures that the program code hooked before the default security software cannot be removed from memory prematurely, thus avoiding access to invalid memory. The calling relationship of the default security software after intermediate installation can be found in [reference needed]. Figure 5 As shown.

[0067] It's worth noting that when an uninstallation command for the pre-installed security software is detected, there's no need to release resident memory; only the function call of the pre-installed security software needs to be obtained. If the first security software is installed before the pre-installed security software, the function call of the pre-installed security software is `hk1_open`. If the pre-installed security software is installed first (i.e., the first security software does not exist), the function call of the pre-installed security software is the system function `sys_open`, which is called after the pre-installed security software passes its security check and accesses system functions.

[0068] Step S20: Modify the target jump address of the jump function in the resident memory 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.

[0069] It should be noted that after obtaining the calling function of the preset security software, assuming that hk1_open is obtained at this time, the target jump address of the resident jump function jmp_open is modified to hk1_open. In this way, the program of this scheme is uninstalled before the second security software, and there will be no access to invalid memory. The system call address set can be a system call table stored in array form, or a set of function pointers representing kernel functions for various system calls, stored in key-value pair strings or other forms.

[0070] Step S30: Uninstall the preset security software.

[0071] Understandably, after modifying the target jump address of the resident memory function to call the function hk1_open, the operation of uninstalling the preset security software can then be performed. The call relationship after uninstallation is as follows: Figure 6 As shown, when an application calls the fopen function, the operating system first jumps to hk2_open according to the system call table. After the second security software completes the security check, it calls the underlying function, which is to jump to jmp_open. Since the target address in jmp_open has been modified, it jumps to hk1_open instead of the previous xxx_open. This prevents the system from crashing due to accessing invalid memory.

[0072] This embodiment provides a method for uninstalling security software. Upon detecting an uninstallation command for preset security software, the method obtains the calling function of the preset security software. The calling function represents a function of the first installed security software or a function called to access system functions after the preset security software passes a security check. The method modifies the target jump address of a jump function in resident memory to the calling function. The resident memory records the jump function and the target jump address, with the jump function specifying the target jump address corresponding to each system call address in the system call address set. The preset security software is then uninstalled. This embodiment avoids invalid memory generation by modifying the target jump address of a pre-allocated resident memory jump function to the calling function of the preset security software during uninstallation. After the security software is uninstalled, the system can access system functions through the target jump address in the system call address set, ensuring the normal operation of the system.

[0073] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 7 Before step S10, the security software uninstallation method further includes steps S01 to S03:

[0074] Step S01: Set the jump function corresponding to each system call address in the system call address set in the resident memory.

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

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

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

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

[0079] It should be understood that the system call addresses in the system call address set are also modified accordingly. This means changing the addresses of system calls in the system call table to the addresses of the jump functions resident in memory. For example, the function address hk1_open corresponding to the open system call in the system call table is replaced with jmp_open (initially sys_open in the system call table, which the first security software replaced with hk1_open). Assuming that a second security software is installed after the default security software, the addresses of system calls such as open, read, write, and close in the system call table are modified to hk2_open, hk2_read, hk2_write, and hk2_close, respectively.

[0080] This example illustrates how an application can call the `open` function. For more details, please refer to [link / reference needed]. Figure 5 When an application calls the `fopen` function, the operating system, based on the system call table, first jumps to the `hk2_open` function of the second security software. After performing a 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 performs its security check, it calls the `hk1_open` function of the first security software for a security check. Finally, after performing its security check, the first security software calls the underlying function `sys_open`, which implements the system functionality.

[0081] In one feasible implementation, step S01 may include steps S011 to S013:

[0082] Step S011: Determine whether there is a resident memory address in the temporary storage module. The information stored in the temporary storage module is discarded after the operating system restarts.

[0083] It's worth noting that by allocating resident memory, it can be ensured that after the default security software is uninstalled, the subsequently hooked modules will not access invalid memory. However, considering that allocating resident memory every time the default security software is installed, repeatedly allocating memory during software installation and uninstallation could lead to system memory leaks. To avoid memory leaks, this embodiment reuses the previously allocated resident memory.

[0084] Specifically, it can be determined whether there is a resident memory address in the temporary storage module. The information stored in the temporary storage module is discarded after the operating system restarts. This can confirm whether resident memory has been requested, thus avoiding duplicate memory requests.

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

[0086] Understandably, if a memory address exists, it can be read from volatile memory, and then a consistency check can be performed on the memory address. If the check passes, the memory can be reused; if the check fails, then a new resident memory can be requested.

[0087] In one feasible implementation, step S012 may further include steps S0121-S0122:

[0088] Step S0121: Obtain the application identification information and identification location of the resident memory.

[0089] It should be understood that during verification, it is possible to obtain the application identification information resident in memory, such as version number information, tag data information, memory length information, etc., and to determine the location of the application identification information in resident memory, such as the beginning or end of the memory.

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

[0091] Understandably, during the verification process, the version number, tag data, and memory length information are checked for consistency according to the identified location. If they match, the memory is reused; otherwise, a new resident memory is requested, and its address is written to the volatile storage system. This ensures that the software does not access invalid memory during installation and uninstallation, and also prevents memory resource leaks.

[0092] Step S013: If the consistency check passes, execute the step of setting the jump function corresponding to each system call address in the system call address set in resident memory.

[0093] In one feasible implementation, after step S012, steps S014 to S016 may also be included:

[0094] Step S014: If the memory address does not exist or the consistency check fails, then request resident memory.

[0095] Step S015: Save the memory address of the resident memory to the temporary storage module.

[0096] Step S016: Perform the step of setting the jump function corresponding to each system call address in the system call address set in the resident memory.

[0097] Understandably, if the specified memory address does not exist or the consistency check fails, resident memory is requested, and the memory address of the resident memory is saved to 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 restarts, thus avoiding the reuse of invalid memory addresses saved before the system restart. When security software is installed subsequently, the memory address is first read from the volatile storage, then verified. If the verification passes, the memory is reused; if the verification fails, resident memory is re-requested, and the steps of setting the jump function corresponding to each system call address in the system call address set in the resident memory are executed again. Furthermore, to support verification, version number information, tag data information, and memory length information can be written to the beginning and end of the memory block during the initial request for resident memory.

[0098] In one feasible implementation, the temporary storage module includes a memory file system or registry, or other storage media that is discarded upon system restart; this is not limited here. Step S015 may also include steps S0151~S0152:

[0099] Step S0151: If the operating system type is Linux, save the memory address of the resident memory to the memory file system.

[0100] Step S0152: If the operating system type is Windows, create a registry and save the memory address of the resident memory to the registry.

[0101] It's important to note that regarding the specific implementation of saving memory addresses to a volatile storage system, for Linux operating systems, the memory addresses can be saved to a memory file system (which can be mounted using `mount -t tmpfs tmpfs path`). For Windows operating systems, the memory addresses can be saved to the registry (the `REG_OPTION_VOLATILE` attribute needs to be specified when creating the registry path using `ZwCreateKey`). This way, if the operating system restarts, the saved information will be lost, and the module in this solution will not access any residual invalid information during startup; if no restart occurs, the saved information will persist, and the module can read the previously saved address information for verification.

[0102] In this embodiment, before executing the hook, the security software of this solution allocates a resident memory space to store temporary jump code. When hooking the system call table, it replaces the addresses in the system call table with the addresses in the resident memory. Subsequent security software hooking the system table uses the addresses in the resident memory space. Therefore, after the security software of this solution is uninstalled, the programs of the subsequently hooked security software will not access invalid memory, thus avoiding system crashes.

[0103] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 8 Before step S10, the security software uninstallation method further includes steps S04 to S07:

[0104] Step S04: If the function called by the preset security software is a function of the first security software, determine the start address and end address of the system kernel module based on the address of the function called.

[0105] Understandably, if the function called by the default security software is a function of another security software (i.e., the first security software was installed before the default security software was installed), in order to avoid the first security software being uninstalled before the default security software, which would lead to the problem of accessing invalid memory, it is necessary to find the module name corresponding to the address (i.e., hk1_open) based on the address saved in advance.

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

[0107] Step S05: Determine the module name corresponding to the address of the called function based on the start address and the end address.

[0108] It should be understood that the module to which the address hk1_open of the called function belongs can be determined based on the address range of "[module start address: module end address]", and the module name can be obtained.

[0109] Step S06: Obtain the driver object corresponding to the address of the called function based on the module name.

[0110] Understandably, the driver object corresponding to hk1_open can be found based on the module name. Specifically, all driver objects in the system can be enumerated to obtain the names of all driver objects, and then matched. The driver object with the same name is the target driver object.

[0111] In the actual implementation, the corresponding driver module name can be determined based on the function address, and then the corresponding driver object can be obtained through ObReferenceObjectByName.

[0112] Step S07: Increase the reference count of the driving object.

[0113] Understandably, incrementing the reference count of the driver object signifies an increase in the number of references to that object, indicating that more parts of the system are using or depending on it. This prevents the module corresponding to `hk1_open` from being unloaded from memory, thus avoiding invalid memory access during subsequent calls to the `hk1_open` function. This process is performed once during the initialization of the pre-installed security software and does not need to be repeated afterward.

[0114] In this embodiment, by obtaining the driver object corresponding to the address of the called function, a reference count is incremented on the driver object to indicate that more places are using or depending on the object. This prevents modules corresponding to other security software from being unloaded from memory, thus avoiding access to invalid memory when calling functions corresponding to other security software later.

[0115] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the security software uninstallation method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0116] This application also provides a security software uninstallation device; please refer to [link / reference]. Figure 9 The security software uninstallation device includes:

[0117] The information acquisition module 10 is used to acquire the calling function of the preset security software when an uninstallation instruction of the preset security software is detected. The calling function represents a function of the first security software called after the security check of the preset security software is passed, or a function called to access system functions. The first security software is installed before the preset security software.

[0118] Address modification module 20 is used to modify the target jump address of the jump function in the resident memory 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.

[0119] The software uninstallation module 30 is used to uninstall the preset security software.

[0120] The security software uninstallation device provided in this application, employing the security software uninstallation method described in the above embodiments, can solve the technical problem. Compared with the prior art, the beneficial effects of the security software uninstallation device provided in this application are the same as those of the security software uninstallation method described in the above embodiments, and other technical features in the security software uninstallation device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0121] This 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, which are executed by the at least one processor to enable the at least one processor to perform the secure software uninstallation method in Embodiment 1 above.

[0122] The following is for reference. Figure 10 The diagram illustrates a structural schematic suitable for implementing a secure software uninstallation device according to embodiments of this application. The secure software uninstallation device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), 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 security software uninstallation device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0123] like Figure 10As shown, the secure software uninstallation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the 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 unit 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 can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the security software uninstallation device to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show security software uninstallation devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0124] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0125] The security software uninstallation device provided in this application, employing the security software uninstallation method described in the above embodiments, can solve the technical problem of security software uninstallation. Compared with the prior art, the beneficial effects of the security software uninstallation device provided in this application are the same as those of the security software uninstallation method described in the above embodiments, and other technical features of this security software uninstallation device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0126] 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 suitable manner in one or more embodiments or examples.

[0127] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0128] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the security software uninstallation method described in the above embodiments.

[0129] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing 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.

[0130] The aforementioned computer-readable storage medium may be included in a security software uninstallation device; or it may exist independently and not be assembled into a security software uninstallation device.

[0131] The aforementioned computer-readable storage medium carries one or more programs. When the one or more programs are executed by a security software uninstallation device, the security software uninstallation device causes the following: upon detecting an uninstallation instruction for preset security software, the security software uninstallation device obtains the calling function of the preset security software, wherein the calling function represents a function called to access system functions after the security check of the preset security software passes; modifies the target jump address of a jump function in resident memory to the calling function, wherein the resident memory records the jump function and the target jump address, wherein 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.

[0132] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can 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 can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0133] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0134] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0135] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described secure software uninstallation method, thereby solving the technical problem. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the secure software uninstallation method provided in the above embodiments, and will not be repeated here.

[0136] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the security software uninstallation method described above.

[0137] The computer program product provided in this application can solve the technical problem. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the security software uninstallation method provided in the above embodiments, and will not be repeated here.

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

Claims

1. A secure software uninstallation method, characterized by, The method comprises: when detecting an uninstall instruction of preset security software, acquiring a calling function of the preset security software, the calling function representing a function of a first security software called after security check of the preset security software passes or a function called for accessing system functions, the first security software being installed prior to the preset security software; modifying a target jump address of a jump function in a resident memory to the calling function, the resident memory recording the jump function and the target jump address, the jump function being used for specifying a target jump address corresponding to each system call address in a system call address set; uninstalling the preset security software; before the step of acquiring the calling function of the preset security software when detecting the uninstall instruction of the preset security software, the method further comprises: if the memory address of the resident memory does not exist in the temporary storage module, applying for the resident memory; saving the memory address of the resident memory to the temporary storage module; setting a jump function corresponding to each system call address in a system call address set in the resident memory; setting a target jump address in the jump function to an address of the preset security software; modifying a system call address in the system call address set to an address of the jump function.

2. The method of claim 1, wherein, The step of setting the jump function corresponding to each system call address in the system call address set in the resident memory comprises: judging whether the memory address of the resident memory exists in a temporary storage module, information stored in the temporary storage module being discarded after the operating system restarts; if the memory address exists, performing consistency check on the memory address; in the case that the consistency check passes, performing the step of setting the jump function corresponding to each system call address in the system call address set in the resident memory.

3. The method of claim 2, wherein, The temporary storage module comprises a memory file system or a registry; The step of saving the memory address of the resident memory to the temporary storage module comprises: in the case that the operating system type is a linux operating system, saving the memory address of the resident memory to a memory file system; in the case that the operating system type is a windows operating system, creating a registry and saving the memory address of the resident memory to the registry.

4. The method of claim 2, wherein, The step of performing consistency check on the memory address if the memory address exists comprises: acquiring application identification information and an identification part of the resident memory; checking whether the identification information of the identification part in the memory address is consistent with the application identification information.

5. The method of claim 1, wherein, Before the step of acquiring the calling function of the preset security software when detecting the uninstall instruction of the preset security software, the method further comprises: in the case that the calling function of the preset security software is a function of the first security software, determining a start address and an end address of a system kernel module according to the address of the calling function; determining a module name corresponding to the address of the calling function according to the start address and the end address; acquiring a drive object corresponding to the address of the calling function according to the module name; increasing a reference count of the drive object.

6. A secure software uninstallation apparatus characterized by comprising: The security software uninstalling apparatus comprises: an information obtaining module, configured to obtain a calling function of a preset security software when detecting an uninstalling instruction of the preset security software, the calling function representing a function of a first security software called after security check of the preset security software passes or a function called for accessing system functions, the first security software being installed before the preset security software; an address modifying module, configured to modify a target jump address of a jump function in a resident memory to the calling function, the resident memory recording the jump function and the target jump address, the jump function being used to specify a target jump address corresponding to each system call address in a system call address set; a software uninstalling module, configured to uninstall the preset security software; the information obtaining module is further configured to apply for a resident memory if the resident memory address does not exist in the temporary storage module, save the resident memory address to the temporary storage module; the information obtaining module is further configured to set a jump function corresponding to each system call address in the system call address set in the resident memory, set the target jump address in the jump function as an address of the preset security software, and modify the system call address in the system call address set to an address of the jump function.

7. A secure software uninstallation apparatus, characterized by comprising: The device comprises a memory, a processor and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the security software uninstalling method according to any one of claims 1 to 5.

8. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program, the computer program being executed by the processor to implement the steps of the security software uninstalling method according to any one of claims 1 to 5.

Images