Automatic system updating device

Abstract

The invention provides an automatic system updating device and method. A system updating event can be recognized, and a result is updated to a white list. The apparatus determines whether at least one event to be executed intercepted from a file system corresponds to a system update event based on a plurality of update rules. The apparatus executes the at least one event to be executed and generates at least one executable file corresponding to the at least one event to be executed, where the generated at least one executable file is not included in the white list. The apparatus adds the at least one executable file generated corresponding to the at least one event to be executed to the white list based on a security setting.

Description

Technical Field

[0001] The present disclosure relates to an automatic system update device and method. Specifically, the present disclosure relates to an automatic system update device and method for identifying system updates and automatically updating a whitelist. Background Art

[0002] During system operation, for systems with higher information security requirements, a whitelist check method will be used to filter executable files, which can work well in a fixed software environment.

[0003] Specifically, the whitelist only allows the device to execute executable files listed in the positive list (eg, application whitelisting), and does not allow the device to execute unknown executable files, so as to ensure that only trusted software can be executed, thereby blocking malware attacks.

[0004] However, when performing a new system update (Windows Update), new system files are expected to be generated. If the newly generated executable files are not in the whitelist as a result of the system update, the device will not be able to execute the new files smoothly, causing the system to not operate smoothly, and the whitelist needs to be manually updated.

[0005] However, unconditionally trusting all new changes will also bring security concerns. It is necessary to avoid the mixing of new files from unknown software. In view of this, how to provide a reliable method to identify system updates and automatically update the whitelist technology is a goal that the industry urgently needs to work on. Summary of the invention

[0006] One purpose of the present disclosure is to provide an automatic system update device. The automatic system update device includes a memory and a processor, and the processor is electrically connected to the memory. The memory is used to store a whitelist. The processor determines whether at least one pending event intercepted from a file system corresponds to a system update event based on multiple update rules. In response to the at least one pending event corresponding to the system update event, the processor generates at least one executable file corresponding to the at least one pending event, wherein the at least one executable file generated by the at least one pending event is not included in the whitelist. The processor adds the at least one executable file generated corresponding to the at least one pending event to the whitelist based on a security setting.

[0007] One purpose of the present disclosure is to provide an automatic system update device. The automatic system update device includes a memory and a processor, and the processor is electrically connected to the memory. The memory is used to store a whitelist. The processor determines whether at least one pending event intercepted from a file system corresponds to a major system update event based on multiple update rules. In response to the at least one pending event corresponding to the major system update event, the processor executes an update execution file or command corresponding to the at least one pending event to generate a repair environment mapping file corresponding to the at least one pending event. The processor mounts and scans the repair environment mapping file. The processor adds multiple mapping executable files contained in the repair environment mapping file to the whitelist, wherein the mapping executable files are not included in the whitelist.

[0008] Another object of the present disclosure is to provide an automatic system update method for an electronic device, which stores a whitelist, and the automatic system update method includes the following steps: based on multiple update rules, determining whether at least one pending event intercepted from a file system corresponds to a system update event; in response to the at least one pending event corresponding to the system update event, generating at least one executable file corresponding to the at least one pending event, wherein the at least one executable file generated by the at least one pending event is not included in the whitelist; based on a security setting, adding the at least one executable file generated corresponding to the at least one pending event to the whitelist.

[0009] The automatic system update technology (at least including the device and the method) provided by the present disclosure determines whether a pending event corresponds to a system update event by analyzing the behavioral characteristics of the pending event. Then, the automatic system update technology provided by the present disclosure can execute the executable file or command corresponding to the pending event. In addition, the automatic system update technology provided by the present disclosure can add the executable file generated corresponding to the pending event to the whitelist based on the security setting, so that the system can pass the whitelist inspection when executing the at least one executable file in the subsequent system. Due to the automatic system update technology provided by the present disclosure, the system update can be identified and the whitelist can be automatically updated, which solves the shortcomings of the prior art.

[0010] The detailed technology and implementation methods of the present disclosure are described below in conjunction with the accompanying drawings so that those skilled in the art to which the present disclosure belongs can understand the technical features of the claimed invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 Describe the updated operation diagram of the existing technology;

