Firmware-level security protection system and method for industrial automation device hard disks

Abstract

The application discloses a firmware-level security protection system and method for an industrial automation device hard disk, and particularly relates to the technical field of storage security protection, and is used for solving the problem of firmware abnormal tampering; the application collects instruction calls, interface accesses and interrupt time stamps in a sliding window, constructs a behavior sequence set containing instruction sequences, call frequencies and sensitive markers, and compares the behavior sequence set with a reference sequence library; based on a transfer relationship and an offset index, a firmware-level determination of operation abnormality, access out-of-bound and tampering risk is triggered; the firmware is divided into control domains, data domains and configuration domains; minimum authority and dynamic isolation are realized by relying on state and authority mapping, authority registers and interface shielding; protected segmented integrity verification and local copy hot switching are combined; a process of detection, isolation and recovery is formed; abnormal writing is performed in a protected cycle log area for threshold updating; and the overall tamper resistance, operation safety and maintainability of the firmware are improved.

Description

Technical Field

[0001] This invention relates to the field of storage security protection technology, and more specifically, to a firmware-level security protection system and method for hard drives in industrial automation equipment. Background Technology

[0002] With the development of the Industrial Internet and intelligent manufacturing, industrial automation equipment is increasingly becoming an important component of critical infrastructure systems. Its operating status, process logic, and control commands are highly dependent on firmware, parameters, and real-time data stored in the storage medium. Typically, the hard drives or solid-state storage devices integrated within these devices are used to host the control system operating system, equipment operation logs, configuration files, and critical control firmware. However, in real-world deployment environments, industrial automation equipment often operates in edge scenarios with network isolation or limited connectivity. The long maintenance cycles and weak online upgrade capabilities result in embedded hard drive firmware remaining in a "fixed" state for extended periods.

[0003] The shortcomings of existing technologies: Current industrial automation equipment generally relies on embedded hard drives to store critical system and control information, but there is still a lack of effective runtime security protection mechanisms at the firmware level. Most technologies only perform static signature verification during the device startup phase, which cannot identify latent or delayed-triggered attack behaviors during operation. This means that once the firmware is tampered with, it will remain undetected for a long time. At the same time, traditional solutions have not established an anomaly identification mechanism and permission isolation strategy based on behavioral characteristics. The repair path after firmware anomalies depends on manual or external system intervention, and lacks the ability to self-verify and self-recover during operation, making it difficult to meet the actual needs of industrial sites for high availability and security controllability. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the present invention provides a firmware-level security protection system and method for hard drives of industrial automation equipment, so as to solve the problem of abnormal firmware tampering in the above-mentioned background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] Firmware-level security protection methods for hard drives in industrial automation equipment include the following steps:

[0007] Collect hard drive firmware access behavior data of industrial automation equipment during operation, construct a behavior sequence set including instruction sequence, call frequency and sensitive area access markers, and identify the operating state that deviates from the normal mode by comparing behavior sequences;

[0008] Based on the behavior comparison results, an anomaly identification mechanism is triggered to determine whether the current firmware has any operational anomalies, access violations, or tampering risks.

[0009] The hard disk firmware is divided into control domain, data domain and configuration domain. Permission mapping rules are established, and access permission adjustment policies are executed based on the anomaly identification results to restrict access to the control domain and configuration domain in abnormal states, and only read-only access is retained.

[0010] The firmware integrity verification process is executed to check the running status of the current firmware version. If the verification fails, the local firmware copy switching process is started to complete the firmware replacement and loading.

[0011] After the switch is completed, abnormal behavior information is recorded and stored in the firmware log area for later use when the abnormal identification threshold is updated.

[0012] In a preferred embodiment, access behavior data of the hard disk firmware during the operation of industrial automation equipment is collected to construct a behavior sequence set containing instruction sequences, call frequencies, and sensitive area access markers. The specific process is as follows:

[0013] Set the sampling period and sliding time window, and obtain the instruction call record, interface access record and interrupt event timestamp generated by the firmware from the hard disk controller within each time window;

[0014] Extract the instruction identifier, access address, interface type, and timestamp for each record;

[0015] The access address is compared with the preset sensitive area address table and a sensitive area access mark is generated. The number of times each instruction is called within the window, the interval between adjacent calls, and the length of continuous triggering are counted to form the call frequency parameter.

[0016] The instruction identifier, call frequency parameter, and sensitive area access mark are combined into a behavior unit in chronological order, and a behavior sequence set is formed by sliding the window.

[0017] In a preferred embodiment, the operating state deviating from the normal pattern is identified by comparing behavioral sequences, and the specific process is as follows:

[0018] Establish a normal operation reference sequence library. The reference sequence is composed of behavioral units within the historical stable window in chronological order and records the transfer relationship between adjacent instructions.

[0019] The behavior sequence of the current time window is standardized and sliced ​​into segments of a preset length, and each slice is aligned with the reference sequence.

[0020] Based on the alignment results, the offset indicators are statistically analyzed. The offset indicators include at least the number of times unregistered instructions appear, the number of times sensitive area access markers appear, the number of times adjacent instruction transfers do not match, and the number of consecutive repeated trigger length exceeding the limit.

[0021] In a continuous window, when any offset indicator reaches a preset offset threshold or an instruction transfer chain not included in the reference sequence library is detected, the current running state is determined to be deviating from the normal mode and an abnormality flag is output.

[0022] In a preferred embodiment, an anomaly detection mechanism is triggered based on the behavior comparison results to determine whether the current firmware has any operational anomalies, access violations, or tampering risks. The specific process is as follows:

[0023] Establish an anomaly identification rule set, which is classified and managed into three categories: operation anomaly, access violation, and tampering risk. Trigger conditions and continuous window counting thresholds are set for each type of rule.

[0024] For operational anomalies, detect the occurrence of illegal or disabled commands, command sequence conflicts, interface call timeouts, and exceeding the limit for the number of abnormal retries. Record the operational anomaly event as soon as any of these events occurs.

[0025] For out-of-bounds access, the current access address, access length and target area attributes are checked according to the address range mapping table and the area permission table. Cross-area write, out-of-bounds DMA transfer or unauthorized write to restricted areas are detected. If any of these are detected, the out-of-bounds access event is recorded.

[0026] To mitigate tampering risks, integrity digest verification is performed on the protected segments of the firmware image, and changes in the control register lock bit state, attempts to write to the boot segment, or signature verification failures are monitored. Any such occurrence results in a tampering risk event being recorded.

[0027] When any type of event is triggered within a single time window, or when the count of the same type of event reaches a preset count threshold within a continuous time window, an anomaly identifier containing an anomaly category label is generated.

[0028] In a preferred embodiment, the hard disk firmware is divided into a control domain, a data domain, and a configuration domain, and permission mapping rules are established. The specific process is as follows:

