A method and system for intelligently monitoring the running state of a collection terminal, and a storage medium

Abstract

The application belongs to the field of safety, and particularly relates to a kind of collection terminal operating state intelligent monitoring method and system and storage medium, specifically, for target monitoring process loading seccomp-bpf filter, and mounting the kernel state eBPF probe program for context monitoring;System call that completely matches whitelist rule is released;System call that violates whitelist rule is blocked and recorded as a blocking event;For system call identification matching but parameter and the parameter mask do not completely match, or key system call that is marked as needing depth detection, trigger kernel state eBPF probe program execution;In a monitoring period, according to the number of accumulated blocking events and the number of suspicious behaviors, the risk index of the current security state of the power collection terminal is calculated by a predetermined weighting function.

Description

Technical Field

[0001] This application belongs to the field of security, and in particular relates to a method and system for intelligent monitoring of the operating status of a data acquisition terminal, and a storage medium. Background Technology

[0002] With the rapid development of smart grids and the Internet of Things (IoT) for power, power data acquisition terminals, as key devices connecting the user side and the power grid master station, are being deployed on an increasingly large scale and in increasingly complex environments. These terminals are responsible for core businesses such as electricity metering, data acquisition, and remote control, serving as the peripheral nerves of the power grid's sensing and control system. Due to their large number, geographically dispersed locations, diverse operating environments, and increasing exposure to open network environments, power data acquisition terminals have become a significant target for cyberattacks. Attacks on such embedded devices, such as malicious code injection, firmware tampering, and unauthorized privilege escalation, can not only cause user data leaks or electricity bill losses but may also affect the stable operation of local power grids, posing a serious threat to the security of the power system. However, power data acquisition terminals are typically resource-constrained embedded systems with limited computing power, memory, and storage space, making it difficult to deploy resource-intensive, heavyweight security protection software. Among existing security protection technologies for embedded devices, host behavior-based intrusion detection is a mainstream method. One common technique is to detect anomalies by monitoring the system call sequence of applications. For example, a whitelist of legitimate system calls can be established in advance through static analysis or dynamic learning, and system calls of processes can be filtered at runtime. However, whitelisting mechanisms based on system call identifiers are coarse-grained and cannot effectively constrain system call parameters. Attackers can exploit legitimate system calls with maliciously crafted parameters to bypass detection, resulting in a high false negative rate. Another approach is to use debugging mechanisms like ptrace to perform in-depth analysis of every system call made by a process. While this can obtain complete call parameters and call chain information, greatly improving detection accuracy, the process of entering the kernel and then switching back to tracing the process for each system call incurs significant performance overhead, which is unacceptable for power data acquisition terminals that require real-time business operations. Therefore, existing technical solutions often struggle to achieve an effective balance between monitoring granularity and system performance overhead. Summary of the Invention

[0003] To address the aforementioned problems, in a first aspect of this invention, a method for intelligent monitoring of the operating status of a data acquisition terminal is proposed, comprising the following steps: Offline analysis of the legitimate execution paths of applications within power acquisition terminals is conducted using a combination of static code analysis and dynamic sandbox operation to construct a whitelist rule set and a legitimate call chain hash library. The whitelist rule set includes system call identifiers and parameter masks used to limit parameters, while the legitimate call chain hash library stores structured hash values ​​generated by system call chains in the legitimate execution paths. Load the seccomp-bpf filter based on the whitelist rule set for the target monitoring process, and mount the kernel-mode eBPF probe program for context monitoring; System calls that fully match the whitelist rules are allowed to proceed; system calls that violate the whitelist rules are blocked and recorded as a blocking event; for system calls whose identifiers match but whose parameters do not fully match the parameter mask, or which are marked as critical system calls requiring in-depth detection, the kernel-mode eBPF probe program is triggered to perform the following operations: directly obtain the complete call chain of the current system call in kernel space, calculate its structured hash value, and compare it with the legitimate call chain hash library; if the hash value is not in the library, it is determined to be a suspicious behavior, and the execution of this system call is immediately terminated and recorded; if the hash value matches, the system call is allowed to continue execution; Within a monitoring cycle, the risk index of the current security status of the power acquisition terminal is calculated using a preset weighting function based on the cumulative number of blocking events and suspicious behaviors.

