A physical device driverless identification processing system based on firmware information analysis

Abstract

The present application relates to the technical field of computer hardware identification and information processing, and particularly relates to a physical device driverless identification processing system based on firmware information analysis, which comprises a device bus enumeration module, a firmware information extraction module, an information analysis module, an identification mapping and completion module and an identification result output module; wherein: the device bus enumeration module generates a device list by scanning the hardware bus in the computer system; the firmware information extraction module is used for reading original firmware data from a predefined firmware storage area; and the information analysis module is used for analyzing device identity information fields from the original firmware data. Through the driverless access, rule analysis and identification completion collaborative mechanism, the present application realizes unified identification and structured output of multiple types of physical devices in a driverless environment, and improves the integrity and adaptability of device identification.

Description

Technical Field

[0001] This invention relates to the field of computer hardware identification and information processing technology, and in particular to a driverless identification and processing system for physical devices based on firmware information parsing. Background Technology

[0002] In scenarios with high hardware requirements, such as information security and system maintenance, it is often impossible to rely on operating system-level drivers to complete device identification and information acquisition. Especially in bare-metal boot, custom system deployment, and driver-restricted industrial terminals or embedded platforms, traditional methods relying on the operating system's device manager cannot be used. The system cannot obtain valid identity information of physical devices, leading to device initialization failure, debugging difficulties, or missing hardware information. At the same time, the firmware structure of devices with different bus types varies greatly, and device model and version information are often scattered in different areas of the firmware, lacking a unified reading and parsing channel, which exacerbates the complexity of device identification in driverless environments.

[0003] Existing technologies lack a unified solution for reliably identifying multiple types of bus physical devices without relying on drivers. Particularly in areas such as bus protocol adaptation, firmware data extraction, model information completion, and visualization output, a systematic integration mechanism is lacking, hindering efficient and automated extraction and identification of device identity information. Therefore, there is an urgent need for a driverless physical device identification and processing system based on firmware information parsing to accurately identify and display information about various types of hardware devices, meeting the needs of device management and system deployment in driverless scenarios. Summary of the Invention

[0004] To achieve the above objectives, the present invention provides a driverless identification and processing system for physical devices based on firmware information parsing.

[0005] A driverless physical device identification and processing system based on firmware information parsing includes a device bus enumeration module, a firmware information extraction module, an information parsing module, an identifier mapping and completion module, and an identification result output module; wherein: Device bus enumeration module: Used to scan the hardware bus in the computer system through the underlying bus protocol without relying on the operating system driver, and generate a device list containing information on all detected physical device nodes; Firmware information extraction module: used to receive the device list, and for each device node in the list, according to its bus type, call the corresponding driverless low-level access interface to read the raw firmware data from the predefined firmware storage area; Information parsing module: Used to receive raw firmware data, load the corresponding parsing rules from the device information parsing rule library according to the device type, and parse and extract the device identity information field from the raw firmware data; Identifier Mapping and Completion Module: This module receives the device identity information field, determines whether the field contains complete readable device model information, and if not, queries the local preset device identifier mapping database based on the device identifier in the field to obtain the corresponding readable device model description information. It then integrates this information with the parsed field to generate structured device identity information. Recognition result output module: Used to receive structured device identity information and convert it into a visual list in a preset format for output.

[0006] Optionally, the device bus enumeration module includes a bus protocol identification unit, a raw protocol communication unit, and a node information collection unit; wherein: Bus protocol identification unit: used to directly access the hardware interface control area exposed by the motherboard firmware during the system startup phase or after the runtime environment is initialized, identify the standard bus protocol types supported in the current system, including PCI, PCIe, USB, SPI and I²C, and record the address mapping and access path information of each protocol in the system; Raw protocol communication unit: It is used to identify the protocol type and access path output by the bus protocol identification unit without loading the operating system driver, directly construct the corresponding bus protocol request data frame through encoding and decoding, and scan the ports of each physical device in the system to obtain the device presence response in the low-level raw communication mode. Node information collection unit: Based on the device response results detected by the bare protocol communication unit, it parses out the device address, device type identifier and port number information, constructs a device list structure containing all physical device nodes, and marks the bus type and enumeration order of each device.

[0007] Optionally, the firmware information extraction module includes a device node scheduling unit, a bus type determination unit, a driverless access interface calling unit, and a firmware data reading unit; wherein: Device node scheduling unit: used to receive the device list output by the device bus enumeration module, and select the device nodes to be processed in sequence according to the enumeration order of the devices in the list; Bus type determination unit: used to read the bus type information marked in the current device node, and determine the driverless underlying access interface type that matches the bus type in the system's preset bus-interface correspondence table; Driverless access interface call unit: Used to directly call the corresponding underlying access interface according to the interface type determined by the bus type determination unit without loading the operating system driver, perform read-only access initialization operation on the target device, and establish a communication channel with the device firmware storage area; Firmware data reading unit: After the communication channel is established, it is used to read the device's firmware storage space in segments according to the predefined firmware storage area address range and reading order rules, obtain continuous raw firmware data, and output the raw firmware data after establishing an association with the corresponding device node.

[0008] Optionally, the firmware data reading unit includes: Address configuration subunit: Used to receive interface call information corresponding to the bus type of the device, and extract the firmware address range matching the current device type from the preset firmware storage area mapping table to determine the starting address. and termination address Establish the address range for this read task; Read rule management subunit: used to load read order rules corresponding to device type, including read block size and read step size, and generate a continuous read task sequence; Segmented Read Execution Subunit: Based on the parameters provided by the address range and read rule management subunit, it performs segmented firmware data read operations in a loop manner; Data Reassembly Subunit: Used to merge firmware fragment data obtained from all reading rounds into a continuous raw firmware data stream in the order of reading, and bind it to the current device node.