[0012] Figure 2 is a schematic diagram depicting the updated operation of certain implementation methods;

[0013] Figure 3A schematic diagram depicting the architecture and environment of the automatic system update device of the first embodiment;

[0014] Figure 4 A schematic diagram depicting events to be executed and update rules in the first implementation mode;

[0015] Figure 5A A schematic diagram depicting update rules of certain embodiments;

[0016] Figure 5B A schematic diagram illustrating update rules for certain embodiments; and

[0017] Figure 6 A partial flow chart depicting the automatic system update method of the third embodiment.

[0018] Description of Figure Numbers:

[0019] 100: Update operation diagram

[0020] S101, S102, S103, S105, S107: Operation:

[0021] 200: Update operation diagram

[0022] S201, S203, S205, S207, S209, S211, S213, S215: Operation: 3: Automatic system update device

[0023] 31: Memory

[0024] 33: Processor

[0025] 35: Transceiver interface

[0026] 300: Whitelist

[0027] 303: System update content

[0028] NW: Network

[0029] 400: Event pending

[0030] UR1: Update rules

[0031] UR2: Update Rules

[0032] UI: Update Project

[0033] EA: Execution Account

[0034] PR: Processing Procedure

[0035] PF: Package File

[0036] PFUR: Package File Update Rules

[0037] PUR: Processor Update Rules

[0038] SSUR: System Service Update Rules

[0039] SS: System Services

[0040] CLUR: Command Line Update Rules

[0041] CL: Command Line

[0042] 600: Automatic system update method

[0043] S601, S603, S605: Steps DETAILED DESCRIPTION

[0044] The following will explain an automatic system update device and method provided by the present disclosure through implementation examples. However, the implementation examples are not intended to limit the present disclosure to any environment, application, or method as described in the implementation examples. Therefore, the description of the implementation examples is only for the purpose of explaining the present disclosure, and is not intended to limit the scope of the present disclosure. It should be understood that in the following implementation examples and drawings, elements that are not directly related to the present disclosure have been omitted and are not shown, and the size of each element and the size ratio between the elements are only for illustration, and are not intended to limit the scope of the present disclosure.

[0045] First, for ease of understanding, let's briefly explain how the system update works in the prior art. Please refer to Figure 1 Schematic diagram 100 of the update operation. Figure 1 As shown, when the device detects that there is a system update, a new executable file will be generated after the update. When an unknown executable file that is not in the white list is to be executed, it cannot be directly executed because the unknown executable file is not in the white list, so the system cannot operate smoothly. Therefore, in such a case, it is necessary to perform additional manual inspection to compare software signs (i.e., operation S105) based on the manually set software trust rules (i.e., operation S103). When it is determined that the executable file meets the trust rules, the executable file is manually added to the white list (i.e., operation S107). However, since the software trust rules need to be manually updated and maintained (i.e., operation S102), they cannot be updated automatically in real time.

[0046] Next, a brief description of one way the system updates work in this disclosure is provided in the following sections. Figure 2 Schematic diagram 200 of the update operation. Figure 2As shown, the present disclosure continuously monitors the pending events of the file system through the monitoring program (i.e., operation S201), and determines whether the pending events correspond to the system update events (i.e., operation S203). When the determination result is no, the monitoring of other pending events of the file system continues. In addition, when the determination result is yes, the determination is further made whether the pending events correspond to the major system update events (i.e., operation S205).

[0047] Next, when the determination result of operation S205 is no, an executable file corresponding to the event to be executed is generated (ie, operation S207 ), and then the executable file is added to the whitelist (ie, operation S209 ).

[0048] In addition, when the judgment result of operation S205 is yes, operation S211 is executed to execute the update execution file or command corresponding to the event to be executed to generate a repair environment mapping file (for example: Winre.wim) corresponding to the event to be executed. (That is, this update comes with a complete update system file, and the update system file has not yet overwritten the running system). Then, the repair environment mapping file is mounted and the files therein are scanned (that is, operation S213). Then, the multiple mapping executable files contained in this mapping file are added to the whitelist (that is, operation S215) to speed up the update speed of the whitelist. Among them, the aforementioned mapping executable file means the executable file taken from the repair environment mapping file, that is, the mapping executable file is part of the update system file.

