A method for controlling the status of a file system

Abstract

This invention discloses a method for controlling system status by identifying files, belonging to the field of embedded system control technology. The method includes the following steps: Step 1, service startup and directory monitoring; Step 2, file detection and parsing; Step 3, content reading and instruction extraction; Step 4, progressive security verification; Step 5, execution and operation logging. This invention achieves system status control through physical contact file identification, replacing traditional UI, network, or hardware interface methods. It avoids the risks of remote attacks and interface exposure, employs a five-layer progressive verification system to ensure that control behavior is unforgeable, unreplayable, and fully auditable. It also supports multiple storage media such as USB and SD cards, and is compatible with various commands such as debugging, upgrading, and configuration. It can still be easily operated in scenarios without network or UI, balancing high security and ease of use in the field.

Description

Technical Field

[0001] This invention relates to the field of embedded system control technology, and more specifically, to a method for controlling the state of a system by identifying files. Background Technology

[0002] With the rapid development of embedded devices, industrial control systems and Internet of Things (IoT) technologies, the deployment scale of various intelligent devices in fields such as industrial control, environmental monitoring, healthcare, and vehicle security continues to expand, leading to an increasing demand for equipment system status management, debugging, maintenance, and security control.

[0003] Currently, the main methods for status control and maintenance management of existing equipment include the following: setting hidden menus or specific operation entries in the software user interface (UI) to realize functions such as switching debugging modes and modifying parameters; physical contact control through debugging interfaces such as serial ports and JTAG or dedicated hardware DIP switches; remote command issuance and status management through network remote interfaces (such as Telnet, SSH, WebAPI); and execution of control operations after authorization verification through password authentication or dedicated client software.

[0004] Furthermore, existing methods all have obvious drawbacks: UI hidden menus are easily accidentally touched or discovered, resulting in poor concealment; serial ports, DIP switches, etc., require disassembly for operation, making on-site maintenance inconvenient; network remote control depends on network connectivity, making it difficult to apply in weak network or isolated scenarios, and it faces the risk of remote attacks; password authentication requires UI cooperation and passwords are easily leaked; hardware switches have limited functionality and cannot support complex commands.

[0005] In addition, the existing solution has a single instruction type and poor scalability, requiring the maintenance of multiple protocols for different functions; the authentication and execution links are coupled, and once the credentials are leaked, unauthorized control will be caused; at the same time, there is a lack of a unified and auditable operation carrier, making it difficult to form complete logs and trace responsibility.

[0006] Therefore, there is a need for a new control method that can achieve system state control through convenient physical contact without requiring conventional UI interaction and network connection, while possessing high security, versatility and auditability. Summary of the Invention

[0007] This invention mainly provides a method for identifying the status of a file control system, which can solve the problems mentioned in the background art.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a method for controlling the status of a file system by identifying its status, comprising:

[0009] S1. The file recognition and control service starts in the background of the device, loads system configuration parameters and preset public keys, and starts periodic file scanning and monitoring of the specified storage directory.

[0010] S2. When a new file is detected in the directory, determine whether it is a control file by using the fixed prefix of the file name. If it is determined to be a control file, parse each field of the file name, extract the instruction type and file name check code, and complete the preliminary verification of the file name format.

[0011] S3. Read the complete contents of the control file and parse it to obtain detailed instruction parameters, security verification information and operation metadata;

[0012] S4. Perform five progressive security checks on the control file in sequence: file name verification, digital signature verification, timestamp and nonce anti-replay verification, permission level verification, and parameter validity verification. If any layer of verification fails, file processing will be stopped and a security alarm will be recorded.

[0013] S5. After all security verifications are passed, the corresponding system interface of the device is called to perform control operations according to the instruction type. After the operation is completed, the operation log is recorded, and the execution status and timestamp suffix are appended to the original control file for renaming.

[0014] Furthermore, in step S1, the file recognition and control service supports configuring multiple storage directory paths to be monitored and performing periodic scans on each monitored directory at preset intervals.

[0015] Furthermore, in step S2, the filename of the control file adopts a segmented convention format, which includes a fixed prefix, an instruction type field, a simplified parameter field, and a check code field in sequence; when determining the control file, the fixed prefix of the filename is matched, and during the initial verification, the check value is recalculated based on the valid field of the filename and compared with the filename check code.

