A sandbox-based terminal software security detection method for area integration

Abstract

This invention discloses a sandbox-based method for security detection of software in converged network terminals. The method includes: before software execution, performing static detection based on a whitelist of digital certificate feature parameters to prevent software with invalid certificates from running; creating a new sandbox and starting a process within it for each software with a valid certificate; collecting all system calls during software execution through the sandbox and extracting sensitive system calls to form a sensitive behavior sequence library; simulating the execution of each system call within the secure area of ​​the sandbox and the program kernel; constructing an abnormal behavior detection automaton from an abnormal behavior policy library to dynamically detect abnormal behavior in the sensitive system calls captured by the sandbox and determine whether they constitute abnormal behavior; if the software is normal, redirecting all files and operations in the sandbox to the converged network terminal system. This invention significantly optimizes the isolation of software execution in converged network terminals, the accuracy of detection results, and the efficiency of the detection process.

Description

Technical Field

[0001] This invention relates to a sandbox-based security testing method for business software in a converged distribution terminal, belonging to the field of converged distribution terminals for power equipment. Background Technology

[0002] As a crucial component of the physical layer of power IoT devices, the integrated distribution transformer terminal integrates processing and display modules, power acquisition and distribution modules, local communication modules, remote communication modules, remote control modules, local interface modules, and backup power modules, meeting the diverse market demands for electricity information collection terminals. The integrated distribution transformer terminal provides a universal computing platform, including a processor, memory, network interface, and embedded operating system, allowing for the installation and operation of various business software according to user needs, thus separating application software from hardware. With the rapid development of smart grids, the application of integrated distribution transformer terminals is becoming more widespread, with an increasing variety and number of business software running on them. While providing smart services to users and power grid companies, it also offers convenient attack channels for criminals. Attackers can install and run pirated software, Trojan horses, viruses, etc., on integrated distribution transformer terminals to steal or tamper with electricity data, damage power equipment, cut off power supply, and attack the core power network, affecting people's normal production and life and the economic interests of power companies, causing significant social security risks. Compared to software security testing on PCs and servers, the computing and storage resources of converged distribution terminals are limited, making it impossible to support complex testing methods. Furthermore, they must return test results as quickly as possible to terminate the execution of abnormal software. Therefore, ensuring the secure operation of software on converged distribution terminals is a crucial prerequisite for the safe operation and development of the power grid.

[0003] The normal operation of application software on the converged terminal of the distribution area must ensure the legitimate use of various resources during the software operation process, including reasonable access to system resources and authorized access to other applications. Therefore, it is necessary to securely isolate the application software on the converged terminal of the distribution area and monitor and analyze the entire operation process to prevent the operation of abnormal software. Currently, software security detection methods used for converged terminals in distribution networks mainly fall into three categories: pre-run authentication, virtualization operation, and post-run log analysis. The first method verifies the signature of the digital certificate locally on the converged terminal before software execution, but this method cannot identify digital certificates with forged keys. The second method uses virtualization technology to build a virtual machine or container on the converged terminal and executes the software within it. However, virtual machines have poor performance, and the software does not perform system rollback after execution, retaining all operation results, making damage to the system by abnormal software unavoidable. The third method analyzes the logs generated during execution and uses various anomaly detection methods to determine if the software is abnormal. However, the software has already performed unrecoverable abnormal operations on the system during execution, and most anomaly detection algorithms are complex and perform poorly on resource-constrained converged terminals.

[0004] In general, existing PC and server-based software security detection methods are complex, time-consuming, and resource-intensive, making them unsuitable for the resource-constrained nature of converged terminals in hardware distribution areas and the security requirement of early detection of abnormal software behavior. Furthermore, existing software security detection methods for converged terminals suffer from the following problems: First, the detection process is primarily completed by the terminal, consuming significant hardware resources and resulting in slow detection speeds; second, analyzing all logs only after the software has fully executed leads to delayed detection of abnormal behavior, and the large amount of data to analyze further slows down the detection process; fourth, after the software is fully executed within a virtual machine or container, modifications and damage to the system by the abnormal software cannot be avoided. Therefore, to ensure the secure operation of converged terminals in hardware distribution areas, a low-hardware-consumption, fast-speed, and rollback-enabled application software security detection method is needed to guarantee the detection and isolation of application software anomalies. Summary of the Invention