[0029] A domain descriptor table is generated based on the address range and functional boundaries of the firmware image. The domain descriptor table records the domain identifier, start and end addresses, included modules, and sensitivity level.

[0030] Set permission bit sets and command whitelists for each domain. Permission bits should at least include read, write, execute, update and manage.

[0031] Establish a mapping table between running status and permissions. The running status should include at least normal, restricted, read-only and frozen states.

[0032] When an exception flag is received, the target permission set is retrieved from the running status and permission mapping table according to the exception category, and enabled through the control register and interface masking table. Specifically, this includes setting the read-only lock, disabling erase and write commands, masking cross-domain writes, and closing the debug update interface.

[0033] Establish a cross-domain access gateway to perform source domain verification, destination address verification, and parameter length verification on access requests from outside the local domain. Requests that fail the verification are rejected and logged.

[0034] Write the permission change log and set a rollback flag when permissions are changed, so that the default permissions can be restored according to the running status and permission mapping table after the exception is resolved.

[0035] In a preferred embodiment, an access control adjustment policy is executed based on the anomaly identification result, and the specific process is as follows:

[0036] Retrieve the target permission status from the runtime status and permission mapping table based on the exception category;

[0037] For abnormal operations, the configuration domain is switched to a restricted state and write is prohibited; for access out of bounds or tampering risks, the control domain and configuration domain are switched to a read-only state or a frozen state.

[0038] Permission changes are issued synchronously through the permission control register and the interface mask table, and permission change logs are recorded.

[0039] In a preferred embodiment, the firmware integrity verification process includes:

[0040] The firmware segment to be verified is determined based on the domain descriptor table, and the factory notarized value of each segment is read. The notarized value includes hash value or digital signature.

[0041] Calculate message digests for the corresponding segments of the currently running firmware within the verification window;

[0042] The notarized value is verified using the public or private key stored in the root of trust area and compared with the message digest for consistency. The verification result is determined by combining the write protection bit of the control register, the boot lock bit, and the status of the version counter.

[0043] Output a verification failure flag when any segment fails verification or the protection bit is abnormal.

[0044] In a preferred embodiment, the local firmware copy switching process includes:

[0045] Suspend unnecessary write requests and refresh the cache queue in read-only or frozen state;

[0046] Read the identifier and version information of the target copy from the protected copy storage area, and perform integrity verification on the copy;

[0047] When the verification passes, the boot selection flag is set and the boot vector is remapped, pointing the execution entry point to the replica entry address;

[0048] Load the initialization parameters and key handle required for the copy, trigger a soft reset or restart the firmware execution thread to complete the hot switch;

[0049] After the switchover is complete, the read-only restriction on the data domain is lifted and the protection state of the control domain is maintained. When the replica verification fails, the data domain is kept in a frozen state and a replica switchover failure alarm is output.

[0050] In a preferred embodiment, recording abnormal behavior information and storing it in the firmware log area includes setting a write-protected circular log area within the firmware image, writing timestamps, abnormal categories, trigger rule identifiers, target domain identifiers, and handling results in chronological order of events, and attaching a sequence number and summary verification to each record. When the capacity reaches a threshold, it is overwritten in a first-in-first-out manner, and a read-only query interface is provided for updating the abnormal identification threshold.

[0051] A firmware-level security protection system for hard drives in industrial automation equipment, used to implement the aforementioned firmware-level security protection methods for hard drives in industrial automation equipment, including:

[0052] The hard disk status identification module is used to collect access behavior data of hard disk firmware during the operation of industrial automation equipment, construct a behavior sequence set including instruction sequence, call frequency and access markers of sensitive areas, and identify the operating status that deviates from the normal mode by comparing behavior sequences.

[0053] The anomaly detection module is used to trigger the anomaly identification mechanism based on the behavior comparison results to determine whether the current firmware has any operational anomalies, access out-of-bounds risks, or tampering risks.

[0054] The identification result execution module is used to divide the hard disk firmware into control domain, data domain and configuration domain, establish permission mapping rules, execute access permission adjustment policies according to the abnormal identification results, restrict access to the control domain and configuration domain in abnormal state, and retain only read-only access function;

[0055] The execution verification module is used to perform the firmware integrity verification process, detect the running status of the current firmware version, and if the verification fails, start the local firmware copy switching process to complete the firmware replacement and loading.

[0056] The abnormal information storage module is used to record abnormal behavior information and store it in the firmware log area after the switch is completed, so that it can be called when the abnormal identification threshold is updated.

[0057] The technical effects and advantages of this invention are as follows:

[0058] This invention collects instruction call records, interface access records, and interrupt event timestamps from hard disk firmware within a sliding time window. It constructs a behavior sequence set, including instruction sequences, call frequencies, and sensitive area access markers, in chronological order. This set is compared with a normal operation reference sequence library. Adjacent instruction transfer relationships and offset indicators trigger anomaly identification rule sets, forming a firmware-level real-time judgment of operational anomalies, access violations, and tampering risks. Based on this, the firmware is divided into control, data, and configuration domains. Relying on the running status and permission mapping table, permission control register, and interface mask table, it achieves minimum permission control and dynamic demotion isolation within each domain. Combined with firmware integrity verification of protected segments (based on the factory notarized value and write protection status of the trusted root region) and hot switching of local firmware copies (setting a boot selection flag and remapping the boot vector), it completes a closed-loop process from detection and isolation to recovery. Simultaneously, abnormal behaviors are written to a write-protected circular log area in chronological order, serving as a read-only basis for updating the anomaly identification threshold. This allows the judgment threshold to converge robustly with changing operating conditions, thereby comprehensively improving the firmware-level anti-tampering capability, operational security, and maintainability of industrial automation equipment. Attached Figure Description

[0059] Figure 1 This is a flowchart of the firmware-level security protection method for hard drives in industrial automation equipment according to the present invention.

[0060] Figure 2 This is a schematic diagram of the firmware-level security protection system for the hard drive of industrial automation equipment according to the present invention. Detailed Implementation

[0061] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] Example 1: As Figure 1 As shown, the firmware-level security protection method for hard drives in industrial automation equipment includes the following steps:

[0063] Collect hard drive firmware access behavior data of industrial automation equipment during operation, construct a behavior sequence set including instruction sequence, call frequency and sensitive area access markers, and identify the operating state that deviates from the normal mode by comparing behavior sequences;

[0064] Based on the behavior comparison results, an anomaly identification mechanism is triggered to determine whether the current firmware has any operational anomalies, access violations, or tampering risks.

[0065] The hard disk firmware is divided into control domain, data domain and configuration domain. Permission mapping rules are established, and access permission adjustment policies are executed based on the anomaly identification results to restrict access to the control domain and configuration domain in abnormal states, and only read-only access is retained.

