A software hash chain-based defense method against firmware break attack of internet of things device

Abstract

The application belongs to the technical field of security protection of Internet of Things equipment firmware, and discloses a method for preventing firmware damage attack of Internet of Things equipment based on software hash chain, which comprises the following steps: filing firmware objects, constructing software hash chain baseline, monitoring multi-source attack events, identifying attack stages, dynamically verifying integrity, implementing graded protection, recovering firmware and feeding back recovery; continuously writing device identification, partition parameters, firmware version and object measurement value into the software hash chain, adjusting the verification period according to the stages of reconnaissance, utilization, privilege escalation and damage, and executing source ban, write freezing, enterprise WeChat alarm, standby partition switching and golden mirror image rewriting in linkage; the method can identify firmware tampering and complete automatic recovery without special security hardware, thereby improving the firmware security and operation continuity of the Internet of Things equipment.

Description

Technical Field

[0001] This invention belongs to the field of firmware security protection technology for Internet of Things (IoT) devices, and particularly relates to a method for defending against firmware destruction attacks on IoT devices based on software hash chains. Background Technology

[0002] IP cameras, home routers, smart sensors, and industrial remote terminals typically run on a Linux kernel and BusyBox user space, with firmware stored in multiple MTD partitions formed by SPI Flash. Due to limitations in device cost, processor architecture, and circuit space, these devices are usually not equipped with TPM chips, TrustZone trusted execution environments, BMC management controllers, and independent security coprocessors. Once attackers gain device management privileges, they can render the device unbootable by erasing and overwriting the boot partition, configuration partition, and firmware partition. Therefore, it is necessary to continuously monitor, verify the integrity of firmware corruption attacks, take protective measures, and automatically recover without adding dedicated security hardware.

[0003] The following problems exist in the existing technology: (1) Existing firmware security protection methods mostly rely on TPM chips, TCM chips, TrustZone extensions and hardware SPI bus monitoring circuits to establish trusted metrics and write protection, which are difficult to deploy in low-cost IoT devices with only general-purpose processors, a small amount of memory and ordinary flash memory; some software integrity verification only compares firmware digests when the device starts up, and does not establish the device identifier, partition geometry parameters, firmware version, firmware object arrangement order and previous metric results as a continuous software hash chain, making it difficult to identify partition boundary modifications, old version rollbacks, firmware object rearrangements and cross-device baseline copying.

[0004] (2) Existing network intrusion detection methods mainly identify network attacks based on port scanning, login failures and abnormal connections. When attackers perform MTD partition erasure and write operations on the device after obtaining device privileges, no corresponding external network traffic is generated, which can easily create a blind spot in firmware storage layer detection. Existing detection, integrity verification, alarm and recovery functions are usually independent of each other. They lack a closed-loop processing mechanism that dynamically adjusts the verification cycle according to the reconnaissance, exploitation, privilege escalation and destruction stages, and directly links the abnormal detection results to write freeze, WeChat alarm, backup partition switching and golden image recovery. Summary of the Invention

[0005] This invention aims to address the problem that existing firmware protection solutions relying on hardware root of trust, hardware SPI bus monitoring, and trusted execution environment are difficult to deploy directly for low-cost IoT devices that lack TPM chips, TrustZone trusted execution environment, BMC management controller, and independent security coprocessor. It also solves the problem that traditional network intrusion detection can only identify port scans, login brute-force attacks, and abnormal connections, but cannot detect attackers performing MTD partition erasure and overwrite operations locally on the device after gaining device privileges. Furthermore, it cannot form a continuous closed loop between attack detection, firmware verification, alarm handling, and firmware recovery.

[0006] To address the aforementioned technical problems, this invention provides a method for defending against firmware corruption attacks on IoT devices based on a software hash chain, including device firmware object archiving, software hash chain baseline construction, multi-source attack event monitoring, firmware corruption attack stage identification, runtime integrity verification, graded protection and recovery, and recovery result feedback.

[0007] Read the processor architecture, kernel version, firmware version, MTD partition table, partition capacity, erase block capacity, mount status, network management port, firmware update process and current running process of IoT devices, and build device firmware object files and protection object sets according to boot partition, configuration partition, firmware partition, key files and key processes.

[0008] Based on the content change attributes of the firmware objects, the configuration partition is divided into a stable region and a service-variable region. The SHA-256 metric value of each firmware object is calculated according to the pre-fixed object number and object arrangement order. The device identifier, firmware object number, partition geometry parameters, firmware version, current metric value and the previous chain node are continuously written into the hash calculation process to generate the baseline software hash chain, baseline chain root and baseline metric record.

[0009] Baseline records are saved to the baseline record area and the golden mirror list area respectively. The baseline software hash chain is re-established after the legitimate firmware update is completed and the startup check is passed. Modification of baseline records is prohibited outside the firmware update window, thereby preventing unauthorized firmware from being written to the trusted baseline.

[0010] The background daemon continuously collects port connection events, login failure events, abnormal management session events, permission change events, abnormal process events, kernel module loading events, MTD write events, MTD erase events, firmware update status, and outbound connection status, and generates a firmware corruption attack monitoring event stream according to a unified event format.