[0005] This invention provides a sandbox-based security detection method for converged terminal software in a distribution network. It aims to address the issues of incomplete process coverage, poor isolation, and low performance in the aforementioned security detection of converged terminal software in distribution networks by utilizing sandbox technology. Before software execution, static detection based on a whitelist is employed. The software is run within a sandbox, and dynamic behavior detection is performed using an automaton during execution. After software execution, a system rollback is performed, covering the entire process before, during, and after software execution. The sandbox feature ensures security isolation while also maintaining detection performance.

[0006] The technical solution adopted in this invention is as follows:

[0007] A sandbox-based security detection method for converged terminal software in a distribution network includes the following steps:

[0008] (1) Static software testing:

[0009] A whitelist is established based on the feature parameters in the digital certificate of each application software. Feature parameters are extracted from the digital certificate of the software to be tested and compared with the whitelist. If the digital certificate is invalid, the application software is prohibited from running. If the digital certificate is valid, proceed to step (2).

[0010] (2) Start the sandbox:

[0011] Create at least one new sandbox and start a process within the sandbox for each certificate-valid application.

[0012] (3) Behavioral feature extraction:

[0013] Collect all system calls made by the application software during its operation, and extract sensitive system calls to form a sensitive behavior sequence library;

[0014] (4) System call redirection:

[0015] Simulate the execution of each system call within the sandbox, and use different redirection methods for different types of system calls;

[0016] (5) Dynamic detection of abnormal behavior:

[0017] An abnormal behavior detection automaton is constructed based on an abnormal behavior strategy library. It dynamically detects sensitive system calls captured by the sandbox, determines whether they constitute abnormal behavior, and judges whether the application software is normal software based on the abnormal behavior.

[0018] (6) System rollback:

[0019] If the application software is normal software, all redirects from the sandbox will be written back to the system; otherwise, the system will roll back to the state before the software ran.

[0020] The beneficial effects of this invention are as follows:

[0021] (1) The detection process adopts a combination of terminal and application center. The construction and maintenance of whitelist library, abnormal behavior strategy library and abnormal behavior judgment automaton are completed in high-performance application center to serve all terminals. Each terminal is only responsible for feature extraction, parameter collection and detection judgment of the software to be detected, reducing the hardware resource consumption of the terminal by the detection algorithm.

[0022] (2) By combining static and dynamic detection, some abnormal behaviors can be screened in advance, and only sensitive system calls can be analyzed in real time during dynamic detection, which improves detection efficiency and allows abnormal software to be discovered as early as possible.

[0023] (3) An abnormal behavior detection automaton is built in the application center based on the abnormal behavior strategy library. The terminal uses sensitive system calls as input to the automaton to perform abnormal behavior detection locally. The detection speed is fast and the hardware resource consumption of the terminal is low. The detection accuracy is ensured through the updating and maintenance of the abnormal behavior strategy library and the automaton. Attached Figure Description

[0024] Figure 1 This invention relates to a network architecture for security detection of converged terminal software in a sandbox-based area.

[0025] Figure 2 This is the specific process of the sandbox-based integrated terminal software security detection method of the present invention.

[0026] Figure 3 This is the software security detection process according to an embodiment of the present invention. Detailed Implementation

