Storage data verification method and device of code case, electronic equipment and medium

Abstract

The invention provides a storage data verification method and device for a code case, electronic equipment and a medium, and the method comprises the steps: obtaining an encryption state value corresponding to a current state in response to a state change operation of the code case; the encryption state value comprises a target write-in address; the target write-in address is compared with a partition mapping table stored in a metadata area, and the type of a target partition to which the encryption state value is to be written is determined; the partition mapping table is used for defining a corresponding relation between a partition address range and a partition type; and verifying the encryption state value according to a value verification rule corresponding to the target partition type, and writing the encryption state value into the target write-in address under the condition of successful verification. Before the encryption state value is written into the target write-in address, the type of the encryption state value and the legality of the value are verified, so that the value written into the target write-in address is a legal value, and the situation that illegal value write-in causes disorder of code case locking logic and affects normal use of a code case is avoided.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of automotive technology, and in particular to a method, device, electronic device, and medium for verifying stored data in a password box. Background Art

[0002] Existing vehicle password box modules usually use an electronic storage unit (such as EEPROM (Electrically Erasable Programmable Read Only Memory)) to store the encryption status value to control the locking logic of the storage box.

[0003] In traditional designs, the encryption status value only supports two valid values: 0 (unencrypted) and 1 (encrypted). When the user triggers the encryption operation, the system reads the status value and determines whether it is 1 to determine whether to start the encryption process and lock the action.

[0004] When the status value of the storage unit becomes an illegal value, such as 255, due to hardware failure, electromagnetic interference or erasure anomaly, the encryption process trigger condition only determines whether the status value is equal to 1. When the illegal value 255 is read, the condition judgment fails. The system mistakenly believes that it is currently in the "unencrypted" state, resulting in the inability to start the encryption process, and ultimately causing the storage box to be unable to be locked, affecting the normal use of the password box. Summary of the Invention

[0005] In view of the above problems, embodiments of the present invention are proposed to provide a method, device, electronic device and medium for verifying stored data of a password box that overcomes the above problems or at least partially solves the above problems.

[0006] In order to achieve the above object, the technical solution adopted by the present invention is as follows: In a first aspect, an embodiment of the present application discloses a method for verifying stored data in a password box, the method comprising: In response to a state change operation of the password box, obtaining an encryption state value corresponding to the current state; the encryption state value includes a target write address; Comparing the target write address with a partition mapping table stored in the metadata area to determine the target partition type to which the encrypted state value is to be written; the partition mapping table is used to define the correspondence between partition address ranges and partition types; The encrypted state value is verified according to a value verification rule corresponding to the target partition type, and if the verification is successful, the encrypted state value is written into the target write address. In a second aspect, an embodiment of the present application discloses a device for verifying stored data of a password box, the device comprising: An acquisition module, configured to obtain an encryption state value corresponding to a current state in response to a state change operation of the password box; the encryption state value includes a target write address; a determination module, configured to compare the target write address with a partition mapping table stored in the metadata area to determine a target partition type to which the encrypted state value is to be written; the partition mapping table is configured to define a correspondence between a partition address range and a partition type; A writing module is used to verify the encryption status value according to the value verification rule corresponding to the target partition type, and if the verification is successful, write the encryption status value into the target write address.

[0007] In a third aspect, an embodiment of the present application discloses an electronic device comprising a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the programs or instructions are executed by the processor, the steps of the method described in the first aspect are implemented.

[0008] In a fourth aspect, an embodiment of the present application discloses a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the method described in the first aspect are implemented.

[0009] In an embodiment of the present application, in response to a state change operation of a password box, an encryption state value corresponding to the current state is obtained; the encryption state value includes a target write address; the target write address is compared with a partition mapping table stored in a metadata area to determine the target partition type to which the encryption state value is to be written; the partition mapping table is used to define the correspondence between a partition address range and a partition type; the encryption state value is verified according to a value verification rule corresponding to the target partition type, and if the verification succeeds, the encryption state value is written to the target write address. Before writing data to be written, such as the encryption state value, into the storage area of ​​the password box, the method of the present application first compares the target write address corresponding to the encryption state value with the partition mapping table stored in the metadata area to determine the type of the target write address. Different data types have different ranges of legal values. By verifying the encryption state value based on the value verification rule corresponding to the target partition type, it can be determined whether the encryption state value is a legal value. That is, before writing the encryption state value to the target write address, the present application verifies the type and legality of the encryption state value, so that the value written to the target write address is a legal value, thereby avoiding the writing of illegal values, which may cause confusion in the password box locking logic and affect the normal use of the password box. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 This is a flowchart of a method for verifying stored data in a password box provided in an embodiment of the present application; Figure 2This is a block diagram of a storage data verification device for a password box provided in an embodiment of the present application; Figure 3 is a block diagram of an electronic device provided in an embodiment of the present application; Figure 4 This is another schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0011] The following describes exemplary embodiments of the present application in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the accompanying drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present application and to fully convey the scope of the present application to those skilled in the art.

[0012] The terms "first", "second", etc. in the specification and claims of this application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, the term "and / or" in the specification and claims is used to describe the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0013] refer to Figure 1 , Figure 1 The present invention provides a method for verifying stored data in a password box, the method comprising: Step 101: In response to a state change operation of the password box, an encryption state value corresponding to the current state is obtained; the encryption state value includes a target write address.

