Camera firmware security evaluation method, device, equipment and storage medium

Abstract

The application relates to the network security technical field and discloses a camera firmware security evaluation method, device, equipment and storage medium, which comprises the following steps: obtaining firmware bottom layer attributes and key offset of a to-be-evaluated firmware, wherein the firmware bottom layer attributes comprise firmware architecture, compression type and startup boot information; based on the firmware bottom layer attributes, calculating the entropy value of firmware data of the to-be-evaluated firmware through a preset entropy value analysis model, and determining a compression region based on the entropy value; extracting a file system corresponding to the compression region, and obtaining compressed data corresponding to the compression region according to the file system and the key offset; scanning sensitive information of the compressed data, and performing security evaluation on the sensitive information. According to the application, the entropy value of data in the to-be-evaluated firmware is determined through the firmware bottom layer attributes and the key offset, the compression region is automatically recognized, the file system and the compressed data are extracted according to the compression region to perform security evaluation, the interference of invalid data is reduced, and the accuracy and speed of vulnerability identification are significantly improved.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a method, apparatus, device and storage medium for security assessment of camera firmware. Background Technology

[0002] With the advancement of smart city and community governance, IoT (Internet of Things) and other camera devices are widely used, making firmware security a key challenge. However, firmware is usually closed-source and heterogeneous, making vulnerability detection difficult. Furthermore, existing methods such as dynamic and static analysis are limited by insufficient device resources and lack of vendor documentation, making it impossible to efficiently process entropy data and identify deep vulnerabilities, resulting in a large number of devices being vulnerable to attacks. Summary of the Invention

[0003] The main objective of this application is to provide a method, apparatus, device, and storage medium for security assessment of camera firmware, aiming to solve the technical problem that existing methods cannot efficiently process firmware entropy data and identify deep vulnerabilities.

[0004] To achieve the above objectives, this application proposes a camera firmware security assessment method, the method comprising:

[0005] Obtain the underlying firmware attributes and key offsets of the firmware to be evaluated. The underlying firmware attributes include firmware architecture, compression type, and boot information.

[0006] Based on the underlying firmware attributes, the entropy value of the firmware data of the firmware to be evaluated is calculated using a preset entropy value analysis model, and the compression region is determined based on the entropy value.

[0007] Extract the file system corresponding to the compressed area, and obtain the compressed data corresponding to the compressed area based on the file system and the key offset;

[0008] Scan the compressed data for sensitive information and perform a security assessment on the sensitive information.

[0009] Optionally, the step of calculating the entropy value of the firmware data of the firmware to be evaluated based on the underlying firmware attributes using a preset entropy analysis model, and determining the compression region based on the entropy value, includes:

[0010] The entropy value of the firmware data of the firmware to be evaluated is calculated by using a preset entropy value analysis model to obtain the entropy value corresponding to each data segment.

[0011] The corresponding entropy threshold is determined based on the compression type in the underlying firmware attributes.

[0012] Data segments with entropy values ​​greater than or equal to the entropy value determination threshold are marked as candidate compression regions, and data segments with entropy values ​​less than the entropy value determination threshold are marked as uncompressed regions.

[0013] The candidate compression regions are subjected to correlation verification, and the candidate compression regions that are continuous and whose entropy fluctuation range is within a preset range are merged to generate a compression region.

[0014] Optionally, after the step of performing correlation verification on the candidate compression regions and merging continuous candidate compression regions with entropy fluctuations within a preset range to generate a compression region, the method further includes:

[0015] The compressed and uncompressed regions are converted into color heatmaps using a binary visualization tool, wherein the color heatmaps identify the data features of the compressed and uncompressed regions using color gradients.

[0016] Optionally, the step of extracting the file system corresponding to the compressed region and obtaining the compressed data corresponding to the compressed region based on the file system and the key offset includes:

[0017] Firmware analysis tools are used to read the file system of the compressed area, and the candidate storage segments of the file system are located in combination with the key offset;

[0018] Perform file system signature detection on the candidate storage segments to identify the file storage type corresponding to the candidate storage segments;

[0019] If the file storage type is a multi-level nested structure, then a depth-first traversal algorithm is used to parse the nesting level layer by layer based on the key offset, and extract all files and subfolders of the file system.

[0020] Based on the file and subfolders, export the compressed data corresponding to the compressed area. The compressed data includes configuration files, key files, executable files, and log files in the directory.

[0021] Optionally, before the step of obtaining the firmware underlying attributes and key offsets of the firmware to be evaluated, the method further includes:

[0022] A device weighting model is constructed based on market share and historical vulnerability data.

[0023] Based on the device weight model, target evaluation devices with higher weights are selected from preset candidate devices;

[0024] Obtain the firmware to be evaluated corresponding to the target evaluation device, and perform hash calculation on the firmware to be evaluated to obtain the firmware hash value;

[0025] The firmware hash value is uploaded to the blockchain evidence storage system for evidence storage, resulting in firmware to be evaluated after integrity verification.

[0026] Optionally, the sensitive information includes hard-coded credential files, internet-exposed devices, and high-risk domain names;

[0027] The step of scanning the sensitive information in the compressed data and performing a security assessment on the sensitive information includes:

[0028] The compressed data is matched using regular expressions, and the hard-coded credential file is located based on the keywords.

[0029] Extract the intranet address and open port information from the sensitive information, and verify the Internet-exposed device based on the intranet address and open port information;

[0030] Extract embedded public resources from the file system and identify high-risk domain names within those public resources;

[0031] A security assessment is performed on the firmware to be evaluated based on the hard-coded credentials file, the internet-exposed device, and the high-risk domain name.

[0032] Optionally, the step of performing a security assessment on the firmware to be evaluated based on the hard-coded credential file, the internet-exposed device, and the high-risk domain name includes:

[0033] The severity level of the vulnerability is determined based on the hard-coded credentials file;

[0034] The exposure ratio is calculated based on the number of internet-exposed devices and the total number of devices.