[0011] Based on the occurrence time, source address, target of operation, process relationship, credibility of collection channel, validity time of evidence, and continuity of preceding and following stages of the monitored event, the reconnaissance stage, exploitation stage, privilege escalation stage, and destruction stage can be identified. When boot partition erasure, unauthorized firmware partition writing, and software hash chain mismatch occur directly, the preceding attack stage can be skipped and the destruction stage can be entered directly.

[0012] The firmware verification scope and cycle are dynamically adjusted according to the current attack phase. Periodic integrity verification is performed under normal conditions. The verification cycle is shortened during the exploitation and privilege escalation phases. When an unauthorized MTD operation is detected, the local metric value corresponding to the abnormal write area is calculated immediately. When the local metric values ​​are inconsistent, the complete partition is read and the current software hash chain is reconstructed.

[0013] The current chain root, current partition metric, current critical file metric, and process whitelist check results are compared with the baseline record to generate firmware integrity verification results. The first firmware object that has changed and the affected partition range are located by the chain node differences.

[0014] Based on the attack phase and integrity verification results, the following actions are taken: service shutdown, attack source blocking, abnormal process termination, root file system read-only mounting, unauthorized MTD write freezing, and enterprise WeChat tiered alarms. Alarm information includes device identifier, attack source, Chinese attack phase, abnormal process, target partition, detection basis, current handling action, and event occurrence time.

[0015] If firmware integrity verification fails, the corresponding recovery path in the backup firmware partition switching path and the golden image write-back path is determined according to the device partition structure. Signature verification, device model verification, version verification and digest verification are performed on the recovery image. Block erasure, block writing, read-back verification and failure retry are performed according to the erase block boundary.

[0016] After recovery, the damaged partition metric is recalculated and the recovered software hash chain is rebuilt. The recovered chain root, kernel startup status, critical service status, network interface status, and critical file integrity status are checked. If all recovery conditions are met, the device service connection is restored. If the recovery conditions are not met, the device is kept isolated and critical alarms continue to be sent.

[0017] This invention thus forms a complete technology chain of "device firmware object archiving - software hash chain baseline construction - multi-source attack event monitoring - attack phase identification - dynamic integrity verification - graded protection and alarm - firmware recovery - post-recovery review".

[0018] The beneficial effects of this invention are as follows: (1) The device identity, firmware object number, partition geometry parameters, firmware version and firmware object metric are written together into a continuous software hash chain, so that when the content, location, capacity, version and arrangement order of any firmware object changes, subsequent chain nodes will change. This enables the identification of firmware replacement, partition boundary modification, old version rollback and cross-device baseline copying on devices without TPM chips and trusted execution environments.

[0019] (2) It integrates network connection, login authentication, process permissions, kernel module and MTD storage operation events to identify firmware destruction attack stages, and dynamically adjusts the firmware verification cycle according to the attack stage. It locates anomalies step by step through local block digest verification and complete software hash chain reconstruction. It can detect device local firmware erasure behavior that traditional network intrusion detection cannot detect, while reducing the processor burden caused by fixed high-frequency complete verification.

[0020] (3) The attack phase identification results are directly converted into source blocking, process termination, MTD write freeze, WeChat alarm and firmware recovery actions. After recovery, the partition metric value, software hash chain and startup health status are re-verified to form a closed loop from attack monitoring to firmware recovery, thereby improving the continuous operation capability and recovery reliability of low-cost IoT devices in the face of permanent denial-of-service attacks. Attached Figure Description

[0021] The accompanying drawings are provided to further understand the present invention and form part of the specification. They are used together with the embodiments of the present invention to explain the invention and do not constitute a limitation thereof.

[0022] Figure 1 This is a flowchart of the IoT device firmware corruption attack defense method based on software hash chain proposed in this invention; Figure 2 This is a schematic diagram of the IoT device firmware corruption attack defense module based on software hash chain proposed in this invention. Detailed Implementation

[0023] Example 1, see Figures 1-2 The present invention provides a method for defending against firmware corruption attacks on Internet of Things (IoT) devices based on software hash chains, including a device firmware object filing step, a software hash chain baseline construction step, a multi-source attack event monitoring step, a firmware corruption attack stage identification step, a runtime integrity verification step, a graded protection and recovery step, and a recovery result feedback step.

[0024] This embodiment is applied to low-cost IoT devices running the Linux kernel and BusyBox user space. The IoT devices use general-purpose ARM or MIPS processors, and the firmware is stored in the MTD partition formed by SPI NOR Flash or SPI NAND Flash. The devices are not equipped with TPM chips, TCM chips, TrustZone trusted execution environment, BMC management controller and independent security coprocessor. All detection, hash calculation, policy execution and recovery control are completed by the device's existing processor.

[0025] The device firmware object creation process reads the processor architecture, kernel version, BusyBox version, device identifier, firmware version, MTD partition table, partition capacity, erase block capacity, mount status, firmware update process, network management port, and currently running process to generate a device firmware object file. It then establishes a set of protection objects according to the boot partition, configuration partition, firmware partition, key files, and key processes.

[0026] After the initial deployment of the device and the completion of the legitimate firmware update, the software hash chain baseline construction steps calculate the SHA-256 metric values ​​of the stable regions and key files of each MTD partition. The device identifier, partition identifier, partition geometric parameters, firmware version, metric value and the previous chain node are sequentially input into the hash calculation process to generate a software hash chain and baseline chain root with a fixed order.