[0014] In an embodiment of the present application, a vehicle lockbox is an electronic storage device installed inside a vehicle, such as in the trunk, center console, or under a seat. It is unlocked via a password, fingerprint, Bluetooth, or other methods and is used to store valuables such as wallets, documents, and electronic devices. It features anti-theft, anti-accidental touch, and data encryption. The lockbox achieves security management and control through an electronic control module combined with a storage unit (such as an EEPROM), sensors (such as a door lock motor sensor), and a communication interface (such as a CAN bus). During use, after opening the lockbox lid and inserting items, the lockbox is manually closed or "locked" is selected on the central control screen. The system automatically triggers the encryption process, writes the status value to the EEPROM, and marks it as "encrypted."

[0015] The lockbox's status can be marked with a status value. For example, after locking, a status value of "1" is written to the EEPROM to indicate that the lockbox is encrypted. After opening, a status value of "0" is written to the EEPROM to indicate that the lockbox is not encrypted. The status value written to the EEPROM can be used to control the locking logic. For example, when the status value is 1, the locking process is triggered.

[0016] When the state of the password box changes, for example, the user triggers an encryption operation and the state value changes from 0 to 1, then the encryption state value corresponding to the current state is 1. The encryption state value is a digital parameter used to uniquely identify the current state of the password box.

[0017] The encrypted state value may include a target write address, which is a predefined storage area for writing the state value of the password box.

[0018] Step 102 : Compare the target write address with the partition mapping table stored in the metadata area to determine the target partition type to which the encryption status value is to be written; the partition mapping table is used to define the correspondence between partition address ranges and partition types.

[0019] In an embodiment of the present application, data such as the status value of the password box can be stored in a storage module. The storage module can be partitioned in advance, with different partitions corresponding to different functions, and an address range and a legal value range are defined for each partition. When writing the encrypted status value, the encrypted status value is written to the corresponding partition and the legality of the encrypted status value is verified to ensure that the encrypted status value is written correctly.

[0020] In some embodiments, when it is necessary to write an encrypted status value, the target write address can first be compared with the partition mapping table pre-stored in the metadata area to determine the partition type corresponding to the target write address. The partition mapping table is pre-defined and is used to define the partition type corresponding to each address range in the storage medium. For example, a partition may include an encryption status area, a reserved area, a metadata area, etc. Among them, the encryption status area can also be called a business area, which is used to store business values ​​required for the current system function (such as encryption status value 0 or 1), the reserved area can be a partition reserved for future expansion or temporary storage, and can be initialized to a unified identification value (such as 0x00), and the metadata area is used to store the partition mapping table. The partition mapping table can record the starting address, length, valid value range, partition type, version number, etc. of each area. The following shows an example of defining the metadata structure of the storage partition in actual application: typedef struct { uint16_t start_addr; / / starting address (2 bytes) uint16_t length; / / Area length (2 bytes) uint8_tvalid_min; / / valid value lower limit (1 byte) uint8_tvalid_max; / / upper limit of valid value (1 byte) uint8_tversion; / / Region version number (1 byte) chardescription

[32] ; / / Area description (32 bytes) } __attribute__((packed)) StoragePartition; / / Ensure compact arrangement The above code defines the data structure of each partition in the metadata area. Each partition includes: starting address, area length, upper and lower limits of valid values, area version number and area description. For example, the partition mapping table is as follows: { / / Encryption status area: valid value range 0x00-0x01 .start_addr = 0x0000, .length= 64, .valid_min = 0x00, .valid_max= 0x01, .version= 1, .description = "Encrypted status area" / / Actual storage length: 15 bytes (UTF-8) } The above code defines the encryption status area, namely, the starting address of the encryption status area is: 0x0000; the length is 64 bytes; the valid value range is 0x00-0x01, that is, it can only store 0 or 1; the version is 1; the description information is: store encryption status information. { / / Reserved area: only 0x00 is allowed to be written .start_addr = 0x0040, .length= 32, .valid_min = 0x00, .valid_max= 0x00, .version= 1, .description = "Reserved area" / / Actual storage length: 9 bytes }, The above code defines the reserved area, namely, the starting address of the reserved area is 0x0040; the length is 32 bytes; the only valid value is 0x00; the version is 1; and the description information is: reserved area. This is reserved for future expansion. { / / Metadata area: allows full range values ​​0x00-0xFF .start_addr = 0x0060, .length= 128, .valid_min = 0x00, .valid_max= 0xFF, .version= 1, .description = "Metadata area" / / Actual storage length: 12 bytes } }; The above code defines the metadata area, with a starting address of 0x0060, a length of 128 bytes, a valid value range of 0x00-0xFF, a version of 1, and a description of "metadata area." This area is used to store metadata and accommodate various types of data. In addition, you can also add the definition of partition type identifier to distinguish different partitions. The definition method is as follows: typedef enum { PARTITION_TYPE_BUSINESS = 0x01, / / Business area PARTITION_TYPE_RESERVED = 0x02, / / reserved area PARTITION_TYPE_METADATA = 0x03 / / Metadata area } PartitionType; That is, the identifier of the service area is 0x01, the identifier of the reserved area is 0x02, and the identifier of the metadata area is 0x03.

[0021] After obtaining the encryption status value, the partition mapping table is used to traverse the partition mapping table to determine whether the target write address falls within the address range of a partition. For example, if the target write address is "0x0000" and "0x0000" is defined as "encrypted state area" in the partition mapping table, it can be determined that the partition type to be written to by the target write address is an encrypted state area.

[0022] Different partition types have different corresponding functions and valid value ranges. For example, the encryption status area can be defined as a partition for storing the status value of a password box, and its allowed write values ​​are "0x00" and "0x01". Then, after determining that the partition to which the encryption status value is to be written is the encryption status area, it can be further determined whether the value of the encryption status value is within the range of "0x00" and "0x01". If so, the encryption status value is a legal value. If not, it means that the encryption status value is an illegal value.

