File processing method, computer readable storage medium and electronic device
Patent Information
- Application Number
- CN202211006484.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-08-22
- Publication Date
- 2026-11-03
- Estimated Expiration
- 2042-08-22
AI Technical Summary
现有技术中,现有技术中,AI模型在部署于计算资源受限的端设备时,现有技术中,对AI模型进行加密计算量大,导致的部署和推理过程中计算量大,影响部署效率。
By constructing a file header structure to randomly corrupt the source file, and then encrypting the random corruption rules and writing them into the source file header, the entire file is not encrypted; only the file header is processed.
It improves the confidentiality and security of AI models while reducing the demand for computing resources, especially on end devices with limited computing resources, and improves the speed of deprotection before inference.
Smart Images

Figure CN115455372B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of artificial intelligence (AI) technology, and in particular to the field of AI model file processing technology. Background Technology
[0002] In the field of AI, once an AI model is built and trained, it can be deployed and released. Without protection, any third party who obtains the model can analyze it using model visualization tools (such as Netron), and even run and use it directly. To protect their AI algorithm models from unauthorized use, current technology uses encryption algorithms to encrypt the entire AI model before deployment and release, and then decrypts it before inference to obtain the original model for inference. However, encrypting the entire AI model becomes computationally intensive when the model is large, especially on edge devices where computing power is limited, hindering the deployment and implementation of AI models on edge devices. Summary of the Invention
[0003] The purpose of this application is to provide a file processing method, a computer-readable storage medium, and an electronic device that can solve the technical problem of large encryption and decryption computation caused by encrypting the entire file when protecting files in the prior art.
[0004] To achieve the above and other related objectives, this application provides a file processing method. The method includes: creating an empty first protected file for a source file; constructing a file header structure associated with the source file based on an operation area list; encrypting the file header structure, and forming a second protected file based on the encrypted file header structure and the first protected file; and processing the source file according to the file header structure, and forming a third protected file based on the processed source file and the second protected file.
[0005] In one embodiment of this application, the constructed file header structure includes a preset protection magic number and a preset number of operation area lists.
[0006] In one embodiment of this application, each operation area in the operation area list consists of an offset address, a target offset address, and an operation length.
[0007] In one embodiment of this application, constructing a file header structure associated with the source file based on the operation area list includes: randomly generating a first set of random numbers and a second set of random numbers, wherein the first set of random numbers corresponds to the offset address of the operation area in the source file, and the second set of random numbers corresponds to the target offset address of the operation area in the source file; inserting a third set of random numbers as the operation length after the offset address of each operation area, wherein the starting position of the third set of random numbers is determined by the target offset address of the operation area.
[0008] In one embodiment of this application, the method of encrypting the file header structure and forming a second protected file based on the encrypted file header structure and the first protected file includes: determining whether the size of the encrypted file header structure is equal to the size of the file header structure before encryption; if so, writing the encrypted file header structure into the header of the first protected file; if not, constructing an auxiliary header of a preset size, then writing the auxiliary header into the header of the first protected file, and writing the encrypted file header structure into the current tail of the first protected file, wherein the auxiliary header includes a preset magic number and the size of the encrypted file header structure.
[0009] In one embodiment of this application, processing the source file according to the file header structure and forming a third protection file based on the processed source file and the second protection file includes: traversing all operation areas in the operation area list: for the first operation area, locating the beginning of the source file, reading the data of the offset address of the operation area and writing it to the current end of the protection file, locating the source file to the target offset address of the current operation area, and writing the data of the operation length of the current operation area to the current end of the protection file; for the last operation area, using the offset address of the operation area as the current operation area offset address, and using the offset address of the operation area preceding the operation area as the auxiliary offset address: first locating the source file to the auxiliary offset address, and writing the data of the current operation area offset address minus the length of the auxiliary offset address. The process begins by moving the source file to the end of the current operation area. Then, the source file is positioned at the target offset address of the current operation area. The operation length of the current operation area is written to the end of the current operation area. Finally, the source file is positioned at the offset address of the last operation area, and the size of the source file minus the offset address of the last operation area is written to the end of the current operation area. For the remaining operation areas, the offset address of that operation area is used as the offset address of the current operation area, and the offset address of the operation area preceding it is used as the auxiliary offset address. The source file is positioned at the auxiliary offset address, the data from the current operation area offset address minus the auxiliary offset address is read and written to the end of the current operation area. The source file is positioned at the target offset address of the current operation area, and the operation length of the current operation area is written to the end of the current operation area.
[0010] In one embodiment of this application, forming a second protected file based on the encrypted file header structure and the first protected file includes: writing the encrypted file header structure into the header of the first protected file to form the second protected file.
[0011] In one embodiment of this application, forming a third protection file based on the processed source file and the second protection file includes: writing the processed source file to the end of the second protection file to form the third protection file.
[0012] To achieve the above and other related objectives, this application also provides a file processing method. The method includes: receiving a protected file, the protected file including first information associated with an encrypted file header structure and second information associated with a processed source file obtained by processing a source file according to the file header structure, wherein the file header structure is constructed based on an operation area list to verify the first information of the protected file based on a preset file header structure; and in response to the first information of the protected file passing the verification, deriving the source file based on the second information of the protected file.
[0013] In one embodiment of this application, the method further includes: allocating the target model buffer; the allocation of the target model buffer includes: traversing all operation areas in the operation area list, adding the operation lengths in all operation areas to obtain the total length of the operation area; allocating the target model buffer size to be at least the size of the protected file - the length of the temporary model header - the total length of the operation area; traversing all operation areas in the operation area list, updating the corresponding operation area offset address to: the original offset address + the length of the temporary file header.
[0014] To achieve the above and other related objectives, this application also provides a computer-readable storage medium having computer-readable program instructions stored thereon, which, when executed, implement the file processing method described above.
[0015] To achieve the above and other related objectives, this application also provides an electronic device, including: a memory configured to store program instructions; and a processor configured to execute the program instructions to implement the file processing method.
[0016] As described above, according to the embodiments of this disclosure, the solution of this application does not encrypt the entire source file (e.g., AI model). Instead, it randomly corrupts the source file by constructing a file header structure and encrypts the random corruption rules before writing them into the source file header. Because the source file is randomly corrupted, the corrupted content is different each time for the same source file, resulting in different protected files after corruption. This maximizes the confidentiality and security of the source file protection. Simultaneously, since the entire source file is not encrypted, the demand for computing resources is reduced while protecting the source file, especially for devices with limited computing resources, thus improving the speed of deprotection before inference. The method of this application is applicable to protecting AI models and various application documents, without limitations on software and hardware environments and scenarios, and has strong versatility. Attached Figure Description
[0017] Figure 1 The diagram shown is a flowchart of a document processing method according to an embodiment of this application.
[0018] Figure 2 The diagram shown is another flowchart of a document processing method according to an embodiment of this application;
[0019] Figure 3 The flowchart shown is a document processing method according to an embodiment of this application, in which the first information of a protected document is verified.
[0020] Figure 4 The flowchart shown is a document processing method according to an embodiment of this application, in which the source file is derived based on the second information of the protected file.
[0021] Figure 5 The flowchart shown is an application example of a file processing method according to an embodiment of this application.
[0022] Figure 6 The diagram shown is a schematic diagram of the principle structure of an electronic device according to an embodiment of this application. Detailed Implementation
[0023] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.
[0024] In existing technologies, the entire AI model is encrypted before deployment and release, and then decrypted before inference to obtain the original model for inference. However, encrypting the entire AI model can be computationally intensive, which is detrimental to the deployment and implementation of AI models on edge devices.
[0025] To address at least the aforementioned issues, this disclosure provides a file processing solution that eliminates the need to encrypt the entire source file. Instead, it constructs a file header structure, randomly corrupts the source file, and encrypts the random corruption rules before writing them into the source file header. This solves the technical problem of high encryption and decryption computational load caused by encrypting the entire file when protecting files in the prior art.
[0026] Hereinafter, specific embodiments of the present disclosure will be described with reference to the accompanying drawings through exemplary embodiments.
[0027] Figure 1 This is a flowchart illustrating a file processing method according to an embodiment of the present disclosure. Figure 1 As shown, the file processing method includes the following steps S110 to S140.
[0028] In step S110, an empty first protected file is created for the source file. In some embodiments, the source file is an AI model file. In other embodiments, the source file is various application documents.
[0029] In some embodiments, the file extension of the empty protected file is the same as that of the source file. In some embodiments, an empty AI protected model file, such as protected_model.pb, is created, and its file extension must be consistent with that of the AI source file, such as .pb or .onnx.
[0030] In addition, in some embodiments, the file processing method may also include determining the size of the source file in preparation for the implementation of subsequent steps S120 to S140.
[0031] In step S120, a file header structure associated with the source file is constructed based on the list of operation areas. In some embodiments, the constructed file header structure includes a preset number of protection magic numbers and a preset number of operation area lists. In some embodiments, each operation area in the operation area list consists of an offset address, a target offset address, and an operation length.
[0032] In step S130, the file header structure is encrypted, and a second protected file is formed based on the encrypted file header structure and the first protected file. In some embodiments, the encrypted file header structure is written into the header of the first protected file to form the second protected file.
[0033] In step S140, the source file is processed according to the file header structure, and a third protected file is formed based on the processed source file and the second protected file. In some embodiments, the processed source file is written to the end of the second protected file to form the third protected file.
[0034] The file processing method according to embodiments of this disclosure does not encrypt the entire source file (e.g., an AI model). Instead, it randomly corrupts the source file by constructing a file header structure and encrypts the random corruption rules before writing them into the source file header. Because the source file is randomly corrupted, the corrupted content is different each time for the same source file, resulting in different protected files, thus maximizing the confidentiality and security of the source file protection. Furthermore, since the entire source file is not encrypted, the demand for computing resources is reduced while protecting the source file.
[0035] The following section will describe in detail how the file header structure is constructed.
[0036] A first set of random numbers and a second set of random numbers are randomly generated, wherein the first set of random numbers corresponds to the offset address of the operation area in the source file, and the second set of random numbers corresponds to the target offset address of the operation area in the source file; a third set of random numbers is inserted after the offset address of each operation area as the operation length, wherein the starting position of the third set of random numbers is determined by the target offset address of the operation area.
[0037] In this embodiment, the file header structure is composed of a preset protection magic number and a preset number of operation area lists.
[0038] Each operation area in the operation area list consists of an offset address, a target offset address, and an operation length.
[0039] Specifically, in this embodiment, a preset number of random numbers are randomly generated, each corresponding to a specific position in the source file: the offset address of the operation area. Then, a data segment of random length is inserted after that position. The starting position of the inserted random length data segment comes from the position determined by another set of random numbers in the source file, namely the target offset address of the operation area. The length of the data inserted at each different offset address of the operation area (i.e., the operation length of the operation area) is random.
[0040] In this embodiment, the process of constructing the file header structure is as follows:
[0041] (1) Set the protection magic number of the file header structure to the preset magic number.
[0042] (2) Set the operation area for the file header structure. The specific process is as follows:
[0043] (a) Generate two sets of predetermined numbers of random integers. The generated random integers must be greater than the predetermined minimum value (e.g., 0) and less than the size of the source file (in bytes). Additionally, the elements within each set of random numbers must be distinct.
[0044] a-1: Arrange one set of random numbers in ascending order and use them as the offset address of the preset number of operation areas.
[0045] a-2: Use another set of random numbers in the order they were generated as the target offset address of the preset number of operation areas.
[0046] (b) Generate another set of a preset number of random integers, requiring that the generated random integers be greater than the preset minimum value (such as 0) and less than the "size of the source file" multiplied by the "preset ratio", wherein the preset ratio is greater than 0 and less than 1.
[0047] The generated random numbers are used as the operation length of the preset number operation area according to the generation order.
[0048] (c) Traverse all preset number of operation areas. For each operation area:
[0049] Determine if the "target offset address + operation length" of the operation area exceeds the size of the source file. If it does, subtract the "target offset address of the operation area" from the "source file size" to obtain the operation length of the operation area.
[0050] In some embodiments, the encryption of the file header structure and the formation of the second protected file based on the encrypted file header structure and the first protected file are carried out in the following manner.
[0051] The constructed file header structure is encrypted using an encryption algorithm; it is determined whether the size of the encrypted file header structure is equal to the size of the file header structure before encryption. If so, the encrypted file header structure is written into the header of the first protected file; if not, an auxiliary header of a preset size is constructed, and then the auxiliary header is written into the header of the first protected file, and the encrypted file header structure is written into the current tail of the first protected file. The auxiliary header includes a preset magic number and the size of the encrypted file header structure.
[0052] For example, first, the constructed model header structure of a preset size is encrypted using a preset symmetric encryption algorithm and key. Then, it is determined whether the size of the encrypted model header structure is equal to the size of the original model header structure.
[0053] If the sizes are equal, the encrypted model header structure is written to the header of the AI-protected model file (e.g., protected_model.pb). Otherwise, an auxiliary header of a preset size is constructed, which includes two pieces of information: the preset magic number and the size of the encrypted model header structure. The auxiliary header is then written to the header of the AI-protected model file (e.g., protected_model.pb), and the encrypted model header structure is written to the current end of the AI-protected model file (e.g., protected_model.pb).
[0054] In some embodiments, processing the source file according to the file header structure and forming a third protected file based on the processed source file and the second protected file includes the following steps.
[0055] Iterate through all operation areas in the operation area list.
[0056] For the first operation area, locate the beginning of the source file, read the data of the offset address of the operation area and write it to the current end of the protection file, locate the source file to the target offset address of the current operation area, and write the data of the operation length of the current operation area to the current end of the protection file.
[0057] For the last operation area, the offset address of this operation area is used as the offset address of the current operation area, and the offset address of the operation area preceding this operation area is used as the auxiliary offset address: First, the source file is positioned at the auxiliary offset address, and the data of the current operation area offset address minus the length of the auxiliary offset address is written to the current end of the protection file. Then, the source file is positioned at the target offset address of the current operation area, and the data of the operation length of the current operation area is written to the current end of the protection file. Finally, the source file is positioned at the offset address of the last operation area, and the data of the size of the source file minus the offset address length of the last operation area is written to the current end of the protection file.
[0058] For the remaining operation area, the offset address of this operation area is used as the offset address of the current operation area, and the offset address of the operation area preceding this operation area is used as the auxiliary offset address: the source file is positioned at the auxiliary offset address, the data of the current operation area offset address minus the length of the auxiliary offset address is read and written to the current end of the protection file, the source file is positioned at the target offset address of the current operation area, and the data of the operation length of the current operation area is written to the current end of the protection file.
[0059] Specifically, in this embodiment, the specific implementation process for generating the protected file is as follows:
[0060] Iterate through all preset number of operation areas in the file header structure. For each operation area:
[0061] (1) If it is the first operation area:
[0062] a) Obtain the offset address of the operation area, use the offset address as the read length, then locate the beginning of the source file, read data of the size of the "offset address of the operation area" into a temporary buffer, and then write the data in the buffer to the current end of the AI protected model file (such as protected_model.pb).
[0063] b) Locate the source file to the target offset address of the current operation area, read the data of the operation length of the current operation area into a temporary buffer, and then write the data in the buffer to the current end of the AI protected model file (such as protected_model.pb).
[0064] (2) If it is the last operation area: use the offset address of this operation area as the offset address of the current operation area, and use the offset address of the operation area preceding this operation area as the auxiliary offset address. Then:
[0065] a) Locate the source file at the auxiliary offset address, read the data from the current operation area offset address minus the length of the auxiliary offset address into a temporary buffer, and then write the data in the buffer to the current end of the AI protected model file (such as protected_model.pb).
[0066] b) Locate the source file to the target offset address of the current operation area, read the data of the operation length of the current operation area into a temporary buffer, and then write the data in the buffer to the current end of the AI protected model file (such as protected_model.pb).
[0067] c) Locate the source file at the offset address of the last operation area, read the data of "source file size" minus "offset address of the last operation area" into a temporary buffer, and then write the data in the buffer to the current end of the AI protected model file (such as protected_model.pb).
[0068] (3) For other operation areas: use the offset address of this operation area as the offset address of the current operation area, and use the offset address of the operation area preceding this operation area as the auxiliary offset address. Then:
[0069] a) Locate the source file at the auxiliary offset address, read the data from the current operation area offset address minus the length of the auxiliary offset address into a temporary buffer, and then write the data in the buffer to the current end of the AI protected model file (such as protected_model.pb).
[0070] b) Locate the source file to the target offset address of the current operation area, read the data of the operation length of the current operation area into a temporary buffer, and then write the data in the buffer to the current end of the AI protected model file (such as protected_model.pb).
[0071] In some embodiments, the file processing method may further include obtaining the source file, which includes an artificial intelligence source model file.
[0072] In some embodiments, after the third protection file is generated, the file processing method may further include performing publishing and deployment based on the third protection file.
[0073] According to embodiments of this disclosure, a source file (e.g., an AI model) is randomly corrupted by constructing a file header structure, and the random corruption rules are encrypted and written into the source file header. Because the source file is randomly corrupted, the corrupted content is different each time for the same source file, resulting in different protected files, thus maximizing the confidentiality and security of the source file protection. Simultaneously, since the entire source file is not encrypted, the demand for computing resources is reduced while protecting the source file.
[0074] Figure 2 This is a flowchart illustrating a file processing method according to an embodiment of the present disclosure. Figure 2 As shown, the file processing method includes the following steps S210 to S230.
[0075] In step S210, a protected file is received, the protected file including first information associated with an encrypted file header structure and second information associated with a processed source file obtained by processing the source file according to the file header structure, wherein the file header structure is constructed based on an operation area list.
[0076] In step S220, the first information of the protected file is verified based on a preset file header structure.
[0077] like Figure 3 As shown, verifying the first information of the protected file based on the preset file header structure includes the following steps S221 to S223.
[0078] In step S221, the encrypted file header structure is derived from the header of the protected file.
[0079] In step S222, the encrypted file header structure is decrypted using a preset symmetric encryption algorithm and key.
[0080] In step S223, the decrypted file header structure is verified based on the preset file header structure.
[0081] Specifically, in this embodiment, the verification is performed according to the encryption method of the file header structure. Specifically, an auxiliary header of a preset size is read from the header of the protected file, and it is determined whether the magic number of the auxiliary header is the same as the preset magic number.
[0082] If they are the same, after locating the protected file to the auxiliary header, data of a specified size is read into a temporary buffer according to the "size of the encrypted file header structure" in the auxiliary header, which serves as the encrypted file header structure. The "preset size of the auxiliary header" plus the "size of the encrypted file header structure" is used as the length of the temporary file header (e.g., protected_model_header_len).
[0083] If they are different, locate the header of the protected file, read the file header structure of the preset size into a temporary buffer, and use it as the encrypted file header structure. Use the preset size of the file header structure as the length of the temporary file header (e.g., protected_model_header_len).
[0084] In step S230, in response to the first information of the protected file being verified, the source file is derived based on the second information of the protected file.
[0085] In some embodiments, such as Figure 4 As shown, deriving the source file based on the second information of the protected file includes the following steps S231 and S232.
[0086] In step S231, the processed source file is derived from the end of the protected file.
[0087] In step S232, the source file is decoded from the processed source file according to the file header structure, and the source file is stored in the target buffer.
[0088] Furthermore, in some embodiments, deriving the source file based on the second information of the protected file includes: decrypting the encrypted file header structure in the temporary buffer using a preset symmetric encryption algorithm and key to obtain the decrypted file header structure. It is then determined whether the protection magic number in the decrypted file header structure is the same as the preset protection magic number: if they are the same, a target file buffer is pre-allocated; otherwise, an invalid file is indicated, and the process exits.
[0089] In this embodiment, the method further includes: allocating the target model buffer. Allocating the target model buffer includes: traversing all operation areas in the operation area list, adding the operation lengths of all operation areas to obtain the total length of the operation area; allocating the target model buffer size to be at least the size of the protected file - the length of the temporary model header - the total length of the operation area; traversing all operation areas in the operation area list, updating the corresponding operation area offset address to: the original offset address + the length of the temporary file header.
[0090] The pre-allocated target file buffer specifically includes: traversing all preset number of operation areas in the file header structure, and summing the operation lengths of all operation areas, which is called the total length of the operation area. The size of the pre-allocated target file buffer is at least: the size of the protected file - the length of the temporary file header - the total length of the operation area. Initialize the pre-allocated target file buffer (e.g., initialize all of them to 0x00).
[0091] Iterate through all the preset number of operation areas in the file header structure. For each operation area, update the corresponding operation area offset address to: original offset address + file temporary header length.
[0092] The original file is decoded from the protected file and stored in the target file buffer. The specific process is as follows:
[0093] Iterate through all preset number of operation areas in the file header structure. For each operation area:
[0094] (1) If it is the first operation area:
[0095] Use the offset address of the current operation area as the offset address of the current operation area, and also use the operation length of the current operation area as the operation length of the current operation area. Then:
[0096] a) Position the protected file to the length of the temporary header (e.g., protected_model_header_len), and then read data of size "current operation area offset address - temporary header length" into the pre-allocated target file buffer.
[0097] b) For each operation area after this operation area, update the corresponding operation area offset address to: original offset address + current operation area length.
[0098] (2) If it is the last operation area:
[0099] The offset address of this operation area is used as the current operation area offset address, the operation length of this operation area is used as the current operation area operation length, the offset address of the previous operation area is used as the auxiliary offset address, and the operation length of the previous operation area is used as the auxiliary operation length. Then:
[0100] a) Locate the protected file to "auxiliary offset address + auxiliary operation length", and read data of length "current operation area offset address - (auxiliary offset address + auxiliary operation length)" into the pre-allocated target file buffer.
[0101] b) Locate the protected file to "current operation area offset address + current operation area operation length", and read data of length "protected file size - (current operation area offset address + current operation area operation length)" into the pre-allocated target file buffer.
[0102] (3) For other operating areas:
[0103] The offset address of this operation area is used as the current operation area offset address, the operation length of this operation area is used as the current operation area operation length, the offset address of the previous operation area is used as the auxiliary offset address, and the operation length of the previous operation area is used as the auxiliary operation length. Then:
[0104] a) Locate the protected file to "auxiliary offset address + auxiliary operation length", and read data of length "current operation area offset address - (auxiliary offset address + auxiliary operation length)" into the pre-allocated target file buffer.
[0105] b) For each operation area after this operation area, update the corresponding operation area offset address to: original offset address + current operation area length.
[0106] Figure 5 The following example illustrates the implementation process of the file processing method described in this embodiment, using AI source files as an example.
[0107] like Figure 5 As shown, when protecting the AI source model file, the process involves obtaining the AI source model file, creating an empty AI protection model file, constructing a model header structure based on the operation area list, encrypting the constructed model header structure, writing it into the header of the AI protection model file, reading the source model, constructing the AI protection model file based on the information in the model header structure, and publishing the processed AI protection model file for actual deployment. When the AI source model file is to be used, the protection model header is verified, the original model is decoded from the protection model file, and stored in the target model buffer. In this embodiment, the entire AI model is not encrypted during the AI model protection process. Instead, the AI model is randomly corrupted, and the random corruption rules are encrypted and written into the AI model header. Because the AI model is randomly corrupted, the corrupted content is different for the same AI model each time, resulting in a different AI protection model after corruption, thereby maximizing the confidentiality and security of AI model protection. Simultaneously, since the entire AI model is not encrypted, the demand for computing resources is reduced while protecting the AI model, especially for end devices with limited computing resources, improving the speed of AI model deprotection before inference. The method in this embodiment is applicable to protecting any AI model, without restrictions on software and hardware environments and scenarios, and has strong versatility.
[0108] Figure 6 This is a block diagram illustrating an electronic device according to an embodiment of the present disclosure. (As shown) Figure 6 As shown, this embodiment provides an electronic device 101, which includes a processor 1001 and a memory 1002. The memory 1002 is used to store computer programs. The processor 1001 is used to execute the computer programs stored in the memory 1002, so that the electronic device 101 performs the steps of the file processing method as described in Embodiment 1. Since the specific implementation process of each step of the file processing method has been described in detail in Embodiment 1, it will not be repeated here.
[0109] Processor 1001 is a CPU (Central Processing Unit). Memory 1002 is connected to processor 1001 via a system bus and communicates with it. Memory 1002 stores computer programs, and processor 1001 runs the computer programs to execute the file processing method described above. Memory 1002 may include random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device.
[0110] Furthermore, this embodiment also provides a computer-readable storage medium storing a computer program thereon, which, when executed by the processor 1001, implements the aforementioned file processing method. The file processing method has already been described in detail above and will not be repeated here.
[0111] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented using computer program-related hardware. The aforementioned computer program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0112] In summary, this application does not encrypt the entire source file (e.g., AI model file). Instead, it randomly corrupts the source file by constructing a file header structure, and then encrypts the random corruption rules and writes them into the source file header. Because the source file is randomly corrupted, the corrupted content is different each time, resulting in different protected files. This maximizes the confidentiality and security of the source file protection. Furthermore, since the entire source file is not encrypted, the demand for computing resources is reduced while protecting the source file, especially for devices with limited computing resources, thus improving the speed of deprotection before inference. The method of this application is applicable to protecting AI model files and various application documents, without limitations on software and hardware environments or scenarios, and has strong versatility. Therefore, this invention effectively overcomes the various shortcomings of existing technologies and has high industrial applicability.
[0113] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.
Claims
1. A file processing method, characterized in that, include: Create an empty first protected file for the source file; Based on the list of operation areas, a file header structure associated with the source file is constructed. The constructed file header structure includes a preset number of protection magic numbers and a preset number of operation area lists. Each operation area in the operation area list consists of an offset address, a target offset address, and an operation length. The file header structure is encrypted, and a second protected file is formed based on the encrypted file header structure and the first protected file; as well as The source file is processed according to the file header structure, and a third protected file is formed based on the processed source file and the second protected file. The process of forming the second protected file based on the encrypted file header structure and the first protected file includes: determining whether the size of the encrypted file header structure is equal to the size of the file header structure before encryption; If yes, the encrypted file header structure is written into the header of the first protected file; otherwise, an auxiliary header of a preset size is constructed, and then the auxiliary header is written into the header of the first protected file, and the encrypted file header structure is written into the current tail of the first protected file, wherein the auxiliary header includes a preset protection magic number and the size of the encrypted file header structure.
2. The file processing method according to claim 1, characterized in that, The process of constructing the file header structure associated with the source file based on the operation area list includes: A first set of random numbers and a second set of random numbers are randomly generated, wherein the first set of random numbers corresponds to the offset address of the operation area in the source file, and the second set of random numbers corresponds to the target offset address of the operation area in the source file; A third set of random numbers is inserted after the offset address of each of the operation areas as the operation length, wherein the starting position of the third set of random numbers is determined by the target offset address of the operation area.
3. The file processing method according to claim 1, characterized in that, Processing the source file according to the file header structure and forming a third protected file based on the processed source file and the second protected file includes: Traverse all operation areas in the operation area list: For the first operation area, locate the beginning of the source file, read the offset address of the operation area and write it to the current end of the second protection file, locate the source file to the target offset address of the current operation area, and write the operation length of the current operation area to the current end of the second protection file. For the last operation area, the offset address of this operation area is used as the current operation area offset address, and the offset address of the operation area preceding this operation area is used as the auxiliary offset address: First, the source file is positioned at the auxiliary offset address, and the data of the current operation area offset address minus the length of the auxiliary offset address is written to the current end of the second protection file. Then, the source file is positioned at the target offset address of the current operation area, and the data of the operation length of the current operation area is written to the current end of the second protection file. Finally, the source file is positioned at the offset address of the last operation area, and the data of the size of the source file minus the offset address length of the last operation area is written to the current end of the second protection file. For the remaining operation area, the offset address of the operation area is used as the current operation area offset address, and the offset address of the operation area preceding the current operation area is used as the auxiliary offset address: the source file is positioned at the auxiliary offset address, the data of the current operation area offset address minus the length of the auxiliary offset address is read and written to the current end of the second protection file, the source file is positioned at the target offset address of the current operation area, and the data of the operation length of the current operation area is written to the current end of the second protection file.
4. The file processing method according to claim 1, characterized in that, Forming a second protected file based on the encrypted file header structure and the first protected file includes: writing the encrypted file header structure into the header of the first protected file to form the second protected file.
5. The file processing method according to claim 1, characterized in that, Forming a third protected file based on the processed source file and the second protected file includes: writing the processed source file to the end of the second protected file to form the third protected file.
6. A computer-readable storage medium storing computer-readable program instructions thereon, characterized in that, When the program instructions are executed, the file processing method is as described in any one of claims 1 to 5.
7. An electronic device, characterized in that, include: The memory is configured to store program instructions; as well as A processor is configured to execute the program instructions to implement the file processing method according to any one of claims 1 to 5.
Citation Information
Patent Citations
File processing method and file processing device
CN104732159A
Method and equipment for generating encrypted file
CN112241538A