[0016] Furthermore, in step S3, the control file content is stored in a structured format and, after parsing, is divided into protocol version, instruction body, security verification information, and operation metadata. The instruction body includes instruction type, execution action, and corresponding parameter set, while the security verification information includes timestamp, one-time random number, digital signature value, and key identifier.

[0017] Furthermore, in step S4, the five-layer progressive security verification is executed in a fixed order: the first layer verifies the legality of the file name format and verification code; the second layer verifies the digital signature through the device's built-in public key; the third layer verifies the validity period of the timestamp and the uniqueness of the one-time random number; the fourth layer matches the risk level of the instruction with the permission level corresponding to the signature key; and the fifth layer verifies the format and value range of the instruction parameters.

[0018] Furthermore, in step S5, when performing control operations, the corresponding system interface is called according to the instruction type. Before performing system upgrade operations, the current system version is automatically backed up, and if the operation fails, it is automatically rolled back to the original version. The operation log records the operation time, instruction type, execution result and exception information. When renaming the control file, the execution status identifier and timestamp are appended to the end of the original file name.

[0019] Furthermore, the monitored storage directory corresponds to at least one of the following: USB storage device, SD card, external hard drive, network shared directory, or a specified directory inside the device, and is compatible with multiple file system formats.

[0020] Furthermore, the device's built-in public key is pre-installed in the read-only storage area at the factory, forming an asymmetric encryption key pair with the private key held by the maintenance terminal; the digital signature is generated by the maintenance terminal using the private key, and the device terminal completes the signature verification by matching the corresponding public key with the key identifier.

[0021] The beneficial effects of the method for controlling the status of a file system according to the present invention are as follows:

[0022] By combining physical media transmission with five-layer progressive in-depth verification, remote network attacks can be prevented. At the same time, verification is performed from file name to content, from identity to permissions, from timeliness to parameter legality, effectively resisting file forgery and replay attacks.

[0023] Meanwhile, the entire process runs silently in the background without a UI entry point, keeping the control mechanism transparent to ordinary users. It also solves the problem of protocol fragmentation in traditional solutions by using a unified dual-file protocol to support multiple commands such as debugging, upgrading, configuration, and export within the same framework.

[0024] Finally, authorized personnel only need to insert the pre-generated control file to automatically complete the verification and execution without disassembling the device or connecting to the network. It is particularly suitable for isolated outdoor or industrial scenarios without network or UI, which greatly reduces the operation threshold and batch maintenance costs. With the complete operation log and file traceability mechanism, a dual audit link is formed to ensure full traceability. No new hardware is required, and the implementation cost is extremely low. Attached Figure Description

[0025] The present invention will now be described in further detail with reference to the accompanying drawings and specific implementation methods.

[0026] Figure 1 This is a schematic diagram of the method flow of the present invention;

[0027] Figure 2 This is a schematic diagram of the architecture design of the present invention;

[0028] Figure 3 This is a schematic diagram of the verification system of the present invention. Detailed Implementation

[0029] To make the technical solution of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] like Figures 1-3 As shown, this embodiment provides a technical solution: a method for controlling the status of a file system by identifying the status of the system, comprising:

[0031] Step 1: Service Startup and Directory Monitoring

[0032] like Figure 2 As shown, the file recognition and control service starts in the background of the device, loads system configuration parameters and preset public keys, and starts periodic file scanning and monitoring of the specified storage directory;

[0033] Specifically, the file recognition and control service supports configuring multiple storage directory paths to be monitored, and performs periodic scans on each monitored directory at preset intervals.

[0034] During the service startup phase, the service is loaded in the background after the device system is powered on. There is no front-end process entry or UI interaction entry. During the startup process, the service configuration file in the device's read-only storage area is read first. The configuration file is parsed and the preset monitoring directory list, scan cycle parameters, supported file system types, log storage path and capacity threshold and other running parameters are obtained. Then, the pre-stored public key set is read from the device's factory-preset ROM secure storage area and the key validity is verified. The public key data is classified and cached in the service running memory according to the key identifier. At the same time, the circular storage queue of the used nonce value and the circular storage buffer of the operation log are initialized to complete the initialization of the service running environment.