[0004] In a second aspect of the present invention, an intelligent monitoring system for the operating status of a data acquisition terminal is proposed, comprising the following modules: The analysis module is used for offline analysis of the legitimate execution paths of applications within the power acquisition terminal. It employs a combination of static code analysis and dynamic sandbox operation to construct a whitelist rule set and a legitimate call chain hash library. The whitelist rule set includes system call identifiers and parameter masks used to limit parameters, while the legitimate call chain hash library stores structured hash values ​​generated by the system call chains in the legitimate execution paths. The configuration module is used to load the seccomp-bpf filter based on the whitelist rule set for the target monitoring process and to mount the kernel-mode eBPF probe program for context monitoring. The monitoring module is used to allow system calls that fully match the whitelist rules; block system calls that violate the whitelist rules and record them as a blocking event; for system calls whose identifiers match but whose parameters do not fully match the parameter mask, or which are marked as critical system calls requiring in-depth detection, the kernel-mode eBPF probe program is triggered to perform the following operations: directly obtain the complete call chain of the current system call in kernel space, calculate its structured hash value, and compare it with the legal call chain hash library; if the hash value is not in the library, it is determined to be a suspicious behavior, and the execution of the current system call is immediately terminated and recorded; if the hash value matches, the system call is allowed to continue execution; The risk calculation module is used to calculate the risk index of the current security status of the power acquisition terminal within a monitoring cycle based on the cumulative number of blocking events and suspicious behaviors, using a preset weighting function.

[0005] In a third aspect of the invention, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the method described in the first aspect.

[0006] This invention provides accurate and reliable behavioral benchmarks for online monitoring by building a whitelist and a legitimate call chain hash library offline. During the online monitoring phase, a seccomp-bpf filter is used for efficient initial filtering of system calls, directly blocking explicit violations and quickly allowing normal behavior, ensuring low monitoring overhead and real-time performance. For suspicious calls with only abnormal parameters, deep detection is performed. By comparing call chain hash values, complex attacks such as control flow hijacking constructed using legitimate system calls can be identified, significantly improving the depth and accuracy of detection. This two-stage monitoring approach, combining coarse-grained filtering and fine-grained deep detection, effectively balances monitoring performance and security. By using a weighting function to quantify discrete security events into a unified risk index, a holistic and accurate assessment of the terminal's security status is achieved, avoiding the bias caused by isolated alerts. Attached Figure Description

[0007] Figure 1 A flowchart of a specific embodiment; Figure 2 A diagram illustrating the calculation of the risk index. Detailed Implementation

[0008] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0009] See Figure 1 The method for intelligent monitoring of the operating status of a data acquisition terminal, as shown, includes the following steps: Step 1: Analyze the legitimate execution paths of the application within the power acquisition terminal offline. Use a combination of static code analysis and dynamic sandbox operation to construct a whitelist rule set and a legitimate call chain hash library. The whitelist rule set includes system call identifiers and parameter masks used to limit parameters. The legitimate call chain hash library stores structured hash values ​​generated by the system call chains in the legitimate execution paths. Static code analysis was performed on the target binary program of the power acquisition terminal using reverse engineering tools such as IDA Pro or Ghidra. By constructing a control flow graph (CFG), all potential system call instructions and their contexts were extracted, and hard-coded parameters such as fixed file paths and port numbers were identified as the basis for parameter masks. For dynamic loading or indirect call scenarios that were difficult to cover by static analysis, dynamic fuzzing tests were performed in QEMU or a customized simulation sandbox. By injecting test cases covering boundary conditions into the application, the actual runtime system call sequence was recorded, which not only supplemented the omissions of static analysis but also confirmed the parameter value range of system calls. Based on the above analysis results, a fine-grained whitelist rule set was constructed. This rule set not only included the allowed system call numbers but also defined parameter constraint masks. For example, for openat calls, the mask required that the path to the opened file must be located in a specific directory such as / etc / config / or a specific file descriptor; for ioctl calls, the allowed command words were restricted. These rules were compiled into a bitmap or binary tree structure for easy matching by subsequent filters. For each legitimate system call point, static analysis is used to trace its predecessor nodes in the function call stack (i.e., parent functions, grandparent functions, etc.) to extract the relative offset addresses of each level of function in the call stack, thus avoiding the influence of ASLR address randomization. The relative offset address sequences are combined, and a unique structured hash value is calculated using algorithms such as CRC32 or MurmurHash. All hash values ​​generated from legitimate paths are stored in a hash table based on an eBPF Map format compatible with, serving as a baseline database for runtime integrity verification.