[0023] This application binds the partition address range with the partition type so that different types of partitions can correspond to different storage rules, such as data format verification, thereby ensuring that the encrypted status value is accurately written to the area that meets its business attributes, avoiding problems such as data out of bounds, illegal access or format abnormalities caused by address errors or type confusion, and laying the foundation for the reliability and security of the storage system.

[0024] Step 103: verify the encryption status value according to the value verification rule corresponding to the target partition type, and if the verification is successful, write the encryption status value into the target write address.

[0025] In this embodiment of the present application, after determining the target partition type for the encrypted state value, the encrypted state value can be verified for legitimacy based on the value verification rules pre-set for the partition corresponding to the target partition type to ensure that the data is written correctly. The correspondence between partition types and value verification rules can be pre-stored in the metadata area.

[0026] For example, the encryption status area can require a value of 0x00 (unencrypted) or 0x01 (encrypted). During verification, the encryption status value is compared with the target partition's rules to check whether the value is within the allowed range, conforms to the preset format, and contains a valid checksum (such as a CRC or hash value).

[0027] If the encryption status value is 0x01 and the target partition type is an encryption status area, the encryption status area rules require that the value can only be 0x00 or 0x01, and the verification passes. If the value is 0x02, the verification fails due to being out of range, and the write is rejected. Only when the verification succeeds will the system write the encryption status value to the target write address. This prevents the storage of illegal values ​​or incorrectly formatted data, prevents misjudgment of the lockbox status or functional failure due to data anomalies, and ensures the accuracy of stored data and the stability of system operation.

[0028] For example, in actual use, the function to implement pre-write verification can be: static bool validate_write_operation(uint32_t addr, uint8_t value) { for (size_t i = 0; i <PARTITION_TABLE_SIZE; ++i) { const StoragePartition *part =&partition_table[i]; if (addr>= part->start_addr&&addr<(part->start_addr + part->length)){ / / Special processing of reserved area if (part->type == PARTITION_TYPE_RESERVED) { return (value == part->valid_min); / / The reserved area can only be written to the preset value } / / General value range check return (value>= part->valid_min)&&(value<= part->valid_max); } } return false; / / The address is not in any partition } The above code implements a pre-write check of the encrypted status value. "addr" is the target write address, and "value" is the data value to be written. The code loops through the partitions to which addr belongs, checking whether the address falls within the address range of the current partition. During this check, only preset fixed values ​​are allowed to be written to reserved areas. For other partitions, the code checks whether the data value to be written is within the permitted range. This ensures that the data written to the storage module is legal, preventing logic errors caused by writing illegal values.

[0029] Before writing the data to be written, such as the encrypted status value, into the storage area of ​​the password box, the method of the present application first determines the type of the target write address based on the comparison between the target write address corresponding to the encrypted status value and the partition mapping table stored in the metadata area. Different data types correspond to different ranges of legal values. By verifying the encrypted status value based on the value verification rule corresponding to the target partition type, it can be determined whether the encrypted status value is a legal value. That is, before writing the encrypted status value to the target write address, the present application verifies the type and legality of the encrypted status value, so that the value written to the target write address is a legal value, so as to avoid the writing of illegal values, which will cause confusion in the password box locking logic and affect the normal use of the password box.

[0030] Optionally, the method further includes: Step 104: When the password box is powered on for the first time, the system version number and initialization flag stored in the metadata area are read; Step 105: When the stored system version number is consistent with the current version number and it is determined according to the initialization flag that the storage module of the password box has not completed initialization, perform an initialization operation on the storage module.

[0031] In this embodiment of the present application, regarding steps 104 and 105, when the lockbox is first powered on and started, the storage module version is first verified and initialized. A fixed storage location in the metadata area can store the system version number and initialization flag. The system version number indicates the current system version, and the initialization flag indicates whether each partition of the storage module has been initialized. By storing these in a fixed storage location, accurate access is ensured upon system startup. The current version number is the version number of the firmware currently running.

[0032] Afterwards, the system version number is compared with the current version number to ensure that the storage data structure is compatible with the currently running firmware, avoiding data parsing errors due to version differences. When the stored system version number is consistent with the current version number, the initialization flag is further checked. If it is determined based on the initialization flag that the storage module has not completed initialization, the initialization operation is triggered. That is, only when the version numbers are consistent and the storage module is not initialized, the system will execute initialization processes such as erasing partitions and filling in default values ​​to ensure that the storage module starts in a standard state. This not only avoids data loss caused by repeated initialization, but also ensures that the initial state of the storage module is correct under the premise of version compatibility, thereby ensuring data consistency and security when the password box system starts.

[0033] Optionally, step 105 includes: Sub-step 1051, verifying the partition address range and partition type in the pre-defined partition mapping table to determine the legitimacy of the partition address range and partition type; Sub-step 1052: When it is determined that the partition address range and the partition type are legal, perform initialization operations on each partition according to the initialization rules corresponding to each partition.

[0034] In the embodiment of the present application, regarding sub-steps 1051 and 1052, during the storage module initialization process, the partition mapping table is first verified to ensure secure and reliable data storage. The pre-defined partition address range and partition type in the partition mapping table stored in the metadata area are first verified to determine their legitimacy.