[0035] The directory monitoring mechanism is based on the system file system event notification mechanism or the timed polling mechanism. For Linux-like systems that support inotify / fswatch, the event-triggered mode is used first to listen for file addition and modification events in each monitored directory. When a storage medium mount event is detected, the mount point path is automatically included in the scan range. For embedded systems such as RTOS that do not support event notification, the timed polling mode is used. According to the preset configurable scan interval (e.g., 1-5 seconds), all configured monitored directory paths are traversed in turn. The file list under the directory is read through the system file interface, and the difference is compared with the previous scan result to identify the newly added file entries. At the same time, it is compatible with the directory read interface of multiple file systems such as FAT32, exFAT, NTFS, and ext4 to ensure that files can be identified normally under different storage media.

[0036] Finally, after completing initialization and monitoring startup, the service performs a full directory scan self-check to confirm that all configured monitoring directories are accessible, public key loading is error-free, and log storage is available. It then enters standby monitoring state, only waking up to execute the scan logic when directory changes are detected or polling time points are reached, ensuring that the control service does not affect the normal operation of the device's main business programs.

[0037] Step 2: File Detection and Parsing

[0038] When a new file is detected in the directory, the file name is used to determine whether it is a control file. If it is a control file, the file name fields are parsed to extract the instruction type and file name check code, and the file name format is initially checked.

[0039] Specifically, the filenames of control files adopt a segmented convention format, which includes a fixed prefix, an instruction type field, a simplified parameter field, and a checksum field in sequence. When determining a control file, the fixed prefix of the filename is matched. During the initial verification, the checksum is recalculated based on the valid fields of the filename and compared with the checksum of the filename.

[0040] First, it iterates through all newly added file entries identified in this round of scanning, reading the complete file name string of each file one by one. It is compatible with both UTF-8 and ASCII file name encoding formats. First, it removes the file extension to get the file name body, and then extracts a fixed length of characters from the beginning of the body. It performs a precise string match with the system's preset control file fixed prefix identifier SYS_CTRL. If the prefix does not match, it is directly determined to be a normal business file and skipped without further processing. This achieves rapid initial screening and greatly reduces unnecessary computational overhead.

[0041] Then, for files with successful prefix matching, the filename body is segmented using the underscore delimiter. The prefix field, instruction type field, simplified parameter field, and checksum field are extracted sequentially. At the same time, the number of fields obtained from the segmentation is checked to see if it meets the segmentation number agreed upon in the protocol. After the number of fields passes the verification, the extracted instruction type field is further matched with the system's built-in set of legal instructions. The legal instructions include seven categories: DEBUG (debug mode), UPGRADE (system upgrade), CONFIG (configuration modification), EXPORT (data export), RESET (system reset), BACKDOOR (backdoor access), and UNLOCK (permission unlock). Files whose instruction type is not in the legal set are judged to have an illegal format.

[0042] Next, filename integrity verification is performed. The three fields of prefix, instruction type, and simplified parameters obtained from the splitting are reassembled into the string to be verified in the original format separated by underscores. The SHA-256 hash algorithm is used to operate on the string to be verified, and the first four hexadecimal characters of the operation result are taken as the calculated verification value. The verification value is compared character by character with the verification code field extracted from the filename. If the two are completely consistent, the filename is determined to have passed the preliminary verification. If there is a difference, it is determined that the filename has been tampered with or has an incorrect format, and the verification fails.

[0043] After the initial filename verification is completed, a corresponding processing task is generated for the control files that pass the verification. Basic information such as file path, extracted instruction type, and simple parameters are stored in the task structure and added to the serial processing queue to await subsequent content reading and deep security verification. For files that fail the verification, the processing flow is terminated directly, and a security alarm log containing the filename, detection time, and reason for failure is recorded. At the same time, the system maintains a single-task serial processing mechanism, scheduling only one processing task to be executed at a time, and queuing the remaining tasks according to the order of detection, so as to avoid system resource competition and abnormal status caused by concurrent processing of multiple files.

[0044] Step 3: Content Reading and Command Extraction

[0045] Read the complete contents of the control file and parse it to obtain detailed instruction parameters, security verification information, and operation metadata;