[0027] The multi-source attack event monitoring steps involve a background daemon continuously collecting port connection events, login failure events, abnormal session events, permission change events, process startup events, kernel module loading events, MTD write events, MTD erase events, firmware update status, and device outbound connection status to generate a firmware corruption attack monitoring event stream.

[0028] The firmware destruction attack phase identification step divides the attack state into reconnaissance phase, exploitation phase, privilege escalation phase, and destruction phase based on the source, occurrence time, credibility, event combination relationship, and continuity relationship between the preceding and following phases of the monitored events. It also generates ordinary monitoring, source blocking, process blocking, firmware write freeze, and integrity enhancement verification instructions based on the current attack phase.

[0029] The runtime integrity verification steps dynamically determine the verification scope and verification cycle according to the current attack stage. Under normal conditions, the firmware partition is periodically verified. During the exploitation and privilege escalation stages, the verification cycle is shortened. During the destruction stage, the affected MTD partition is read immediately and the current software hash chain is reconstructed. The current chain root, partition metric, critical file metric, and process whitelist check results are compared with the baseline record to generate the firmware integrity verification result.

[0030] The graded protection and recovery steps, based on the attack phase and firmware integrity verification results, include shutting down exposed services, blocking attack sources, terminating abnormal processes, restricting firmware update interfaces, freezing unauthorized MTD writes, and pushing Chinese graded alarms to WeChat. If firmware integrity verification fails, the system performs backup firmware partition switching or write-back of the golden image according to the device partition structure, and re-verifies the firmware partition after the write-back.

[0031] The recovery result feedback process collects the recovery image verification results, partition write-back results, restart results, business service recovery results, and post-recovery software hash chain results, and generates a recovery feedback record. When the recovery is successful, network services are restored and the defense posture is updated. When the recovery fails, the device is kept in isolation and critical alarms are continuously pushed.

[0032] Through the above processing, this method forms a continuous closed loop of attack monitoring, software hash chain verification, write restriction, hierarchical alarm and firmware recovery without adding TPM chip, TrustZone extension and security coprocessor. It solves the problem that low-cost IoT devices cannot deploy hardware trust root solutions and network layer detection cannot detect local firmware erasure behavior.

[0033] Example 2: Based on all the above examples, the device firmware object documentation step and the software hash chain baseline construction step specifically include firmware object enumeration, stable region division, metric order solidification, chain node generation, baseline redundancy storage, and legal update control.

[0034] The firmware object enumeration process reads the / proc / mtd and MTD device node information, and builds a partition object table according to the partition start address order. Each partition object records the device node, partition name, partition capacity, erase block capacity, mount path, read and write attributes, and firmware version association information.

[0035] In this embodiment, the device firmware objects are sequentially set as the bootloader partition, configuration partition, firmware partition, / etc / passwd file, / etc / shadow file, / bin / busybox file, / sbin / telnetd file, and / etc / init.d / rcS file. Each object is written into a software hash chain according to a fixed number to prevent the seemingly consistent chain root from being obtained after changing the object arrangement order at runtime.

[0036] When the configuration partition contains network addresses, wireless parameters, and user settings, it is divided into a stable area and a service-variable area according to the list of valid configurations. The stable area includes startup scripts, permission configurations, firmware update policies, and management service parameters. The service-variable area does not directly enter the firmware main chain. The service-variable area is verified through independent configuration version records to avoid normal parameter modifications triggering firmware corruption alarms.

[0037] Each MTD partition is read using a streaming hash method. The device reads a fixed-length data block from the flash memory each time and continuously updates the SHA-256 context. After reading all stable regions of a partition, the partition metric is output, so that devices with limited available memory do not need to load the complete firmware into memory at once.

[0038] Construct the software hash chain corresponding to the r-th baseline establishment or runtime verification according to Formula 1:

[0039] In Formula 1, Let H represent the initial chain node in the r-th chain construction process, and let H represent the SHA-256 hash operation. Indicates the unique identifier of the device. This indicates the batch or round identifier for baseline establishment. This indicates a data concatenation operation.

[0040] In Formula 1, This represents the chain node corresponding to the k-th firmware object during the r-th chain construction process. This indicates the chain node corresponding to the previous firmware object. This represents the fixed number of the k-th firmware object. This represents the starting position, capacity, erase block capacity, and stable region mapping of the k-th firmware object. Indicates the current valid firmware version. This represents the current SHA-256 metric value of the k-th firmware object.

[0041] In Formula 1, denoted as the root of the software hash chain generated during the r-th chain construction process, and K represents the total number of firmware objects entering the software hash chain; when the content, location, capacity, version, and stable region mapping of any preceding firmware object changes, the corresponding chain node and all subsequent chain nodes change.

[0042] During the initial deployment, baseline partition metrics, baseline key file metrics, and baseline chain roots are generated, and baseline records are saved to the baseline record area and the golden image list area of ​​the configuration partition, respectively. The two baseline records contain a mutual verification digest. If the two baseline records are inconsistent, it is not allowed to directly select one to overwrite the other. Instead, a baseline record anomaly is generated and a full firmware verification is initiated.