[0035] The partition mapping table defines the partition types corresponding to different address ranges, such as business areas, metadata areas, reserved areas, etc. The legitimacy of the partition address range is verified by checking whether the starting and ending addresses of each partition are reasonable, whether there is address overlap, or whether the addresses exceed the total capacity of the storage medium. For example, if the address ranges of two partitions partially overlap, data writing may be chaotic; if a partition address exceeds the physical address range of the storage medium, it is an invalid configuration. By verifying the legitimacy of the partition type, it can be confirmed whether the type defined for each partition conforms to the standard type predefined by the system, avoiding illegal or meaningless partition type definitions. Only when the partition address range and partition type are verified can the initialization operation of each partition be implemented according to the partition mapping table.

[0036] After confirming that the partition address range and partition type are legal, initialization operations are performed on them according to the initialization rules corresponding to each partition. Different types of partitions have different initialization requirements and purposes. For example, the business area may need to erase the original data first, and then fill it with specific default values, such as all 0s, to prepare for the subsequent storage of business-related data. Business-related data can be the encryption status value of the password box; the metadata area may need to write initial partition mapping table information, system configuration parameters, etc. to ensure that the system can correctly identify and manage each partition; the reserved area may only need to be marked as unused or filled with specific identification values ​​so that it can be dynamically allocated or adjusted as needed. By performing initialization according to the initialization rules corresponding to each partition, each partition can be initialized to a suitable initial state, providing an orderly and secure basic environment for subsequent data storage, reading and management, and ensuring the stable operation and data integrity of the password box device.

[0037] Optionally, the partition types include: business area, reserved area and metadata area, and sub-step 1052 includes: Sub-step 10521, erasing the original data of the service area and filling all data with 0; Sub-step 10522: erasing the original data in the reserved area and filling it with a preset security value; Sub-step 10523, erasing the original data in the metadata area and filling data according to the erase mode value.

[0038] In the embodiment of the present application, for sub-steps 10521 to 10523, the business area is used to store business data, such as the encryption status value of the password box. During initialization, the original data is first cleared through an erase operation to ensure that the storage module is restored to the physical default state, and then it is forcibly filled with all 0s. For example, when the password box is not set with a password, the encryption status value of the business area defaults to 0, and the system can judge that it is currently in an "unencrypted" state. In addition, filling with all 0s can also eliminate the residual historical data and avoid misjudgment of the status caused by the residual old value of the storage medium, such as the residual value 0x01 being mistakenly identified as "encrypted". By erasing and then filling with all 0s, the consistency of the initial state of the data is doubly guaranteed from the physical and logical levels.

[0039] The reserved area is reserved for future expansion or temporary storage. During initialization, the original data is erased and then filled with a "preset safety value," such as 0x00 or another specific identifier value, which is not limited in this embodiment. Erasing residual data prevents illegal values ​​from being misused by subsequent business logic. At the same time, filling the area with the preset safety value ensures compatibility with subsequent type changes in the reserved area.

[0040] The metadata area stores information such as the partition mapping table and system version number. During initialization, the original data must be erased first and then filled with the erase mode value, such as 0xFF. This is used to confirm the erase result and mark the area as initialized. For example, when the system reads the metadata area and finds a region containing 0xFF, it can quickly determine that the region is in its initial state, avoiding configuration parsing errors caused by residual historical values.

[0041] An initialization process is shown below: bool initialize_storage() { StorageMetadata meta = {0}; if (!read_metadata(&meta)) return false; if (meta.init_flag != INIT_MAGIC_NUMBER) { if (!validate_partitions()) return false; for (size_t i = 0; i <PARTITION_TABLE_SIZE; ++i) { const StoragePartition *part =&partition_table[i]; / / Business area initialization (type judgment) if (part->type == PARTITION_TYPE_BUSINESS) { if (!erase_eeprom(part->start_addr, part->length) || !fill_eeprom(part->start_addr, part->length, 0x00)) { / / Force initialization to 0 return false; } } / / Initialize the reserved area else if (part->type == PARTITION_TYPE_RESERVED) { if (!erase_eeprom(part->start_addr, part->length) || !fill_eeprom(part->start_addr, part->length, part->valid_min)) { / / Must fill in the preset value return false; } } / / The metadata area maintains the original logic else { if (!erase_eeprom(part->start_addr, part->length) || !fill_eeprom(part->start_addr,part->length, ERASE_PATTERN)) { return false; } } } if (!write_metadata() || !write_u16_eeprom(INIT_FLAG_ADDR, INIT_MAGIC_NUMBER)) { return false; } } return true; } First, read the metadata and check whether it has been initialized, for example, by checking whether the magic number of the metadata area init_flag is equal to the preset INIT_MAGIC_NUMBER. "init_flag" is used to store the value of the initialization flag. If it has not been initialized, verify the validity of the partition mapping table through "validate_partitions()". "validate_partitions()" is a pre-defined partition verification function used to verify whether the address range overlaps, whether the type is valid, etc. If the verification is successful, initialize each partition according to the partition type. For example, after erasing the data in the business area, fill it with all 0s, fill the reserved area with preset values, and fill the metadata area with "erase mode value" after erasing. After completion, update the metadata and initialization flag values. If it has been initialized, skip the above process and return success directly.

[0042] Optionally, before step 105, the method further includes: Step 106: If the system version number is inconsistent with the current version number, determine a data migration plan based on the difference between the system version number and the current version number; Step 107: Migrate the data in the storage module according to the data migration solution.

[0043] In an embodiment of the present application, with respect to step 106 and step 107, during the operation of the password box system, a firmware upgrade or downgrade may cause the system version number to change. Therefore, after the system is powered on, the version must be verified first. When it is detected that the system version number stored in the metadata area is inconsistent with the currently running firmware version number, it means that the system firmware version has changed. At this time, the corresponding data migration plan can be determined based on the difference between the two version numbers. Different version differences correspond to different data structures, storage formats or functional changes. For example, the format of the version number can be: "Major version number.Minor version number". Changes in the major version number indicate changes in the partition structure, and the minor version number indicates logical fine-tuning. Therefore, based on the difference between the system version number and the current version number, the data migration plan can be determined.