[0049] Next, the following paragraphs will explain the application environment of this disclosure, please refer to Figure 3 .like Figure 3 As shown, the automatic system update device 3 receives system update content 303 (e.g., update package, installation package, etc.) for updating its device, and the automatic system update device 3 determines whether it is possible to collect update results corresponding to the system update content 303. For example, the automatic system update device 3 can receive the system update content 303 from a network NW (e.g., an internal network or an external network).

[0050] Those who need to be explained, Figure 3 This is only used to illustrate an embodiment of the present disclosure. The present disclosure does not limit the source of the system update content 303. Any method in which the automatic system update device 3 receives the system update content 303 and performs a system update should fall within the scope of the present disclosure.

[0051] The automatic system update device 3 of the first embodiment of the present disclosure is schematically shown in FIG. Figure 3 The automatic system update device 3 comprises a memory 31 , a processor 33 and a transceiver interface 35 . The processor 33 is electrically connected to the memory 31 and the transceiver interface 35 .

[0052] It should be noted that the memory 31 can be a memory, a universal serial bus disk, a hard disk, an optical disk, a flash disk, or any other storage medium or circuit known to a person skilled in the art and having the same function. The transceiver interface 35 is an interface capable of receiving and transmitting data or any other interface capable of receiving and transmitting data known to a person skilled in the art. The processor 33 can be any processing unit, a central processing unit (CPU), a microprocessor, or any other computing device known to a person skilled in the art.

[0053] In this embodiment, the memory 31 is used to store a white list 300. It should be noted that the white list 300 stores files that are allowed to be executed and basic information of the corresponding files, such as file names, timestamps, etc. In some embodiments, the white list 300 may further store file fingerprints of the corresponding files.

[0054] In some embodiments, the whitelist 300 may be generated by the automatic system update device 3 itself. In some embodiments, the whitelist 300 may be directly obtained by an external device (eg, multiple devices jointly maintain and update the whitelist 300).

[0055] In this embodiment, the processor 33 can continuously monitor the operating process of a file system (e.g., Windows File System). In addition, the processor 33 can intercept an event to be executed (hereinafter referred to as a pending event) from the file system and analyze the behavior characteristics of the pending event to determine whether the pending event is a system update event.

[0056] In addition, when the processor 33 has determined that the event to be executed is a system update event, the processor 33 needs to perform the following automatic system update determination operation.

[0057] Specifically, the processor 33 determines whether the pending event intercepted from the file system corresponds to the system update event based on multiple update rules. It should be noted that the processor 33 can process one or more pending events (i.e., at least one pending event) in sequence. For ease of explanation, the following description will be based on the processor 33 executing one pending event. Those skilled in the art should be able to understand the operation of multiple pending events based on the description content of this disclosure.

[0058] It should be noted that each of the update rules is a rule generated by the processor 33 analyzing the behavior characteristics of the system when updating. For example, the behavior characteristics may include a specific executor (e.g., system account LocalSystem, system account LocalService), a specific processing program, a specific package file path, and a specific storage location.

[0059] In some embodiments, the update rules are generated by analyzing multiple historical system update events of the file system by the processor 33. For example, the processor 33 obtains multiple historical system update events from the file system. Then, the processor 33 obtains the historical behavior characteristics corresponding to each of the historical system update events to generate the update rules.

[0060] For easier understanding, please refer to the following example. Figure 4 .At Figure 4 In the example, the event to be executed 400 is a known historical system update event, and the event to be executed 400 includes the original information corresponding to the event to be executed, such as the update item, the execution account, the processing program, the package file path, etc.