[0009] Optionally, the information parsing module includes a device type determination unit, a parsing rule loading unit, a field location parsing unit, and a field normalization output unit; wherein: Device type determination unit: Used to receive the raw firmware data output by the firmware information extraction module, and combine it with the device node information associated with the raw firmware data to read the bus type and device identifier of the device. Parsing rule loading unit: used to load a parsing rule set that corresponds one-to-one with the device type from a preset device information parsing rule library according to the device type identifier. The parsing rule set explicitly defines the field offset position, field length and field encoding method in the firmware data. Field positioning and parsing unit: It is used to sequentially scan the original firmware data according to the parsing rule set, extract the data segment of the corresponding length at the preset field offset position, and complete the field decoding process according to the encoding method defined in the rule to obtain the original value of the device identity information field. Field normalization output unit: Used to perform format unification processing on the parsed device identity information fields, convert field content from different sources and with different encoding forms into a unified data structure, and output device identity information fields containing device identifiers, model codes and version identifiers.

[0010] Optionally, the field normalization output unit includes: Field integrity verification subunit: It receives the device identity information field, verifies the existence of each field according to the list of required fields defined in the parsing rule set, and marks the field type identifier of missing fields; Field type unification sub-unit: Used to uniformly map similar fields from different parsing rule sets to preset field types based on field type identifiers, including uniformly mapping manufacturer-related fields to manufacturer identifier fields, model-related fields to model code fields, and version-related fields to version identifier fields; Field format standardization subunit: used to perform format conversion processing on field content according to a unified field type, including converting numeric fields to standard hexadecimal representation and character fields to a unified character encoding format; Structured encapsulation subunit: Used to encapsulate the device identity information fields that have completed format standardization processing according to the preset field order and data structure template, generating a set of structured device identity information fields containing field names, field types and field values.

[0011] Optionally, the identifier mapping and completion module includes a readability determination unit, an identifier extraction unit, a mapping query unit, and an information integration and output unit; wherein: Readability determination unit: It receives a set of device identity information fields, determines whether there is complete readable device model information in the set of fields according to preset readability determination rules, and outputs the readability determination result; Identifier extraction unit: When the readability determination unit determines that the current device identity information field does not contain complete readable device model information, it extracts device identifier information related to the uniqueness of the device identity from the field set. The device identifier includes manufacturer identifier and model code identifier, and forms an identifier combination key for database query. Mapping Query Unit: Used to receive the identifier combination key output by the identifier extraction unit, and perform a matching query in the locally preset device identifier mapping database to obtain readable device model description information that corresponds one-to-one with the identifier combination key; Information integration and output unit: It is used to merge the readable device model description information obtained by the mapping query unit with the original device identity information field set, and complete the missing model field content according to the unified data structure template to generate structured device identity information containing manufacturer identifier, model description and version identifier.

[0012] Optionally, the readability determination rules include whether the model field is character data, whether the field length meets the minimum readable length requirement, and whether the field content conforms to the standard model naming character set constraints.

[0013] Optionally, the identifier mapping and completion module queries a locally pre-set device identifier mapping database. When no result is found, an abnormal structure fingerprint inverse mapping mechanism is activated to extract the parsing failure fields and abnormal data structures from the original firmware data, generating an abnormal structure fingerprint. The abnormal structure fingerprint is then input into a rare device structure-identity backtracking model. Fingerprint-device matching is used to obtain the candidate set of device models with the highest probability, and this set is fused with the parsed fields to generate structured device identity information and label the recognition trust level. Specifically, this includes: The abnormal field extraction unit is used to extract field fragments that failed to be parsed or have incomplete semantics and their corresponding original firmware data structures from the set of device identity information fields that failed to be parsed or were missing. An abnormal structure fingerprint generation unit is used to combine the extracted field fragments with their contextual structure information in the firmware data to construct an abnormal structure fingerprint including field offset position, length, byte pattern and field adjacency relationship, forming a structural feature description that can be used for identification and backtracking. The fingerprint-device matching model invocation unit is used to input abnormal structure fingerprints into a pre-trained rare device structure-identity backpropagation model. The model is built based on a historical rare device dataset and supports similarity matching between the input fingerprint and known device structures. The candidate device set generation unit is used to output the candidate set of device models with the highest probability based on the fingerprint matching score, and each candidate is accompanied by a similarity confidence score; The fusion identification generation unit is used to fuse the candidate device model set with the original parsed field set to generate structured device identity information after the missing results are filled in, and to attach an identification confidence level label to indicate the confidence level of the current identification result and the data integrity evaluation.

[0014] Optionally, the mapping query unit includes: Index building subunit: used to build a multi-field composite index on the local preset device identifier mapping database during system initialization. The composite index is based on fields including manufacturer identifier, model code, subsystem identifier and version number. Combination Key Matching Subunit: Used to receive the identifier combination key output by the identifier extraction unit, and perform a matching search in the indexed data structure according to the format of VendorID + Device ID or Vendor ID + Device ID + SubSys ID to ensure a one-to-one correspondence between the combination key and the record in the database; Description information retrieval subunit: After a successful combination key match, this subunit is used to extract the corresponding readable device model description information from the database, including the full model name, series, functional characteristics, and device classification tags.

[0015] Optionally, the recognition result output module includes a field sorting unit, a format mapping unit, and a list generation output unit; wherein: Field sorting unit: Used to receive the structured device identity information output by the identifier mapping and completion module, and sort the manufacturer identifier, device model description and version identifier in a unified manner according to the preset field order to form an ordered set of fields; Format mapping unit: used to map an ordered set of fields to standardized display fields according to a preset output format template, specifying the display name, display order and display attributes of each field; List generation output unit: Used to generate a visual list of device identity information with completed format mapping by device node, and output it to the user interface in a unified list format.

[0016] The beneficial effects of this invention are: This invention, by constructing a module chain including device bus enumeration, firmware information extraction, information parsing, identifier mapping, and recognition result output, achieves automatic identification and model information extraction of multiple types of physical devices without operating system driver support, solving the technical problem of being unable to identify devices in bare-metal or driver-limited environments in the prior art.

[0017] This invention, through a rule-based field parsing mechanism and a local identifier mapping database, ensures that device identity information under different bus protocols and firmware formats can be output in a unified format, improving the integrity and readability of the identification results, and possessing good scalability and adaptability to engineering deployment.