[0043] Before a legitimate firmware update begins, the firmware update package signature, target device model, firmware version increment status, and update window authorization status are verified. After the update is completed and passes the startup check, the software hash chain is rebuilt, and the new chain root is bound to the firmware update list. Modification of the baseline record is prohibited outside of the firmware update window.

[0044] Regarding parameter adjustments: When flash read speed is low, reduce the single hash read block length and extend the normal verification cycle; when the available memory of the device increases, increase the hash read block length; when the variable fields of the configuration partition service are adjusted, update the stable region mapping synchronously, but do not change the measurement order of the boot partition and firmware partition.

[0045] Through the above processing, this method writes firmware content, partition location, partition capacity, firmware version, and device identity together into the software hash chain, which can identify firmware content replacement, partition boundary modification, old version rollback, and cross-device baseline copying. This solves the problem that when comparing only the hash of a single firmware file, the measurement objects are independent of each other and cannot reflect the order of firmware composition.

[0046] Example 3: Based on all the above examples, this example uses a cross-layer event continuity identification algorithm for the multi-source attack event monitoring step and the firmware destruction attack stage identification step. Specifically, it performs event standardization, event trust assignment, time decay processing, stage evidence aggregation, and disposal instruction generation.

[0047] Port connection events include continuous probes to Telnet, SSH, and HTTP management ports within a short period of time; login failure events include continuous authentication failures from the same source address, default account attempts, and short-term source address switching; and exploitation events include abnormal management session establishment, unauthorized file uploads, and abnormal command interpreter startup.

[0048] Privilege escalation events include user identity jumps by ordinary privilege processes, unauthorized setting of execution permissions, abnormal memory mapping contention, abnormal kernel module loading, and access to sensitive device nodes. Destructive events include MTD erase requests outside the firmware update window, MTD write requests, boot partition writes, large-scale continuous writes to firmware partitions, batch deletion of critical files, and software hash chain mismatches.

[0049] Each monitoring event generates the event time, source address, target port, process identifier, parent process identifier, user identifier, operation object, operation type, firmware update window status, and the trustworthiness of the acquisition channel. The trustworthiness of the acquisition channel is determined based on the consistency of kernel audit records, system log records, process status records, and network connection records.

[0050] The confidence level of the attack phase at the t-th monitoring time and the s-th attack phase is calculated according to Formula 2:

[0051] In Formula 2, This represents the credibility of the attack phase at the t-th monitoring time and the s-th attack phase. This indicates the credibility of the attack phase in the preceding attack phase. This represents the coefficient of continuity of the previous attack phase on the current attack phase.

[0052] In Formula 2, This represents the set of evidence events corresponding to the s-th attack phase. This represents the weight of the influence of evidence event e on the s-th attack phase. This indicates the credibility of evidence event e at monitoring time t. Indicates the time when evidence event e occurs. This represents the effective timescale of evidence for the s-th attack phase.

[0053] In Formula 2, It includes the reconnaissance phase, the utilization phase, the power-enhancing phase, and the sabotage phase. This indicates the target attack phase with the highest credibility at the t-th monitoring time. When the destruction phase includes boot partition erasure, unauthorized firmware partition writing, and software hash chain mismatch, it is not required that all preceding phases occur. The evidence of destruction can directly drive the credibility of the destruction phase to reach the disposal condition.

[0054] When the credibility of the reconnaissance phase reaches the monitoring condition, the frequency of source address connection recording is increased. When the credibility of the utilization phase reaches the handling condition, the source address is blocked and unnecessary remote management sessions are closed. When the credibility of the privilege escalation phase reaches the handling condition, the abnormal process is terminated, the kernel module loading is frozen, and enhanced integrity verification is started. When the credibility of the destruction phase reaches the handling condition, unauthorized MTD writing is immediately frozen, the business network is isolated, and the recovery judgment process is initiated.

[0055] When the same source address continues to generate the same account, the same device fingerprint, and the same command sequence after changing the network address, the events corresponding to multiple source addresses can be merged into the same attack session by using session fingerprints, reducing the possibility of attackers circumventing single address threshold detection by switching addresses.

[0056] Regarding parameter adjustments: In home camera scenarios, the impact weight of Telnet exposure and default account events is increased; in industrial RTU scenarios, the impact weight of kernel module loading, boot partition writing, and abnormal outbound connection events is increased; when the device is under authorized maintenance, the impact of legitimate management connection events is reduced, but the impact of unauthorized MTD erasure events is not reduced.

[0057] Through the above processing, this algorithm no longer relies solely on a single login count threshold to determine attacks. Instead, it identifies the attack progression stage based on the temporal continuity of events at the network layer, process layer, and firmware storage layer. This solves the problem of inaccurate risk assessment when attackers change source addresses, bypass single thresholds, or directly perform firmware corruption from within the controlled device.

[0058] Example 4: Based on all the above examples, the runtime integrity verification steps specifically include MTD operation monitoring, verification cycle switching, local rapid verification, complete chain reconstruction, legitimate update exclusion, and abnormal object location.

[0059] The MTD operation monitoring process reads / proc / mtd to obtain the partition topology, and at the same time reads the write count, erase count, and recent operation time exported by the MTD driver. When the current kernel does not export the operation count, the calling process, target device node, starting address, and operation length of the MTD write function and MTD erase function are recorded through software audit hooks.