[0066] The firmware integrity verification process is executed to check the running status of the current firmware version. If the verification fails, the local firmware copy switching process is started to complete the firmware replacement and loading.

[0067] After the switch is completed, abnormal behavior information is recorded and stored in the firmware log area for later use when the abnormal identification threshold is updated.

[0068] Step 1: Collect hard drive firmware access behavior data of industrial automation equipment during operation, construct a behavior sequence set including instruction sequences, call frequencies, and sensitive area access markers, and identify operating states that deviate from the normal mode by comparing behavior sequences. Specifically, the implementation is as follows:

[0069] Parameters and data source initialization are performed, and the sampling period and sliding time window are set. The length of the sliding time window is an integer multiple of the sampling period, and the window sliding step is smaller than the length of the sliding time window to ensure continuous window coverage. Within each sliding time window, the instruction call record, interface access record and interrupt event timestamp generated by the firmware are obtained from the recording interface of the hard disk controller. All time-related data are uniformly converted into the same time base to form a time tag. The instruction call record contains the instruction identifier, access address and interface type. The interface access record contains the interface type and access address. The interrupt event timestamp is used to define the event sequence and the interval between adjacent events.

[0070] During the data extraction phase, the instruction identifier, access address, interface type, and time stamp are extracted sequentially for each record. The access address is compared with a pre-set sensitive area address table, which is written by factory configuration or authorized configuration and records the start and end addresses of each sensitive area. The comparison results are used to generate sensitive area access tags. When the access address falls into any sensitive area, the behavior is marked as sensitive access.

[0071] The process of obtaining the call frequency parameter involves counting the number of calls for each type of instruction identifier within the current sliding time window to obtain the total number of calls for that instruction within the window. The difference between the timestamps of two consecutive occurrences of the same instruction identifier is used as the adjacent call interval for statistical analysis. The maximum consecutive length of consecutive repetitions of the same instruction identifier is used as the consecutive trigger length for statistical analysis. Subsequently, the instruction identifier, call frequency parameter, and sensitive area access marker are combined into a behavior unit in chronological order. The behavior unit is a minimal descriptive record sorted by timestamp, containing information related to the frequency of a firmware behavior within the current sliding time window. As the window slides, the behavior units within each window are continuously accumulated to form a behavior sequence set. The behavior sequence set is a collection of behavior unit sequences arranged in chronological order within multiple sliding time windows.

[0072] When establishing the normal operation reference sequence library, historical stable windows are selected as the reference data source. Historical stable windows refer to the set of sliding time windows that have been confirmed on-site to have no abnormal indicators, no permission changes, and equipment operating conditions within the normal production line cycle. The behavioral units within the historical stable windows are arranged into reference sequences in chronological order, and adjacent instruction transfer relationships are recorded from each reference sequence. Adjacent instruction transfer relationships refer to ordered pairs of instruction identifiers of the preceding and following behavioral units in chronological order, used to describe the instruction transfer characteristics during normal operation. The reference sequences and their adjacent instruction transfer relationships are stored in the normal operation reference sequence library, which can be managed by operating condition. When the equipment switches operating conditions, the corresponding category of reference sequence and adjacent instruction transfer relationship is selected.

[0073] The behavior sequence within the current time window is standardized. This standardization process includes: unifying the timestamp format and sorting rules; removing abnormal records lacking necessary fields; performing consistency checks on instruction identifiers according to the instruction identifier definition table; performing consistency checks on interface types according to the interface type definition table; and normalizing access addresses to ensure consistency with the sensitive area address table. After standardization, the sequence is sliced ​​according to a preset length, determined by system configuration, to ensure a one-to-one correspondence between slices and reference sequence segments. Reference sequence segments with the same length as the slice are selected from the normal operating reference sequence library. If multiple candidate segments exist, the reference sequence segment closest in time to the current slice is selected as the alignment object. The current slice and its corresponding reference sequence segment are then aligned one-to-one, based on chronological order, with the first behavior unit in the slice corresponding to the first behavior unit in the reference sequence segment, and this alignment is completed sequentially.

[0074] Offset metrics are calculated based on the alignment results. Offset metrics include the number of times unregistered instructions appear, the number of times sensitive area access markers appear, the number of times adjacent instruction transfers do not match, and the number of consecutive repeated trigger length exceeding the limit.

[0075] The method for obtaining the number of occurrences of unregistered instructions is as follows: check the instruction identifier of each behavior unit in the current slice one by one. If the instruction identifier is not registered in the instruction identifier set of the normal operation reference sequence library, then increment the number of occurrences of the unregistered instruction by one.

[0076] The method for obtaining the occurrence count of sensitive area access markers is as follows: check the sensitive area access markers of each behavior unit in the current slice one by one, and increment the occurrence count of the sensitive area access marker when it is marked as sensitive access;

[0077] The method for obtaining the number of adjacent instruction transfer mismatches is as follows: check the ordered pairs formed by the instruction identifiers of two adjacent action units one by one in the current slice. If the ordered pair does not appear in the adjacent instruction transfer relationship recorded under the same working condition category, then increment the number of adjacent instruction transfer mismatches by one.

[0078] The method for obtaining the number of consecutive repeated trigger length exceeding the limit is as follows: calculate the consecutive trigger length for each instruction identifier in the current slice. The consecutive trigger length is the maximum number of times the instruction identifier appears consecutively in the time sequence. When the consecutive trigger length of any instruction identifier exceeds the preset consecutive trigger length limit, record an over-limit event and increment the number of consecutive repeated trigger length exceeding the limit by one.

[0079] The preset offset threshold is obtained by offline analysis of the statistical results of each offset index in the historical stable window. The threshold that can distinguish between normal fluctuations and abnormal offsets is selected. The threshold is stored as a configuration item and loaded at runtime. In the continuous window, when any offset index reaches the corresponding preset offset threshold, or when an instruction transfer chain not included in the reference sequence library is detected during alignment (meaning that the ordered pair of adjacent instruction identifiers appearing in the current slice does not exist in the adjacent instruction transfer relationship of the reference sequence library and does not belong to any operating condition category), the current running state is determined to be deviating from the normal mode and an abnormality identifier is output. The abnormality identifier includes the name of the triggered offset index and the timestamp of the current window, so that subsequent processing can be performed according to the abnormality identification rule set.

[0080] An example of sliding time window acquisition and behavior sequence alignment is as follows:

[0081] The sampling period is set to one second, the sliding time window length to ten seconds, and the window sliding step size to one second. Within a certain sliding time window, instruction call records and interface access records sorted by time tag are obtained from the hard disk controller: the order of instruction identifier appearance is "read block to read block to write block to synchronization and finally to read block", and the access addresses fall into addresses one to five one by one, and the interface type is storage interface one in all cases; the access addresses are compared with the sensitive area address table, and it is found that the third "write block" hits the configuration field parameter area, so a sensitive area access mark is assigned. Statistical call frequency parameters: Within this sliding time window, the number of calls to "read block" is three, the time tag difference between two adjacent "read block" calls is two seconds and three seconds, and the maximum continuous trigger length is two; the number of calls to "write block" is one, and the continuous trigger length is one. The instruction identifier, call frequency parameters, and sensitive area access marker are combined into a behavior unit according to the time sequence. As the window slides, the behavior sequence set is accumulated. When establishing a normal operation reference sequence library, the reference sequence of the historical stable window "read block to read block to synchronization and finally to read block" is selected and the adjacent instruction transfer relationship is recorded. The behavior sequence of the current time window is sliced ​​according to the preset length and aligned with the reference sequence one by one to obtain the offset index: the number of adjacent instruction transfer mismatches is one ("read block to write block" does not appear in the adjacent instruction transfer relationship), and the number of times the sensitive area access marker appears is one. Since either of them reaches the preset offset threshold (both are set to one), the current running state is determined to be deviating from the normal mode and an abnormal identifier (including abnormal category label, trigger rule identifier, and time tag) is output.

[0082] Step 2: Based on the behavior comparison results, trigger the anomaly detection mechanism to determine whether the current firmware has any operational anomalies, access violations, or tampering risks. The specific implementation is as follows:

[0083] An anomaly identification rule set is established, categorized into three types: operational anomalies, access violations, and tampering risks. Each rule is assigned a unique trigger rule identifier and a corresponding continuous window count threshold. The continuous window count threshold is obtained as follows:

[0084] The system counts the natural fluctuation range of such events within a historical stable window, selects the upper limit of the count that can distinguish between normal fluctuations and abnormal deviations as the threshold, and solidifies it in the form of a configuration item. During operation, the system receives abnormal identification clues from the behavior sequence comparison step output by sliding time windows (these clues include deviation indicators such as unregistered instructions, access to sensitive areas, instruction transfer mismatch, and continuous triggering of limits), and triggers the judgment process of the corresponding category rules accordingly.

[0085] For different types of operational anomalies, the system maintains two base tables: an instruction identifier definition table and a disabled instruction table. Illegal instructions are those whose instruction identifiers are not registered in the instruction identifier definition table; disabled instructions are those registered in the disabled instruction table and prohibited from being invoked in the current operating condition. Within each sliding time window, the system sequentially checks for: 1) the occurrence of illegal or disabled instructions, by checking each instruction identifier in the behavior unit; if an instruction is not registered or hits the disabled instruction table, an operational anomaly event is recorded; 2) instruction sequence conflicts, by forming ordered pairs of instruction identifiers from two adjacent behavior units and comparing them with the adjacent instruction transfer relationships recorded in the normal operation reference sequence library. The system performs the following operations: 1) Check each call against the specified timestamps. If no match is found, an operation exception event is recorded. 2) Check the API call timeout. For each API call, record its start and end timestamps. Compare the difference between the two timestamps with a preset API timeout limit. If the difference exceeds the limit, an operation exception event is recorded. 3) Check the API call retry count. Within the same sliding time window, count failed calls with the same instruction identifier and pointing to the same access address. Compare the count with a preset retry limit. If the count exceeds the limit, an operation exception event is recorded. Each of these events will be recorded as an operation exception event within the window, along with the trigger rule identifier and timestamp.

[0086] For out-of-bounds access categories, the system maintains two base tables: an address range mapping table and a region permission table. The address range mapping table records the start and end addresses of each storage region, as well as the domain and region attributes to which the region belongs. The region permission table records the allowed access types (read, write, execute, update, and manage) for each region in the current running state. The determination of out-of-bounds access is carried out in the following order: First, cross-region write detection: when the target address and write length of a write request cross the address range of two or more different regions, an out-of-bounds access event is recorded. Second, out-of-bounds DMA transfer detection: the start address and transfer length of the DMA transfer are calculated to determine the boundary. When the start address and the end address of the transfer length exceed the end address of a single target region, an out-of-bounds access event is recorded. Third, unauthorized write detection for restricted regions: the target region is used as the key to query the region permission table to see if writing is allowed. If the result is not allowed, an out-of-bounds access event is recorded. Any of the above hits will record an out-of-bounds access event in this window, along with the trigger rule identifier, target region attributes, and time tag.

[0087] For tampering risk categories, the system maintains a list of protected segments and a trusted root area. The list of protected segments includes the boot segment, configuration segment, and firmware segments that the manufacturer specifies need to be protected. The trusted root area stores the public key or private key used for verification and the factory notarized value (the notarized value includes the hash value and / or digital signature). The tampering risk assessment is conducted sequentially as follows: First, integrity digest verification is performed by calculating the message digest for each protected segment within the verification window and comparing it with the factory-certified value of the corresponding segment. If they do not match, a tampering risk event is recorded. Second, control register lock bit status change monitoring is performed by periodically reading the control register related to firmware write protection. If the lock bit changes from a protected state to an unprotected state, a tampering risk event is recorded. Third, boot segment write attempt detection is performed by intercepting write commands and comparing the target address with the boot segment address range in the protected segment list. If the target address falls within the boot segment range, a tampering risk event is recorded. Fourth, signature verification failure detection is performed by using the public key in the trusted root area to verify the digital signature of the protected segment. If the verification fails, a tampering risk event is recorded. Any of the above occurrences will result in a tampering risk event being recorded in this window, along with a trigger rule identifier, an affected segment identifier, and a timestamp.

[0088] Event aggregation and anomaly identifier generation employs two parallel mechanisms: single-window triggering and continuous window counting. Within a single sliding time window, an anomaly identifier is generated immediately when any of the three categories of events—operational anomaly, access violation, or tampering risk—is recorded. In the continuous time window mechanism, an independent counter is maintained for each category. When the window slides, the count of events of that category in the new window is compared with the continuous window counting threshold for that category. An anomaly identifier is generated when the count reaches or exceeds the continuous window counting threshold. The anomaly identifier includes at least an anomaly category label, a trigger rule identifier, a window start time label and an end time label, an event count, and a trigger type field. The trigger type field is used to distinguish between single-window triggering and continuous window triggering. The generated anomaly identifier serves as input for subsequent permission adjustment processes and is simultaneously written to the firmware log area.

[0089] Step 3: Divide the hard drive firmware into a control domain, a data domain, and a configuration domain; establish permission mapping rules; and execute access permission adjustment policies based on anomaly identification results to restrict access to the control domain and configuration domain in abnormal states, retaining only read-only access functionality. Specifically, the implementation is as follows:

[0090] During the firmware assembly phase, a domain descriptor table is generated based on the address range and functional boundaries of the firmware image: boot-critical code such as boot and key management, as well as protected register access routines, are assigned to the control domain; file system data buffers and ordinary data access routines are assigned to the data domain; and device parameter storage, log management, debugging updates, and configuration writing routines are assigned to the configuration domain. For each domain, the domain identifier, start address, end address, included modules, and sensitivity level are recorded.

[0091] Each domain is assigned a set of permission bits and a whitelist of instructions. The permission bit set uses five categories of permissions: read, write, execute, update, and management. Read allows reading content within the domain, write allows writing to or erasing content within the domain, execute allows loading and executing code from the domain, update allows version switching or overwriting of firmware images and configuration content, and management allows changing control configurations such as the domain descriptor table, runtime status, and permission mapping table. The instruction whitelist lists the instruction sets allowed to be invoked in the domain, organized by instruction identifier within the firmware, and explicitly restricts cross-domain calls. Based on the aforementioned domain descriptor table and permission bit set, a mapping table between running state and permission is established. The running state includes at least normal state, restricted state, read-only state, and frozen state. Each running state corresponds to the target permission combination for each domain. For example, in the normal state, the control domain allows execution and reading, prohibits writing and updating, and only allows necessary management; the data domain allows reading and writing, and prohibits execution and management; the configuration domain allows updating and reading under controlled processes, and prohibits execution and arbitrary writing. In the restricted state, read-only state, and frozen state, writing and updating are gradually tightened until only reading is retained or access is completely blocked.

[0092] At runtime, the cross-domain access gateway is initialized to constrain inter-domain access: When processing each access request, the cross-domain access gateway first verifies the source domain based on the domain to which the request originates. Then, it locates the target domain in the domain descriptor table based on the target address and verifies the target address. Next, it verifies the parameter length and interface type based on the parameter length and interface type corresponding to the request's read, write, execute, update, or management intent. If any verification fails, the access request is rejected, and the reason for rejection and a timestamp are recorded. To ensure the atomicity of permission activation and revocation, the firmware provides two execution surfaces: a permission control register and an interface mask table. The permission control register is used to set hard switches such as read-only lock, write protection, execute prohibition, and update prohibition. The interface mask table is used to block specific write, erase, debug, and update interfaces according to instruction identifiers.

[0093] When an exception identifier generated by the preceding steps is received (the exception identifier includes an exception category label, a trigger rule identifier, and a time label), the firmware first looks up the target permission status corresponding to the exception category in the running status and permission mapping table. Based on the lookup result, the permission adjustment process is invoked: a read-only lock and write protection are set in the permission control register, and execution prohibition and update prohibition are set if necessary. At the same time, write, erase, cross-domain write, and debug update interfaces related to the exception category are blocked in the interface blocking table. For cross-domain write risks, a cross-domain write blocking item is also enabled in the cross-domain access gateway to reject cross-domain write requests that are inconsistent between the source domain and the target domain and are not authorized by the instruction whitelist. After the permission adjustment is completed, this permission change is written to the write-protected log area in the firmware image in the form of a permission change log. The recorded content includes the time label, exception category label, target domain identifier, permission bit change, control register setting status, and interface blocking table update entries. A rollback flag is set to indicate that the default permission status can be restored according to the running status and permission mapping table after the exception is resolved.

[0094] Perform differentiated domain permission switching based on exception categories, switching the configuration domain to a restricted state and disabling write access: Read the target permission combination from the operation exception to the restricted state of the configuration domain in the runtime status and permission mapping table; set write protection for the configuration domain and clear update authorization in the permission control register; block configuration write and unnecessary debug update interfaces in the interface masking table, while retaining read-only access to the configuration domain to ensure diagnostic readability; for access out-of-bounds or tampering risk categories, switch the control domain and configuration domain to read-only or frozen states.

[0095] When an anomaly indicates an access violation or tampering risk, the target permission combination of "access violation to read-only state of control domain and read-only state of configuration domain" or "tampering risk to frozen state of control domain and frozen state of configuration domain" is read from the runtime status and permission mapping table. Read-only lock, write protection and update prohibition are set for control domain and configuration domain respectively in permission control register. If necessary, execution prohibition is added to control domain to achieve frozen state. Cross-domain write and all update interfaces are blocked in the interface masking table. After the above changes are completed, permission change log is recorded synchronously and the rollback flag is kept valid so that after the anomaly is resolved and the firmware integrity verification is passed, the recovery process restores the permissions of control domain, data domain and configuration domain to the default permission combination according to runtime status and permission mapping table.

[0096] It should be noted that all judgments are completed through explicit table-driven and switch-set operations, including: the domain descriptor table, running status and permission mapping table, instruction whitelist, address range mapping table, and region permission table are fixed during firmware compilation or authorized configuration; the exception identifier is generated by the preceding behavior comparison and exception identification mechanism and serves as the trigger condition for the permission adjustment process in this embodiment; the setting and clearing of the permission control register and interface mask table are executed in transactional order, with the interface masked first and then the write protection set, and the write protection is canceled first and then the interface mask is restored during revocation to avoid contention and intermediate states; the cross-domain access gateway remains effective before and after permission adjustment to ensure consistency in the rules for source domain verification, target address verification, and parameter length verification.

[0097] Step 4: Execute the firmware integrity verification process to check the running status of the current firmware version. If the verification fails, initiate the local firmware copy switching process to complete the firmware replacement and loading. The specific implementation is as follows:

[0098] First, the firmware integrity verification process is executed:

[0099] The firmware segment to be verified is determined based on the domain descriptor table. The firmware segment includes at least a boot segment, a protected code segment in the control domain, and a protected configuration segment in the configuration domain. The factory notarized value corresponding to each segment is read from the trusted root area. The factory notarized value includes a hash value and / or a digital signature.

[0100] The system calculates message digests for each segment sequentially within the verification window. The calculation method is as follows: data is read byte-by-byte according to the physical order of the segments in non-volatile memory and fed into the message digest calculation process in fixed block sizes until the entire segment is traversed, resulting in a fixed-length digest output. If the factory-certified value of a segment is a hash value, the calculated message digest is compared with this hash value for consistency. If the factory-certified value of a segment is a digital signature, the public or private key stored in the root of trust area is used to verify the digital signature, and the verified reference digest is compared with the message digest for consistency. To avoid only internal... In the event of a missed check due to inconsistent content but an abnormal protection bit, after completing the content consistency check for each segment, the system reads the control register to write the protection bit and the boot lock bit to confirm that the protected segment is in a protected state; at the same time, it reads the version counter to confirm that the currently running firmware version has not experienced an unauthorized version rollback or abnormal transition; if the content consistency of any segment fails, or any protected bit is in an abnormal state, or the version counter indicates an abnormal version transition, a verification failure flag is immediately generated. The verification failure flag includes the segment identifier, the reason for failure (content inconsistency, abnormal protection bit, or abnormal version), and a timestamp, and the current verification process ends.