[0018] This invention solves the problem that traditional identifier mapping cannot continue when firmware fields are missing or format is abnormal by introducing an abnormal structure fingerprint inverse mapping mechanism. It can automatically extract the context structure information of the failed parsing fields to construct abnormal structure fingerprints and call the pre-trained rare device structure-identity back-reasoning model to realize reverse reasoning and candidate identification of the identity of unknown or rare devices. This enhances the robustness and completion capability of the driverless identification system in low-label firmware and non-standard device scenarios. Furthermore, through the identification trust level labeling mechanism, it provides structured results and trustworthiness assessment support for the upper-layer system. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only for this invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1This is a schematic diagram of a driverless identification and processing system for physical devices according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the identifier mapping and completion module in an embodiment of the present invention. Detailed Implementation

[0021] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. It should also be noted that, to make the embodiments more comprehensive, the following embodiments are the best and preferred embodiments, and those skilled in the art can use other alternative methods to implement some well-known technologies; moreover, the accompanying drawings are only for more specific description of the embodiments and are not intended to specifically limit the present invention.

[0022] It should be noted that the use of terms such as "an embodiment," "an embodiment," "an exemplary embodiment," and "some embodiments" in the specification indicates that the described embodiment may include a specific feature, structure, or characteristic, but not every embodiment necessarily includes that specific feature, structure, or characteristic. Furthermore, when a specific feature, structure, or characteristic is described in connection with an embodiment, implementing such a feature, structure, or characteristic in conjunction with other embodiments (whether explicitly described or not) should be within the knowledge of those skilled in the art.

[0023] Generally, terms can be understood at least partly from their use in context. For example, depending at least partly on the context, the term "one or more" as used herein can be used to describe any feature, structure, or characteristic in a singular sense, or a combination of features, structures, or characteristics in a plural sense. Additionally, the term "based on" can be understood not necessarily to convey an exclusive set of factors, but rather, alternatively, depending at least partly on the context, to allow for the presence of other factors that are not necessarily explicitly described.

[0024] like Figures 1-2 As shown, a driverless physical device identification processing system based on firmware information parsing includes a device bus enumeration module, a firmware information extraction module, an information parsing module, an identifier mapping and completion module, and an identification result output module; wherein: Device bus enumeration module: Used to scan the hardware bus in the computer system through the underlying bus protocol without relying on the operating system driver, and generate a device list containing information on all detected physical device nodes; Firmware information extraction module: used to receive the device list, and for each device node in the list, according to its bus type, call the corresponding driverless low-level access interface to read the raw firmware data from the predefined firmware storage area; Information parsing module: Used to receive raw firmware data, load the corresponding parsing rules from the device information parsing rule library according to the device type, and parse and extract the device identity information field from the raw firmware data; The identifier mapping and completion module receives the device identity information field and determines whether the field contains complete readable device model information. If not, it queries the local pre-set device identifier mapping database based on the device identifier in the field to obtain the corresponding readable device model description information, and integrates it with the parsed field to generate structured device identity information. When no result is found, it initiates the abnormal structure fingerprint reverse mapping mechanism, extracts the parsed failed fields and abnormal data structures from the original firmware data, and generates an abnormal structure fingerprint. The abnormal structure fingerprint is input into the rare device structure-identity backtracking model, and the highest probability device model candidate set is obtained through fingerprint-device matching. It is then fused with the parsed field to generate structured device identity information and label the recognition confidence level.

[0025] Recognition result output module: Used to receive structured device identity information and convert it into a visual list in a preset format for output.

[0026] The device bus enumeration module includes a bus protocol identification unit, a raw protocol communication unit, and a node information collection unit; wherein: Bus protocol identification unit: used to directly access the hardware interface control area exposed by the motherboard firmware during the system startup phase or after the runtime environment is initialized, identify the standard bus protocol types supported in the current system, including PCI, PCIe, USB, SPI and I²C, and record the address mapping and access path information of each protocol in the system; Raw protocol communication unit: It is used to identify the protocol type and access path output by the bus protocol identification unit without loading the operating system driver, directly construct the corresponding bus protocol request data frame through encoding and decoding, and scan the ports of each physical device in the system to obtain the device presence response in the low-level raw communication mode. The node information collection unit is used to parse the device address, device type identifier, and port number information based on the device response results detected by the bare protocol communication unit, construct a device list structure containing all physical device nodes, and mark the bus type and enumeration order of each device. The above unit obtains physical device node information without relying on the operating system driver by directly accessing the motherboard's underlying interface and using a bare communication mechanism. This ensures the system's device enumeration capability in a driverless or minimally driven environment, providing a complete physical device data foundation for subsequent firmware information extraction and identification.

[0027] The following are implementation examples: In an industrial control host using an x86 architecture and without operating system drivers, a device bus enumeration module based on a UEFI firmware interface is pre-deployed to achieve driverless identification of underlying physical devices. The specific operation is as follows: The system executes an initialization script in the UEFIShell environment. First, it accesses the _SB (SystemBus) node in the motherboard's ACPI table to extract the hardware bus types currently supported by the system and their corresponding controller mapping addresses. After parsing, the host currently supports the following buses: PCI bus, root bridge address 0x0000:00:1f.0; USB bus, EHCI controller address 0x00:1d.0; I²C bus, controller address 0xFED40000; The above information is recorded by the bus protocol identification unit and encapsulated into a bus mapping table and transmitted to the bare protocol communication unit; Based on the identified PCI bus root bridge address, the system uses the raw PCI configuration space access method to traverse the device numbers in the range of 0x00:00.0 to 0xFF:1F.7: By writing the bus-device-function number combination to each configuration address, and reading its VendorID and DeviceID fields, it can be determined whether the device exists. For the USB bus, directly send the standard Get_Descriptor request frame 0x800x060x01000x0000; For the I²C bus, the address range from 0x03 to 0x77 is directly polled based on the SMBus protocol to check the response signal; the above communication process is entirely based on the underlying read / write port and memory mapping method, without calling any operating system API or driver service; After enumeration, the system successfully discovered the following device nodes: Bus type Address / Number Device type identifier Enumeration order PCI 00:1f.2 0x8086:0x2922 1 USB Port 1 (RootHub) 0x1A2C:0x2124 2 I²C 0x50 SPD EEPROM 3 The node information collection unit stores the above information in a structured format in the device list.