[0060] Under normal operating conditions, integrity verification is performed on the boot partition, stable area of ​​firmware partition and critical files at a cycle of 60 seconds. During the reconnaissance phase, the normal cycle is maintained. During the exploitation phase, the verification cycle is shortened to 15 seconds. During the privilege escalation phase, the verification cycle is shortened to 3 seconds. When an unauthorized MTD operation event occurs, the affected partition is immediately verified.

[0061] Local fast verification first reads the erased block overwritten by the abnormal write address and calculates the local metric value. The local metric value is then compared with the baseline block summary table. If the local metric value is inconsistent, the corresponding complete partition is read and the current software hash chain is rebuilt, reducing processor usage and flash bus contention caused by reading the entire flash memory for every minor risk event.

[0062] The complete chain reconstruction calculates the current partition metric and key file metric in the order of objects determined by Formula 1 to generate the current chain root. When the current chain root is inconsistent with the baseline chain root, the chain nodes and partition metric of each object are compared to locate the first firmware object with a difference and the affected partition range.

[0063] When the device is in the authorized firmware update window, the firmware update process must have a pre-registered process identifier, a successful signature verification record, a target partition list, and a write time range. MTD writes that meet all the conditions are marked as legitimate update transactions. When the write target exceeds the update list, the write time exceeds the authorized range, or the update process changes, the legitimate update transaction is immediately terminated and becomes a destructive phase event.

[0064] When a valid write occurs in the variable service area of ​​the configuration partition, the independent configuration version record is updated, but the firmware main chain is not updated; when a write occurs in the stable area of ​​the configuration partition, the integrity verification of the configuration partition is performed immediately to avoid frequent firmware main chain reconstruction triggered by normal changes in network parameters.

[0065] If the current root link, partition metric, and critical file metric are all consistent, but the process whitelist is abnormal, a system integrity error is generated and process isolation is performed; if the current root link is inconsistent, regardless of whether the process whitelist is normal, a firmware integrity error is generated and the recovery judgment process is initiated.

[0066] Regarding parameter adjustments: When the flash memory capacity increases, segmented verification is performed in the order of boot partition priority, firmware header priority, and abnormal write area priority; when the device service load increases, low-risk complete verification is delayed, but immediate verification triggered by unauthorized MTD operations is not delayed; after multiple rounds of verification stabilize, the normal verification cycle is gradually restored.

[0067] Through the above processing, this method dynamically switches the verification cycle at risk stages and uses local block digests and complete software hash chains to form a two-level verification, solving the problems of fixed high-frequency complete verification consuming device computing power and fixed low-frequency verification failing to detect firmware erasure in a timely manner.

[0068] Example 5: This example is based on all the above examples. The graded protection in the graded protection and recovery steps specifically includes attack surface hardening, source blocking, process handling, firmware write restrictions, alarm shaping, and enterprise WeChat push notifications.

[0069] The attack surface hardening process checks Telnet ports, SSH ports, HTTP management ports, default accounts, empty passwords, debugging services, anonymous file transfer services, and unnecessary startup scripts based on the device firmware object file, and generates executable shell hardening tasks according to risk priority.

[0070] When the Telnet service is not a necessary service for the device's business, stop the Telnet daemon and delete the auto-start item in the startup script. When remote management must be retained, restrict the management source address and prohibit login with empty passwords. When the default account exists, generate a password update task. When the debugging service exists, close the debugging entry in normal operation.

[0071] Once the stage credibility is met and the handling conditions are met, the attack source address is written into the temporary blocking table. If the login fails five times consecutively, the source address will be blocked for 30 minutes. When the same attack session switches source addresses, the newly added source address will be blocked synchronously based on the session fingerprint.

[0072] Once the trustworthiness of the privilege escalation phase reaches the disposal condition, the abnormal process and its child processes are terminated, the corresponding executable file summary and parent-child process relationship are recorded, the root file system is remounted to read-only state, and non-firmware update processes are restricted from accessing the MTD device node.

[0073] Once the credibility of the compromise phase reaches the handling conditions, stop non-essential network services, maintain the minimum network connection required for the WeChat Work alarm channel, freeze the firmware update entry, initiate real-time verification of the affected partition, and save a snapshot of the attack event.

[0074] Alarm events include device identifier, device address, attack source, Chinese attack stage, severity level, target partition, abnormal process, detection basis, current protection action, and event occurrence time. The reconnaissance stage is mapped to the medium-risk level, the exploitation stage is mapped to the high-risk level, and the privilege escalation stage and the destruction stage are mapped to the severe level.

[0075] The WeChat alarm system only pushes high-risk and critical level events in real time, with an interval of no less than 2 seconds between two consecutive pushes. When multiple events occur within the push interval, they are aggregated according to the attack session, and events with higher attack stages and higher target partition importance are prioritized for retention.

[0076] When a device is temporarily unable to access the WeChat Work interface, an alarm will be written to a local sequential queue. Once the network is restored, the alarm will be resent according to the event time and severity level. After the restoration is completed, a monitoring summary will be generated, which includes the number of reconnaissance events, the number of exploitation events, the number of privilege escalation events, the number of sabotage events, the number of blocked sources, and the restoration execution results.

[0077] Through the above processing, this method directly converts the attack phase identification results into service shutdown, source blocking, process termination, MTD write restriction, and real-time Chinese alarm actions, solving the problem that the detection component only generates logs and cannot prevent the attack from continuing to advance to the firmware corruption stage.