[0035] Calculate real-time threat intelligence weights based on the high-risk domain names;

[0036] A risk assessment model is constructed using the hazard level, the exposure ratio, and the real-time threat intelligence weight, and the security risk value of the firmware to be assessed is calculated based on the risk assessment model.

[0037] Furthermore, to achieve the above objectives, this application also proposes a camera firmware security assessment device, which includes:

[0038] The attribute acquisition module is used to acquire the underlying firmware attributes and key offsets of the firmware to be evaluated. The underlying firmware attributes include firmware architecture, compression type and boot information.

[0039] The entropy calculation module is used to calculate the entropy value of the firmware data of the firmware to be evaluated based on the underlying attributes of the firmware and through a preset entropy analysis model, and to determine the compression region based on the entropy value.

[0040] The data acquisition module is used to extract the file system corresponding to the compressed area, and obtain the compressed data corresponding to the compressed area based on the file system and the key offset;

[0041] The security assessment module is used to scan the sensitive information in the compressed data and perform a security assessment on the sensitive information.

[0042] In addition, to achieve the above objectives, this application also proposes a camera firmware security assessment device, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the camera firmware security assessment method as described above.

[0043] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the camera firmware security assessment method described above.

[0044] In this application, the entropy value of the data in the firmware to be evaluated is determined by the firmware's underlying attributes and key offsets. Compressed regions are automatically identified, and the file system and compressed data are then extracted based on these regions for security assessment. This reduces interference from invalid data and significantly improves the accuracy and speed of vulnerability identification. Traditional entropy analysis often leads to misjudgments due to data noise. This application innovatively introduces a dual verification mechanism combining entropy boundary detection algorithms and binary color mapping technology. Through entropy analysis and visualization, compressed regions are automatically identified, solving the problem of existing tools' inefficient handling of entropy data. For the common multi-layered nested structures in IoT firmware, a depth-first traversal algorithm is developed to achieve recursive extraction of the entire file system. Firmwalker (an automated tool for searching sensitive information such as passwords and keys in firmware file systems) is integrated for keyword filtering, achieving a 100% detection rate, far exceeding the coverage rate of sensitive information scanning, and significantly improving the detection rate of hard-coded credentials. Attached Figure Description

[0045] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0047] Figure 1 This is a flowchart illustrating the first embodiment of the camera firmware security assessment method of this application;

[0048] Figure 2 This is a schematic diagram of the hierarchical processing mechanism of this application;

[0049] Figure 3 This is a flowchart illustrating the second embodiment of the camera firmware security assessment method of this application;

[0050] Figure 4 A binary color heatmap generated for the camera firmware security assessment method of this application;

[0051] Figure 5 This is a flowchart illustrating the third embodiment of the camera firmware security assessment method of this application;

[0052] Figure 6 This is a flowchart illustrating the fourth embodiment of the camera firmware security assessment method of this application;

[0053] Figure 7 This is a flowchart illustrating the logic of generating scenario-based remediation solutions based on vulnerability types in this application.

[0054] Figure 8 This is a schematic diagram of the module structure of the camera firmware security assessment device according to an embodiment of this application;

[0055] Figure 9 This is a schematic diagram of the device structure of the hardware operating environment involved in the camera firmware security assessment method in this application embodiment.

[0056] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0057] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0058] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0059] With the advancement of smart city and community governance, IoT and other camera devices are widely used, making firmware security a critical challenge. Firmware is often closed-source and heterogeneous, making vulnerability detection difficult. Existing methods such as dynamic and static analysis are limited by insufficient device resources and lack of vendor documentation, making it difficult to efficiently identify deep vulnerabilities, such as hard-coded passwords and SSL (Secure Sockets Layer) key leaks, leaving a large number of devices vulnerable to attack.

[0060] Existing technologies mainly include similarity-based firmware security detection tools and blockchain-assisted firmware management. For example: 1. Blockchain firmware updates. A firmware management architecture based on blockchain and the Inter-Planetary File System is proposed, ensuring firmware transmission security through a distributed ledger, but it cannot solve the security vulnerabilities of the firmware itself; 2. Code similarity analysis. A detection technology based on code genes is developed, which improves vulnerability identification accuracy through function embedding and local call flow graph analysis, but it is inefficient when processing high-entropy firmware (average time 1 hour); 3. Fuzz testing technology: Dynamic detection of memory corruption vulnerabilities, but it has low coverage and is time-consuming (average 210 seconds / firmware). Existing technical solutions generally suffer from the following technical problems: 1. Insufficient efficiency: Traditional methods such as symbolic execution or fuzzing are time-consuming and their accuracy decreases in high-entropy firmware; 2. Limited coverage: Existing tools such as Firmayne only support part of the architecture and cannot deeply deconstruct nested file systems, such as the highly compressed Linux read-only file system SquashFS, resulting in sensitive information such as hard-coded passwords and IP addresses being ignored; 3. Low degree of automation: They rely on manual updates and static analysis and lack integrated processes, such as entropy analysis and recursive extraction, making it difficult to identify zero-day vulnerabilities in real time.

[0061] Therefore, this application provides a method for security assessment of IoT camera firmware based on multi-stage entropy analysis and recursive file system extraction. It utilizes entropy and Binwalk tools to achieve automated analysis, which significantly improves the accuracy and speed of vulnerability identification, especially for the detection of hard-coded credentials and unencrypted data, filling the gap in existing technology for high-entropy firmware processing.

[0062] It should be noted that the executing entity in this embodiment can be a computing service device with data storage, algorithm operation, tool invocation, and network interaction capabilities, such as a computer, or an electronic device capable of performing the above functions. The following description uses a firmware security assessment system as an example to illustrate this embodiment and the subsequent embodiments.

[0063] Based on this, embodiments of this application provide a method for assessing camera firmware security, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the camera firmware security assessment method of this application.

[0064] In this embodiment, the camera firmware security assessment method includes:

[0065] Step S10: Obtain the firmware underlying attributes and key offsets of the firmware to be evaluated. The firmware underlying attributes include firmware architecture, compression type, and boot information.

[0066] It's important to note that the underlying firmware attributes are the core characteristics that determine the foundation and data organization of the firmware being evaluated. Firmware architecture refers to the hardware processor architecture to which the firmware is adapted, such as MIPS (Microprocessor without Interlocked Piped Stages) architecture. Compression type refers to the compression algorithm used when storing firmware data, such as LZMA (Lempel-Ziv-Markov chain-Algorithm), which determines the subsequent data decompression technology path. Boot information refers to the critical data used during the firmware boot phase to initialize hardware and load the kernel, such as U-Boot boot parameters and boot partition addresses. Critical offsets refer to the byte offset values ​​of specific data segments (such as kernel data or the start address of the file system) relative to the start address of the firmware file, used to accurately locate the core coordinates of the target data.

[0067] Specifically, a file recognition tool (such as the `file` command in Linux) is used to initially parse the complete firmware file to be evaluated. By analyzing the firmware file header identifier and data encoding characteristics, the firmware architecture (e.g., identifying instruction set features to match the MIPS architecture) and compression type (e.g., detecting compressed data identifiers to determine the LZMA type) are determined. Next, a firmware analysis tool (such as Binwalk) is called to perform a full scan of the firmware file. The tool's built-in signature database is used to match boot-related data features (such as U-Boot signatures) to extract boot information. Finally, based on the scan results of the firmware analysis tool, the difference between the starting address of the target data segment (such as the kernel or file system) output by the tool and the starting address of the firmware file is read to determine the key offset. At the same time, the obtained firmware architecture, compression type, boot information, and key offset are associated and stored to form the basic data for subsequent entropy analysis and file system extraction.

[0068] Furthermore, to ensure the generalizability of the analysis results, the following steps are included before step S10:

[0069] A device weight model is constructed based on market share and historical vulnerability data; a target evaluation device with a higher weight is selected from preset candidate devices based on the device weight model; the firmware to be evaluated corresponding to the target evaluation device is obtained, and a hash calculation is performed on the firmware to be evaluated to obtain the firmware hash value; the firmware hash value is uploaded to the blockchain evidence storage system for evidence storage to obtain the firmware to be evaluated after integrity verification.

[0070] It should be noted that the device weighting model is a quantitative assessment model built on the scope of device security impact and risk probability. Market share refers to the market share of a specific IoT device in the target application field (such as smart cameras in community governance scenarios); historical vulnerability data refers to the device's past vulnerability records obtained from public vulnerability databases and vendor vulnerability announcements, reflecting the device's inherent security risk level; the blockchain evidence storage system is a trusted storage system built on distributed ledger technology, which can ensure that the firmware hash value cannot be maliciously modified after storage.

[0071] Understandably, choosing to build a device weighting model based on high market share and historical vulnerability data avoids sample bias from niche devices, allowing for priority selection of high-threat target cameras and ensuring the generalizability of the analysis results. Firmware data is then downloaded through official channels to mitigate the risk of sample tampering at the source. Blockchain-based evidence storage technology is integrated into the preprocessing stage to perform hash calculations on the firmware file, generating a firmware hash value. This hash value is uploaded to the blockchain in real-time to prevent tampering, implementing a dual-channel verification mechanism. Metadata such as the firmware hash value, firmware version, and acquisition time are uploaded to the blockchain node through the blockchain evidence storage system's interface. After successful node consensus verification, a blockchain evidence storage certificate is obtained, completing the firmware integrity verification and yielding the complete firmware for subsequent evaluation.

[0072] Step S20: Based on the underlying firmware attributes, calculate the entropy value of the firmware data of the firmware to be evaluated using a preset entropy analysis model, and determine the compression region based on the entropy value.

[0073] It should be noted that entropy is a quantitative indicator of data randomness. A higher entropy value indicates stronger data randomness and a greater likelihood that the data is compressed or encrypted. Compressed regions refer to continuous data segments in firmware processed using compression or encryption algorithms. Their entropy values ​​are typically higher than those of uncompressed data regions, making them key target areas for extracting data from the file system.

[0074] It should be understood that a sliding window mechanism can be introduced into entropy calculation to perform secondary calculations on overlapping areas of data blocks, avoiding entropy deviations caused by data block boundary divisions. This is particularly suitable for accurate identification at the boundary between compressed and uncompressed data. For firmware with mixed compression types, a dynamic threshold adjustment module can be built. By identifying the feature codes of different compression algorithms, the matching entropy threshold can be automatically switched in the corresponding data segment to solve the problem of adaptability of a single threshold to mixed compression scenarios.

[0075] Step S30: Extract the file system corresponding to the compressed area, and obtain the compressed data corresponding to the compressed area based on the file system and the key offset.

[0076] It should be noted that the file system corresponding to the compressed area refers to the system used to manage the file storage structure contained in the firmware compressed data segment, including file directories, index tables, storage block allocation information, etc. The compressed data refers to the specific file content contained within the compressed area, including configuration files, executable programs, key certificates, etc., and is the direct object of firmware functionality implementation and security risk analysis.

[0077] Understandably, the starting address of the file system within the compressed area can be located based on the key offset. Firmware extraction tools (such as Unsquashfs and binwalk) are then called to load the binary data corresponding to that address, and the file system type is identified through the file system signature library built into the tool. Secondly, if the file system is a nested structure, the nesting level can be parsed layer by layer based on the key offset, and the directory structure of all sub-file systems can be extracted by recursively traversing. Then, the file system index table information is used, combined with the key offset, to locate the storage address and length of each file, and the compressed data of the original file is read and decompressed (for compressed files) to obtain the compressed data of the original file.

[0078] Step S40: Scan the sensitive information of the compressed data and perform a security assessment on the sensitive information.