[0028] The firmware information extraction module includes a device node scheduling unit, a bus type determination unit, a driverless access interface call unit, and a firmware data reading unit; among which: Device node scheduling unit: It is used to receive the device list output by the device bus enumeration module, and select the device nodes to be processed in sequence according to the enumeration order of the devices in the list, so as to ensure that each physical device node enters the firmware information extraction process one by one. Bus type determination unit: used to read the bus type information marked in the current device node, and determine the driverless underlying access interface type that matches the bus type in the system's preset bus-interface correspondence table; Table 1 Bus-Interface Correspondence Table Bus type Driverless access interface type Interface identifier API call method PCI PCI configuration space direct access interface PCI_CFG_DIRECT Port I / O, BDF direct index PCIe MMIO mapping interface PCIe_MMIO Memory mapping, reading BAR space USB Control transmission interface (standard request) USB_CTRL_REQ USB Request Packet Transmission I²C SMBus direct communication interface I2C_SMBUS_ACCESS Address polling + register access SPI SPI Master Device Read / Write Interface SPI_DIRECT_IO Timing control read In Table 1 above, the bus type indicates the hardware bus where the device is located; the driverless access interface type indicates the name of the direct access interface module registered in the system for that bus type; the interface identifier is the interface call code used by the firmware information extraction module for internal identification and scheduling; the interface call method describes the communication method and access path of the interface; this correspondence table is part of the system initialization configuration. After the firmware information extraction module performs bus type determination, it automatically looks up the table to determine the required interface based on the bus where the device is located, so that the system can establish a targeted communication path without a driver and realize direct firmware reading operation.

[0029] Driverless access interface call unit: Used to directly call the corresponding underlying access interface according to the interface type determined by the bus type determination unit without loading the operating system driver, perform read-only access initialization operation on the target device, and establish a communication channel with the device firmware storage area; Firmware data reading unit: After the communication channel is established, it reads the device's firmware storage space in segments according to the predefined firmware storage area address range and reading order rules to obtain continuous raw firmware data. After establishing an association between the raw firmware data and the corresponding device node, it outputs the data. The above unit, through the unit-based collaborative design of device node scheduling, bus type determination, driverless interface calls, and firmware data reading process, enables the system to stably and completely obtain the raw firmware data of each physical device without operating system driver support, providing a consistent and reliable data input foundation for subsequent information parsing.

[0030] The firmware data reading unit includes: Address configuration subunit: Used to receive interface call information corresponding to the bus type of the device, and extract the firmware address range matching the current device type from the preset firmware storage area mapping table to determine the starting address. and termination address Establish the address range for this read task; Read rule management subunit: used to load read order rules corresponding to device type, including read block size and read step size, and generate a continuous read task sequence; Segmented Read Execution Subunit: Based on parameters provided by the address range and read rule management subunit, it performs segmented firmware data read operations in a cyclic manner. The expression is: , ,in, For the first The starting address for the next read; To read the step size; Indicates the reading round; Data Reassembly Subunit: This subunit is used to merge firmware fragment data obtained from all reading rounds into a continuous raw firmware data stream according to the reading order, and bind it to the current device node as input to the information parsing module. Through the above subunit, the system can realize structured, secure, and controllable reading of firmware information of various devices, ensuring the accuracy and stability of the reading process in a driverless environment, and improving the subsequent parsing accuracy.

[0031] The information parsing module includes a device type determination unit, a parsing rule loading unit, a field location and parsing unit, and a field normalization output unit; among which: Device type determination unit: It is used to receive the raw firmware data output by the firmware information extraction module, and combine it with the device node information associated with the raw firmware data to read the bus type and device identifier of the device, and determine the device type identifier corresponding to the current device as the sole basis for parsing rule selection; Parsing rule loading unit: It is used to load a parsing rule set that corresponds one-to-one with the device type from the preset device information parsing rule library according to the device type identifier. The parsing rule set explicitly limits the field offset position, field length and field encoding method in the firmware data; Field positioning and parsing unit: It is used to sequentially scan the original firmware data according to the parsing rule set, extract the data segment of the corresponding length at the preset field offset position, and complete the field decoding process according to the encoding method defined in the rule to obtain the original value of the device identity information field. The field normalization output unit is used to standardize the format of the parsed device identity information fields, converting field content from different sources and with different encoding formats into a unified data structure, and outputting device identity information fields containing device identifiers, model codes, and version identifiers. Through the layered design of device type determination, parsing rule loading, field location parsing, and normalization output processes, the above unit enables the information parsing module to accurately match parsing rules for different types of devices, stably extract device identity information fields from the original firmware data, and provide a consistent and referable data foundation for subsequent identifier mapping and completion processing.

[0032] The aforementioned device information parsing rule base includes: Resolution Rule Set 1: PCI / PCIe Class Device Resolution Rule Set Applicable device types: Standard expansion devices based on PCI or PCIe buses Rule description: Firmware data originates from PCI / PCIe configuration space and extended configuration area; fields are located using a fixed byte offset method; field encoding is little-endian binary encoding; Field parsing definition: Device manufacturer identification field: offset address 0x00, length 2 bytes; Device model identifier field: offset address 0x02, length 2 bytes; Subsystem identifier field: Offset address 0x2C, length 2 bytes; Firmware version field: Offset address 0x08, length 1 byte; The parsed output is a set of device identity information fields, which are used to uniquely identify the hardware identity of a PCI / PCIe device.

[0033] Rule set 2: USB class device resolution rule set Applicable device types: Standard peripherals based on the USB bus Rule description: Firmware data originates from device descriptors and string descriptors; fields are located using descriptor indexing; field encoding is UTF-16LE. Field parsing definition: Device manufacturer string index: Descriptor Index 1; Device model string index: Descriptor Index 2; Product version field: Descriptor Index 3; During parsing, the descriptor index is read first, and then the corresponding string content is located through the index to form a readable device identity information field.