[0078] Example 6: Based on all the above examples, the firmware recovery in the graded protection and recovery steps specifically includes recovery condition confirmation, recovery image selection, recovery image verification, damaged partition write-back, write-back result verification, controlled reboot, and post-boot review.

[0079] The recovery condition verification process checks the current chain root, partition metric, MTD abnormal operation records, and attack phase credibility. When the current chain root is inconsistent and the differing objects are located in the boot partition or firmware partition, an automatic recovery task is generated. Only when critical files are abnormal and the firmware partitions are consistent, the abnormal files are first recovered from the golden file list, and then the full chain verification is re-executed.

[0080] When the device adopts a dual firmware partition structure, after the integrity of the currently running partition is abnormal, the image signature, image version, target device model and software hash chain root of the inactive partition are read. After all are verified, the inactive partition is set as the next boot partition, and a boot success confirmation time limit is set for the current recovery task.

[0081] When the device adopts a single firmware partition structure, the golden image corresponding to the damaged partition is read from the read-only recovery area; when the boot partition is damaged and the device is still running, the golden copy of the boot partition is written back first to avoid the device losing its boot capability after power failure or restart before the recovery is completed.

[0082] The recovery image uses RSA-2048 signature and SHA-256 digest to perform software verification. The signature public key is written into the recovery program during the firmware building stage. If any of the image signature, device model, image version, or image digest fails verification, the write-back is stopped and the device remains in network isolation.

[0083] Before writing back the damaged partition, the business processes accessing the target partition are stopped. The recovery image is divided into multiple recovery data blocks according to the erase block boundaries. Erasure, writing, reading back and block digest comparison are performed in sequence. If the current recovery data block read back digest is inconsistent, it is rewritten. Automatic recovery is terminated when the number of consecutive failures reaches the limit.

[0084] After all recovery data blocks are written, the target partition metric is recalculated and the recovered software hash chain is reconstructed according to Formula 1. The recovered chain root must be consistent with the target chain root recorded in the recovery image list. If the chain roots are inconsistent, normal startup will not be performed.

[0085] After a controlled reboot, the recovery daemon checks the kernel boot completion flag, critical service startup status, network interface status, critical file integrity, and software hash chain results. If the boot check passes, it submits a boot success flag. If the boot check fails to complete within the confirmation time limit, it increments the boot failure count and switches to the previous available firmware partition or reloads the gold image.

[0086] When the legitimate firmware version remains unchanged, the recovery process does not update the baseline chain root; when the recovery image belongs to a verified new version, a new baseline must be established after the signed firmware update transaction is completed to prevent attackers from writing unauthorized firmware into the baseline through the recovery process.

[0087] Through the above processing, this method sequentially completes image signature verification, block write-back, read-back verification, software hash chain review, and boot health check after firmware anomaly, solving the problem of corrupted images being restarted due to only performing firmware partition switching without verifying the recovery image and recovery results.

[0088] Example 7: This example is based on all the above examples and uses a BusyBox-based IP camera to illustrate the actual operation of this method.

[0089] The IP camera uses an ARM926EJ-S processor, runs a Linux 3.4 kernel and BusyBox 1.19.4, and has an 8MB SPIFlash capacity. The flash memory includes a 256KB boot partition, a 64KB configuration partition, and a 7872KB firmware partition. The device is not equipped with a TPM chip, TrustZone extension, BMC management controller, or independent security coprocessor.

[0090] The defense agent runs as a background daemon. Upon initial startup, it reads three MTD partitions and calculates the SHA-256 metrics of the stable regions of the three partitions, as well as / etc / passwd, / etc / shadow, / bin / busybox, / sbin / telnetd, and / etc / init.d / rcS. Then, it builds a baseline software hash chain in a fixed order.

[0091] Under normal conditions, the attack event monitoring cycle is set to 3 seconds, the MTD integrity verification cycle is set to 60 seconds, the login failure blocking threshold is set to 5 times, the source address blocking time is set to 30 minutes, and the minimum push interval for WeChat alarms is set to 2 seconds.

[0092] In the isolated test network, the test terminal first continuously scans the camera management port to detect and identify events during the defense proxy reconnaissance phase; the test terminal then continuously submits erroneous credentials to the Telnet service. The third erroneous credential generates an exploitation phase anomaly record, and the fifth erroneous credential triggers the blocking of the source address.

[0093] After the test terminal switches its source address and establishes an unauthorized management session, the test environment submits a controlled privilege escalation test payload to the device. The attack monitoring process generates privilege escalation phase events based on abnormal memory mapping behavior, user identity changes, and suspicious process startup records, and immediately executes abnormal process termination, root file system read-only mounting, and enhanced integrity verification.

[0094] The test environment then triggered a boot partition erase test under isolated conditions. The MTD operation monitoring process identified boot partition erase requests within non-firmware update windows and generated a corruption phase event. The system immediately froze subsequent MTD writes, isolated non-essential service networks, and performed boot partition hash verification.

[0095] The current boot partition metric and the current software hash chain root are inconsistent with the baseline record. The WeChat alarm pushes a severe alarm, which includes the attack phase "damage", the target partition "boot partition", the abnormal operation type, the attack source, the detection time, and the current recovery status.