[0046] Specifically, the control file content is stored in a structured format and, after parsing, is divided into protocol version, instruction body, security verification information, and operation metadata. The instruction body includes instruction type, execution action, and corresponding parameter set, while the security verification information includes timestamp, one-time random number, digital signature value, and key identifier.

[0047] The process begins by retrieving the current control file task from the serial processing queue. The file at the corresponding path is then opened in read-only mode via the standard file system interface. The file size is first checked to ensure it is within the preset legal range to prevent memory overflow caused by excessively large files. For small configuration control files, the entire file content is read into the memory buffer at once. For large firmware files used for system upgrades, a segmented reading method is adopted. The structured metadata area at the beginning of the file is read first, while the main firmware data is read as needed during the instruction execution phase. During the reading process, both LF and CRLF newline character formats are automatically compatible, and UTF-8 and ASCII encoded file content are also supported to ensure that control files generated in different maintenance environments can be read normally.

[0048] The content structured parsing calls the built-in JSON parsing library to perform syntax parsing on the read file structured content, verify the legality of the JSON format, and if there are syntax errors, the file is deemed invalid and processing is terminated. After parsing, the data is extracted into four modules according to the field hierarchy agreed upon in the protocol: The first module is the version protocol version field, which extracts the version number string for subsequent compatibility judgment; the second module is the command body, which further breaks down and extracts the type command type, action execution action, and parameter set, while verifying whether the command type is consistent with the file name extracted to avoid the exception of file name and content mismatch; the third module is the security verification information, which extracts the timestamp, nonce one-time random number, signature digital signature value, and key_id key identifier in sequence; the fourth module is the metadata operation metadata, which extracts the operator identifier and reason operation reason fields. The metadata is only used for auditing and does not participate in the command execution logic.

[0049] Next, the data from each module obtained through the parsing is checked for required fields through a field integrity verification mechanism. This confirms that core fields such as instruction type, execution action, digital signature, key identifier, timestamp, and nonce are not empty and that the data types meet the protocol requirements. If any required field is missing, the file format is deemed invalid. At the same time, a cross-consistency check between the file name and content is performed. The instruction type parsed from the content is compared with the instruction type extracted from the file name stage. If they are inconsistent, the processing is terminated and a security alarm is recorded. After the check passes, all the parsed data is structured and stored in the processing context of the current task to form a complete control task data packet, which is then passed to the subsequent security verification stage.

[0050] Finally, the temporary memory buffer occupied during file reading is released, the file handle is closed to avoid file resource occupation causing the storage medium to fail to be unloaded normally, and the current task status is marked as parsing completed and awaiting security verification. This is then updated in the task status table of the serial processing queue, waiting for scheduling to enter the five-layer progressive security verification process.

[0051] Step 4: Progressive Security Verification

[0052] like Figure 3 As shown, the control file is subjected to five progressive security checks in sequence: filename verification, digital signature verification, timestamp and nonce anti-replay verification, permission level verification, and parameter validity verification. If any layer of verification fails, file processing is stopped and a security alarm is recorded.

[0053] Specifically, the five-layer progressive security verification is performed in a fixed order: the first layer verifies the validity of the file name format and the verification code; the second layer verifies the digital signature using the device's built-in public key; the third layer verifies the validity period of the timestamp and the uniqueness of the one-time random number; the fourth layer matches the risk level of the instruction with the permission level corresponding to the signature key; and the fifth layer verifies the format and value range of the instruction parameters.

[0054] The process involves sequentially performing a first-level filename verification and a second-level digital signature verification. The first-level verification is based on the parsed complete filename field. It reassembles the prefix, instruction type, and simplified parameter fields and calculates the verification value using the SHA-256 hash algorithm. This value is then compared with the verification code extracted from the filename to confirm that the filename has not been tampered with or that there have been any abnormal file system reads during the reading and storage process. This layer of verification has extremely low computational cost and can quickly filter obviously illegal files, reducing the computational overhead of subsequent deep verification. The second-level digital signature verification matches the corresponding public key from the public key set cached in memory when the service starts, based on the parsed key_id key identifier. Then, it extracts all structured data from the file content except for the signature field, concatenates the fields in a fixed order as agreed in the protocol to generate the original signature, generates a message digest using the SHA-256 algorithm, and then uses the matched public key to perform a signature verification operation on the digital signature value using the RSA-2048 or ECC-P256 algorithm. If the signature verification passes, it confirms that the file was generated by the authorized entity holding the corresponding private key and that the file content is complete and has not been tampered with.