[0034] Resolution Rule Set 3: I²C / SMBus Class Device Resolution Rule Set Applicable device types: Onboard devices based on I²C or SMBus communication Rule description: Firmware data source is EEPROM or register mapping area; it adopts register address sequential reading method; field encoding method is ASCII encoding; Field parsing definition: Device model field: Register address 0x00–0x0F; Manufacturer code field: Register address 0x10–0x17; Firmware version field: Register address 0x18–0x1B; During parsing, character data is extracted and concatenated in order of address range to obtain the complete device identity field.

[0035] Parsing rule set 4: SPI class device parsing rule set Applicable device types: SPI bus-based storage or control devices Rule description: Firmware data source is SPI Flash identification area; data reading is triggered by command-response method; field encoding method is fixed-length hexadecimal encoding; Field parsing definition: Manufacturer identification field: Read command 0x9F, returns byte 1; Device model field: Read command 0x9F, returns bytes 2–3; Capacity identifier field: Read command 0x9F returned the 4th byte; The parsing results are output in structured numerical form for subsequent mapping and completion modules to process.

[0036] Field normalization output units include: Field integrity verification subunit: It receives the device identity information field, verifies the existence of each field according to the list of required fields defined in the parsing rule set, marks the field type identifier of missing fields, and forms the integrity verification result; Field type unification sub-unit: Used to uniformly map similar fields from different parsing rule sets to preset field types based on field type identifiers, including uniformly mapping manufacturer-related fields to manufacturer identifier fields, model-related fields to model code fields, and version-related fields to version identifier fields; Field format standardization subunit: Used to perform format conversion processing on field content according to a unified field type, including converting numeric fields to standard hexadecimal representation, converting character fields to a unified character encoding format, removing invalid padding data, and generating field values ​​with consistent format; The structured encapsulation subunit is used to encapsulate the device identity information fields that have undergone format standardization according to a preset field order and data structure template, generating a structured set of device identity information fields containing field names, field types, and field values, and outputting it to the identifier mapping and completion module. The above subunit performs integrity verification, type normalization, format standardization, and structured encapsulation on the device identity information fields, so that the parsing results from different buses and different firmware structures have a unified data expression form, ensuring the data consistency and processability of the subsequent identifier mapping and recognition result output process.

[0037] The identifier mapping and completion module includes a readability determination unit, an identifier extraction unit, a mapping query unit, and an information integration and output unit; among which: Readability determination unit: It receives a set of device identity information fields, determines whether there is complete readable device model information in the set of fields according to preset readability determination rules, and outputs the readability determination result; Identifier extraction unit: When the readability determination unit determines that the current device identity information field does not contain complete readable device model information, it extracts device identifier information related to the uniqueness of the device identity from the field set. The device identifier includes the manufacturer identifier and the model code identifier, and forms an identifier combination key for database query. Mapping Query Unit: Used to receive the identifier combination key output by the identifier extraction unit, and perform a matching query in the locally preset device identifier mapping database to obtain readable device model description information that corresponds one-to-one with the identifier combination key. A deterministic mapping relationship between device identifiers and readable device model descriptions is pre-established in the device identifier mapping database. The information integration and output unit is used to merge the readable device model description information obtained by the mapping query unit with the original device identity information field set, complete the missing model field content according to a unified data structure template, generate structured device identity information containing manufacturer identifier, model description and version identifier, and output the structured device identity information to the recognition result output module. The above unit determines the readability of the device identity information fields and introduces a local mapping completion mechanism based on device identifier when readable model information is missing. This enables the system to stably obtain complete and readable device identity information in a driverless environment, avoid the loss of recognition results due to incomplete firmware fields, and improve the standardization and consistency of device recognition results.

[0038] The readability criteria include whether the model field is character data, whether the field length meets the minimum readable length requirement, and whether the field content conforms to the standard model naming character set constraints.

[0039] The specific determination steps are as follows: Step 1: From the set of device identity information fields output by the field normalization output unit, retrieve data items with the field type "device model field" and determine whether the corresponding field exists; if the device model field is not found, it is directly determined that it does not contain complete and readable device model information; if the device model field exists, proceed to the next determination step. Step 2: After confirming the existence of the model field, read the data type identifier of the field to determine whether it is character data; if the field type is string or character array, proceed to the next step; if the field type is pure numeric or control code, it is directly determined to be an unreadable model field; this step is used to distinguish between directly presentable model information and coded values ​​that only have identification meaning, and to avoid misjudging numeric codes as readable model numbers; Step 3: For the model field that has passed the data type determination, further verify the field content length and the proportion of valid characters: determine whether the field character length reaches the preset minimum readable length threshold; determine whether there is a continuous valid character sequence in the field content, and exclude empty characters, padding characters or meaningless placeholder content; only when the field length and content integrity simultaneously meet the preset conditions is the field considered to have basic readability; Step 4: After ensuring basic readability of the fields, perform semantic validity checks on the field content: check whether the field content consists only of the preset model naming character set; check whether the field content contains at least one continuous character pattern that conforms to the device model naming rules; through this step, ensure that the field content is not only displayable, but also understandable as a device model description. Step 5: Only when the judgment results of Steps 1 to 4 are all passed will the system output the judgment result that the current device identity information field set contains complete readable device model information; if any judgment step fails, the judgment result will be output that the current device identity information field set does not contain complete readable device model information.

[0040] The mapping query unit includes: Index building subunit: used to build a multi-field composite index on the local pre-set device identifier mapping database during system initialization. The composite index is based on fields including Vendor ID, Device ID, SubSys ID, and Revision, to support quick location using composite keys; Combination Key Matching Subunit: Used to receive the identifier combination key output by the identifier extraction unit, and perform a matching search in the indexed data structure according to the format of VendorID + Device ID or Vendor ID + Device ID + SubSys ID to ensure a one-to-one correspondence between the combination key and the record in the database; Table 2 Device Identifier Mapping Database Vendor ID Device ID SubSys ID Revision Model Full Name To which series Functional features Equipment classification labels 8086 2922 10280252 02 Intel ICH9 SATA ICH9 Storage Controller motherboard chipset 10DE 1C82 11BF1458 A1 NVIDIA GTX 1050 GTX10 Graphics card rendering output Dedicated graphics card 1A2C 2124 00000000 01 USB 3.0 Host Ctrl ASMedia High-speed data communication External expansion controller 0CF3 E005 17AA3044 01 Qualcomm Atheros QCA61x4 QCA6 Wireless communication adapter Network adapter Description information retrieval subunit: After a successful combination key match, this subunit extracts the corresponding readable device model description information from the database, including the full model name, series, functional features, and device classification tags. By constructing an indexed data structure and a precise matching mechanism based on combination keys, the mapping query unit can quickly locate the model description information corresponding to the device identifier in the local database, achieving reliable completion of device identity information and improving overall recognition efficiency and data consistency.