[0079] It should be noted that sensitive information refers to key information in compressed data that may pose security risks. Specifically, it may include hard-coded credentials (such as fixed passwords and access tokens), network configuration information (such as internal network IP addresses and open ports), external addresses (such as embedded public resources and domain names), and key files (such as private keys and encryption keys).

[0080] In one example, reference Figure 2 , Figure 2 This is a schematic diagram of the layered processing mechanism of this application. First, after firmware acquisition, a static analysis layer performs preliminary analysis to ensure the integrity and traceability of the analyzed sample, establishing a verifiable firmware analysis baseline. Then, a dynamic deconstruction layer performs in-depth analysis and presents data features through entropy-visualization analysis, penetrating the compression and encryption layer to visualize the internal structure, revealing the firmware's internal structure and locating potential risk areas. Following the dynamic deconstruction layer, a sensitive information mining layer extracts recursive files, efficiently identifying hard-coded vulnerabilities and configuration risks, establishing a comprehensive threat hunting network. Finally, a multi-dimensional scanning engine performs comprehensive detection, outputting to the vulnerability verification layer to complete the overall analysis loop, highlighting risk points, quantifying risks, and relating them to actual attack scenarios to generate actionable remediation strategies.

[0081] In this embodiment, the entropy value of the data in the firmware to be evaluated is determined by the underlying firmware attributes and key offsets. Compressed regions are automatically identified, and file systems and compressed data are extracted from these regions for security assessment. This reduces interference from invalid data and significantly improves the accuracy and speed of vulnerability identification. Furthermore, standardized device screening, firmware integrity assurance, and basic attribute parsing ensure the integrity and traceability of the analysis samples, establishing a verifiable firmware analysis baseline.

[0082] Reference Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the camera firmware security assessment method of this application. Based on the first embodiment described above, a second embodiment of the camera firmware security assessment method of this application is proposed.

[0083] In the second embodiment, step S20 includes:

[0084] Step S201: Calculate the entropy value of the firmware data of the firmware to be evaluated using a preset entropy analysis model to obtain the entropy value corresponding to each data segment.

[0085] It should be noted that the entropy analysis model refers to a pre-constructed algorithmic model used to quantify and evaluate the randomness of data. Its core is based on Shannon entropy theory, calculating information entropy by the probability of different bytes appearing in statistical data to quantify the degree of disorder in the data. Firmware data refers to the raw binary data of firmware files, including various data structures such as code segments, data segments, compressed regions, and whitespace padding. A data segment refers to a continuous data unit obtained after dividing the firmware data into blocks of fixed length (e.g., 256 bytes, 512 bytes), and is the basic unit for entropy calculation.

[0086] In one example, an improved entropy analysis model is used to quantify data randomness. This model uses the Shannon entropy formula to calculate byte distribution, identifying high-entropy regions (values ​​close to 1) that indicate compressed / encrypted data, thus avoiding invalid scans. See below:

[0087]

[0088] Where H is the entropy value, The probability of an event is determined by several steps. First, the binary data of the firmware to be evaluated is divided into consecutive blocks according to a preset block size. For the last data that is less than a block, it is treated as a separate data segment according to its actual length. At the same time, the starting offset address of each data segment in the firmware is recorded. Second, a preset entropy analysis model is called to calculate the entropy value for each data segment. For example, the frequency of occurrence of the 256 bytes from 0x00 to 0xFF in the data segment is counted, and then substituted into the Shannon entropy formula to obtain the entropy value of the data segment. The probability of occurrence of the i-th byte is the event probability.

[0089] Step S202: Determine the corresponding entropy threshold based on the compression type in the firmware's underlying attributes.

[0090] It is understandable that compression type refers to the type of compression algorithm used when storing firmware data. Different compression types have different randomness characteristics after compression due to differences in algorithm principles. The entropy value judgment threshold is a critical entropy value used to distinguish between compressed data and uncompressed data. When the entropy value of a data segment is higher than or equal to the threshold, it is judged as a region that may have undergone compression processing; otherwise, it is judged as an uncompressed region.

[0091] It should be understood that entropy values ​​can be statistically analyzed on typical data for each compression type beforehand through extensive sample testing to determine the entropy distribution range for each compression type. A compression type-threshold mapping library can then be constructed to determine the entropy threshold. For newly emerging compression algorithms or variants, the mapping library can be automatically updated through online sample learning, calculating the peak value of its entropy distribution and setting an initial threshold. This threshold can then be manually reviewed and confirmed to ensure its adaptability to the new compression type.

[0092] Step S203: Mark the data segments whose entropy value is greater than or equal to the entropy value determination threshold as candidate compression regions, and mark the data segments whose entropy value is less than the entropy value determination threshold as uncompressed regions.

[0093] It should be noted that candidate compression regions refer to the set of data segments whose entropy values ​​reach or exceed the judgment threshold. These data segments, due to their high randomness, are initially identified as regions that may undergo compression. Uncompressed regions refer to the set of data segments whose entropy values ​​are below the judgment threshold. Their data randomness is relatively low, and they typically contain uncompressed code, structured configuration information, etc. For example, low-entropy regions (H < 0.7) have low data randomness and can skip redundant text data; high-entropy regions (H ≥ 0.95) have strong data randomness and are marked as core targets for compression / encryption, such as the LZMA kernel.

[0094] Step S204: Perform correlation verification on the candidate compression regions, and merge the candidate compression regions that are continuous and whose entropy fluctuation range is within a preset range to generate a compression region.

[0095] It should be noted that correlation verification refers to the process of verifying whether the initially marked candidate compressed regions conform to the inherent characteristics of compressed data from dimensions such as spatial continuity and entropy stability. The purpose is to eliminate discrete, abnormal, and false candidate regions. A continuous candidate compressed region refers to multiple candidate compressed data segments that are adjacent and without gaps in the firmware physical address. These regions are more likely to be components of the same compressed block. Entropy fluctuation amplitude refers to the maximum difference in entropy values ​​among data segments within a continuous candidate compressed region, reflecting the stability of data randomness. The preset range is a fluctuation threshold set based on the distribution law of compressed data entropy values; exceeding this range indicates that the data characteristics may be abnormal.