[0101] After generating a verification failure flag, the system enters the preparation phase of the local firmware copy switching process: If it is not currently in read-only or frozen state, the system is first switched to read-only or frozen state; read-only state allows necessary reading and control, while frozen state completely prohibits writing and updating in high-risk situations. In this state, unnecessary write requests are suspended. Unnecessary write requests refer to ordinary data field writes and log extension writes that are unrelated to data consistency or exception handling; then, the cache queue is refreshed. The refresh method is as follows: first, new write queues are stopped, and writes already in the queue are completed in sequence or their non-critical parts are discarded. Then, critical control data (such as exception flags and minimum diagnostic information) that have not yet been written to disk in the cache are written to disk to ensure that there are no pending critical write operations before the switch; after the refresh is completed, the firmware enters the switch-ready state;

[0102] Once the switchover is ready, the identifier and version information of the target copy are read from the protected copy storage area, and an integrity check is performed on the copy. The integrity check process is the same as the firmware integrity check process described above: the message digest is calculated segment by segment according to the segment range corresponding to the copy, and the consistency is compared with the factory notarized value saved for the copy in the protected copy storage area; if necessary, the write protection bit and boot lock bit of the control register are also read to confirm that the copy image has not been modified. If the copy integrity check fails, the copy remains frozen and a copy switchover failure alarm is output. The copy switchover failure alarm includes the copy identifier, the reason for failure, and the timestamp, while retaining the verification failure identifier for subsequent manual intervention; if the copy integrity check passes, the actual switchover phase begins.

[0103] The actual switching phase steps are as follows:

[0104] First, a boot selection flag is set to indicate that the next execution entry point originates from the replica image. Then, the boot vector is remapped, redirecting it from the current firmware's execution entry address to the replica's entry address. This remapping is completed within an uninterruptible critical section to ensure atomicity. Next, the initialization parameters and key handle required for replica execution are loaded. Initialization parameters include clock, bus, and interface initialization configurations required for replica operation, while the key handle is used for subsequent access to the trusted root region and protected segments. After these preparations are complete, a soft reset or firmware execution thread restart is triggered. Upon reset, the system executes from the replica's entry address based on the set boot selection flag and the remapped boot vector, completing the hot switch. To ensure safe convergence during the switch, the protection state of the control domain remains unchanged within the stability detection window after replica startup. Only after stable replica operation is detected (no new anomaly flags appear, and critical register states are normal) is the read-only restriction on the data domain lifted. The lifting of the configuration domain is performed in stages according to the anomaly type, running status, and permission mapping table requirements, maintaining a read-only state as necessary until subsequent verification is completed.

[0105] Both successful and failed handovers are recorded and alarms are output: when the handover is successful, the setting time of the start selection flag, the remapping target of the boot vector, the execution entry address, the loading status of initialization parameters, and the loading status of the key handle are written to the firmware log area; when the handover fails, in addition to outputting a copy handover failure alarm, the reason for the failure is recorded and kept in a frozen state to avoid further risks.

[0106] An example of firmware integrity verification and local firmware copy switching process is as follows:

[0107] Within the verification window, the segments to be verified are determined based on the domain descriptor table as the boot segment, the protected code segment of the control domain, and the protected configuration segment of the configuration domain. The factory notarized values ​​of the three segments are read from the root of trust region (digital signatures for the boot segment and the protected code segment of the control domain, and hash values ​​for the protected configuration segment of the configuration domain). The message digest is read byte-by-byte in physical order of the segments and calculated: for the boot segment and the protected code segment of the control domain, the digital signature is verified using the public key, and the obtained reference digest is compared with the message digest for consistency; for the protected configuration segment of the configuration domain, the message digest is compared with the hash value for consistency; simultaneously, the write protection bit and boot lock bit of the control register are read, and the version counter is checked to confirm that the protected segments are in a protected state and there is no abnormal version transition. In this example, the consistency comparison of the protected configuration segment of the configuration domain fails, and a verification failure flag (including segment identifier, failure reason, and timestamp) is immediately generated.

[0108] Switch to read-only mode, suspend unnecessary write requests and refresh the cache queue; read the target replica identifier and version information from the protected replica storage area, perform integrity verification on the replica according to the same process, and after all three segments pass the consistency test, set the startup selection flag and remap the boot vector, point the execution entry address to the replica entry address, load the replica's initialization parameters and key handle, and trigger a soft reset to complete the hot switch; maintain the control domain protection state within the stability detection window after the replica starts, and after no new abnormal identifiers appear and the critical register states are normal, remove the read-only restriction on the data domain; if the replica integrity verification fails, maintain the frozen state and output a replica switch failure alarm.

[0109] Step 5: After the switch is completed, record the abnormal behavior information and store it in the firmware log area for later use when updating the abnormal identification threshold. The specific implementation is as follows:

[0110] A write-protected circular log area is reserved within the firmware image, and log area header metadata is set at the beginning of this area. The metadata includes at least a capacity threshold, record capacity, head pointer, tail pointer, serial number counter, and read-only flag. The capacity threshold is used to limit the maximum number of records that can be stored; the record capacity is the number of records currently occupied; the head pointer and tail pointer are used to locate the oldest record and the next write position; the serial number counter is used to assign a unique serial number to a new record; the read-only flag is used to indicate the access attributes of this area; write protection means that ordinary writing is prohibited in this area, and controlled append writing can only be performed through log append routines with management permissions.

[0111] When it is necessary to record abnormal behavior information (such as after completing a local firmware copy switch or receiving an abnormality flag), the firmware call log append routine writes the timestamp, abnormality category, trigger rule identifier, target domain identifier, and handling result in chronological order of events, and assigns a sequence number and digest verification to each record. The timestamp is obtained from the system's unified time base; the abnormality category is selected as operation abnormality, access violation, or tampering risk; the trigger rule identifier corresponds to a unique identifier in the abnormality identification rule set; the target domain identifier is a control domain, data domain, or configuration domain; the handling result indicates the executed permission adjustment or local firmware copy switch result (e.g., switch success or switch failure alarm).

[0112] The sequence number is assigned as follows: the current value of the sequence number counter is read and incremented by one to obtain the sequence number of this record, and then the counter is written back for updating. The digest verification is generated as follows: the byte streams of timestamp, exception category, trigger rule identifier, target domain identifier, handling result and sequence number are sequentially sent into the digest calculation process in a fixed field order. The digest calculation process mixes and compresses the input bytes one by one until all inputs are completed, and outputs a digest value of fixed length. This digest value is written along with the record for verification of record integrity during subsequent read-only queries.