[0041] The identifier mapping and completion module also includes: The abnormal field extraction unit is used to extract field fragments that failed to be parsed or have incomplete semantics and their corresponding original firmware data structures from the set of device identity information fields that failed to be parsed or were missing. The abnormal structure fingerprint generation unit is used to combine the extracted field fragments with their contextual structure information in the original firmware data to construct an abnormal structure fingerprint that includes field offset position, length, byte pattern and field adjacency relationship, forming a structural feature description that can be used to identify backtracking; the abnormal structure fingerprint is used to describe the contextual structure features of the parsed field in the original firmware data.

[0042] Assume the original firmware data is ; Define the abnormal structure fingerprint as: ; in, This is a set of triples organized by field offset for the raw firmware data. No. The byte offset address of each field. For field length, For the field content value (raw bytes), This indicates the set of indexes that failed to resolve. A bit vector representing the content of a field. Indicates the distance from the previous field. This indicates the distance to the next field.

[0043] This fingerprint structure is used to comprehensively express the field position, length, bit pattern, and contextual adjacency features to form a structural recognition feature vector.

[0044] The fingerprint-device matching model calling unit is used to input the abnormal structure fingerprint into the pre-trained rare device structure-identity backpropagation model. The model is built based on the historical rare device dataset. The model operation supports similarity matching between the input fingerprint and the known device structure, and outputs a score list of all known devices that are similar to the fingerprint structure, thus completing the mapping from fingerprint to device matching score. The rare device structure-identity backtracking model is a model used to backtrack the most likely device identity from anomalous structure fingerprints, and is represented as follows: ; The identifier representing the k-th candidate device output by the rare device structure-identity backtracking model, such as a model number or a unique device identifier. For candidate devices The structure matching probability, with a value range of [0,1], is given. This represents the set of candidate devices output by the model. The model is a graph embedding-based structure matching model, with fingerprint similarity measurement and candidate device ranking at its core. The core idea of ​​the rare device structure-identity backtracking model is to represent the structural fingerprint in the device firmware as a graph structure, and then use graph embedding and structure matching algorithms to find the closest candidate set of device identities from a historical rare device database. The overall model structure includes the following: 1. Fingerprint encoder: converts fingerprints of abnormal structures. Represented as a graph structure with attributes Among them, nodes Represents an exception field, edge Indicates the adjacent, overlapping, or logical relationships between fields; node attributes Including field offset position, segment length, byte pattern summary, field type label, etc., the GCN graph embedding network is used to embed the graph structure into a fixed-dimensional vector representation. .

[0045] 2. Reference Device Graph Embedding Library: Pre-builds structural graphs for all known devices in the rare device library. And encoded into vectors through the same graph embedding network. The structure is embedded in the database.

[0046] 3. Similarity Measurement and Matching Module: Calculates similarity using cosine similarity or Euclidean distance. With each reference vector Similarity score between them: The player who scored the highest Candidate devices Normalized to matching probability .

[0047] The model training process is as follows: 1. Data construction.

[0048] Data source: Firmware data of rare historical devices and records of anomaly identification cases.

[0049] Each training sample is ,in, It is an abnormal structure fingerprint extracted from a failed or incomplete recognition task. This is the actual device identifier corresponding to the abnormal fingerprint.

[0050] 2. Structure diagram construction and label alignment.

[0051] Construct a graph for each fingerprint. Extract field offsets, lengths, adjacency relationships, context summaries, etc. Encode into embedding vectors using a graph embedding network. The label is its device identification number.

[0052] 3. Training objectives.

[0053] Classification pattern training (if the device library is small): Use device identity as multi-class labels to train the graph classification model; Metric learning training (if there are many devices or high scalability requirements): Use contrastive loss or triplet loss for training to optimize the semantic space of the structural fingerprint embedding, making similar devices closer and different devices farther apart.

[0054] 4. Construct the loss function: ; For abnormal fingerprint embedding, Embed the corresponding diagram of a similar device. Embedding diagrams for different devices. This is the interval coefficient, used to separate positive and negative samples.

[0055] The model's operating mechanism is as follows: Online phase input: Input abnormal structure fingerprint Constructing a graph structure , through embedded network encoding .

[0056] Structure matching process: Search for structures in the structure embedding library. The most similar 1. Embedded vectors; calculate similarity scores and normalize them to match probabilities. Returns the set of candidate device identities. .

[0057] Output Fusion and Credibility Level Assessment: The candidate results are fused with the parsed fields, and the recognition credibility level is calculated by combining the field matching degree and similarity score. Output structured device identity information.

[0058] The candidate device set generation unit is used to output the candidate set of device models with the highest probability based on the fingerprint matching score, and each candidate is accompanied by a similarity confidence score; The matching score function is defined as follows: ; in, The first in the rare equipment library Structural fingerprint of a known device For bit pattern similarity, For field length matching degree, To ensure structural consistency at offset positions, For structural topological similarity, Weighting factors set for experience.

[0059] After inference by the model, the output is as follows: The most similar candidate device identifiers and the corresponding matching probability ,satisfy: .