[0061] In this example, the processor 33 analyzes the content of the pending event 400 and generates an update rule UR1 corresponding to the pending event 400. In this example, the update rule UR1 includes fields such as the update item UI, the execution account EA, the processing program PR, and the package file PF. The update item UI corresponds to "KB4480730", the execution account EA corresponds to "LocalSystem", the processing program PR corresponds to "m siexec.exe", and the package file PF corresponds to "%WINDIR%\SoftwareDistribution\Download\017a\Windows10.0-KB4480730-x64.msi".

[0062] In some embodiments, the processor 33 further replaces the name in the path with a wildcard “*” to cover more update items of the same type. For example, the processor 33 replaces the contents such as “4480730” and “017a” in the update rule UR1 with “*” and generates the update rule UR2.

[0063] In some implementations, the update rules include at least one of a process update rule, a system service update rule, a command line update rule, and a package file update rule, or a combination thereof.

[0064] For easier understanding, please refer to the following example. Figure 5A and Figure 5B .At Figure 5A In the package file update rule PFUR, there are four fields: update item UI, execution account EA, processing program PR, package file PF. Taking the second set of package file update rule PFUR as an example, the update item UI corresponds to "KB*", the execution account EA corresponds to "LocalSystem", the processing program PR corresponds to "dism.exe", and the package file PF corresponds to "%ProgramFiles%\CUAssistant\Download\Windows10.0-KB*-x64.cab".

[0065] At Figure 5A In the PUR, the update rule contains three fields: update item UI, execution account EA, and process PR. Taking the second set of update rule PUR as an example, the update item UI corresponds to "SecurityUpdate", the execution account EA corresponds to "LocalSystem", and the process PR corresponds to "%WINDIR%\ServiceProfiles\NetworkService\AppData\Local\Temp\mpam-*.exe".

[0066] At Figure 5B In the system service update rule SSUR, there are three fields: update item UI, execution account EA, system service SS, etc. Taking the second group of system service update rule SSUR as an example, its update item UI corresponds to "QualityUpdate", execution account EA corresponds to "LocalSystem", and system service SS corresponds to "DoSvc".

[0067] At Figure 5B In the command line update rule CLUR, there are three fields: update project UI, execution account EA, command line CL. For example, the update project UI of the command line update rule CLUR corresponds to "ProgramPackageUpdate", the execution account EA corresponds to "LocalSystem", and the command line CL corresponds to "%WINDIR%\System32\svchost.exe-kwsappx-p-sAppXSvc".

[0068] In this embodiment, after the processor 33 determines that the pending event corresponds to the system update event (ie, an update event that complies with the update rule), the processor 33 then executes the update execution file or command corresponding to the pending event.

[0069] In this embodiment, the processor 33 can add the executable file generated corresponding to the pending execution event to the whitelist 300 based on a security setting.

[0070] In some embodiments, the automatic system update device 3 can set security settings based on different usage environments to determine update events based on different trust levels. Specifically, the security setting corresponds to one of a plurality of security levels (e.g., high security level, medium security level, low security level), and each of the security levels corresponds to a different whitelist update determination.

[0071] It should be noted that the processor 33 may also set different update rule compliance ratios (eg, 100%, 80% or 50% update rule compliance ratios) for different security levels.

[0072] In some embodiments, the processor 33 verifies the system account corresponding to the execution of the event to be executed. Then, in response to the system account meeting the system permissions (e.g., system account LocalSystem, system account LocalService), the processor 33 compares the event to be executed with the update rules to calculate an update rule compliance ratio. Finally, the processor 33 determines whether the at least one execution event corresponds to the system update event based on the update rule compliance ratio and the security setting.

[0073] For example, when the security setting corresponds to the highest level, the processor 33 needs to determine whether the event to be executed fully complies with the update rule (eg, complies with all fields in the encapsulation file update rule PFUR) before collecting the update result.

[0074] For another example, when the security setting corresponds to the medium level, the processor 33 can collect the update result when it determines that part of the update rules are met (for example, only the processing procedure PR and the package file PF field in the package file update rule PFUR are met).

[0075] For another example, when the security setting corresponds to a low level, the processor 33 can collect the update result when it determines that part of the update rules are met (for example, only the execution account EA and the package file PF field in the package file update rule PFUR are met).