[0044] After the data migration plan is determined, specific migration operations can be performed on the data in the storage module according to the migration plan.

[0045] Optionally, the format of the version number defines a major version number and a minor version number, and step 106 includes: Sub-step 1061: If the major version number of the system version number is inconsistent with the major version number of the current version number, the data migration solution is full data migration; Sub-step 1062: If the major version number of the system version number is consistent with the major version number of the current version number, and the minor version number of the system version number is inconsistent with the minor version number of the current version number, then the data migration solution is incremental data migration.

[0046] In an embodiment of the present application, for sub-steps 1061 to 1062, the format of the version number can be: "major version number.minor version number". Therefore, if the major version number of the system version number is inconsistent with the major version number of the current version number, it indicates that the partition structure has changed, and the data migration plan is full data migration. Through full data migration, parsing errors caused by residual old data formats can be avoided.

[0047] If the system's major version number matches the current version's major version number, but the system's minor version number doesn't match the current version's minor version number, it indicates that only minor logic adjustments are required. Incremental data migration can be used. This means modifying only the data that needs to be updated, retaining the unchanged data, reducing the migration workload.

[0048] For example, the version verification process is: void check_storage_compatibility() { StorageVersion stored_version; read_from_eeprom(VERSION_ADDR,(uint8_t*)&stored_version, sizeof(stored_version)); if (stored_version.major != CURRENT_VERSION.major) { / / Major version change triggers full data migration execute_full_migration(); } else if (stored_version.minor != CURRENT_VERSION.minor) { / / Minor version change triggers incremental logic adjustment execute_partial_migration(); } / / Update to the current version write_to_eeprom(VERSION_ADDR,(uint8_t*)&CURRENT_VERSION, sizeof(CURRENT_VERSION)); } The execution logic of the above code is as follows: read the stored system version number from the fixed address VERSION_ADDR and perform version comparison. If the major version is inconsistent: trigger full data migration; if the minor version is inconsistent: trigger incremental data migration. After the migration is complete, write the current version number CURRENT_VERSION back to the storage.

[0049] Optionally, step 107 includes: Sub-step 1071: If the data migration solution is full data migration, compare the partition mapping table corresponding to the current version number with the partition mapping table corresponding to the system version number to determine a partition comparison result; Sub-step 1072: If the partition comparison result indicates that the partition type has changed, check whether the data in the first target partition complies with the value verification rules of the changed partition type. If it does not comply, erase the data in the first target partition and fill in the data according to the changed partition type; the first target partition is the partition whose type has changed in the partition corresponding to the system version number.

[0050] In an embodiment of the present application, for sub-steps 1071 and 1072, if the data migration scheme is full data migration, it indicates that the partition table structure has been adjusted, such as adding a new partition type or changing the partition type. The specific comparison process may be: comparing the partition mapping table corresponding to the current version number with the partition mapping table corresponding to the system version number, traversing each entry in the partition mapping table corresponding to the current version number, and locating the corresponding entry in the partition mapping table corresponding to the system version number through the starting address to determine the partition comparison result. If the partition comparison result indicates that the partition type has changed, verify whether the data in the first target partition complies with the value verification rules of the changed partition type. For example, if the first target partition is changed from the reserved area to the business area, then it is necessary to verify whether the data in the first target partition complies with the value verification rules of the business area. If not, the old data in the first target partition needs to be erased and filled with data that meets the requirements of the business area.

[0051] For example, when the use of a storage area changes (such as when a reserved area is converted to a business area), the validity of historical data is automatically checked and the area change history (old use, new use, and change time) is recorded in the metadata area. The implementation code is as follows: typedef struct { uint16_tstart_addr; / / area starting address uint16_tlength; / / Area length uint8_told_type; / / Old type (0 = reserved area, 1 = business area) uint8_tnew_type; / / new type uint32_tchange_time; / / Change timestamp } StorageChangeRecord; For full data migration, that is, when the major version is changed, the sample code for implementation is as follows: void execute_full_migration() { / / Traverse all areas and check whether the type has changed for (int i = 0; i <NUM_PARTITIONS; i++) { StoragePartition new_part = new_partition_table[i]; StoragePartition old_part = find_old_partition(new_part.start_addr); / / If the area type changes (such as reserved area → business area) if (old_part.type != new_part.type) { / / Verify the validity of old data if (!validate_region(old_part.start_addr, old_part.length, new_part.valid_min, new_part.valid_max)) { / / Perform data cleanup sanitize_region(new_part.start_addr, new_part.length, new_part.init_value); } } } } The execution logic of the above code is: traverse all areas and check whether the type has changed. If the area type has changed, such as the reserved area is changed to the business area, the validity of the old data is verified. If the old data is illegal, the data cleaning operation is performed. The following is an example of the data cleaning function: void sanitize_region(uint16_t start_addr, uint16_t length, uint8_tinit_value) { for (uint16_t addr = start_addr; addr <start_addr + length; addr++) { uint8_t value = read_from_eeprom(addr); if (value<new_part.valid_min || value> new_part.valid_max) { write_to_eeprom(addr, init_value); / / reset to initial value } } } The execution logic of the above code is: verify whether the old data meets the value verification specifications of the new partition type. If not, erase the old data and reset the area to the initial value of the new partition type.