[0096] The recovery process reads the golden copy of the boot partition and completes RSA-2048 signature verification. Then, the boot partition is written back according to the erase block boundaries. After each recovery data block is written, a readback digest comparison is performed. After all data blocks are verified, the boot partition metric and software hash chain root are recalculated.

[0097] During the test, the system detected changes in the MTD partition metric within 60 seconds and completed the recovery image loading, signature verification, corrupted partition write-back, software hash chain verification, and device restart within approximately 185 seconds. After the device restarted, critical services resumed operation, and the software hash chain root was consistent with the target baseline chain root.

[0098] The defense agent saves attack session identifiers, four-stage trust changes, MTD abnormal operation records, verification cycle changes, partition metrics, software hash chain nodes, WeChat push records, recovery data block write results, and startup health check results, enabling a firmware corruption attack to be traced from initial reconnaissance to recovery completion.

[0099] Regarding parameter adjustments: When processor performance is low, adjust the normal MTD verification cycle to 120 seconds, while retaining the instant verification of unauthorized MTD operations; when the industrial RTU is in a high-security operating environment, reduce the login failure ban threshold to 3 times; when the firmware partition capacity increases, use local fast verification to first locate the abnormal erase block, and then start the complete software hash chain reconstruction.

[0100] Through the above processing, this method forms a complete technology chain of "device filing - software hash chain baseline construction - multi-source event monitoring - attack phase identification - dynamic integrity verification - graded protection and alarm - firmware recovery - post-recovery review", enabling low-cost IoT devices without dedicated security hardware to continue to use existing processor and flash memory resources to complete attack identification, alarm and recovery after the firmware is erased.

Claims

1. A method for defending against firmware corruption attacks on Internet of Things (IoT) devices based on software hash chains, characterized in that, Includes the following steps: Step S1: Read the processor architecture, kernel version, firmware version, MTD partition table, partition capacity, erase block capacity, mount status, network management port, firmware update process and current running process of the IoT device; establish protection objects according to the boot partition, configuration partition, firmware partition, key files and key processes; generate device firmware object file and protection object set; and send the device firmware object file and protection object set to steps S2 and S3. Step S2: Receive the device firmware object file and the protection object set, determine the stable region, fixed number, and measurement order of each firmware object, calculate the measurement value of each firmware object, and continuously write the device identifier, firmware object number, partition geometry parameters, firmware version, measurement value, and previous chain node into the hash calculation process to generate a baseline software hash chain, a baseline chain root, and a baseline measurement record. Then, send the baseline software hash chain, the baseline chain root, and the baseline measurement record to step S5. Step S3: Receive the device firmware object file, configure the monitoring object according to the network management port, firmware update process, MTD device node and currently running process, collect port connection events, login failure events, abnormal management session events, permission change events, process start events, kernel module loading events, MTD write events, MTD erase events, firmware update status and outbound connection status, generate firmware damage attack monitoring event stream, and send the firmware damage attack monitoring event stream to step S4; Step S4: Receive the firmware destruction attack monitoring event stream, and identify the reconnaissance stage, exploitation stage, privilege escalation stage, and destruction stage based on the occurrence time, source address, operation object, process relationship, trusted status of the acquisition channel, valid time of evidence, and continuous status of the attack stage for each monitoring event. Generate the target attack stage and the stage control command, and send the target attack stage and the stage control command to steps S5 and S6. Step S5: Receive the target attack phase, the phase control command, the baseline software hash chain, the baseline chain root, and the baseline metric record. Determine the integrity verification range and integrity verification cycle based on the target attack phase. First, calculate the local metric value of the abnormal write area. When the local metric values ​​are inconsistent, calculate the metric value of the corresponding complete partition and reconstruct the current software hash chain. Compare the current chain root, the current partition metric value, the current critical file metric value, and the process whitelist check result with the corresponding baseline record to generate firmware integrity verification results and abnormal firmware object location results. Send the firmware integrity verification results and the abnormal firmware object location results to step S6. Step S6: Receive the target attack phase, the phase control command, the firmware integrity verification result, and the abnormal firmware object location result. Based on the target attack phase, execute network service restrictions, attack source blocking, abnormal process termination, unauthorized MTD write freezing, and tiered alarms. When the firmware integrity verification result is abnormal, determine the firmware recovery path based on the device partition structure, verify the recovery image, and perform recovery on the damaged partition. Generate protection handling results and recovery execution results, and send the protection handling results and recovery execution results to step S7. Step S7: Receive the protection and handling results and the recovery execution results, recalculate the recovery partition metric and rebuild the recovered software hash chain, check the recovered chain root, device startup status, critical service status, network interface status and critical file integrity status, generate recovery feedback records, updated monitoring parameters and updated integrity verification parameters, and send the updated monitoring parameters and updated integrity verification parameters to steps S3 and S5.

2. The method for defending against firmware corruption attacks on IoT devices based on software hash chains according to claim 1, characterized in that, In steps S1 and S2, a partition object table is established according to the starting address of the MTD partition. The partition object table records the device node, partition name, partition capacity, erase block capacity, mount path, read / write attributes, and firmware version association information. The configuration partition is divided into a stable area and a service-variable area. The stable area includes startup scripts, permission configurations, firmware update policies, and management service parameters. The service-variable area is verified through independent configuration version records. The boot partition, configuration partition stable area, firmware partition and key files are arranged in order according to fixed numbers, and each firmware object and its corresponding intermediate result inherits the corresponding fixed number.