[0010] Step 2: Load the seccomp-bpf filter based on the whitelist rule set into the target monitoring process, and attach the kernel-mode eBPF probe program for context monitoring. A loader is written in user space to compile the whitelist rule set generated in step one into BPF bytecode using the libseccomp library. By injecting pre-loading code before the target monitoring process starts, or by modifying the process's startup logic, the compiled BPF filter is loaded into the target process's kernel structure by calling the `prctl(PR_SET_SECCOMP,SECCOMP_MODE_FILTER,...)` interface. The filter acts as the first line of defense, returning `SECCOMP_RET_ERRNO` or `SECCOMP_RET_KILL` for explicitly illegal system calls, `SECCOMP_RET_ALLOW` for legal calls with simple parameters, and allowing critical calls requiring deep detection, such as `execve` and `mprotect`, but marking the context for subsequent eBPF probe intervention.

[0011] A kernel-mode probe program based on eBPF (Extended BPF) is attached to a system call entry point, such as sys_enter or the entry function of a specific system call, using kprobe or tracepoint. When loading the eBPF program, it is compiled into eBPF bytecode using Clang / LLVM and injected into the kernel via the bpf() system call. Simultaneously, multiple eBPF Maps are created in kernel space: one BPF_MAP_TYPE_HASH stores the hash library of valid call chains generated in step one, and another BPF_MAP_TYPE_PERCPU_ARRAY records statistical data on blocked and suspicious events in real time.

[0012] To ensure that eBPF probes only affect the target power acquisition process, the probe program must include PID / TGID filtering logic. This can be achieved by dynamically maintaining a list of monitored process PIDs in the eBPF Map. Whenever a system call is triggered, the probe first checks if the current context's `bpf_get_current_pid_tgid()` function is in the monitoring list. If a match is found, subsequent deep detection logic is activated; otherwise, the probe operation terminates directly to minimize the impact on overall system performance.

[0013] Step 3: Allow system calls that fully match the whitelist rules; block system calls that violate the whitelist rules and record them as a blocking event; for system call identifiers that match but whose parameters do not fully match the parameter mask, or for system calls marked as critical system calls requiring deep detection, trigger the kernel-mode eBPF probe program to perform the following operations: directly obtain the complete call chain of the current system call in kernel space, calculate its structured hash value, and compare it with the legitimate call chain hash library; if the hash value is not in the library, it is determined to be a suspicious behavior, and the execution of this system call is immediately terminated and recorded; if the hash value matches, the system call is allowed to continue execution; When a target process initiates a system call, the Seccomp filter processes it in the kernel first. For requests that fully match the whitelist (i.e., the system call number matches and the parameters pass the mask verification), Seccomp directly returns Allow, and the system call executes normally. For violations of basic rules, such as attempting to execute an unauthorized socket call, Seccomp directly blocks the call, sends a log to the user-space audit daemon, and increments a counter.

[0014] For requests marked as critical system calls or requiring fuzzy matching of parameters, such as `execve` executing a shell script, after Seccomp allows the request, the eBPF probe mounted at the same point immediately captures the execution flow. The eBPF program calls the `bpf_get_stackid()` helper function or manually traverses the `pt_regs` register structure to obtain mixed backtrace information of the current kernel stack and user stack. The program strips the absolute memory addresses from the stack frames, retaining only the offsets relative to the code segment base address, thereby generating a standardized call chain sequence.

[0015] The eBPF program calculates the hash value of the sequence in real time in kernel mode and uses the `bpf_map_lookup_elem` instruction to perform an O(1) lookup in the valid call chain hash library Map. If the lookup fails, it indicates that although the system call itself is valid, its call path is abnormal, possibly due to a ROP attack or an illegal jump. The eBPF program will terminate the process directly using `bpf_send_signal(SIGKILL)`, or use `bpf_override_return` to tamper with the system call return value to an error code, while simultaneously reporting detailed attack stack information via the Ring Buffer. If the lookup succeeds, the probe exits silently, allowing the system call to continue to be processed by the kernel.

[0016] Step 4: Within a monitoring cycle, the risk index of the current security status of the power acquisition terminal is calculated using a preset weighting function based on the cumulative number of blocking events and suspicious behaviors.

[0017] Deploy a lightweight security daemon in user space and set a monitoring period, for example, every 60 seconds. The daemon periodically reads the accumulated counter values ​​in the kernel-space eBPF Map via bpf_map_lookup_elem. The counters are divided into two categories: the number of illegal calls directly blocked by Seccomp. and the number of call chain exceptions detected by eBPF Preset blocking weight Such as 0.5 and suspicious behavior weight For example, in 5.0, in one embodiment, the calculation formula is: ,in Using historical decay factors or environmental sensitivity coefficients, the above formula ensures that high-risk ROP attacks can rapidly increase the risk index, while occasional accidental interceptions will only produce lower risk values.