[0076] In some embodiments, when the security setting corresponds to the highest level (e.g., the first security level), the processor 33 needs to determine that the update rule is fully met before executing the update. In addition, the automatic system update device 3 can directly add the at least one executable file generated by the event to be executed to the whitelist 300 after executing the update.

[0077] In some embodiments, when the security setting corresponds to a medium level (e.g., the second security level), the processor 33 can execute this update when it determines that some update rules are met (e.g., 80% of the behavior characteristics are met). In addition, after executing this update, the processor 33 first puts the generated executable file into the update observation list for monitoring, and only after a certain period of time has passed and it is confirmed that there is no problem, does the processor 33 add the executable file to the whitelist 300.

[0078] In some embodiments, when the security setting corresponds to a low level (e.g., the third security level), the processor 33 can execute this update when it determines that some update rules are met (e.g., 50% of the behavior characteristics are met). In addition, the processor 33 may not add the generated executable file to the whitelist 300 after executing this update.

[0079] In some embodiments, the processor 33 may further determine whether it is a major system update that includes a repair environment mapping file (e.g., Winre.wim), and by mounting the repair environment mapping file, obtain multiple mapping executable files included therein and add them to the whitelist to speed up the update of the whitelist 300. Specifically, the processor 33 determines whether the at least one pending event corresponds to a major system update event. Then, in response to the at least one pending event corresponding to the major system update event, the processor 33 executes a repair environment mapping file (e.g., Winre.wim) corresponding to the at least one pending event, and scans the complete updated system files included therein. Finally, the processor 33 adds the multiple mapping executable files included in the repair environment mapping file to the whitelist 300.

[0080] In some embodiments, when adding to the whitelist 300, the processor 33 further generates a file fingerprint of the executable file to avoid misjudgment caused by malicious software forging file names. Specifically, the processor 33 calculates a file fingerprint corresponding to the executable file based on the executable file generated by the pending execution event. Then, the processor 33 adds the file fingerprint corresponding to the executable file to the whitelist 300. The file fingerprint refers to confirming whether the executable file has been modified or damaged during the download process through, for example, the MD5 information digest algorithm.

[0081] As can be seen from the above description, the automatic system update device 3 provided by the present disclosure determines whether a pending event corresponds to a system update event by analyzing the behavioral characteristics of the pending event. Then, the automatic system update device 3 provided by the present disclosure can execute the update execution file or command corresponding to the pending event. In addition, the automatic system update device 3 provided by the present disclosure can add the executable file generated corresponding to the pending event to the whitelist based on the security setting, so that the system can pass the whitelist inspection when executing the at least one executable file in the subsequent process. Since the automatic system update device 3 provided by the present disclosure can identify system updates and automatically update the whitelist, the shortcomings of the prior art are solved.

[0082] In short, in addition to the operations performed in the first embodiment, in the second embodiment, the processor 33 can directly determine whether at least one pending event intercepted from a file system corresponds to a major system update event based on multiple update rules.

[0083] Next, in response to the at least one pending event corresponding to the major system update event, the processor 33 mounts and scans a repair environment mapping file (e.g., Winre.wim) corresponding to the at least one pending event, wherein the repair environment mapping file carries a complete update system file, the update system file includes a plurality of mapping executable files, and has not overwritten the running system. Finally, the processor 33 adds the mapping executable files to the whitelist.

[0084] In some implementations, the processor 33 may further add the executable files generated corresponding to the at least one pending execution event to the whitelist based on a security setting.

[0085] In some embodiments, the security setting corresponds to one of a plurality of security levels, and each of the security levels corresponds to a whitelist update determination.

[0086] In certain embodiments, when the security setting corresponds to a first security level among the security levels, the processor 33 further performs the following operations: in response to executing the mounting and scanning of the repair environment mapping file (for example: Winre.wim), the mapped executable files generated corresponding to at least one event to be executed are added to the whitelist.