[0055] The third layer, timestamp and nonce anti-replay verification, and the fourth layer, permission level verification, are the core security layers for building a defense-in-depth system. The third layer anti-replay verification first reads the device's current system time, calculates the difference between the current time and the file's timestamp, and compares this difference with a preset validity period threshold (e.g., default 24 hours, configurable from 1 hour to 7 days). If the validity period is exceeded, the verification fails. Then, it reads the queue of the 1000 most recently used nonce values ​​stored in the service's memory, comparing each one with the current file's nonce value. If the value already exists in the queue, it's considered a replay attack, and the verification fails. If the verification passes, the current nonce value is written to the end of the queue, and the queue capacity reaches the limit. The system automatically overwrites the oldest stored history within a limited time. The fourth-level permission verification first matches the preset risk permission level mapping rules according to the instruction type. Data export and log viewing correspond to Level 1 permission requirements, configuration modification and debug mode switching correspond to Level 2 permission requirements, system upgrade and factory reset correspond to Level 3 permission requirements, and backdoor access and root permission unlocking correspond to Level 4 permission requirements. Then, it queries the permission level bound to the key based on the key_id of the current signing key and determines whether the key permission level is greater than or equal to the minimum permission level required by the current instruction. If the permission is insufficient, the verification fails. This achieves hierarchical authorization control of high-risk operations and prevents low-permission keys from performing high-risk operations.

[0056] Finally, the fifth layer of parameter validity verification is performed. Based on the parameter verification rules corresponding to the current instruction type, the data type, value range, and system compatibility of each parameter in the parameters set are verified one by one. For example, for debug instructions, the debug level and duration are verified to be within the legal range; for upgrade instructions, the target version number is verified to be higher than the current system version; and for configuration instructions, each configuration item is verified to conform to the system parameter specifications to prevent illegal parameters from causing system malfunctions. After all five layers of verification pass, the task status is marked as safe and verified, and the process proceeds to the instruction execution stage. If any layer of verification fails, all subsequent verification processes are immediately terminated, and a security alarm log containing the failure level, failure reason, file path, and detection time is recorded simultaneously. All context data of the task is cleaned up, and no system control operations are triggered to ensure that illegal files cannot have any impact on the device system.

[0057] Step 5: Execution and Operation Recording

[0058] After all security verifications are passed, the corresponding system interface of the device is called to execute the control operation according to the instruction type. After the execution is completed, the operation log is recorded, and the execution status and timestamp suffix are appended to the original control file and renamed.

[0059] Specifically, when performing control operations, the corresponding system interface is called according to the instruction type. Before performing system upgrade operations, the current system version is automatically backed up. If the operation fails, it is automatically rolled back to the original version. The operation log records the operation time, instruction type, execution result and exception information. When renaming the control file, the execution status identifier and timestamp are appended to the end of the original file name.

[0060] First, the corresponding execution processing function is matched according to the instruction type in the task context, and the device system native interface is called to perform control operations: For DEBUG type instructions, the system log output level is modified according to the debug level in the parameters, the SSH or local debug port with the corresponding permissions is opened, and a duration timer is started. After the duration specified by the parameters is reached, the debug port is automatically closed and the original log level is restored. For CONFIG type instructions, the legality of the configuration parameters is verified line by line, and then written to the device system configuration file and the configuration hot reload is triggered. It can take effect without restarting the device. For EXPORT type instructions, the device log, running data and other contents are read according to the data range specified by the parameters, packaged and generated into an export file and stored in the current storage medium. For UPGRADE type system upgrade instructions, the currently running system firmware is first fully backed up to the device local backup partition, and the backup version number and backup time are recorded. Then, the firmware data in the control file is read in segments and written to the system upgrade partition. After writing, the firmware integrity and version number are verified. If the verification is successful, it is marked to boot from the new partition on the next boot. If the verification fails, the original system partition is directly retained and the upgrade process is skipped.

[0061] If errors such as write exception or verification failure occur during execution, the rollback mechanism is automatically triggered to restore the original system firmware of the backup partition and clear the temporary upgrade data to ensure that the device is always in a working state. For RESET, BACKDOOR, and UNLOCK commands, the corresponding system interface is called to perform the corresponding operation in accordance with the preset permission and parameter rules.