[0018] In an optional embodiment, the construction of the whitelist rule set specifically involves: For each legitimate system call of the application, analyze the value range of its key security parameters, and generate corresponding bitmasks for parameters with constant or enumerable values; for pointer-type parameters, analyze the legality characteristics of the content they point to, and generate content-based deep filtering rules.

[0019] For numeric and flag-type parameters, such as `flags` in `open` calls, `prot` permissions in `mmap`, and `cmd` in `ioctl`, static analysis is used to extract macro definitions and constant values ​​from the source code to construct a strict bitmap mask. For example, if a file descriptor only allows read operations, the generated rules require that the parameter `flags&O_ACCMODE` must be strictly equal to `O_RDONLY`; if combined flags are allowed, bitwise AND operations are used to verify whether the parameter contains unauthorized bits, such as `arg&~(ALLOWED_MASK)==0`. For enumerated type parameters, such as `protocol` in `socket`, a list of allowed values ​​is established and compiled into a series of comparison jump instructions, such as `JNE`, when generating BPF instructions.

[0020] For pointer type parameters, such as file path string pointers and network structure pointers, since Seccomp's native filtering cannot dereference pointers, deep detection rules on the eBPF side are used. The analysis tool automatically extracts valid path prefixes, such as / var / log / app / , and key member values ​​within the structure, such as the port number in sockaddr_in. These constraints are then transformed into triple rule descriptions of "offset-length-value". For example, for a file path: "Reading the first N bytes of memory pointed to by the pointer must match a preset whitelist path prefix". These rules are serialized and loaded into the kernel's eBPF Map.

[0021] In an optional embodiment, the generation of the structured hash value specifically involves: Obtain N consecutive return addresses from the topmost stack frame back up in the user-mode call stack when the system call occurs. Concatenate the N address values ​​into a byte sequence in order, and apply the SHA-256 hash algorithm to the sequence to generate a 32-byte hash value as the structured hash value, where N is a preset integer.

[0022] To overcome the disruption of address fixity caused by address space layout randomization, address normalization is performed after obtaining the return address stack. The system reads the memory mapping table ` / proc / pid / maps` of the current process to obtain the loaded dynamic link library `.so` and the base address of the main program. The absolute virtual address in the stack frame is subtracted from the base address of its respective module to calculate the relative offset relative to the start of the module's code segment. This relative offset remains constant across different execution orders. A backtracking depth N is set, for example, N=5, covering the critical path from the current function to the entry function. The extracted N 64-bit relative offsets are concatenated in the call order to obtain a binary buffer of length N×8 bytes. The OpenSSL library or the kernel's built-in encryption API is called to perform the SHA-256 algorithm on this buffer, generating a 32-byte digest. To improve runtime lookup efficiency, in one embodiment, the first 8 or 16 bytes of the hash value are extracted as an index key and stored in a Bloom filter or hash table to quickly determine whether the call path exists in the whitelist.

[0023] In an optional embodiment, the kernel-mode eBPF probe program performs the following operations: By using the eBPF helper functions provided by the kernel, the register state and user space memory data of the target process can be read directly without interrupting the execution of the target process or performing process context switching, thereby obtaining system call parameters and context information.

[0024] Specifically, using the context access interface provided by eBPF, register values ​​are extracted from the `struct pt_regs` structure passed from the kernel to the mount point. Based on the calling convention of the target CPU architecture, the corresponding registers are read to obtain system call parameters. For example, on the ARM64 architecture, registers X0 to X5 are read to obtain the first six parameters; on the x86_64 architecture, registers such as RDI, RSI, and RDX are read. Since the eBPF program runs in JIT-compiled native machine code within the kernel context, this process does not require pausing the process and incurs no overhead from switching between user mode and kernel mode. Auxiliary functions such as `bpf_probe_read_user()` or `bpf_probe_read_user_str()` are used to read user space memory. When the parameter is a pointer, such as the buffer pointer of a `write` call, the probe program copies the actual user space data to the eBPF stack space or the per-CPU array map based on the address value in the register. The above operations are performed under the protection of page table mapping; the kernel automatically handles page faults or invalid address accesses, and even reading illegal addresses will not cause a system crash.