[0052] Optionally, step 107 includes: Sub-step 1073 , if the data migration scheme is incremental data migration, obtaining an incremental change configuration file; Sub-step 1074, if the incremental change configuration file indicates to perform a preset operation on the data of the second target partition, then traverse and read the data of the second target partition, and perform the preset operation on the data of the second target partition; the preset operation includes: any one of: byte expansion operation, field deletion operation, and field content change operation.

[0053] In the embodiment of the present application, for sub-steps 1073 and 1074, if the data migration scheme is incremental data migration, it indicates that it is a logic fine-tuning, the second target partition is used to represent the partition that has changed, and the incremental change configuration file is used to indicate the preset operation for changing the second target partition, which can include any one of: byte expansion operation, field deletion operation, and field content change operation; for example, taking the incremental change configuration file indicating that the preset operation performed on the second target partition is a byte expansion operation as an example, if the second target partition is an encrypted state area, the incremental change configuration file indicates that the encrypted state area is expanded from 1 byte to 2 bytes. At this time, the encrypted state area can be traversed and the data stored in the encrypted state area can be format converted to data that meets the new format requirements.

[0054] An example of incremental data migration is as follows: void execute_partial_migration() { / / Example: Encryption status area expanded from 1 byte to 2 bytes for (uint16_t addr = ENCRYPTION_STATUS_START; addr <ENCRYPTION_STATUS_END; addr += 2) { uint8_t old_value = read_from_eeprom(addr); uint16_t new_value = (old_value == 0xFF) ? 0x0000 : old_value; write_to_eeprom(addr, (uint8_t)(new_value>>8)); / / write high byte write_to_eeprom(addr + 1, (uint8_t)(new_value&0xFF)); / / write low byte }} The above code illustrates the incremental migration process by expanding the encryption status area from 1 byte to 2 bytes. This involves traversing the encryption status area in 2-byte increments, from the starting address ENCRYPTION_STATUS_START to the ending address ENCRYPTION_STATUS_END. The old data is read from address "addr" to obtain the original 1-byte encryption status value. If the old value was 0xFF, the new value is 0x0000; otherwise, the old value is retained (for example, 0x01 becomes 0x0001). The new value, new_value, is split into the upper 8 bits and lower 8 bits, respectively, and written to two adjacent addresses to complete the data format conversion.

[0055] If the incremental change configuration file indicates that the preset operation to be performed on the second target partition is a field deletion operation, when performing the incremental change, the second target partition can be traversed to determine whether the field to which the data in the second target partition belongs is the old field indicated by the incremental change configuration file to be deleted. If so, the data corresponding to the old field is deleted. If the incremental change configuration file indicates that the preset operation to be performed on the second target partition is a field content change operation, for example, if the second target partition is a reserved area, and the incremental change configuration file indicates that the preset value of the reserved area is changed from value "A" to value "B", then when performing the incremental change, the data in the reserved area can be traversed to change value "A" to value "B".

[0056] Optionally, after step 107, the method further includes: Step 108: Save the partition mapping table corresponding to the current version number to the metadata area, and replace the system version number stored in the metadata area with the current version number.

[0057] In an embodiment of the present application, after completing version verification and initialization, the partition mapping table corresponding to the current version number can be saved to the metadata area, and the system version number stored in the metadata area can be replaced with the current version number to correctly process various types of data generated during the subsequent password box operation.

[0058] In summary, in an embodiment of the present application, in response to a state change operation of a password box, an encryption state value corresponding to the current state is obtained; the encryption state value includes a target write address; the target write address is compared with a partition mapping table stored in a metadata area to determine the target partition type to which the encryption state value is to be written; the partition mapping table is used to define the correspondence between a partition address range and a partition type; the encryption state value is verified according to a value verification rule corresponding to the target partition type, and if the verification succeeds, the encryption state value is written to the target write address. Before writing data to be written, such as an encryption state value, into the storage area of ​​the password box, the method of the present application first compares the target write address corresponding to the encryption state value with the partition mapping table stored in the metadata area to determine the type of the target write address. Different data types have different ranges of legal values. By verifying the encryption state value based on the value verification rule corresponding to the target partition type, it is possible to determine whether the encryption state value is a legal value. That is, before writing the encryption state value to the target write address, the present application verifies the type and legality of the encryption state value, so that the value written to the target write address is a legal value, thereby avoiding the writing of illegal values, which may cause confusion in the lock box locking logic and affect the normal use of the password box.

[0059] refer to Figure 2 , which shows a storage data verification device 20 of a password box provided in an embodiment of the present application, the device comprising: An acquisition module 201 is configured to obtain an encryption state value corresponding to a current state in response to a state change operation of the password box; the encryption state value includes a target write address; Determination module 202, configured to compare the target write address with a partition mapping table stored in the metadata area to determine the target partition type to which the encrypted state value is to be written; the partition mapping table is configured to define a correspondence between a partition address range and a partition type; The writing module 203 is configured to verify the encryption status value according to a value verification rule corresponding to the target partition type, and write the encryption status value into the target write address if the verification succeeds.

[0060] Optionally, the device further comprises: The reading module is used to read the system version number and initialization flag stored in the metadata area when the password box is powered on for the first time; The initialization module is used to initialize the storage module when the stored system version number is consistent with the current version number and it is determined according to the initialization flag that the storage module of the password box has not completed initialization.

[0061] Optionally, the initialization module includes: A first verification submodule is configured to verify the partition address range and partition type in the predefined partition mapping table to determine the legitimacy of the partition address range and partition type; The first initialization submodule is configured to perform initialization operations on each partition according to the initialization rules corresponding to each partition when it is determined that the partition address range and the partition type are legal.