[0113] The cyclic write operation follows a first-in, first-out (FIFO) overwrite strategy. The firmware calculates the write position based on the tail pointer, writes the complete record atomically, first writes the record body and digest verification, then updates the tail pointer and record capacity. When the record capacity is less than the capacity threshold, it only increments the record capacity. When the record capacity reaches the capacity threshold, a FIFO overwrite is performed, which advances the head pointer by one record unit to discard the oldest record while maintaining the record capacity equal to the capacity threshold. The update order uses a two-stage approach: the first stage completes the record body and digest verification write and sets the record ready flag; the second stage commits metadata updates (including tail pointer and, if necessary, head pointer advances). During recovery, if a record ready flag is found but metadata has not been committed, the record is used as a valid record to supplement the metadata commit; if digest verification fails or writing is incomplete, the record is discarded and the pointer remains unchanged.

[0114] The read-only query interface is used for anomaly identification threshold updates. This interface provides read capabilities in read-only, restricted, normal, and frozen states, but does not provide any write access. The query process is as follows: the caller provides a timestamp range, anomaly category, and optional trigger rule or target domain identifiers as filtering conditions. The log reading routine traverses records chronologically from the head pointer to the tail pointer. For each candidate record, the digest value is recalculated according to the same field order and compared with the digest within the record. Only records with consistent digests are output. The output fields remain consistent with those written, allowing the threshold maintenance module to statistically analyze the occurrence count, event distribution, and handling result distribution of events within a continuous window. This provides a basis for maintaining the preset offset threshold and continuous window counting threshold. This read-only query interface only consumes read permissions and does not change the head pointer, tail pointer, or record capacity.

[0115] The first log record after the switchover is completed must include the result of the replica switchover and a timestamp for closed-loop tracking of the anomaly handling effect. When the system recovers from a frozen or read-only state to a normal state, the threshold maintenance module reads records within a specified time range through a read-only query interface, identifies and counts them according to event categories and trigger rules, and compares them with on-site operating information to form threshold adjustment suggestions. The actual update of the threshold is completed in the configuration domain through a controlled update process. The update process must comply with the management permission requirements of the running status and permission mapping table, and the log area itself is not rewritten.

[0116] It should be noted that the thresholds involved in the embodiments can be determined according to specific scenarios and needs.

[0117] This invention collects instruction call records, interface access records, and interrupt event timestamps from hard disk firmware within a sliding time window. It constructs a behavior sequence set, including instruction sequences, call frequencies, and sensitive area access markers, in chronological order. This set is compared with a normal operation reference sequence library. Adjacent instruction transfer relationships and offset indicators trigger anomaly identification rule sets, forming a firmware-level real-time judgment of operational anomalies, access violations, and tampering risks. Based on this, the firmware is divided into control, data, and configuration domains. Relying on the running status and permission mapping table, permission control register, and interface mask table, it achieves minimum permission control and dynamic demotion isolation within each domain. Combined with firmware integrity verification of protected segments (based on the factory notarized value and write protection status of the trusted root region) and hot switching of local firmware copies (setting a boot selection flag and remapping the boot vector), it completes a closed-loop process from detection and isolation to recovery. Simultaneously, abnormal behaviors are written to a write-protected circular log area in chronological order, serving as a read-only basis for updating the anomaly identification threshold. This allows the judgment threshold to converge robustly with changing operating conditions, thereby comprehensively improving the firmware-level anti-tampering capability, operational security, and maintainability of industrial automation equipment.

[0118] Example 2: Firmware-level security protection system for hard drives in industrial automation equipment, such as... Figure 2 As shown, it specifically includes:

[0119] The hard disk status identification module is used to collect access behavior data of hard disk firmware during the operation of industrial automation equipment, construct a behavior sequence set including instruction sequence, call frequency and access markers of sensitive areas, and identify the operating status that deviates from the normal mode by comparing behavior sequences.

[0120] The anomaly detection module is used to trigger the anomaly identification mechanism based on the behavior comparison results to determine whether the current firmware has any operational anomalies, access out-of-bounds risks, or tampering risks.

[0121] The identification result execution module is used to divide the hard disk firmware into control domain, data domain and configuration domain, establish permission mapping rules, execute access permission adjustment policies according to the abnormal identification results, restrict access to the control domain and configuration domain in abnormal state, and retain only read-only access function;

[0122] The execution verification module is used to perform the firmware integrity verification process, detect the running status of the current firmware version, and if the verification fails, start the local firmware copy switching process to complete the firmware replacement and loading.

[0123] The abnormal information storage module is used to record abnormal behavior information and store it in the firmware log area after the switch is completed, so that it can be called when the abnormal identification threshold is updated.

[0124] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, ATA hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium can be a solid-state ATA hard disk.

[0125] It should be understood that, in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0126] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0127] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0128] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0129] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

Claims

1. A firmware-level security protection method for hard drives in industrial automation equipment, characterized in that, Includes the following steps: Collect hard drive firmware access behavior data of industrial automation equipment during operation, construct a behavior sequence set including instruction sequence, call frequency and sensitive area access markers, and identify the operating state that deviates from the normal mode by comparing behavior sequences; Based on the behavior comparison results, an anomaly identification mechanism is triggered to determine whether the current firmware has any operational anomalies, access violations, or tampering risks. The hard disk firmware is divided into control domain, data domain and configuration domain. Permission mapping rules are established, and access permission adjustment policies are executed based on the anomaly identification results to restrict access to the control domain and configuration domain in abnormal states, and only read-only access is retained. The firmware integrity verification process is executed to check the running status of the current firmware version. If the verification fails, the local firmware copy switching process is started to complete the firmware replacement and loading. After the switch is completed, abnormal behavior information is recorded and stored in the firmware log area for later use when the abnormal identification threshold is updated. Data on hard drive firmware access behavior of industrial automation equipment during operation is collected, and a behavior sequence set containing instruction sequences, call frequencies, and sensitive area access markers is constructed. The specific process is as follows: Set the sampling period and sliding time window, and obtain the instruction call record, interface access record and interrupt event timestamp generated by the firmware from the hard disk controller within each time window; Extract the instruction identifier, access address, interface type, and timestamp for each record; The access address is compared with the preset sensitive area address table and a sensitive area access mark is generated. The number of times each instruction is called within the window, the interval between adjacent calls, and the length of continuous triggering are counted to form the call frequency parameter. The instruction identifier, call frequency parameter, and sensitive area access mark are combined into a behavior unit in chronological order, and a behavior sequence set is formed by sliding the window.