[0025] In an optional embodiment, obtaining the complete call chain of the current system call directly in kernel space specifically involves: The kernel-mode stack backtracking helper function is invoked to extract the instruction pointer sequence of the user-mode stack based on the stack frame information maintained by the kernel or ORC / DWARF debugging information, thereby obtaining a series of return addresses that constitute a complete call chain.

[0026] Specifically, the eBPF program calls the helper functions bpf_get_stackid() or bpf_get_stack() to quickly traverse the kernel and user stacks of the current thread using the Linux kernel's built-in unwinder, based on the frame pointer register chain preserved at compile time, or, in newer kernel versions, ORC (Orc Reversible Unwinder) metadata. bpf_get_stack directly writes the extracted 64-bit instruction addresses into a pre-allocated BPF Map buffer. To save kernel space and accelerate alignment, the probe program does not perform symbol resolution in kernel mode, but instead uses these raw addresses or ASLR-corrected offsets as feature data. If the call chain is too deep and exceeds the buffer limit (e.g., 512 bytes), the eBPF program truncates the lowest stack frame, prioritizing the most recent N-level call relationships.

[0027] See Figure 2 In an optional embodiment, the risk index of the current safety status of the power acquisition terminal is calculated using a preset weighting function, and the calculation formula is as follows: Where R is the risk index; N_b is the cumulative number of blocking events during the monitoring period; N_s is the cumulative number of suspicious behaviors during the monitoring period; w_b and w_s are the preset weights of blocking events and suspicious behaviors, respectively; and T is the preset risk threshold.

[0028] The data acquisition layer periodically reads and clears two counters from the kernel eBPF Map via atomic operations: the number of times the data was directly intercepted by Seccomp. Number of path hash verification failures , This represents scanning behavior or low-level attack attempts, while This represents advanced attacks that bypass initial filtering but exhibit logical inconsistencies, such as code reuse attacks. The weights are usually set much higher than ,For example , .

[0029] When the number of weighted attacks is much less than T, the exponential part is a large positive number, the denominator is extremely large, and the risk value R approaches 0. When the accumulated attack behavior approaches T, R will rise rapidly to around 50 in an S-shaped curve; Once the attack intensity exceeds T, the exponent becomes negative, the denominator approaches 1, and R quickly saturates to 100.

[0030] In an optional embodiment, the legitimate execution path of the application within the offline power acquisition terminal specifically includes: Static analysis is performed on the binary file of the business program of the power acquisition terminal to extract the control flow graph, identify all possible function call relationships and system call points, and generate a set of static legal paths. In a sandbox environment that is consistent with the real operating environment, run all business programs of the power acquisition terminal, execute the comprehensive functional test set, and use dynamic analysis tools to record the execution path. The path set generated by static analysis is merged with the path set of dynamic execution records to remove duplicates, eliminate unreachable paths, and generate legal execution paths.

[0031] Using the scripting interface of IDA Pro or Ghidra, traverse all code segments of the binary file. Starting from the main function and all exported interfaces, recursively construct the function call graph. For each identified system call instruction, such as SVC or SYSCALL, record the call hierarchy of its associated function. For paths where indirect jumps are uncertain, mark them as pending nodes and infer possible jump targets using heuristic algorithms or taint analysis. Place the business program in a QEMU full-system simulator or controlled device, load all test cases, including unit tests, integration tests, and fuzz tests. Using strace, perf, or a custom QEMU plugin, record all system calls and their exact call stack snapshots during actual program runtime, and parse dynamic library loading and polymorphic function calls that cannot be determined in static analysis.

[0032] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for intelligent monitoring of the operating status of a data acquisition terminal, characterized in that, Includes the following steps: Offline analysis of the legitimate execution paths of applications within power acquisition terminals is conducted using a combination of static code analysis and dynamic sandbox operation to construct a whitelist rule set and a legitimate call chain hash library. The whitelist rule set includes system call identifiers and parameter masks used to limit parameters, while the legitimate call chain hash library stores structured hash values ​​generated by system call chains in the legitimate execution paths. Load the seccomp-bpf filter based on the whitelist rule set for the target monitoring process, and mount the kernel-mode eBPF probe program for context monitoring; System calls that fully match the whitelist rules are allowed to proceed; system calls that violate the whitelist rules are blocked and recorded as a blocking event; for system calls whose identifiers match but whose parameters do not fully match the parameter mask, or which are marked as critical system calls requiring in-depth detection, the kernel-mode eBPF probe program is triggered to perform the following operations: directly obtain the complete call chain of the current system call in kernel space, calculate its structured hash value, and compare it with the legitimate call chain hash library; if the hash value is not in the library, it is determined to be a suspicious behavior, and the execution of this system call is immediately terminated and recorded; if the hash value matches, the system call is allowed to continue execution; Within a monitoring cycle, the risk index of the current security status of the power acquisition terminal is calculated using a preset weighting function based on the cumulative number of blocking events and suspicious behaviors.