[0087] In certain embodiments, when the security setting corresponds to a second security level among the security levels, the processor 33 further performs the following operations: in response to executing the mounting and scanning of the repair environment mapping file (for example: Winre.wim), adding the generated mapping executable files to an update watch list; and monitoring the update watch list for a time interval to add the update watch list to the white list.

[0088] In certain embodiments, when the security setting corresponds to a third security level among the security levels, the processor 33 further performs the following operations: in response to executing the mounting and scanning of the repair environment mapping file (for example: Winre.wim), the mapped executable files generated corresponding to at least one event to be executed are not added to the whitelist.

[0089] In some implementations, the processor 33 further performs the following operations: obtaining a plurality of historical system update events from the file system; and obtaining historical behavior features corresponding to each of the historical system update events to generate the update rules.

[0090] In certain embodiments, the processor 33 determines whether the at least one pending event corresponds to the major system update event and further includes the following operations: verifying a system account corresponding to the execution of the at least one pending event; in response to the system account complying with a system permission, comparing the at least one pending event with the update rules to calculate an update rule compliance ratio; and determining whether the at least one pending event corresponds to the major system update event based on the update rule compliance ratio and the security setting.

[0091] In some embodiments, the processor 33 further performs the following operations: based on the repair environment mapping file (e.g., Winre.wim) generated by the at least one event to be executed, mount its image file and scan the executable files contained therein, calculate the file fingerprint corresponding to each of the executable files; and add the file fingerprint corresponding to each of the executable files to the whitelist.

[0092] In some embodiments, the update rules include at least one of a processing program update rule, a system service update rule, a command line update rule, and a package file update rule, or a combination thereof. In addition to the above steps, the second embodiment can also perform all operations and steps of the automatic system update device 3 described in the first embodiment, has the same functions, and achieves the same technical effects. A person skilled in the art of the present disclosure can directly understand how the second embodiment performs these operations and steps based on the above first embodiment, has the same functions, and achieves the same technical effects, so it will not be repeated.

[0093] The third embodiment of the present disclosure is an automatic system update method, the flow chart of which is depicted in Figure 6 The automatic system update method 600 is applicable to an electronic device, such as the automatic system update device 3 described in the first embodiment. The electronic device stores a white list, such as the white list 300 described in the first embodiment. The automatic system update method 600 performs system update and updates the white list through steps S601 to S607.

[0094] In step S601 , the electronic device determines whether at least one pending event intercepted from a file system corresponds to a system update event based on a plurality of update rules.

[0095] Next, in step S603, the electronic device generates at least one executable file corresponding to the at least one pending event in response to the at least one pending event corresponding to the system update event, wherein the at least one executable file generated by the at least one pending event is not included in the whitelist.

[0096] Finally, in step S605 , the electronic device adds the at least one executable file generated corresponding to the at least one event to be executed to the whitelist based on a security setting.

[0097] In some embodiments, the security setting corresponds to one of a plurality of security levels, and each of the security levels corresponds to a whitelist update determination.

[0098] In some implementations, when the security setting corresponds to a first security level among the security levels, the automatic system update method 600 further includes the following step: adding the at least one executable file generated corresponding to the at least one pending event to be executed to the whitelist.

[0099] In certain embodiments, when the security setting corresponds to a second security level among the security levels, the automatic system update method 600 further includes the following steps: adding the generated at least one executable file to an update watch list; and after monitoring the update watch list for a time period, adding the at least one executable file to the white list.

[0100] In some embodiments, when the security setting corresponds to a third security level among the security levels, the automatic system update method 600 further includes the following step: not adding the at least one executable file generated corresponding to the at least one pending event to the whitelist.

[0101] In some embodiments, the automatic system update method 600 further includes the following steps: obtaining a plurality of historical system update events from the file system; and obtaining historical behavior features corresponding to each of the historical system update events to generate the update rules.

[0102] In certain embodiments, the automatic system update method 600 further includes the following steps: determining whether the at least one pending event corresponds to a major system update event; in response to the at least one pending event corresponding to the major system update event, executing one updateable executable file or command corresponding to the at least one pending event to generate a repair environment mapping file (e.g., Winre.wim), wherein the mapping file carries a complete updated system file including multiple mapping executable files and has not yet overwritten the running system; and adding the mapping executable files to the whitelist.