[0060] The fusion identification and generation unit merges the candidate device model set with the original parsed field set to generate structured device identity information after completion of missing results, and attaches an identification confidence level label to indicate the confidence level and data integrity evaluation of the current identification result. (The parsed fields are then processed.) With the set of candidate devices output by the model The data is then fused to generate structured recognition results, and a recognition reliability level is provided. : ; in, This indicates the proportion of candidate device structures that match the parsed fields, and Number of MatchedFields represents the candidate device structure and... The number of fields that successfully matched in the middle field; Total Fields is the total number of all predefined fields in the candidate device structure. This represents the structural matching probability of the highest candidate. This represents the reduction in recognition entropy from initial uncertainty to fingerprint matching, and , This represents the structural uncertainty (information entropy) of candidate devices before matching, reflecting the degree of ambiguity before the system identifies them. This indicates the uncertainty of the candidate set retained after matching; the smaller the value, the more focused and clear the recognition results. The weighting coefficients calculated for the trust level satisfy the following conditions: .

[0061] Trust level This rating is ultimately added to the structured recognition results to indicate the reliability of the device's recognition results.

[0062] The final structured device identity information output structure is as follows: ; VendorID represents the device manufacturer identifier, typically a 16-bit or 32-bit encoding; ModelDescription represents a readable description of the device model; and Version represents the device firmware or hardware version identifier.

[0063] If the device model information comes from structural fingerprint matching candidates, its source and confidence level must be indicated in the form of a label.

[0064] The recognition result output module includes a field sorting unit, a format mapping unit, and a list generation output unit; among which: Field sorting unit: Used to receive the structured device identity information output by the identifier mapping and completion module, and sort the manufacturer identifier, device model description and version identifier in a unified manner according to the preset field order to form an ordered set of fields; Format mapping unit: used to map an ordered set of fields to standardized display fields according to a preset output format template, specifying the display name, display order and display attributes of each field; List generation and output unit: This unit generates a visual list of device identity information with completed format mapping, item by item, based on the device nodes, and outputs it to the user interface in a unified list format. The above steps, through field sorting, format mapping, and list-based output processing of the structured device identity information, present the device recognition results in a unified and clear visual form, ensuring the readability and consistency of the driverless recognition results, and facilitating subsequent viewing and retrieval.

[0065] This invention encompasses any substitutions, modifications, equivalent methods, and solutions made within the spirit and scope of this invention. To provide the public with a thorough understanding of this invention, specific details are described in detail in the following preferred embodiments; however, those skilled in the art will fully understand the invention even without these details. Furthermore, to avoid unnecessary misunderstanding of the essence of this invention, well-known methods, processes, procedures, components, and circuits are not described in detail.

[0066] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A driverless identification and processing system for physical devices based on firmware information parsing, characterized in that, It includes a device bus enumeration module, a firmware information extraction module, an information parsing module, an identifier mapping and completion module, and a recognition result output module; among which: Device bus enumeration module: Used to scan the hardware bus in the computer system through the underlying bus protocol without relying on the operating system driver, and generate a device list containing information on all detected physical device nodes; Firmware information extraction module: used to receive the device list, and for each device node in the list, according to its bus type, call the corresponding driverless low-level access interface to read the raw firmware data from the predefined firmware storage area; Information parsing module: Used to receive raw firmware data, load the corresponding parsing rules from the device information parsing rule library according to the device type, and parse and extract the device identity information field from the raw firmware data; Identifier Mapping and Completion Module: This module receives the device identity information field, determines whether the field contains complete readable device model information, and if not, queries the local preset device identifier mapping database based on the device identifier in the field to obtain the corresponding readable device model description information. It then integrates this information with the parsed field to generate structured device identity information. Recognition result output module: Used to receive structured device identity information and convert it into a visual list in a preset format for output.

2. The physical device driverless identification processing system based on firmware information parsing according to claim 1, characterized in that, The device bus enumeration module includes a bus protocol identification unit, a raw protocol communication unit, and a node information collection unit; wherein: Bus protocol identification unit: used to directly access the hardware interface control area exposed by the motherboard firmware during the system startup phase or after the runtime environment is initialized, identify the standard bus protocol types supported in the current system, including PCI, PCIe, USB, SPI and I²C, and record the address mapping and access path information of each protocol in the system; Raw protocol communication unit: It is used to identify the protocol type and access path output by the bus protocol identification unit without loading the operating system driver, directly construct the corresponding bus protocol request data frame through encoding and decoding, and scan the ports of each physical device in the system to obtain the device presence response in the low-level raw communication mode. Node information collection unit: Based on the device response results detected by the bare protocol communication unit, it parses out the device address, device type identifier and port number information, constructs a device list structure containing all physical device nodes, and marks the bus type and enumeration order of each device.

3. The physical device driverless identification processing system based on firmware information parsing according to claim 1, characterized in that, The firmware information extraction module includes a device node scheduling unit, a bus type determination unit, a driverless access interface calling unit, and a firmware data reading unit; wherein: Device node scheduling unit: used to receive the device list output by the device bus enumeration module, and select the device nodes to be processed in sequence according to the enumeration order of the devices in the list; Bus type determination unit: used to read the bus type information marked in the current device node, and determine the driverless underlying access interface type that matches the bus type in the system's preset bus-interface correspondence table; Driverless access interface call unit: Used to directly call the corresponding underlying access interface according to the interface type determined by the bus type determination unit without loading the operating system driver, perform read-only access initialization operation on the target device, and establish a communication channel with the device firmware storage area; Firmware data reading unit: After the communication channel is established, it is used to read the device's firmware storage space in segments according to the predefined firmware storage area address range and reading order rules, obtain continuous raw firmware data, and output the raw firmware data after establishing an association with the corresponding device node.

4. The physical device driverless identification processing system based on firmware information parsing according to claim 3, characterized in that, The firmware data reading unit includes: Address configuration subunit: Used to receive interface call information corresponding to the bus type of the device, and extract the firmware address range matching the current device type from the preset firmware storage area mapping table to determine the starting address. and termination address Establish the address range for this read task; Read rule management subunit: used to load read order rules corresponding to device type, including read block size and read step size, and generate a continuous read task sequence; Segmented Read Execution Subunit: Based on the parameters provided by the address range and read rule management subunit, it performs segmented firmware data read operations in a loop manner; Data Reassembly Subunit: Used to merge firmware fragment data obtained from all reading rounds into a continuous raw firmware data stream in the order of reading, and bind it to the current device node.