2. The method according to claim 1, characterized in that, The set of rules for constructing the whitelist is specifically as follows: For each legitimate system call of the application, analyze the value range of its key security parameters, and generate corresponding bitmasks for parameters with constant or enumerable values; for pointer-type parameters, analyze the legality characteristics of the content they point to, and generate content-based deep filtering rules.

3. The method according to claim 2, characterized in that, The generation of the structured hash value is specifically as follows: Obtain N consecutive return addresses from the topmost stack frame back up in the user-mode call stack when the system call occurs. Concatenate the N address values ​​into a byte sequence in order, and apply the SHA-256 hash algorithm to the sequence to generate a 32-byte hash value as the structured hash value, where N is a preset integer.

4. The method according to claim 1, characterized in that, The kernel-mode eBPF probe program performs the following operations: By using the eBPF helper functions provided by the kernel, the register state and user space memory data of the target process can be read directly without interrupting the execution of the target process or performing process context switching, thereby obtaining system call parameters and context information.

5. The method according to claim 4, characterized in that, The process of directly obtaining the complete call chain of the current system call in kernel space is as follows: The kernel-mode stack backtracking helper function is invoked to extract the instruction pointer sequence of the user-mode stack based on the stack frame information maintained by the kernel or ORC / DWARF debugging information, thereby obtaining a series of return addresses that constitute a complete call chain.

6. The method according to claim 1, characterized in that, The risk index of the current safety status of the power acquisition terminal is calculated using a preset weighting function. The calculation formula is as follows: Where R is the risk index; This refers to the cumulative number of blocking events within the monitoring period; This refers to the cumulative number of suspicious behaviors during the monitoring period. and These are the preset weights for blocking events and suspicious behaviors, respectively; T is the preset risk threshold.

7. The method according to any one of claims 1-6, characterized in that, The legal execution paths of the application within the offline power acquisition terminal specifically include: Static analysis is performed on the binary file of the business program of the power acquisition terminal to extract the control flow graph, identify all possible function call relationships and system call points, and generate a set of static legal paths. In a sandbox environment that is consistent with the real operating environment, run all business programs of the power acquisition terminal, execute the comprehensive functional test set, and use dynamic analysis tools to record the execution path. The path set generated by static analysis is merged with the path set of dynamic execution records to remove duplicates, eliminate unreachable paths, and generate legal execution paths.

8. An intelligent monitoring system for the operating status of a data acquisition terminal, characterized in that, Includes the following modules: The analysis module is used for offline analysis of the legitimate execution paths of applications within the power acquisition terminal. It employs a combination of static code analysis and dynamic sandbox operation to construct a whitelist rule set and a legitimate call chain hash library. The whitelist rule set includes system call identifiers and parameter masks used to limit parameters, while the legitimate call chain hash library stores structured hash values ​​generated by the system call chains in the legitimate execution paths. The configuration module is used to load the seccomp-bpf filter based on the whitelist rule set for the target monitoring process and to mount the kernel-mode eBPF probe program for context monitoring. The monitoring module is used to allow system calls that fully match the whitelist rules; block system calls that violate the whitelist rules and record them as a blocking event; for system calls whose identifiers match but whose parameters do not fully match the parameter mask, or which are marked as critical system calls requiring in-depth detection, the kernel-mode eBPF probe program is triggered to perform the following operations: directly obtain the complete call chain of the current system call in kernel space, calculate its structured hash value, and compare it with the legal call chain hash library; if the hash value is not in the library, it is determined to be a suspicious behavior, and the execution of the current system call is immediately terminated and recorded; if the hash value matches, the system call is allowed to continue execution; The risk calculation module is used to calculate the risk index of the current security status of the power acquisition terminal within a monitoring cycle based on the cumulative number of blocking events and suspicious behaviors, using a preset weighting function.

9. The system according to claim 8, characterized in that, The set of rules for constructing the whitelist is specifically as follows: For each legitimate system call of the application, analyze the value range of its key security parameters, and generate corresponding bitmasks for parameters with constant or enumerable values; for pointer-type parameters, analyze the legality characteristics of the content they point to, and generate content-based deep filtering rules.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-7.

Images