[0103] In certain embodiments, determining whether the at least one event to be executed corresponds to the system update event further includes the following steps: verifying a system account corresponding to executing the at least one event to be executed; in response to the system account complying with a system permission, comparing the at least one event to be executed with the update rules to calculate an update rule compliance ratio; and determining whether the at least one event to be executed corresponds to the system update event based on the update rule compliance ratio and the security setting.

[0104] In some embodiments, the automatic system update method 600 further includes the following steps: calculating a file fingerprint corresponding to the at least one executable file based on the at least one executable file generated by the at least one pending event; and adding the file fingerprint corresponding to the at least one executable file to the whitelist.

[0105] In some implementations, the update rules include at least one of a processing program update rule, a system service update rule, a command line update rule, and a package file update rule, or a combination thereof.

[0106] In addition to the above steps, the third embodiment can also perform all operations and steps of the automatic system update device 3 described in the first embodiment and the second embodiment, has the same functions, and achieves the same technical effects. A person skilled in the art of the present disclosure can directly understand how the third embodiment performs these operations and steps based on the above-mentioned first embodiment and the second embodiment, has the same functions, and achieves the same technical effects, so it will not be repeated.

[0107] In summary, the automatic system update technology (at least including the device and the method) provided by the present disclosure determines whether a pending event corresponds to a system update event by analyzing the behavioral characteristics of a pending event. Then, the automatic system update technology provided by the present disclosure executes the update execution file or command corresponding to the pending event. In addition, the automatic system update technology provided by the present disclosure can add the executable file generated corresponding to the pending event to the whitelist based on the security setting, so that the system can pass the whitelist inspection when executing the at least one executable file in the subsequent process. Due to the automatic system update technology provided by the present disclosure, the system update can be identified and the whitelist can be automatically updated, thus solving the shortcomings of the prior art.

[0108] The above embodiments are only used to illustrate some embodiments of the present disclosure and to explain the technical features of the present disclosure, and are not used to limit the scope and range of protection of the present disclosure. Any changes or equivalent arrangements that can be easily completed by a person skilled in the art of the present disclosure belong to the scope claimed by the present disclosure, and the scope of the claims of the present disclosure shall be subject to the scope of the claims.

Claims

1. An automatic system update device, comprising: A memory for storing the whitelist; and A processor is electrically connected to the memory and is used to perform the following operations: Based on a plurality of update rules, determining whether at least one pending event intercepted from the file system corresponds to a system update event; In response to the at least one pending event corresponding to the system update event, generating at least one executable file corresponding to the at least one pending event, wherein the at least one executable file generated by the at least one pending event is not included in the whitelist; and Based on the security setting, the at least one executable file generated corresponding to the at least one event to be executed is added to the whitelist. 2 . The automatic system update device according to claim 1 , wherein the security setting corresponds to one of a plurality of security levels, and each of the plurality of security levels corresponds to a whitelist update determination.

3. The automatic system update device according to claim 2, wherein when the security setting corresponds to a first security level among the plurality of security levels, the processor further performs the following operations: The at least one executable file generated corresponding to the at least one event to be executed is added to the whitelist.

4. The automatic system update device according to claim 2, wherein when the security setting corresponds to a second security level among the plurality of security levels, the processor further performs the following operations: Adding the generated at least one executable file to an update watch list; and After monitoring the update watch list time interval, the at least one executable file is added to the white list.

5. The automatic system update device according to claim 2, wherein when the security setting corresponds to a third security level among the plurality of security levels, the processor further performs the following operations: The at least one executable file generated corresponding to the at least one event to be executed is not added to the whitelist.

6. The automatic system update device according to claim 1, wherein the processor further performs the following operations: Obtaining a plurality of historical system update events from the file system; and The historical behavior characteristics corresponding to each of the plurality of historical system update events are obtained to generate the plurality of update rules.