[0062] Optionally, the partition types include: a service area, a reserved area, and a metadata area, and the first initialization submodule includes: A first initialization unit, configured to erase original data in the service area and fill all data with 0; A second initialization unit, configured to erase the original data in the reserved area and fill it with a preset security value; The third initialization unit is used to erase the original data in the metadata area and fill the data according to the erasure mode value.

[0063] Optionally, the device further comprises: A version verification module, configured to determine a data migration plan based on the difference between the system version number and the current version number if the system version number is inconsistent with the current version number; The migration module is used to perform migration operations on the data of the storage module according to the data migration plan.

[0064] Optionally, the format of the version number defines a major version number and a minor version number, and the version verification module includes: A first migration submodule is configured to, if the major version number of the system version number is inconsistent with the major version number of the current version number, determine that the data migration solution is a full data migration; The second migration submodule is used to configure the data migration solution to be incremental data migration if the major version number of the system version number is consistent with the major version number of the current version number and the minor version number of the system version number is inconsistent with the minor version number of the current version number.

[0065] Optionally, the migration module includes: A first comparison submodule is configured to compare the partition mapping table corresponding to the current version number with the partition mapping table corresponding to the system version number to determine a partition comparison result if the data migration solution is full data migration; The first execution submodule is used to verify whether the data in the first target partition complies with the value verification rules of the changed partition type if the partition comparison result indicates that the partition type has changed. If not, the data in the first target partition is erased and the data is filled in according to the changed partition type; the first target partition is the partition whose type has changed in the partition corresponding to the system version number.

[0066] Optionally, the migration module includes: A second comparison submodule is configured to obtain an incremental change configuration file if the data migration solution is incremental data migration; The second execution submodule is used to traverse and read the data of the second target partition and perform the preset operation on the data of the second target partition if the incremental change configuration file indicates to perform a preset operation on the data of the second target partition; the preset operation includes: any one of: byte expansion operation, field deletion operation, and field content change operation.

[0067] Optionally, the device comprises: The metadata area update module is used to save the mapping table to the metadata area and replace the system version number stored in the metadata area with the current version number.

[0068] In summary, in an embodiment of the present application, in response to a state change operation of a password box, an encryption state value corresponding to the current state is obtained; the encryption state value includes a target write address; the target write address is compared with a partition mapping table stored in a metadata area to determine the target partition type to which the encryption state value is to be written; the partition mapping table is used to define the correspondence between a partition address range and a partition type; the encryption state value is verified according to a value verification rule corresponding to the target partition type, and if the verification succeeds, the encryption state value is written to the target write address. Before writing data to be written, such as an encryption state value, into the storage area of ​​the password box, the method of the present application first compares the target write address corresponding to the encryption state value with the partition mapping table stored in the metadata area to determine the type of the target write address. Different data types have different ranges of legal values. By verifying the encryption state value based on the value verification rule corresponding to the target partition type, it is possible to determine whether the encryption state value is a legal value. That is, before writing the encryption state value to the target write address, the present application verifies the type and legality of the encryption state value, so that the value written to the target write address is a legal value, thereby avoiding the writing of illegal values, which may cause confusion in the lock box locking logic and affect the normal use of the password box.

[0069] Reference Figure 3 , the electronic device 600 may include one or more of the following components: a processing component 602 , a memory 604 , a power component 606 , a multimedia component 608 , an audio component 610 , an input / output (I / O) interface 612 , a sensor component 614 , and a communication component 616 .

[0070] The processing component 602 generally controls the overall operation of the electronic device 600, such as operations associated with display, phone calls, data communications, camera operation, and recording operations. The processing component 602 may include one or more processors 620 to execute instructions to perform all or part of the steps of the above-described method. In addition, the processing component 602 may include one or more modules to facilitate interaction between the processing component 602 and other components. For example, the processing component 602 may include a multimedia module to facilitate interaction between the multimedia component 608 and the processing component 602.

[0071] The memory 604 is used to store various types of data to support operations on the electronic device 600. Examples of such data include instructions for any application or method operating on the electronic device 600, contact data, phone book data, messages, pictures, multimedia, etc. The memory 604 can be implemented by any type of volatile or non-volatile storage device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0072] The power supply assembly 606 provides power to the various components of the electronic device 600. The power supply assembly 606 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 600.

[0073] The multimedia component 608 includes a screen that provides an output interface between the electronic device 600 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, it may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide action. In some embodiments, the multimedia component 608 includes a front-facing camera and / or a rear-facing camera. When the electronic device 600 is in an operating mode, such as a capture mode or a multimedia mode, the front-facing camera and / or the rear-facing camera can receive external multimedia data. Each front-facing camera and the rear-facing camera can have a fixed optical lens system or have focal length and optical zoom capabilities.

[0074] The audio component 610 is used to output and / or input audio signals. For example, the audio component 610 includes a microphone (MIC) that is used to receive external audio signals when the electronic device 600 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals can be further stored in the memory 604 or transmitted via the communication component 616. In some embodiments, the audio component 610 also includes a speaker for outputting audio signals.

[0075] I / O interface 612 provides an interface between processing component 602 and peripheral interface modules, such as a keyboard, click wheel, buttons, etc. These buttons may include but are not limited to: a home button, volume buttons, a start button, and a lock button.