[0062] After execution, a complete operation audit log is generated. The log content includes fields such as the system timestamp of the operation, instruction type, execution action, key identifier, operator information, operation reason, execution result status, execution time, and abnormal error information. The log is written to the device's local circular storage buffer, using a first-in-first-out circular overwrite mechanism. By default, the most recent operation record is retained, including all security alarm records of verification failures and operation records of successful executions. At the same time, for abnormal operations that fail verification, the risk level and failure reason are additionally marked to facilitate subsequent security audits and attack tracing. The log storage area is independent of the ordinary business data storage area, and only the control service has write permissions to prevent the log from being tampered with or deleted.

[0063] Finally, the original control file in the storage medium is renamed. Based on the original filename, an execution status indicator and a timestamp suffix are appended before the extension: if the execution is successful, _DONE_ followed by the current system time in year-month-day-hour-minute-second format is appended; if the execution fails, _FAIL_ followed by the corresponding timestamp and a simplified failure reason code is appended. After the renaming operation is completed, all memory context resources occupied by the task are released, all related file handles are closed, the task is removed from the serial processing queue, and the next pending task in the processing queue is scheduled. The entire execution and logging process is completed silently in the background without generating any prompts or pop-ups on the device UI, ensuring that the control mechanism is transparent to ordinary users.

[0064] To illustrate the effects achieved by using this invention, we provide the following application scenario examples:

[0065] Scenario Example 1

[0066] This scenario is applied to troubleshooting production anomalies in a chemical plant's PLC controller. The equipment is deployed in an isolated industrial intranet environment, and the equipment UI only provides basic operation permissions to operators, with no maintenance or debugging access.

[0067] The specific implementation steps are as follows:

[0068] Control file preparation: Maintenance engineers configure debugging parameters in a dedicated tool on their office computers and generate corresponding control files, named as follows:

[0069] SYS_CTRL_DEBUG_ENABLE_A3F2.dat

[0070] The file content is in JSON format and includes command parameters such as debug level and duration. It also includes operator identification and metadata about the reason for the operation. Finally, the file content is digitally signed using the private key of the vendor's level 2 maintenance personnel to generate a complete control file.

[0071] On-site media preparation: Copy the generated control file to a regular USB flash drive, and the engineer takes the flash drive to the equipment site.

[0072] Automatic device identification and execution: When the USB flash drive is inserted into the USB interface of the PLC controller, the file identification and control service in the device background detects the new control file within 3 seconds and automatically completes file name parsing, content reading and five-layer progressive security verification.

[0073] Command execution takes effect: After all verifications are successful, the device automatically starts debug mode, enables SSH access permissions, adjusts the system log level to the corresponding debug level, and starts a timer. After the preset duration is reached, debug mode is automatically turned off and the original log configuration is restored.

[0074] Operation logging: After execution, the device automatically records a complete operation audit log and renames the original control file on the USB drive, as shown below:

[0075] SYS_CTRL_DEBUG_ENABLE_A3F2_DONE_20260625143022.dat

[0076] Engineers can connect to the device via SSH to retrieve detailed logs and complete troubleshooting. The entire process requires no operation on the device's UI, and ordinary operators are unaware of the existence of the debugging function.

[0077] Scenario Example 2

[0078] This scenario involves firmware upgrades for air quality monitoring stations deployed in the field. A total of 50 monitoring station devices are located in a remote, network-free environment, and the on-site personnel lack professional equipment maintenance skills.

[0079] The specific implementation steps are as follows:

[0080] Upgrade file preparation: Senior engineers prepare system upgrade control files on their office devices. The files embed the V2.1.5 firmware version and are named as follows:

[0081] SYS_CTRL_UPGRADE_V2.1.5_C9E7.bin

[0082] The file contains upgrade instructions and corresponding version parameters, digitally signed using a Level 3 senior engineer's private key, and sets the timestamp validity period to 7 days to accommodate the cycle requirements of batch upgrades.

[0083] Bulk media distribution: Copy the same upgrade control file to 50 USB flash drives and distribute them to field personnel.