[0096] Specifically, first, all candidate compression regions are traversed in firmware physical address order to identify adjacent groups of continuous candidate regions without other data segment intervals. Second, the maximum and minimum entropy values ​​of each data segment within each group of continuous candidate regions are calculated to obtain the entropy fluctuation range. Then, the fluctuation range is compared with a preset range. If the fluctuation range is less than or equal to the preset range, the group of continuous candidate regions is determined to be correlated, and they are merged into a complete compression region. The starting address, total length, and average entropy value of the merged region are recorded. If the fluctuation range is greater than the preset range, the group of regions is split, and data segments with abnormal entropy values, such as discrete segments with a sudden drop in entropy value, are removed. Only the parts with the required fluctuation are retained and merged. Finally, the length of the merged compression region is checked. If the length is less than the minimum typical value of compressed data, it is determined to be an invalid region and removed. Finally, a set of compression regions that meet the characteristics of compressed data is obtained.

[0097] Furthermore, to visually demonstrate data distribution characteristics, automatically identify compressed regions, and address the problem that existing tools cannot efficiently process high-entropy data, step S204 is followed by:

[0098] The compressed and uncompressed regions are converted into color heatmaps using a binary visualization tool, wherein the color heatmaps identify the data features of the compressed and uncompressed regions using color gradients.

[0099] In one example, reference Figure 4 , Figure 4 This is a binary color heatmap generated for the camera firmware security assessment method of this application. Combined with Binvis, the binary color heatmap uses color gradients to identify data features, visually displaying data distribution characteristics and automatically identifying compressed areas, solving the problem of existing tools' inefficient handling of high-entropy data. Red blocks represent high-entropy encrypted areas, requiring priority processing; blue blocks represent structured data, such as file headers and ASCII codes; green blocks represent low-entropy plaintext, which can be quickly scanned. The right side shows the corresponding assembly language-edited data. It presents the specific addresses of the firmware binary data (e.g., 017d940 to 017da70) and the corresponding hexadecimal data at those addresses (e.g., "d5 d6 19 3c dd9c 68 1d" at 017d940), along with partial ASCII code parsing results. Furthermore, it labels the byte class range (0x00 to 0xff), data volume (low), and other attribute information, and supports data export.

[0100] In this embodiment, an improved entropy analysis model quantifies data randomness, identifies compressed / encrypted data indicated by high-entropy regions, and avoids invalid scans. A binary visualization tool is introduced to generate a binary color heatmap, using color gradients to identify data features and visually display data distribution characteristics. This allows for the automatic identification of compressed regions, solving the problem of existing tools being unable to efficiently process high-entropy data.

[0101] Reference Figure 5 , Figure 5 This is a flowchart illustrating the third embodiment of the camera firmware security assessment method of this application. Based on the first embodiment described above, a third embodiment of the camera firmware security assessment method of this application is proposed.

[0102] In the third embodiment, step S30 includes:

[0103] Step S301: Use a firmware analysis tool to read the file system of the compressed area and locate the candidate storage segment of the file system in combination with the key offset.

[0104] It's important to note that firmware analysis tools are specialized tools for parsing firmware data structures, extracting file systems, and identifying critical data segments. Examples include Binwalk, which possesses core functions such as signature matching, offset location, and file system extraction, and is adaptable to various architectures and file system types. Candidate storage segments refer to contiguous data segments that, based on compressed regions and key offsets, may contain a complete file system. Alternatively, firmware analysis tools can be used to precisely extract the kernel based on offsets using preset commands, such as LZMA compressed data.

[0105] Step S302: Perform file system signature detection on the candidate storage segment to identify the file storage type corresponding to the candidate storage segment.

[0106] It should be noted that file system signature detection refers to determining the file system type by verifying the presence of a distinctive byte sequence, or signature, of a specific file system in candidate storage segments. A signature is a fixed identifier written to the file system during initialization. File storage type refers to the specific category of the file system, reflecting the file's organization, storage structure, and access mechanism.

[0107] Step S303: If the file storage type is a multi-level nested structure, then the nesting level is parsed layer by layer based on the key offset using a depth-first traversal algorithm to extract all files and subfolders of the file system.

[0108] Understandably, a multi-level nested structure refers to a hierarchical structure in which a file system contains sub-file systems, and the sub-file systems may further contain the next level of sub-file systems. For example, the multi-level nested structure is common in IoT firmware. The U-Boot boot layer contains the LZMA kernel layer, and the LZMA kernel layer contains the SquashFS file system layer.

[0109] Specifically, the starting address of the main file system recorded in the key offset is read, and the firmware analysis tool is called to parse the directory structure of the main file system based on this starting address to identify whether there are sub-file system image files in the main file system; a depth-first traversal algorithm is started, with the main file system as the current parsing level, and the storage paths and relative offsets of all sub-file system image files in the current level are extracted, and the actual starting offset of each sub-file system is calculated by combining the starting address of the main file system; for each sub-file system, the above parsing process is repeated until there are no new sub-file systems in the current level; after the traversal is completed, all files (such as configuration files, key files) and subfolders in each file system are extracted in hierarchical order, and saved to local storage according to the original directory structure to form a complete file set.

[0110] In one example, all files and subfolders are recursively extracted using the Binwalk-eM flag, achieving a four-level nested file system traversal. This successfully deconstructs the SquashFS+LZMA composite structure and fully extracts the Linux root directory system. This process can specifically reveal the SSL private key file in the / etc_ro directory, supporting the on-site generation of forged certificates for man-in-the-middle attack verification.

[0111] Step S304: Based on the file and subfolder, export the compressed data corresponding to the compressed area. The compressed data includes configuration files, key files, executable files, and log files in the directory.