3. The method for defending against firmware corruption attacks on IoT devices based on software hash chains according to claim 2, characterized in that, In step S2, each MTD partition is divided into multiple consecutive read blocks according to the available memory of the IoT device, and the corresponding partition's metric value is generated by streaming hash calculation. The initial chain node is generated based on the device identifier and the baseline batch identifier. The previous chain node, the current firmware object number, the partition geometry parameters of the current firmware object, the current firmware version and the current metric value are concatenated and then SHA-256 hash calculation is performed to generate the current chain node. The chain node corresponding to the last firmware object is determined as the baseline chain root, and the baseline measurement record is saved to the baseline record area and the golden mirror list area respectively. Once the legitimate firmware update is complete and the startup check passes, the baseline software hash chain is regenerated. Modification of the baseline metric record is prohibited during non-firmware update windows.

4. The method for defending against firmware corruption attacks on IoT devices based on software hash chains according to claim 3, characterized in that, In steps S3 and S4, the reconnaissance phase corresponds to continuous port probing events, the exploitation phase corresponds to continuous login failures, default account attempts, abnormal management session establishment, and unauthorized file upload events, the privilege escalation phase corresponds to user identifier transitions, abnormal memory mapping contention, abnormal kernel module loading, and sensitive device node access events, and the destruction phase corresponds to MTD erasure, MTD writing, boot partition writing, continuous firmware partition writing, batch deletion of critical files, and software hash chain mismatch events outside the firmware update window. An attack session fingerprint is generated based on the account identifier, device fingerprint, and command sequence. Monitoring events with different source addresses but continuous behavior are then grouped into the same attack session based on the attack session fingerprint.

5. The method for defending against firmware corruption attacks on IoT devices based on software hash chains according to claim 4, characterized in that, In step S4, the attack stage credibility status of each attack stage is generated based on the influence weight of the evidence event corresponding to each attack stage, the credibility status of the acquisition channel, the event occurrence time, the validity time of the evidence, and the status of the previous attack stage. The attack phase with the highest credibility and that meets the corresponding phase determination conditions is defined as the target attack phase. When any of the following destructive events is detected: boot partition erasure, unauthorized firmware partition writing, and software hash chain mismatch, the target attack phase is directly identified as the destructive phase, and an immediate integrity verification instruction and an unauthorized MTD write freeze instruction are generated.

6. The method for defending against firmware corruption attacks on IoT devices based on software hash chains according to claim 5, characterized in that, In step S5, firmware integrity verification is performed according to the first verification cycle under normal operating conditions, firmware integrity verification is performed according to the second verification cycle which is shorter than the first verification cycle when in the exploitation phase, and firmware integrity verification is performed according to the third verification cycle which is shorter than the second verification cycle when in the privilege escalation phase. When an unauthorized MTD operation event is detected, the erase block covered by the abnormal operation address is read and a local metric is calculated. The local metric is then compared with the baseline block summary record. When the local metric values ​​are inconsistent, the corresponding complete partition is read, the current partition metric value is calculated, and the current software hash chain is reconstructed according to a fixed metric order. The location result of the abnormal firmware object is determined based on the first different chain node in the current software hash chain and the baseline software hash chain.

7. The method for defending against firmware corruption attacks on IoT devices based on software hash chains according to claim 6, characterized in that, In step S6, when in the exploitation phase, the attack source is written into the blocking table and the corresponding unauthorized management session is closed; when in the privilege escalation phase, the abnormal process and its child processes are terminated, kernel module loading is restricted, and the root file system is adjusted to read-only state; when in the destruction phase, unnecessary network services are stopped, firmware update entry is frozen, and the network connection corresponding to the alarm channel is maintained. The alarm severity level is determined based on the target attack stage, and the reconnaissance stage, exploitation stage, privilege escalation stage and destruction stage are respectively mapped to the corresponding Chinese attack stage names; The alarm message is generated by the device identifier, attack source, Chinese attack stage name, alarm severity level, target partition, abnormal process, detection basis, current protection action and event occurrence time, and the alarm message that meets the push conditions is pushed through the WeChat Work interface. When two consecutive alarm messages do not reach the minimum push interval, the corresponding alarm events are aggregated according to the attack session.

8. The method for defending against firmware corruption attacks on IoT devices based on software hash chains according to claim 7, characterized in that, In steps S6 and S7, the firmware recovery path includes the backup firmware partition switching path and the gold image write-back path. When executing the backup firmware partition switching path, the image signature, image version, target device model and software hash chain root corresponding to the inactive firmware partition are verified, and the inactive firmware partition is set as the next boot partition after the verification is successful. When executing the gold image write-back path, the signature, device model, image version and image digest of the gold image are verified, and the erase, write, read back and block digest comparison are performed on the damaged partition in sequence according to the erase block boundary; After all recovered data blocks are written, the recovery partition metric is recalculated and the recovered software hash chain is rebuilt. When the recovered chain root is consistent with the target chain root and the device startup status, critical service status, network interface status, and critical file integrity status all meet the recovery conditions, a recovery success result is generated and the device service connection is restored.

Images