2. The firmware-level security protection method for hard drives of industrial automation equipment according to claim 1, characterized in that: And by comparing behavioral sequences, the operating states that deviate from the normal pattern are identified. The specific process is as follows: Establish a normal operation reference sequence library. The reference sequence is composed of behavioral units within the historical stable window in chronological order and records the transfer relationship between adjacent instructions. The behavior sequence of the current time window is standardized and sliced ​​into segments of a preset length, and each slice is aligned with the reference sequence. Based on the alignment results, the offset indicators are statistically analyzed. The offset indicators include at least the number of times unregistered instructions appear, the number of times sensitive area access markers appear, the number of times adjacent instruction transfers do not match, and the number of consecutive repeated trigger length exceeding the limit. In a continuous window, when any offset indicator reaches a preset offset threshold or an instruction transfer chain not included in the reference sequence library is detected, the current running state is determined to be deviating from the normal mode and an abnormality flag is output.

3. The firmware-level security protection method for hard drives of industrial automation equipment according to claim 2, characterized in that: Based on the behavior comparison results, an anomaly detection mechanism is triggered to determine whether the current firmware has any operational anomalies, out-of-bounds access, or tampering risks. The specific process is as follows: Establish an anomaly identification rule set, which is classified and managed into three categories: operation anomaly, access violation, and tampering risk. Trigger conditions and continuous window counting thresholds are set for each type of rule. For operational anomalies, detect the occurrence of illegal or disabled commands, command sequence conflicts, interface call timeouts, and exceeding the limit for the number of abnormal retries. Record the operational anomaly event as soon as any of these events occurs. For out-of-bounds access, the current access address, access length and target area attributes are checked according to the address range mapping table and the area permission table. Cross-area write, out-of-bounds DMA transfer or unauthorized write to restricted areas are detected. If any of these are detected, the out-of-bounds access event is recorded. To mitigate tampering risks, integrity digest verification is performed on the protected segments of the firmware image, and changes in the control register lock bit state, attempts to write to the boot segment, or signature verification failures are monitored. Any such occurrence results in a tampering risk event being recorded. When any type of event is triggered within a single time window, or when the count of the same type of event reaches a preset count threshold within a continuous time window, an anomaly identifier containing an anomaly category label is generated.

4. The firmware-level security protection method for hard drives of industrial automation equipment according to claim 3, characterized in that: The hard drive firmware is divided into control, data, and configuration domains, and permission mapping rules are established. The specific process is as follows: A domain descriptor table is generated based on the address range and functional boundaries of the firmware image. The domain descriptor table records the domain identifier, start and end addresses, included modules, and sensitivity level. Set permission bit sets and command whitelists for each domain. Permission bits should at least include read, write, execute, update and manage. Establish a mapping table between running status and permissions. The running status should include at least normal, restricted, read-only and frozen states. When an exception flag is received, the target permission set is retrieved from the running status and permission mapping table according to the exception category, and enabled through the control register and interface masking table. Specifically, this includes setting the read-only lock, disabling erase and write commands, masking cross-domain writes, and closing the debug update interface. Establish a cross-domain access gateway to perform source domain verification, destination address verification, and parameter length verification on access requests from outside the local domain. Requests that fail the verification are rejected and logged. Write the permission change log and set a rollback flag when permissions are changed, so that the default permissions can be restored according to the running status and permission mapping table after the exception is resolved.

5. The firmware-level security protection method for hard drives of industrial automation equipment according to claim 4, characterized in that: Based on the anomaly identification results, the access control adjustment policy is executed. The specific process is as follows: Retrieve the target permission status from the runtime status and permission mapping table based on the exception category; For abnormal operations, the configuration domain is switched to a restricted state and write is prohibited; for access out of bounds or tampering risks, the control domain and configuration domain are switched to a read-only state or a frozen state. Permission changes are issued synchronously through the permission control register and the interface mask table, and permission change logs are recorded.

6. The firmware-level security protection method for hard drives of industrial automation equipment according to claim 5, characterized in that: The firmware integrity verification process includes: The firmware segment to be verified is determined based on the domain descriptor table, and the factory notarized value of each segment is read. The notarized value includes hash value or digital signature. Calculate message digests for the corresponding segments of the currently running firmware within the verification window; The notarized value is verified using the public or private key stored in the root of trust area and compared with the message digest for consistency. The verification result is determined by combining the write protection bit of the control register, the boot lock bit, and the status of the version counter. Output a verification failure flag when any segment fails verification or the protection bit is abnormal.

7. The firmware-level security protection method for hard drives of industrial automation equipment according to claim 6, characterized in that: The local firmware copy switching process includes: Suspend unnecessary write requests and refresh the cache queue in read-only or frozen state; Read the identifier and version information of the target copy from the protected copy storage area, and perform integrity verification on the copy; When the verification passes, the boot selection flag is set and the boot vector is remapped, pointing the execution entry point to the replica entry address; Load the initialization parameters and key handle required for the copy, trigger a soft reset or restart the firmware execution thread to complete the hot switch; After the switchover is complete, the read-only restriction on the data domain is lifted and the protection state of the control domain is maintained. When the replica verification fails, the data domain is kept in a frozen state and a replica switchover failure alarm is output.

8. The firmware-level security protection method for hard drives of industrial automation equipment according to claim 7, characterized in that: Record abnormal behavior information and store it in the firmware log area, including a write-protected circular log area set in the firmware image. Write timestamps, abnormal categories, trigger rule identifiers, target domain identifiers and handling results in chronological order of events, and attach a sequence number and summary verification to each record. When the capacity reaches the threshold, it is overwritten in a first-in-first-out manner, and a read-only query interface is provided for abnormal identification threshold update calls.

9. A firmware-level security protection system for hard drives of industrial automation equipment, used to implement the firmware-level security protection method for hard drives of industrial automation equipment as described in any one of claims 1-8, characterized in that, include: The hard disk status identification module is used to collect access behavior data of hard disk firmware during the operation of industrial automation equipment, construct a behavior sequence set including instruction sequence, call frequency and sensitive area access markers, and identify the operating status that deviates from the normal mode by comparing behavior sequences; The anomaly detection module is used to trigger the anomaly identification mechanism based on the behavior comparison results to determine whether the current firmware has any operational anomalies, access out-of-bounds risks, or tampering risks. The identification result execution module is used to divide the hard disk firmware into control domain, data domain and configuration domain, establish permission mapping rules, execute access permission adjustment policies according to the abnormal identification results, restrict access to the control domain and configuration domain in abnormal state, and retain only read-only access function; The execution verification module is used to perform the firmware integrity verification process, detect the running status of the current firmware version, and if the verification fails, start the local firmware copy switching process to complete the firmware replacement and loading. The abnormal information storage module is used to record abnormal behavior information and store it in the firmware log area after the switch is completed, so that it can be called when the abnormal identification threshold is updated.

Images