[0112] It's important to understand that files and subfolders refer to collections of files with complete directory hierarchies, parsed from multi-level nested or non-nested file systems. Configuration files store firmware operating parameters, such as network configuration and device parameters; key files store sensitive information such as encryption / decryption keys and certificate private keys; executable files implement core firmware functions, such as camera control and data transmission; and log files record event information during firmware operation.

[0113] Understandably, when exporting compressed data from files and subfolders, the process involves several steps. First, a local export directory is created that matches the firmware's file system directory structure. This ensures that the local directory hierarchy perfectly corresponds to the file and subfolder organization in the firmware. For example, files in the firmware's " / etc / config" directory correspond to the local "export directory / etc / config". Second, all files and subfolders are traversed, and read and export operations are performed on each file. For text files such as configuration files and log files, the file content can be directly read and saved to the corresponding local directory in its original encoding format. For binary files such as key files and executable files, the original data stream is obtained in binary read mode to avoid information loss due to data format conversion, and then saved to the corresponding local directory. Third, the metadata of each file is recorded during the export process and stored along with the file content to ensure the integrity of the exported data. Finally, after the export is complete, the files in the local export directory are checked for integrity. The hash value of each exported file is calculated and compared with the hash value of the corresponding file in the firmware's file system. Once it is confirmed that there is no data corruption or omission, the export of the compressed data is complete.

[0114] In this embodiment, a depth-first traversal algorithm is developed for the multi-layer nested structure commonly found in firmware, to achieve recursive extraction of the entire file system, thus avoiding the defect of traditional single-layer extraction that misses sub-file system data.

[0115] Reference Figure 6 , Figure 6 This is a flowchart illustrating the fourth embodiment of the camera firmware security assessment method of this application. Based on the above embodiments, the fourth embodiment of the camera firmware security assessment method of this application is proposed.

[0116] In the fourth embodiment, the sensitive information includes hard-coded credential files, internet-exposed devices, and high-risk domain names. Step S40 includes:

[0117] Step S401: Match keywords in the compressed data using regular expressions, and locate the hard-coded credential file based on the keywords.

[0118] It's important to note that regular expressions, by defining matching logic for specific character combinations, can efficiently retrieve content in text that matches the rules. In sensitive information identification, they are used to locate strings containing specific keywords. Keywords refer to characteristic words strongly related to hard-coded credentials, such as "password," "secret," "key," and "token." Hard-coded credential files refer to files in firmware that contain permanently stored sensitive information such as account passwords, access tokens, and API keys. These files pose a high security risk because the credentials are not encrypted and cannot be dynamically modified.

[0119] Understandably, using the Firmwalker tool to match keywords such as "passwd" and "password" via regular expressions can quickly locate hard-coded credential files and significantly improve the detection rate of hard-coded credentials.

[0120] Step S402: Extract the intranet address and open port information from the sensitive information, and verify the Internet-exposed device based on the intranet address and open port information.

[0121] It should be understood that the internal network address refers to the local area network IP address of the device recorded in the firmware; open port information refers to the network ports and associated service types that are allowed to be accessed externally in the firmware configuration; and internet-exposed devices refer to devices whose internal network addresses can be directly accessed via the Internet due to improper configuration or design flaws, which pose a risk of remote attacks.

[0122] Understandably, when conducting network exposure analysis, the first step is to build a network information extraction rule base, designing regular expressions for internal network addresses and matching rules for open ports. Secondly, the network configuration files within sensitive information are traversed, and the rule base is used to extract all internal network addresses and their corresponding open ports and service types. Then, network detection tools are used to perform port scans on the extracted internal network addresses to detect whether port mapping or NAT traversal configurations result in internet reachability. Finally, the scan results are used for verification. If the open ports of the internal network address can be accessed in a public network environment, such as through a public IP address and port mapping, it is determined to be an internet-exposed device, and the exposed ports, services, and potential risks are recorded. For example, the internal network IP address (e.g., 192.168.1.1) and open ports (HTTP / 80, Telnet / 23) can be extracted, and the Shodan API can be used to verify internet-exposed devices.

[0123] Step S403: Extract the embedded public resources in the file system and identify high-risk domain names in the public resources.

[0124] It is understandable that embedded public resources refer to public network resource information pre-stored in the firmware file system for interacting with external networks, including domain names, URL links, IP addresses, etc.; high-risk domain names refer to domain names that may pose a threat to device security or user privacy, including malware distribution domain names, phishing website domain names, domain names related to known vulnerability exploitation, uncertified third-party data collection domain names, etc., and their risk level can be determined through a threat intelligence database.

[0125] Specifically, the VirusTotal API can be called to classify embedded URLs in the firmware for malicious purposes and identify high-risk domains.

[0126] Step S404: Perform a security assessment on the firmware to be evaluated based on the hard-coded credentials file, the internet-exposed device, and the high-risk domain name.

[0127] In one example, a multi-dimensional sensitive information sniffing engine can be built, integrating three scanning strategies to efficiently identify hard-coded vulnerabilities and configuration risks, establish a full-dimensional threat hunting network, construct a three-level threat hunting model, and realize the linkage between static vulnerabilities and real-time threat intelligence. Refer to Table 1, which is the three-level scanning strategy table for identifying hard-coded vulnerabilities and configuration risks in this application.

[0128] Table 1

[0129]

[0130] Furthermore, to enable technicians to intuitively assess the firmware security level based on risk values, providing a precise quantitative basis for subsequently developing differentiated response strategies, step S404 may include:

[0131] The severity level of the vulnerability is determined based on the hard-coded credentials file; the exposure ratio is calculated based on the number of internet-exposed devices and the total number of devices; the real-time threat intelligence weight is calculated based on the high-risk domain name; a risk assessment model is constructed using the severity level, the exposure ratio, and the real-time threat intelligence weight; and the security risk value of the firmware to be assessed is calculated based on the risk assessment model.