[0027] The technical solution of the present invention is further described below with reference to embodiments. The security detection method proposed in this invention is mainly used for converged terminals in distribution networks. When a converged terminal needs to run business software, it performs security isolation to ensure that the business software is legitimate and has no abnormal behavior, and will not affect the system or other software, thus guaranteeing the secure operation of the converged terminal. Because business software comes from a wide range of sources, it may contain Trojans or viruses that are disguised in various ways, making it difficult to identify from the software installation files. During or after software operation, it may seize system resources or damage system and other software data. Therefore, it is necessary to detect illegal software and abnormal behavior before and during software operation, and to roll back the system to the state before software execution after operation. The sandbox technology is used to ensure security isolation, while a whitelist database and automated machines are used to improve detection performance. Currently, the main methods for security testing of converged terminal software in the distribution area are to verify the software's certificate on the converged terminal before the software runs, or to execute the software on a virtual machine on the converged terminal and then analyze the logs. Through analysis and experiments, it has been found that the detection methods are highly complex and not suitable for resource-constrained converged terminals in the distribution area. Abnormal software behavior can only be detected after the software has been fully executed. The security of virtual machines and container isolation is low and it is difficult to perform system rollback.

[0028] The proposed sandbox-based software security detection method for converged terminals in a distribution network creates at least one sandbox for each running application on the converged terminal. The software process runs within the sandbox; the software may be downloaded from an application center or uploaded locally. File access and system state changes during software execution are redirected to the secure area of ​​the sandbox and the software kernel. After software execution, the system is rolled back or rewritten based on whether the software exhibits abnormalities. The network architecture is described in [reference needed]. Figure 1 .

[0029] The proposed sandbox-based method for software security detection in converged terminal networks includes software security isolation, anomaly detection, and system rollback processes, as follows: Figure 2 As shown. This invention utilizes the technical features of sandboxes to ensure secure software isolation and system rollback; by combining application centers and terminals, some operations are migrated to the application center, reducing the consumption of terminal hardware resources; static and dynamic detection are implemented step by step to detect some abnormal software in advance, and only sensitive system calls are analyzed in real time to reduce the amount of data analyzed and detect abnormal behavior as quickly as possible; a detection automaton is built in the application center and used on the terminal to determine abnormal behavior, resulting in fast detection speed and low terminal resource consumption. This achieves low hardware consumption, fast detection speed, and system rollback-capable software security detection on converged terminals in distribution centers. The specific software security detection method includes the following six steps:

[0030] 1. Static testing

[0031] The application center establishes a software whitelist library, WhiteLib, based on the characteristic parameters in the digital certificates of each application software. The terminal then retrieves this whitelist from the software to be detected, S. i The system extracts feature parameters from digital certificates and compares them with a whitelist database to prevent software with invalid certificates from running on converged terminals in the distribution area. The specific process is as follows:

[0032] ① Construct a whitelist: If the application software set in the application center is S = {S1, S2, ..., S...} n}, from each application software S x Digital certificate Sig(S x Extract the software serial number SID from ) x and the EnVar set of encryption parameters for digital certificates x The features that constitute this software are Cha x =(SID) x ,EnVar x The characteristics of all application software constitute the certificate feature library SigLib = {Sig(S1), Sig(S2), ..., Sig(S... n The feature set of all application software constitutes the software whitelist library.

[0033] WhiteLib={(SID1,EnVar1),(SID2,EnVar2),...,(SID n ,EnVar n The integrated terminal in the substation downloads the software certificate feature library SigLib and the software whitelist library WhiteLib from the application center, where n represents the number of application software, 1≤x≤n.

[0034] ② Calculate the test results: The converged terminal in the distribution area calculates the test results from the application software S under test. i Digital certificate Sig(S i Extracting features Cha i =(SID) i ,EnVar i If Sig(S) is satisfied at the same time i )∈SigLib and Cha i If ∈WhiteLib, then the static detection result is true, and the software under test S i If the software is certified as legitimate, proceed to step 2; otherwise, if the static test result is false, a message "Software certificate error" will be displayed, and the software will exit.

[0035] 2. Start the sandbox

[0036] First, create a new Sandbox. i Then in the Sandbox i For each certificate, the application software S is valid i The execution starts a process P i .

[0037] 3. Behavioral Feature Extraction

[0038] Collection application software S i All system calls during runtime are analyzed, and sensitive system calls are extracted to form the sensitive behavior sequence library ActSeqLib. The specific process is as follows:

[0039] ①Sandbox i Capture application software S via Hook method i Basic information about each system call C i,j =(Name i,j RV i,j VarSet i,j ) and write it to the runtime_log, where C i,j The software S represented i The j-th system call generated during runtime, Name i,j and RV i,j These represent system calls C. i,jName and return value, VarSet i,j Indicates system call C i,j The set of all parameter values;

[0040] ② The system call C i,j With the sensitive call library SCallLib = {Call1, Call2, ..., Call...} h A comparison is performed, and a call is made to each sensitive system. k =(Name k RV k ,SVar k If the system calls C i,j Not a sensitive system call, i.e., a system call Then ignore C i,j Otherwise, extract system call C. i,j System call name i,j Return value RV i,j and the set of parameter values ​​for sensitive parameters SVarSet i,j This forms a sensitive system call C' i,j =(Name i,j RV i,j ,SVarSet i,j And insert them into the sensitive behavior sequence library ActSeqLib in chronological order, where h represents the number of sensitive system calls, and Name k and RV k These represent system calls Call. k Name and return value, SVar k Indicates a system call Call k The set of sensitive parameter names among all parameters.

[0041] 4. System call redirection

[0042] In Sandbox i Internal simulation executes each system call C i,j According to system call C i,j Different types of data require different redirection methods, as detailed below:

[0043] ① When the system calls C i,j When making system calls related to files, it is necessary to access the system path P. j The file f below j If file f j For system files and system calls C i,j If the access is read-only, then the Sandbox... i Directly through path P j Access file fj If file f j For system files and system calls C i,j If the access involves a write operation, then file f will be... j Copy to Sandbox i Path P′ within the safe zone j Below, P′ j That is, P j The redirection path; if file f j For application software S i The newly created file will have path P j Redirect to SandBox i Path P′ within the safe zone j and on path P′ j Create a new file f j Subsequent work on file f j All access to the file is conducted within a secure area; if file f j For other software on the converged terminal of the distribution area a The generated files are then processed using other software. a Private key SKey a For file f j After signing, the ciphertext f′ will be... j =En(f j ,SKey a Store in Sandbox i Path P′ within the safe zone j Under, only when the system calls C i,j Access is read-only and application software S i Owns other software S a public key PKey a At that time, application software S i Only then can it be done through path P′ j and public key PKey a Accessing file f′ j Access file f after designing j =De(f′) j ,PKey a Otherwise, terminate the application software S. i The execution of the function will prompt "illegal access to data file", where the functions En() and De() represent the file's signing and designing functions, respectively.

[0044] ② When the system calls C i,j When making process-related system calls, the greatest precaution is to prevent cloning the process itself or creating a new process. First, create a new sandbox (SandBox'). i Then, according to the system call C i,jA new process P′ is created using the provided program path, command-line arguments, and environment variables. i And put it into the new Sandbox. i Run in the middle, and finally terminate the original process P. i The execution.

[0045] ③ When the system calls C i,j When an exit instruction is given, process P is terminated. i After execution, proceed to step 5 for abnormal behavior detection.

[0046] ④ When the system calls C i,j For other instructions, hardware-assisted virtualization is used to process system calls in C. i,j Redirected from the Linux system kernel to program S i It executes within the virtual kernel.

[0047] 5. Dynamic detection of abnormal behavior

[0048] The application center uses the ExpFA automaton, constructed from the ExpRuleLib library of abnormal behavior policies, to detect abnormal behavior. The terminal uses the Sandbox. i C's captured sensitive call i,j Perform dynamic detection to determine the application software S i The detection process for determining whether abnormal behavior has been identified is as follows:

[0049] ① The application center maintains the abnormal behavior policy library ExpRuleLib, which stores the system call sequence of all known abnormal behaviors. Each abnormal behavior is an ordered list of several sensitive system calls. The application center constructs the abnormal behavior detection automaton ExpFA based on the abnormal behavior policy library ExpRuleLib.

[0050] ② The integrated terminal in the distribution area downloads the abnormal behavior detection automaton ExpFA from the application center;

[0051] ③ When Sandbox i Calling a sensitive system C' i,j When added to the sensitive behavior sequence library ActSeqLib, sensitive system calls C' will be included. i,j As input to the ExpFA (Abnormal Behavior Detection Automaton), the new state of ExpFA after the state transition is calculated. If the new state is the final state of the automaton, then some sensitive system calls in the current sensitive behavior sequence library ActSeqLib have met the abnormal behavior criteria, and an error message should be displayed or the application software S should be terminated. i Otherwise, continue execution within the Sandbox. i P in i process;

[0052] ④ If process P i If the sensitive behavior sequence library ActSeqLib is empty at the end, then the application software S i This is normal software;

[0053] ⑤ If process P i If the abnormal behavior detection automaton ExpFA is still in a non-final state at the end, then the default software S... i This is normal software; it prompts for manual confirmation. If manual confirmation is required, application software S... i If the software is abnormal, it is necessary to further specify that a certain sensitive system call sequence in the sensitive behavior sequence library ActSeqLib is a new type of abnormal behavior and submit it to the application center. After receiving it, the application center will immediately update the abnormal behavior policy library ExpRuleLib and the abnormal behavior detection automaton ExpFA.

[0054] 6. System rollback

[0055] ①If application software S i If the software is detected as normal, then the Sandbox will be set. i Each file within the secure area is redirected to the corresponding path on the Linux system, and the application software S... i Operations in the virtual kernel are redirected back to the Linux kernel, all files in the secure region are deleted, and the sandbox is destroyed. i ;

[0056] ②If application software S i The software was detected as malicious; all files in the safe zone were deleted and the Sandbox was destroyed. i The Linux system of the converged terminal in the distribution area will be rolled back to the application software S. i The state before running.

[0057] Example

[0058] The security detection method in this embodiment is described in [reference]. Figure 3 The specific process is as follows: User A downloads software S1 from the application center and installs it on the integrated terminal B in the distribution area. Since it is uncertain whether software S1 contains a Trojan program, software S1 needs to undergo a security check when it runs on the integrated terminal B in the distribution area. If software S1 is normal software, it can run normally; otherwise, software S1 should be prevented from running on the integrated terminal B in the distribution area.

[0059] ① Static detection stage: First, the integrated terminal B in the substation downloads the software certificate feature library SigLib and the software whitelist library WhiteLib from the application center as the basis for static detection. Then, it extracts the software feature Cha(SID1,EnVar1) from the software's digital certificate Sig(S1), which includes the software serial number SID1 and the set of encryption feature parameters EnVar1. Finally, the comparison shows that Sig(S1)∈SigLib and Cha∈WhiteLib. Therefore, the software S1 is a software with a valid certificate and further detection is required.

[0060] ② Sandbox startup phase: Start the sandbox SandBox1 and run the process P1 of software S1 within it;

[0061] ③ Behavioral Feature Extraction Stage: If Sandbox1 captures a system call sys_open() that opens a file, with three parameters: file path path1, open flag flag1, and operation permission mode1, and the return value is of type int, then the system call C1(sys_open,int,(path1,flag1,mode1)) is written to the system call log; then, it is compared with the sensitive call library and a sensitive call C2 with the same name is found, but its sensitive parameter values ​​are file path path and operation permission mode. Therefore, system call C1 is determined to be a sensitive call. After extracting the sensitive parameters, C1 forms the corresponding sensitive system call C1'(sys_open,nt,(path1,mode1)), and C1' is inserted into the sensitive behavior sequence library ActSeqLib in chronological order.

[0062] ④ System call redirection phase: If sensitive system call C1' needs to read file f1 of software S2 under path1, it first needs to create a file f2 under path2 in the secure area of ​​SandBox1. Then, it uses the user private key SKey of software S2 to sign file f1 and copy it to file f2. Subsequently, software S1 can access the signed file f2 through the redirected path path2 and use S2's public key PKey to design and obtain the original file f1.

[0063] ⑤ Dynamic detection phase of abnormal behavior: First, the application center maintains the abnormal behavior strategy library ExpRuleLib and builds the abnormal behavior detection automaton ExpFA. Then, the converged terminal B of the station downloads the abnormal behavior detection automaton ExpFA from the application center and uses the sensitive system call C1' generated in the behavior feature extraction phase as the input of the automaton ExpFA. Then, the next state of the automaton is calculated as the final state. Finally, the dynamic detection result is obtained. The software S1 contains abnormal behavior, that is, S1 is abnormal software.

[0064] ⑥ System rollback phase: Since software S1 is abnormal software, the safe area of ​​SandBox1 is deleted, and then SandBox1 is destroyed. At this time, the system state of the converged terminal is exactly the same as before running software S1.

[0065] The embodiments described herein are merely exemplary implementations. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. These embodiments are provided to fully and completely disclose the invention and to fully convey the scope of the invention to those skilled in the art. The terminology used in the exemplary embodiments illustrated in the accompanying drawings is not intended to limit the invention. In the accompanying drawings, the same units / elements are referred to by the same reference numerals.

[0066] Unless otherwise stated, the terms used herein (including technical terms) have the common understanding meaning to those skilled in the art; in addition, it is understood that terms defined by commonly used dictionaries should be understood to have a meaning consistent with the context of their relevant field, and should not be understood to have an idealized or overly formal meaning.

Claims

1. A sandbox-based method for security detection of converged terminal software in a distribution network, characterized in that, The method specifically includes the following steps: (1) Static software testing: A whitelist is established based on the feature parameters in the digital certificate of each application software. Feature parameters are extracted from the digital certificate of the software to be tested and compared with the whitelist. If the digital certificate is invalid, the application software is prohibited from running. If the digital certificate is valid, proceed to step (2). (2) Start the sandbox: Create at least one new sandbox and start a process within the sandbox for each certificate-valid application. (3) Behavioral feature extraction: Collect all system calls made by the application software during its operation, and extract sensitive system calls to form a sensitive behavior sequence library; (4) System call redirection: Simulate the execution of each system call within the sandbox, and use different redirection methods for different types of system calls; (5) Dynamic detection of abnormal behavior: An abnormal behavior detection automaton is constructed based on an abnormal behavior policy library. This automaton dynamically detects sensitive system calls captured in the sandbox, determines whether they constitute abnormal behavior, and then uses this abnormal behavior to determine whether the application software is normal. Specifically, this includes: ① The application center maintains the abnormal behavior policy library ExpRuleLib. Each abnormal behavior is an ordered list of several sensitive system calls. The application center constructs the abnormal behavior detection automaton ExpFA based on the abnormal behavior policy library ExpRuleLib. ② The integrated terminal in the distribution area downloads the abnormal behavior detection automaton ExpFA from the application center; ③ When Sandbox i Accessing basic information of a sensitive system When added to the sensitive behavior sequence library ActSeqLib, a system call will be made. As input to the ExpFA (Exposure Automaton for Abnormal Behavior Detection), the new state of ExpFA after the state transition is calculated. If the new state is the final state of the automaton, then some sensitive system calls in the current sensitive behavior sequence library ActSeqLib have already met the abnormal behavior criteria, and an error message should be displayed or the software under test should be terminated. i Otherwise, continue execution within the Sandbox. i process P in i process; ④ If process P i If the sensitive behavior sequence library ActSeqLib is empty at the end, then the software under test S i This is normal software; ⑤ If process P i If the abnormal behavior detection automaton ExpFA is still in a non-final state at the end, then the software under test S is assumed to be in the default state. i If the software is functioning normally, manual confirmation will be prompted; if manual confirmation is required, the software under test (S) will proceed. i If it is abnormal software, it is necessary to further specify that a certain sensitive system call sequence in the sensitive behavior sequence library ActSeqLib is a new type of abnormal behavior and submit it to the application center. After receiving it, the application center will immediately update the abnormal behavior policy library ExpRuleLib and the abnormal behavior detection automaton ExpFA. (6) System rollback: If the application software is normal software, all redirects from the sandbox will be written back to the system; otherwise, the system will roll back to the state before the software ran.

2. The sandbox-based method for security detection of converged terminal software in a distribution network, as described in claim 1, is characterized in that... The specific steps of step (1) are as follows: ① The application center starts from each application software S x Digital certificate Sig(S x Extracting the software serial number and digital certificate encryption parameter set from the data constitutes the software's characteristic Cha. x The features of all application software constitute the software certificate feature library SigLib, and the feature set of all application software constitutes the software whitelist library WhiteLib. The integrated terminal in the substation downloads the certificate feature library SigLib and the software whitelist library WhiteLib from the application center. ② The converged terminal in the distribution area is tested from the software S. i Digital certificate Sig(S i Extracting features Cha i If the digital certificate Sig(S i ) and features Cha i If a software appears in both the software certificate signature library SigLib and the software whitelist library WhiteLib, the static detection result is true, and the software under test S... i If the certificate indicates that the software is legitimate, proceed to step (2); otherwise, if the static test result is false, prompt "software certificate error" and exit the software.

3. The sandbox-based method for detecting the security of converged terminal software in a distribution network, as described in claim 1, is characterized in that... The specific steps of step (3) are as follows: ①Sandbox i Capture the software under test S using a Hook method i Basic information about each system call And write it to the runtime_log; ② The system call C i,j Compare with the sensitive call library SCallLib; if the system call C... i,j If it is not a sensitive system call, then ignore the system call C. i,j Otherwise, extract system call C. i,j Sensitive information forms sensitive system calls. and system call Insert them into the sensitive behavior sequence library ActSeqLib in chronological order.

4. The sandbox-based method for security detection of converged terminal software in a distribution network, as described in claim 1, is characterized in that... The specific steps of step (4) are as follows: ① When the system calls C i,j When making system calls related to files, it is necessary to access the system path P. j The file f below j , If file f j For system files and system calls C i,j If the access is read-only, then the Sandbox... i Directly through path P j Access file f j ; If file f j For system files and system calls C i,j If the access involves a write operation, then file f will be... j Copy to Sandbox i Redirect path within the safe zone Down; If file f j Software under test S i The newly created file will have path P j Redirect to Sandbox i Paths within the safe zone and in the path Create a new file f j Subsequent work on file f j All access is conducted within a secure area; If file f j For other software on the converged terminal of the distribution area a The generated files are then processed using other software. a Private key to file f j After signing, the encrypted text Store in Sandbox i Redirecting paths within a safe zone Under, only when the system calls C i,j Access is read-only and the software under test S i Owns other software S a When the public key is obtained, the software under test S i Only through the path and public key access file Otherwise, terminate the software under test S. i The execution was successful, and a message "illegal access to data file" was displayed. ② When the system calls C i,j When dealing with process-related system calls, the greatest precaution is to prevent cloning the process itself or creating a new process. First, create a new sandbox, then adjust the system call settings accordingly. i,j The provided program path, command-line arguments, and environment variable arguments create a new process. Then run it in the new sandbox, and finally terminate the original process P. i The execution; ③ When the system calls C i,j When an exit instruction is given, process P is terminated. i After execution, proceed to step (5) for abnormal behavior detection; ④ When the system calls C i,j When it is another instruction, the system call C will be executed. i,j Redirected from the Linux system kernel to program S i It executes within the virtual kernel.

5. The sandbox-based method for security detection of converged terminal software in a distribution network, as described in claim 1, is characterized in that... The specific steps of step (6) are as follows: ①If the software under test S i If the software is detected as normal, then the Sandbox will be set. i Each file within the secure area is redirected to the corresponding path on the Linux system, and the program S... i Operations in the virtual kernel are redirected back to the Linux kernel, all files in the secure region are deleted, and the sandbox is destroyed. i ; ②If the software under test S i The software was detected as malicious; all files in the safe zone were deleted and the Sandbox was destroyed. i The Linux system of the converged terminal in the distribution area will be rolled back to the software S. i The state before running.

6. A converged terminal device for distribution areas, comprising a memory, a processor, and a program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 5.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

Images