7. The automatic system update device according to claim 1, wherein the processor further performs the following operations: Determining whether the at least one event to be executed corresponds to a major system update event; In response to the at least one pending event corresponding to the major system update event, executing an update execution file or command corresponding to the at least one pending event to generate a repair environment mapping file corresponding to the at least one pending event; Mounting and scanning the repair environment mapping file; as well as Adding multiple mapping executable files included in the repair environment mapping file to the whitelist.

8. The automatic system update device according to claim 1, wherein determining whether the at least one pending event corresponds to the system update event further comprises the following operations: Verify the system account corresponding to executing the at least one event to be executed; In response to the system account meeting the system permissions, comparing the at least one event to be executed with the plurality of update rules to calculate an update rule compliance ratio; and Based on the update rule compliance ratio and the security setting, it is determined whether the at least one event to be executed corresponds to the system update event.

9. The automatic system update device according to claim 1, wherein the processor further performs the following operations: Based on the at least one executable file generated by the at least one pending event, calculating a file fingerprint corresponding to the at least one executable file; and The file fingerprint corresponding to the at least one executable file is added to the whitelist. 10 . The automatic system update device according to claim 1 , wherein the plurality of update rules include at least one of a processing program update rule, a system service update rule, a command line update rule, and a package file update rule, or a combination thereof.

11. An automatic system update device, comprising: A memory for storing the whitelist; and A processor is electrically connected to the memory and is used to perform the following operations: Based on a plurality of update rules, determining whether at least one pending event intercepted from the file system corresponds to a major system update event; In response to the at least one pending event corresponding to the major system update event, executing an update execution file or command corresponding to the at least one pending event to generate a repair environment mapping file corresponding to the at least one pending event; Mounting and scanning the repair environment mapping file; as well as Adding a plurality of mapping executable files included in the repair environment mapping file to the whitelist, wherein the plurality of mapping executable files are not included in the whitelist.

12. The automatic system update device according to claim 11, wherein the processor further performs the following operations: Based on the security setting, the plurality of mapped executable files corresponding to the at least one event to be executed are added to the whitelist. 13 . The automatic system update device of claim 12 , wherein the security setting corresponds to one of a plurality of security levels, and each of the plurality of security levels corresponds to a whitelist update determination.

14. The automatic system update device according to claim 13, wherein when the security setting corresponds to a first security level among the plurality of security levels, the processor further performs the following operations: The plurality of mapping executable files generated corresponding to the at least one event to be executed are added to the whitelist.

15. The automatic system update device according to claim 13, wherein when the security setting corresponds to a second security level among the plurality of security levels, the processor further performs the following operations: adding the plurality of mapping executable files to an update watch list; and After monitoring the update watch list time interval, the plurality of mapping executable files are added to the white list.

16. The automatic system update device according to claim 13, wherein when the security setting corresponds to a third security level among the plurality of security levels, the processor further performs the following operations: The plurality of first executable files generated corresponding to the at least one event to be executed are not added to the whitelist.

17. The automatic system update device according to claim 11, wherein the processor further performs the following operations: Obtaining a plurality of historical system update events from the file system; and The historical behavior characteristics corresponding to each of the plurality of historical system update events are obtained to generate the plurality of update rules.

18. The automatic system update device according to claim 12, wherein determining whether the at least one pending event corresponds to the major system update event further comprises the following operations: Verify the system account corresponding to executing the at least one event to be executed; In response to the system account meeting the system permissions, comparing the at least one event to be executed with the plurality of update rules to calculate an update rule compliance ratio; and Based on the update rule compliance ratio and the security setting, it is determined whether the at least one event to be executed corresponds to the major system update event.

19. The automatic system update device according to claim 11, wherein the processor further performs the following operations: Calculating a file fingerprint corresponding to each of the plurality of mapped executable files; and The file fingerprint corresponding to each of the plurality of mapped executable files is added to the whitelist. 20 . The automatic system update device according to claim 11 , wherein the plurality of update rules comprise at least one of a processing program update rule, a system service update rule, a command line update rule, and a package file update rule, or a combination thereof.

Images