[0132] It should be noted that the vulnerability severity level refers to the risk level classified based on the sensitivity and exploitability of hard-coded credentials, such as high-risk, medium-risk, and low-risk, reflecting the threat level when the vulnerability exists alone. The risk assessment model refers to a quantitative calculation model that integrates severity level, exposure ratio, and real-time threat intelligence weights, used to output a security risk value that can directly measure the overall security status of the firmware.

[0133] In one example, reference Figure 7 , Figure 7 This is a flowchart illustrating the logic of generating scenario-based remediation solutions based on vulnerability types in this application. In Phase Four, vulnerability output, processing is categorized according to the specific vulnerability type (credential-based, key-based, and external connection-based). For credential-based vulnerabilities, a credential management solution is generated; for key-based vulnerabilities, the ACME protocol is invoked to automatically update the key; and for external connection-based vulnerabilities, DNS filtering is initiated to block malicious connections. These three processing paths are ultimately embedded into the device configuration, deploying the remediation solution to the device. The effectiveness of the remediation is then verified to confirm whether the vulnerability has been eliminated, and the risk score is updated.

[0134] In this phase, a three-dimensional risk scoring system is adopted to transform technical vulnerabilities into quantifiable decision-making criteria. The mathematical model of the risk matrix quantification model is as follows:

[0135]

[0136] Where C represents the severity level, calculated based on the CVSS score. The data comes from the severity level of the extracted vulnerability features, ranging from 0 to 10 points, such as hardcoded password = 9.8; E represents the exposure ratio, calculated as: number of online devices / total number of devices × 100%. The real-time threat intelligence weighting formula is: 0.5 × (number of malicious domains) + 0.3 × (number of CVE associations), with data sourced from the VirusTotal API output. For example, in a hardcoded email vulnerability, C = 8.5 (information disclosure) and E = 19.3%. =1.2 (associated with 1 historical CVE), with a risk score of approximately 86.29, representing a high risk.

[0137] A four-level response strategy is implemented based on the scoring results. When the score is below 30, it is considered low risk and an observation strategy based on monitoring logs is adopted; when the score is between 30 and 60, it is considered medium risk and repairs must be completed within 3 days; when the score is between 60 and 80, it is considered high risk and an emergency response is initiated within 24 hours; when the score is above 80, it is considered emergency and network disconnection and isolation operations must be performed immediately.

[0138] Of course, corresponding scenario-based remediation solutions can be generated based on the vulnerability type. Refer to Table 2, which is a mapping table between vulnerability types and remediation strategies.

[0139] Table 2

[0140]

[0141] For example, if a hardcoded email account is identified as high-risk and linked to the Mirai botnet attack chain, affecting approximately 100 devices (verified by Shodan), the recommended remediation is to enforce a certificate rotation policy.

[0142] In this embodiment, by integrating credential mining, network exposure analysis, and threat intelligence, the system achieves a comprehensive assessment of risks from single sensitive information identification to multi-dimensional risk assessment, fully covering security vulnerabilities of firmware in areas such as credential security, network exposure, and domain association, thereby improving the comprehensiveness and depth of the assessment.

[0143] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the camera firmware security assessment method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0144] This application also provides a camera firmware security assessment device; please refer to... Figure 8 The camera firmware security assessment device includes:

[0145] The attribute acquisition module 10 is used to acquire the underlying firmware attributes and key offsets of the firmware to be evaluated. The underlying firmware attributes include firmware architecture, compression type and boot information.

[0146] Entropy calculation module 20 is used to calculate the entropy value of the firmware data of the firmware to be evaluated based on the underlying attributes of the firmware and through a preset entropy analysis model, and to determine the compression area based on the entropy value.

[0147] The data acquisition module 30 is used to extract the file system corresponding to the compressed area, and to obtain the compressed data corresponding to the compressed area based on the file system and the key offset.

[0148] The security assessment module 40 is used to scan the sensitive information of the compressed data and perform a security assessment on the sensitive information.

[0149] The camera firmware security evaluation device provided in this application, employing the camera firmware security evaluation method described in the above embodiments, can solve the technical problem that existing methods cannot efficiently process firmware entropy data and identify deep vulnerabilities. Compared with the prior art, the beneficial effects of the camera firmware security evaluation device provided in this application are the same as those of the camera firmware security evaluation method provided in the above embodiments, and other technical features in the camera firmware security evaluation device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0150] This application provides a camera firmware security assessment device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the camera firmware security assessment method in the first embodiment described above.

[0151] The following is for reference. Figure 9 This document illustrates a structural schematic diagram of a camera firmware security evaluation device suitable for implementing embodiments of this application. The camera firmware security evaluation device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 9The camera firmware security assessment device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0152] like Figure 9 As shown, the camera firmware security assessment device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the camera firmware security assessment device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the camera firmware security assessment device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows camera firmware security assessment devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0153] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0154] The camera firmware security assessment device provided in this application, employing the camera firmware security assessment method described in the above embodiments, can solve the technical problem that existing methods cannot efficiently process firmware entropy data and identify deep vulnerabilities. Compared with the prior art, the beneficial effects of the camera firmware security assessment device provided in this application are the same as those of the camera firmware security assessment method provided in the above embodiments, and other technical features in this camera firmware security assessment device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0155] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0157] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the camera firmware security assessment method in the above embodiments.

[0158] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0159] The aforementioned computer-readable storage medium may be included in the camera firmware security assessment device; or it may exist independently and not be assembled into the camera firmware security assessment device.

[0160] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the camera firmware security assessment device, cause the camera firmware security assessment device to perform the camera firmware security assessment method described above.

[0161] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0162] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0163] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0164] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described camera firmware security assessment method. This solves the technical problem that existing methods cannot efficiently process firmware entropy data and identify deep vulnerabilities. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the camera firmware security assessment method provided in the above embodiments, and will not be repeated here.