5. The physical device driverless identification processing system based on firmware information parsing according to claim 1, characterized in that, The information parsing module includes a device type determination unit, a parsing rule loading unit, a field location parsing unit, and a field normalization output unit; wherein: Device type determination unit: Used to receive the raw firmware data output by the firmware information extraction module, and combine it with the device node information associated with the raw firmware data to read the bus type and device identifier of the device. Parsing rule loading unit: used to load a parsing rule set that corresponds one-to-one with the device type from a preset device information parsing rule library according to the device type identifier. The parsing rule set explicitly defines the field offset position, field length and field encoding method in the firmware data. Field positioning and parsing unit: It is used to sequentially scan the original firmware data according to the parsing rule set, extract the data segment of the corresponding length at the preset field offset position, and complete the field decoding process according to the encoding method defined in the rule to obtain the original value of the device identity information field. Field normalization output unit: Used to perform format unification processing on the parsed device identity information fields, convert field content from different sources and with different encoding forms into a unified data structure, and output device identity information fields containing device identifiers, model codes and version identifiers.

6. The physical device driverless identification processing system based on firmware information parsing according to claim 5, characterized in that, The field normalization output unit includes: Field integrity verification subunit: It receives the device identity information field, verifies the existence of each field according to the list of required fields defined in the parsing rule set, and marks the field type identifier of missing fields; Field type unification sub-unit: Used to uniformly map similar fields from different parsing rule sets to preset field types based on field type identifiers, including uniformly mapping manufacturer-related fields to manufacturer identifier fields, model-related fields to model code fields, and version-related fields to version identifier fields; Field format standardization subunit: used to perform format conversion processing on field content according to a unified field type, including converting numeric fields to standard hexadecimal representation and character fields to a unified character encoding format; Structured encapsulation subunit: Used to encapsulate the device identity information fields that have completed format standardization processing according to the preset field order and data structure template, generating a set of structured device identity information fields containing field names, field types and field values.

7. The physical device driverless identification processing system based on firmware information parsing according to claim 1, characterized in that, The identifier mapping and completion module includes a readability determination unit, an identifier extraction unit, a mapping query unit, and an information integration and output unit; wherein: Readability determination unit: Used to receive a set of device identity information fields, determine whether there is complete readable device model information in the set of fields according to preset readability determination rules, and output the readability determination result; the readability determination rules include whether the model field is character data, whether the field length meets the minimum readable length requirement, and whether the field content conforms to the standard model naming character set constraints; Identifier extraction unit: When the readability determination unit determines that the current device identity information field does not contain complete readable device model information, it extracts device identifier information related to the uniqueness of the device identity from the field set. The device identifier includes manufacturer identifier and model code identifier, and forms an identifier combination key for database query. Mapping Query Unit: Used to receive the identifier combination key output by the identifier extraction unit, and perform a matching query in the locally preset device identifier mapping database to obtain readable device model description information that corresponds one-to-one with the identifier combination key; Information integration and output unit: It is used to merge the readable device model description information obtained by the mapping query unit with the original device identity information field set, and complete the missing model field content according to the unified data structure template to generate structured device identity information containing manufacturer identifier, model description and version identifier.

8. The physical device driverless identification processing system based on firmware information parsing according to claim 1, characterized in that, The identifier mapping and completion module queries a locally pre-set device identifier mapping database. When no result is found, an abnormal structure fingerprint inverse mapping mechanism is initiated. This mechanism extracts the parsing failure fields and abnormal data structures from the original firmware data to generate an abnormal structure fingerprint. The abnormal structure fingerprint is then input into a rare device structure-identity backtracking model. Fingerprint-device matching yields the candidate set of device models with the highest probability, which is then fused with the parsed fields to generate structured device identity information and label its recognition credibility level. Specifically, this includes: The abnormal field extraction unit is used to extract field fragments that failed to be parsed or have incomplete semantics and their corresponding original firmware data structures from the set of device identity information fields that failed to be parsed or were missing. An abnormal structure fingerprint generation unit is used to combine the extracted field fragments with their contextual structure information in the firmware data to construct an abnormal structure fingerprint including field offset position, length, byte pattern and field adjacency relationship, forming a structural feature description that can be used for identification and backtracking. The fingerprint-device matching model invocation unit is used to input abnormal structure fingerprints into a pre-trained rare device structure-identity backpropagation model. The model is built based on a historical rare device dataset and supports similarity matching between the input fingerprint and known device structures. The candidate device set generation unit is used to output the candidate set of device models with the highest probability based on the fingerprint matching score, and each candidate is accompanied by a similarity confidence score; The fusion identification generation unit is used to fuse the candidate device model set with the original parsed field set to generate structured device identity information after the missing results are filled in, and to attach an identification confidence level label to indicate the confidence level of the current identification result and the data integrity evaluation.

9. A physical device driverless identification processing system based on firmware information parsing according to claim 7, characterized in that, The mapping query unit includes: Index building subunit: used to build a multi-field composite index on the local preset device identifier mapping database during system initialization. The composite index is based on fields including manufacturer identifier, model code, subsystem identifier and version number. Combination Key Matching Subunit: Used to receive the identifier combination key output by the identifier extraction unit, and perform a matching search in the indexed data structure according to the format of Vendor ID + Device ID or Vendor ID + Device ID + SubSys ID to ensure a one-to-one correspondence between the combination key and the record in the database; Description information retrieval subunit: After a successful combination key match, this subunit is used to extract the corresponding readable device model description information from the database, including the full model name, series, functional characteristics, and device classification tags.

10. The physical device driverless identification processing system based on firmware information parsing according to claim 1, characterized in that, The recognition result output module includes a field sorting unit, a format mapping unit, and a list generation output unit; wherein: Field sorting unit: Used to receive the structured device identity information output by the identifier mapping and completion module, and sort the manufacturer identifier, device model description and version identifier in a unified manner according to the preset field order to form an ordered set of fields; Format mapping unit: used to map an ordered set of fields to standardized display fields according to a preset output format template, specifying the display name, display order and display attributes of each field; List generation output unit: Used to generate a visual list of device identity information with completed format mapping by device node, and output it to the user interface in a unified list format.

Images