[0076] The sensor assembly 614 includes one or more sensors for providing various aspects of status assessment for the electronic device 600. For example, the sensor assembly 614 can detect the open / closed state of the electronic device 600, the relative positioning of components, such as the display and keypad of the electronic device 600. The sensor assembly 614 can also detect changes in the position of the electronic device 600 or a component of the electronic device 600, the presence or absence of user contact with the electronic device 600, the orientation or acceleration / deceleration of the electronic device 600, and temperature changes of the electronic device 600. The sensor assembly 614 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 614 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 614 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0077] The communication component 616 is used to facilitate wired or wireless communication between the electronic device 600 and other devices. The electronic device 600 can access a wireless network based on a communication standard, such as WiFi, a carrier network (such as 2G, 3G, 4G or 5G), or a combination thereof. In an exemplary embodiment, the communication component 616 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 616 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0078] In an exemplary embodiment, the electronic device 600 can be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors or other electronic components to implement a storage data verification method for a password box provided in an embodiment of the present application.

[0079] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 604 including instructions. The instructions can be executed by the processor 620 of the electronic device 600 to perform the above method. For example, the non-transitory storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0080] Figure 4 A block diagram of an electronic device 700 is shown according to an exemplary embodiment. For example, the electronic device 700 can be provided as a server. Figure 4 Electronic device 700 includes a processing component 722, which further includes one or more processors, and memory resources represented by memory 732 for storing instructions executable by processing component 722, such as applications. The applications stored in memory 732 may include one or more modules, each corresponding to a set of instructions. In addition, processing component 722 is configured to execute instructions to perform a method for verifying stored data in a password box provided in an embodiment of the present application.

[0081] The electronic device 700 may further include a power supply component 726 configured to perform power management of the electronic device 700, a wired or wireless network interface 750 configured to connect the electronic device 700 to a network, and an input / output (I / O) interface 758. The electronic device 700 may operate based on an operating system stored in the memory 732, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, or the like.

[0082] An embodiment of the present application also provides a computer program product, including a computer program, which implements the method for verifying stored data of a password box when executed by a processor.

[0083] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of the present application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0084] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for verifying stored data in a password box, characterized in that: The method comprises: In response to a state change operation of the password box, obtaining an encryption state value corresponding to the current state; the encryption state value includes a target write address; Comparing the target write address with a partition mapping table stored in the metadata area to determine the target partition type to which the encrypted state value is to be written; the partition mapping table is used to define the correspondence between partition address ranges and partition types; The encrypted state value is verified according to a value verification rule corresponding to the target partition type, and if the verification is successful, the encrypted state value is written into the target write address.

2. The method according to claim 1, characterized in that The method further comprises: When the password box is powered on for the first time, the system version number and initialization flag stored in the metadata area are read; When the stored system version number is consistent with the current version number and it is determined according to the initialization flag that the storage module of the password box has not completed initialization, the storage module is initialized.

3. The method according to claim 2, characterized in that Initializing the storage module includes: Verify the partition address range and partition type in the predefined partition mapping table to determine the legitimacy of the partition address range and partition type; When it is determined that the partition address range and the partition type are legal, initialization operations are performed on each partition according to the initialization rules corresponding to each partition.

4. The method according to claim 3, characterized in that The partition types include: business area, reserved area and metadata area. Initialization operations are performed on each partition according to the initialization rules corresponding to each partition, including: Erase the original data of the business area and fill it all with 0; Erasing the original data in the reserved area and filling it with a preset security value; The original data in the metadata area is erased, and data is filled in according to the erase mode value.

5. The method according to claim 2, characterized in that Before performing an initialization operation on the storage module, the method further includes: If the system version number is inconsistent with the current version number, determining a data migration plan based on the difference between the system version number and the current version number; According to the data migration solution, a migration operation is performed on the data of the storage module.

6. The method according to claim 5, characterized in that The version number format defines the major version number and the minor version number. If the system version number is inconsistent with the current version number, a data migration plan is determined based on the difference between the system version number and the current version number, including: If the major version number of the system version number is inconsistent with the major version number of the current version number, the data migration solution is full data migration; If the major version number of the system version number is consistent with the major version number of the current version number, and the minor version number of the system version number is inconsistent with the minor version number of the current version number, then the data migration solution is incremental data migration.

7. The method according to claim 6, characterized in that According to the data migration solution, the data in the storage module is migrated, including: If the data migration solution is full data migration, the partition mapping table corresponding to the current version number is compared with the partition mapping table corresponding to the system version number to determine a partition comparison result; If the partition comparison result indicates that the partition type has changed, check whether the data in the first target partition complies with the value verification rules of the changed partition type. If it does not comply, erase the data in the first target partition and fill in the data according to the changed partition type; the first target partition is the partition whose type has changed in the partition corresponding to the system version number.

8. The method according to claim 6, characterized in that According to the data migration solution, the data in the storage module is migrated, including: If the data migration solution is incremental data migration, obtaining an incremental change configuration file; If the incremental change configuration file indicates to perform a preset operation on the data of the second target partition, the data of the second target partition is traversed and read, and the preset operation is performed on the data of the second target partition; the preset operation includes: any one of: byte extension operation, field deletion operation, and field content change operation.

9. The method according to claim 5, characterized in that After performing a migration operation on the data in the storage module according to the data migration solution, the method further includes: The partition mapping table corresponding to the current version number is saved to the metadata area, and the system version number stored in the metadata area is replaced with the current version number.

10. A storage data verification device for a password box, characterized in that: The device comprises: An acquisition module, configured to obtain an encryption state value corresponding to a current state in response to a state change operation of the password box; the encryption state value includes a target write address; a determination module, configured to compare the target write address with a partition mapping table stored in the metadata area to determine a target partition type to which the encrypted state value is to be written; the partition mapping table is configured to define a correspondence between a partition address range and a partition type; A writing module is used to verify the encryption status value according to the value verification rule corresponding to the target partition type, and if the verification is successful, write the encryption status value into the target write address.

11. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the method according to any one of claims 1 to 9.

Images