[0165] The above description is only a part of the embodiments of this application and does not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A camera firmware security evaluation method, characterized in that, The camera firmware security evaluation method comprises: obtaining firmware bottom layer attributes and key offsets of the firmware to be evaluated, wherein the firmware bottom layer attributes comprise firmware architecture, compression type and booting guide information; based on the firmware bottom layer attributes, calculating the entropy value of the firmware data of the firmware to be evaluated through a preset entropy value analysis model, and determining the compression region based on the entropy value; extracting the file system corresponding to the compression region, and obtaining the compressed data corresponding to the compression region according to the file system and the key offsets; scanning sensitive information of the compressed data, and performing security evaluation on the sensitive information; the step of calculating the entropy value of the firmware data of the firmware to be evaluated through a preset entropy value analysis model based on the firmware bottom layer attributes, and determining the compression region based on the entropy value, comprising: calculating the entropy value of the firmware data of the firmware to be evaluated through a preset entropy value analysis model, obtaining the entropy value corresponding to each data segment; determining the corresponding entropy value determination threshold according to the compression type in the firmware bottom layer attributes; marking the data segment with the entropy value greater than or equal to the entropy value determination threshold as a candidate compression region, and marking the data segment with the entropy value less than the entropy value determination threshold as a non-compression region; performing correlation verification on the candidate compression region, and merging the candidate compression regions that are continuous and have an entropy fluctuation amplitude within a preset range to generate a compression region. 2.The camera firmware security evaluation method of claim 1, wherein, after the step of performing correlation verification on the candidate compression region and merging the candidate compression regions that are continuous and have an entropy fluctuation amplitude within a preset range to generate a compression region, further comprising: convert the compression region and the non-compression region into a color heat map through a binary visualization tool, wherein the color heat map identifies the data characteristics of the compression region and the non-compression region with a color gradient. 3.The camera firmware security evaluation method of claim 1, wherein, the step of extracting the file system corresponding to the compression region, and obtaining the compressed data corresponding to the compression region according to the file system and the key offsets, comprising: reading the file system of the compression region using a firmware analysis tool, and locating the candidate storage segment of the file system based on the key offsets; performing file system signature detection on the candidate storage segment to identify the file storage type corresponding to the candidate storage segment; if the file storage type is a multi-layer nested structure, then based on the key offsets, the nested levels are analyzed layer by layer through a depth-first traversal algorithm, and all files and sub-folders of the file system are extracted; according to the files and sub-folders, the compressed data corresponding to the compression region is exported, which includes configuration files, key files, executable files and log files under the directory.

4. The camera firmware security evaluation method according to any one of claims 1 to 3, wherein, before the step of obtaining firmware bottom layer attributes and key offsets of the firmware to be evaluated, further comprising: constructing a device weight model according to market share and vulnerability history data; selecting a target evaluation device with higher weight from a preset candidate device based on the device weight model; obtaining the firmware to be evaluated corresponding to the target evaluation device, and performing hash calculation on the firmware to be evaluated to obtain a firmware hash value; Upload the firmware hash value to a blockchain notarization system for notarization to obtain the integrity-verified firmware to be evaluated.

5. The camera firmware security evaluation method according to any one of claims 1 to 3, wherein, The sensitive information includes a hard-coded credential file, an Internet-exposed device, and a high-risk domain name. The step of scanning the sensitive information in the compressed data and performing a security assessment on the sensitive information comprises: Matching a keyword in the compressed data through a regular expression and locating the hard-coded credential file according to the keyword; Extracting an internal network address and open port information from the sensitive information and verifying the Internet-exposed device according to the internal network address and the open port information; Extracting an embedded public resource in the file system and identifying a high-risk domain name in the public resource; Performing a security assessment on the firmware to be evaluated according to the hard-coded credential file, the Internet-exposed device, and the high-risk domain name. 6.The camera firmware security evaluation method of claim 5, wherein, The step of performing a security assessment on the firmware to be evaluated according to the hard-coded credential file, the Internet-exposed device, and the high-risk domain name comprises: Determining a hazard level of a vulnerability according to the hard-coded credential file; Calculating an exposure ratio based on the number of Internet-exposed devices and the total number of devices; Calculating a real-time threat intelligence weight according to the high-risk domain name; Constructing a risk assessment model through the hazard level, the exposure ratio, and the real-time threat intelligence weight and calculating a security risk value of the firmware to be evaluated according to the risk assessment model.

7. A camera firmware security evaluation apparatus, characterized by comprising: The device comprises: An attribute acquisition module configured to acquire firmware bottom-layer attributes and a key offset of a firmware to be evaluated, wherein the firmware bottom-layer attributes comprise a firmware architecture, a compression type, and booting guide information; An entropy value calculation module configured to calculate an entropy value of firmware data of the firmware to be evaluated based on the firmware bottom-layer attributes through a preset entropy value analysis model and determine a compressed region based on the entropy value; A data acquisition module configured to extract a file system corresponding to the compressed region and acquire compressed data corresponding to the compressed region according to the file system and the key offset; A security assessment module configured to scan sensitive information in the compressed data and perform a security assessment on the sensitive information; The entropy value calculation module is further configured to calculate an entropy value of firmware data of the firmware to be evaluated through a preset entropy value analysis model to obtain an entropy value corresponding to each data segment, determine a corresponding entropy value determination threshold according to the compression type in the firmware bottom-layer attributes, mark a data segment with an entropy value greater than or equal to the entropy value determination threshold as a candidate compressed region, and mark a data segment with an entropy value less than the entropy value determination threshold as a non-compressed region; perform a correlation check on the candidate compressed region, merge candidate compressed regions that are continuous and have an entropy value fluctuation amplitude within a preset range, and generate a compressed region.

8. A camera firmware security evaluation device, comprising: The device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program is configured to implement the steps of the camera firmware security assessment method according to any one of claims 1 to 6.

9. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program. The computer program is executed by the processor to implement the steps of the camera firmware security evaluation method in any one of claims 1 to 6.

Images