[0084] Batch execution on site: On-site personnel go to each monitoring station in turn, and only need to insert the USB flash drive into the USB port of the monitoring station equipment. No other operation is required.

[0085] Automatic device processing: After each device detects the control file in the USB flash drive, it automatically completes file name parsing, content reading and five-layer security verification. After the verification is successful, it first fully backs up the currently running system firmware to the device's local backup partition, and then writes the new firmware data in segments. After the writing is completed, it verifies the integrity and version validity of the firmware.

[0086] Automatic result processing: If the upgrade verification is successful, the system will be marked to boot from the new firmware partition on the next system startup, a success log will be recorded and the control file will be renamed; if write errors or verification failures occur during the upgrade process, the system will automatically trigger the rollback mechanism to restore the backed-up original system firmware and clear the temporary upgrade data to ensure that the device can run normally. At the same time, the failure status and failure reason will be marked when renaming the file.

[0087] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A method for controlling the status of a file system by identifying its status, characterized in that: S1. The file recognition and control service starts in the background of the device, loads system configuration parameters and preset public keys, and starts periodic file scanning and monitoring of the specified storage directory. S2. When a new file is detected in the directory, determine whether it is a control file by using the fixed prefix of the file name. If it is determined to be a control file, parse each field of the file name, extract the instruction type and file name check code, and complete the preliminary verification of the file name format. S3. Read the complete contents of the control file and parse it to obtain detailed instruction parameters, security verification information and operation metadata; S4. Perform five progressive security checks on the control file in sequence: file name verification, digital signature verification, timestamp and nonce anti-replay verification, permission level verification, and parameter validity verification. If any layer of verification fails, file processing will be stopped and a security alarm will be recorded. S5. After all security verifications are passed, the corresponding system interface of the device is called to perform control operations according to the instruction type. After the operation is completed, the operation log is recorded, and the execution status and timestamp suffix are appended to the original control file for renaming.

2. The method for controlling the status of a file system according to claim 1, characterized in that: In step S1, the file recognition and control service supports configuring multiple storage directory paths to be monitored and performing periodic scans on each monitored directory at preset intervals.

3. The method for controlling the status of a file system according to claim 1, characterized in that: In step S2, the filename of the control file adopts a segmented convention format, which includes a fixed prefix, an instruction type field, a simplified parameter field, and a check code field in sequence. When determining the control file, the fixed prefix of the filename is matched. During the initial verification, the check value is recalculated based on the valid field of the filename and compared with the filename check code.

4. The method for controlling the status of a file system by identifying the status according to claim 1, characterized in that: In step S3, the control file content is stored in a structured format and, after parsing, is divided into protocol version, instruction body, security verification information, and operation metadata. The instruction body includes instruction type, execution action, and corresponding parameter set. The security verification information includes timestamp, one-time random number, digital signature value, and key identifier.

5. A method for controlling the status of a file system by identifying documents according to claim 1, characterized in that: In step S4, the five-layer progressive security verification is performed in a fixed order: the first layer verifies the legality of the file name format and verification code; the second layer verifies the digital signature through the device's built-in public key; the third layer verifies the validity period of the timestamp and the uniqueness of the one-time random number; the fourth layer matches the risk level of the instruction with the permission level corresponding to the signature key; and the fifth layer verifies the format and value range of the instruction parameters.

6. The method for controlling the status of a file system according to claim 1, characterized in that: In step S5, when performing control operations, the corresponding system interface is called according to the instruction type. Before performing system upgrade operations, the current system version is automatically backed up, and if the operation fails, it is automatically rolled back to the original version. The operation log records the operation time, instruction type, execution result and exception information. When renaming the control file, the execution status identifier and timestamp are appended to the end of the original file name.

7. A method for controlling the status of a file system by identifying documents according to claim 1, characterized in that: The monitored storage directory corresponds to at least one of the following: USB storage device, SD card, external hard drive, network shared directory, or a specified directory inside the device, and is compatible with multiple file system formats.

8. The method for controlling the status of a file system by identifying the status according to claim 1, characterized in that: The device's built-in public key is pre-installed in the read-only storage area at the factory, forming an asymmetric encryption key pair with the private key held by the maintenance terminal; the digital signature is generated by the maintenance terminal using the private key, and the device terminal completes the signature verification by matching the corresponding public key with the key identifier.

Images