A method and system for encrypted file recovery based on key context

Abstract

This invention discloses a method and system for recovering encrypted files based on key context. The method includes: acquiring the underlying binary image of the target storage medium; parsing the file system structure to locate the inode table; filtering encrypted file inodes whose status is deleted, and extracting key information including data block pointers, master key identifiers, and encryption policy descriptors; obtaining the master key from the associated system kernel based on the master key identifier, and calculating and generating a file content encryption key in combination with the encryption policy descriptor; decrypting the extracted encrypted data blocks using the key, and reassembling them in sequence to complete file recovery. This invention avoids the huge computational consumption of traditional brute-force attacks by directly utilizing residual metadata of the file system and the master key cached by the kernel for key reconstruction, and, based on the general FBE mechanism, does not rely on specific vulnerabilities, significantly improving the recovery efficiency and applicability for Android FBE encrypted files.

Description

Technical Field

[0001] This invention relates to the fields of information security and electronic data forensics, specifically to a method and system for recovering encrypted files based on key context. Background Technology

[0002] With the continuous improvement of security in mobile device operating systems (such as Android), file-based encryption (FBE) has gradually replaced full-disk encryption (FDE) as the mainstream encryption method. The FBE mechanism generates an independent encryption key for each file, which greatly enhances data security and enables more granular access control.

[0003] However, this highly secure design poses a significant challenge to traditional electronic data forensics and data recovery techniques. In traditional file systems, file deletion typically involves only the marking of metadata; the file content itself remains on the disk, and data can be recovered by restoring the metadata or file engraving. But under the FBE mechanism, file deletion not only means that the metadata is marked as "unused," but more importantly, the unique encryption key corresponding to that file is usually discarded or destroyed by the system. Once the key is lost, the encrypted data blocks remaining on the disk become unreadable gibberish, making data recovery extremely difficult.

[0004] Existing technical solutions for recovering deleted FBE encrypted files mainly fall into the following categories: Brute-force: Trying all possible key combinations. This method is computationally impractical due to the extremely large key spaces of modern encryption algorithms (such as AES-256).

[0005] Cold start attack: Attempts to extract keys from memory remnants after a device has been powered off. This method has a low success rate and often requires physical contact with the device and operation within a very short time window, making it unsuitable for general use.

[0006] Vulnerability Exploitation: Extracting keys by exploiting kernel vulnerabilities in specific system versions. This method is limited by system version and patch updates, and cannot be used as a general forensic technique.

[0007] In summary, existing technologies lack a stable, universal, and efficient recovery method that does not rely on specific vulnerabilities. Therefore, there is an urgent need for a new technical solution that can effectively recover deleted FBE encrypted files by utilizing metadata remaining in the file system and key context information in the system kernel that may not have been destroyed. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a method and system for recovering encrypted files based on key context. This method reconstructs the encryption key of deleted files by deeply analyzing residual encryption strategies and identification information in file system metadata, combined with analysis of the operating system kernel key management subsystem, thereby achieving file decryption and recovery.

[0009] To achieve the above objectives, the present invention provides a method for recovering encrypted files based on key context, comprising the following steps: S1. Obtain the underlying binary image of the target storage medium; S2. Parse the file system structure of the image, locate and extract the inode table; S3. Traverse the index node table, filter out the encrypted file index nodes whose status is deleted, and extract the key information from the encrypted file index nodes. The key information includes at least an array of pointers to data blocks, a master key identifier linked to the system key ring, and an encryption policy descriptor. S4. Obtain the master key from the system kernel of the target storage medium based on the master key identifier, and calculate and generate the file content encryption key based on the master key and the encryption policy descriptor; S5. Extract the encrypted data block from the image based on the array of pointers to the data block, and decrypt the encrypted data block using the file content encryption key; S6. Reassemble the decrypted data blocks in order to complete file recovery.

[0010] Furthermore, step S1 obtains the underlying binary image of the target storage medium, specifically including: reading the underlying binary image of the target storage medium by physical extraction or by using a disk copying tool with the highest system privileges.

[0011] Furthermore, step S2 also includes parsing the file system structure of the image and obtaining the superblock and block bitmap.

[0012] Furthermore, step S3 specifically includes: parsing the disk layout of each inode in the inode table, the disk layout being divided into a core metadata area, an encryption and identification area, and an extended attribute area; the core metadata area at least includes a file type and permission field for recording the deletion status, a file size field as the basis for recovery, a file block number field indicating the amount of data, and an array of pointers to data blocks as the basis for recovering file content; the encryption and identification area at least includes a suggestion information field containing an encryption hint bit and a flag field containing an encryption enable flag bit; the extended attribute area at least includes an encryption policy descriptor recording the encryption algorithm and a master key identifier linked to the system key ring; checking the file type and permission fields to confirm that the file is in a deleted state, checking the flag field to confirm that the encryption enable flag bit has been set, extracting the data block pointer array from the core metadata area, and extracting the master key identifier and encryption policy descriptor from the extended attribute area.

[0013] Furthermore, step S4 obtains the master key from the system kernel of the target storage medium based on the master key identifier, specifically including searching for and extracting the cached master key from the operating system kernel environment or memory dump data associated with the target storage medium based on the master key identifier.

[0014] Furthermore, step S4, the file content encryption key, is specifically calculated and generated based on the HKDF key derivation function algorithm, including: using the master key identifier as the salt value and the master key as the input key, calculating and generating a pseudo-random key using the SHA512 algorithm; using the pseudo-random key as the input key and preset application context information as the information input, calculating and generating the original key material using the SHA512 algorithm; wherein, the preset application context information is constructed by concatenating a preset prefix and a random number; and truncating the original key material according to the encryption policy descriptor to generate the file content encryption key.

[0015] Furthermore, step S4 also includes: initializing an encryption algorithm object based on the file content encryption key according to a preset encryption algorithm identifier.

[0016] Furthermore, step S5 specifically includes: extracting encrypted data blocks from the image based on pointers to data blocks, and decrypting the encrypted data blocks sequentially using an encryption algorithm object.

[0017] Furthermore, step S6 also includes using file signature verification technology to check whether the sequentially reconstructed file header signature meets the format requirements of the preset file type; if the sequentially reconstructed file metadata is incomplete, the decrypted data stream is analyzed and extracted using file engraving technology.

[0018] Secondly, the present invention provides an encrypted file recovery system based on key context, comprising: The image acquisition module is configured to acquire the underlying binary image of the target storage medium; The file system parsing module is configured to parse the file system structure of the image, locate and extract the inode table; The metadata scanning module is configured to traverse the index node table, filter out encrypted file index nodes whose status is deleted, and extract key information from the encrypted file index nodes. The key information includes at least an array of pointers to data blocks, a master key identifier linked to the system key ring, and an encryption policy descriptor. The key recovery module is configured to retrieve the master key from the system kernel of the target storage medium based on the master key identifier, and calculate and generate a file content encryption key based on the master key and the encryption policy descriptor. The data decryption module is configured to extract encrypted data blocks from the image based on pointers to data blocks, and decrypt the encrypted data blocks using the file content encryption key; The file reconstruction module is configured to reconstruct the decrypted data blocks in sequence to complete file recovery.

[0019] Compared with the prior art, the beneficial effects of the present invention are: High efficiency: It avoids the huge amount of computation required for traditional brute-force key cracking, and improves recovery efficiency by directly locating and utilizing the master key cached in the system kernel and derived parameters in the file metadata.

[0020] Universality: This method is based on the FBE encryption implementation mechanism of the Android Linux kernel standard, and utilizes the common features of file systems (such as F2FS) and kernel key management subsystem (Keyring). It does not rely on the private vulnerabilities of specific devices and has a wider range of applications.

[0021] Reliability: By introducing file signature verification and file engraving technology, the validity of the decrypted and reconstructed files can be verified, ensuring the integrity and availability of the recovered data. Attached Figure Description

[0022] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and, together with the description, serve to explain the principles of the invention. Other embodiments and many anticipated advantages of the embodiments will be readily recognized as they become better understood through reference to the following detailed description. Elements in the drawings are not necessarily to scale. The same reference numerals refer to corresponding similar parts.

[0023] Figure 1 This is a flowchart of an encrypted file recovery method based on key context according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the F2FS file system inode structure and disk layout according to an embodiment of the present invention; Figure 3 A flowchart illustrating the process of deriving the encryption key for file content according to an embodiment of the present invention; Figure 4 This is a framework diagram of a key context-based encrypted file recovery system according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a computer device suitable for implementing electronic devices according to embodiments of the present invention. Detailed Implementation

[0024] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0025] Example 1 refer to Figure 1 This embodiment provides a method for recovering encrypted files based on key context, and the specific steps are as follows: S100: Obtain the underlying binary image of the target storage medium.

[0026] Specifically, physical extraction devices can be used to directly read storage chips (such as eMMC and UFS), or a disk copying tool with the highest system privileges (root privileges) (i.e., the dd tool) can be used to perform a full disk or partition bit-to-bit image copy of the target storage medium to obtain a complete underlying binary image.

[0027] S200: Parse the file system structure, locate and extract the inode table.

[0028] Specifically, the file system type (e.g., F2FS or EXT4) in the image is identified. Its superblock is parsed to obtain basic configuration parameters of the file system, the block bitmap is parsed to understand the disk block allocation, and finally the inode table is located and extracted, which is the basis for building a complete disk layout map.

[0029] S300. Traverse the index node table, filter out the deleted encrypted file index nodes and extract key information.

[0030] Specifically, this step requires a deep analysis of the internal structure of each inode. (See reference...) Figure 2 In this embodiment, the disk layout of the index node is divided into three main areas for analysis: 1. Core metadata area: File type and permissions field (i_mode, offset 0x00): Check this field. When a file is deleted, specific locations will be cleared or marked as free.

[0031] The file size field (i_size, offset 0x08): This is the key information for recovering the file data size.

[0032] The file occupancy block number field (i_blocks, offset 0x10) indicates the actual disk space occupied by the file.

[0033] Data block pointer array (i_addr, offset 0x30~): Contains physical address pointers to data blocks that directly or indirectly point to the contents of the file. This is the fundamental basis for recovering the file contents.

[0034] 2. Encryption and Identification Area: The advice information field (i_advise, offset 0x1C) may contain encryption hint bits.

[0035] Flags field (i_flags, offset 0x2C): Check if this field is set to "Encryption Enable Flag" to confirm whether the file corresponding to this node is encrypted.

[0036] Optionally, the encryption and identification area also includes an encryption context (i_crypt_info): this is a pointer to a critical structure. Although this pointer may be nulled when the file is deleted, the fscrypt_info structure it points to may not have been destroyed in kernel memory. Residual information about it needs to be searched for in the image or memory dump data, or inferred from the encryption policy of its parent directory.

[0037] 3. Expand the attribute area: The encryption policy descriptor (fscrypt_policy_descriptor) records the encryption algorithm (such as AES-256-XTS) and its version information.

[0038] Master key identifier (key_identifier): This is an important index linked to the system key ring and is also used as a salt value in subsequent key derivation.

[0039] In step S300, the system traverses the inode table and filters out inodes that simultaneously satisfy the condition that "the file type and permission field (i_mode) is marked as deleted" and "the flag field (i_flags) is marked as encrypted". For the filtered nodes, the system extracts an array of data block pointers from their core metadata area and extracts the encryption policy descriptor (fscrypt_policy_descriptor) and the master key identifier (key_identifier) ​​from the extended attribute area.

[0040] S400, Reconstructing the Encryption Key: The master key is obtained from the system kernel of the target storage medium based on the master key identifier. A file content encryption key is then calculated and generated based on the master key and the encryption policy descriptor. This is the core step of this invention. (See reference...) Figure 3 This step is divided into two stages: obtaining the master key and obtaining the derived subkeys. S410. Extract the master key. Based on the master key identifier, search for and extract the cached master key from the operating system kernel environment or memory dump data associated with the target storage medium.

[0041] Specifically, since the master key is typically cached in the device's volatile memory (RAM), this step uses the master key identifier (key_identifier) ​​extracted from step S300 as an index to perform feature matching and searching in the kernel's keyring (e.g., a system keyring named "@f") service or memory dump to locate the corresponding master key. This typically involves reverse engineering of the device's kernel key management logic.

[0042] S420, Derived File Content Encryption Key. The file content encryption key is specifically calculated and generated based on the HKDF key derivation function algorithm, including: Extraction phase: Using the master key identifier as the salt and the master key as the input key, a pseudo-random key (PRK) is generated using the SHA512 algorithm. That is, PRK = HMAC - SHA512 (salt = Key Identifier, key = Master Key).

[0043] Expansion Phase: Using a pseudo-random key as the input key and preset application context information as the input (Info), the original key material is generated using the SHA512 algorithm. The preset application context information is constructed by concatenating a preset prefix (e.g., the string "fscrypt") and a random number (Nonce, extracted from the encryption policy descriptor region). This preset application context information corresponds to the present parameter and size parameter in non-Ceph, non-hardware encryption modes. That is, the output key material = HMAC - SHA512(key=PRK,info="fscrypt" + Nonce + counter).

[0044] Post-processing stage: The original key material is truncated according to the encryption policy descriptor (such as indicating the AES-256-XTS algorithm) to generate the file content encryption key.

[0045] Furthermore, step S420 also includes initializing the encryption algorithm object.

[0046] Specifically, based on the preset encryption algorithm identifier, the encryption algorithm object is initialized using the encryption key of the file content. For example, based on the encryption algorithm identifier (such as AES-256-XTS), the derived key is used to initialize the encryption algorithm object (such as EVP_CIPHER_CTX in OpenSSL) for subsequent data block decryption.

[0047] S500, extract and decrypt data blocks.

[0048] Specifically, based on the pointer array (i_addr) of data blocks extracted in S300, encrypted data blocks (typically 4KB in size) are read from the corresponding physical address of the underlying binary image. The encryption algorithm object constructed in step S430 is then used to decrypt each read encrypted data block. During decryption, an initialization vector (IV) needs to be calculated based on the logical location of the data block (such as sector number or inode number).

[0049] S600, File Reorganization and Verification.

[0050] Specifically, the decrypted data blocks are written to a new file in their logical order within the original file, completing the reassembly. To verify the recovery result, file signature verification technology is used to check the file header. For example, for JPEG files, it is checked whether they contain an FFD8 FF E0 header, and for PDF files, it is checked whether they contain a %PDF- header. If the verification passes, the recovery is marked as successful; if the verification fails or the metadata is incomplete, further feature analysis and extraction are performed on the decrypted data stream using file engraving technology.

[0051] Example 2 refer to Figure 4This embodiment provides a system for implementing the above method, comprising: The image acquisition module 100 is configured to acquire the underlying binary image of the target storage medium; The file system parsing module 200 is configured to parse the file system structure of the image, locate and extract the inode table; Metadata scanning module 300 is configured to traverse the index node table, filter out encrypted file index nodes whose status is deleted, and extract key information from the encrypted file index nodes. The key information includes at least an array of pointers to data blocks, a master key identifier linked to the system key ring, and an encryption policy descriptor. The key recovery module 400 is configured to obtain the master key from the system kernel of the target storage medium based on the master key identifier, and calculate and generate a file content encryption key based on the master key and the encryption policy descriptor. The data decryption module 500 is configured to extract encrypted data blocks from the image based on pointers to data blocks, and decrypt the encrypted data blocks using the file content encryption key; The file reconstruction module 600 is configured to reconstruct the decrypted data blocks in sequence to complete file recovery.

[0052] The beneficial effects of this invention are as follows: High efficiency: It avoids the huge amount of computation required for traditional brute-force key cracking, and improves recovery efficiency by directly locating and utilizing the master key cached in the system kernel and derived parameters in the file metadata.

[0053] Universality: This method is based on the FBE encryption implementation mechanism of the Android Linux kernel standard, and utilizes the common features of file systems (such as F2FS) and kernel key management subsystem (Keyring). It does not rely on the private vulnerabilities of specific devices and has a wider range of applications.

[0054] Reliability: By introducing file signature verification and file engraving technology, the validity of the decrypted and reconstructed files can be verified, ensuring the integrity and availability of the recovered data.

[0055] The following is for reference. Figure 5 It shows a schematic diagram of the structure of a computer system suitable for implementing an electronic device according to embodiments of the present invention. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0056] like Figure 5As shown, the computer system includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 502 or programs loaded from storage section 508 into random access memory (RAM) 503. RAM 503 also stores various programs and data required for the operation of system 500. CPU 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0057] The following components are connected to I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a liquid crystal display (LCD) and speakers, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card and a modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to I / O interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 510 as needed so that computer programs read from it can be installed into storage section 508 as needed.

[0058] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable storage medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs the functions defined in the methods of the present invention. It should be noted that the computer-readable storage medium of the present invention can be a computer-readable signal medium or a computer-readable storage medium or any combination thereof. The computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable storage medium other than a computer-readable storage medium that can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

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

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

[0061] The modules described in the embodiments of the present invention can be implemented in software or in hardware.

[0062] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the following: acquire the underlying binary image of the target storage medium; parse the file system structure of the image, locate and extract the inode table; traverse the inode table, filter out encrypted file inodes whose status is deleted, and extract key information from the encrypted file inodes, the key information including at least an array of pointers to data blocks, a master key identifier linked to the system key ring, and an encryption policy descriptor; obtain the master key from the system kernel of the target storage medium based on the master key identifier, and calculate and generate a file content encryption key based on the master key and the encryption policy descriptor; extract encrypted data blocks from the image based on the array of pointers to data blocks, and decrypt the encrypted data blocks using the file content encryption key; reassemble the decrypted data blocks in order to complete file recovery.

[0063] The specific embodiments of the present invention have been described above, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0064] In the description of this invention, it should be understood that the terms "upper," "lower," "inner," "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The simple fact that certain measures are recited in mutually different dependent claims does not indicate that combinations of these measures cannot be used for improvement. Any reference signs in the claims should not be construed as limiting the scope.

Claims

1. A method for recovering encrypted files based on key context, characterized in that, Includes the following steps: S1. Obtain the underlying binary image of the target storage medium; S2. Parse the file system structure of the image, locate and extract the inode table; S3. Traverse the index node table, filter out the encrypted file index nodes whose status is deleted, and extract the key information from the encrypted file index nodes. The key information includes at least an array of pointers to data blocks, a master key identifier linked to the system key ring, and an encryption policy descriptor. S4. Obtain the master key from the system kernel of the target storage medium based on the master key identifier, and calculate and generate the file content encryption key based on the master key and the encryption policy descriptor; S5. Extract the encrypted data block from the image based on the pointer array pointing to the data block, and decrypt the encrypted data block using the file content encryption key; S6. Reassemble the decrypted data blocks in order to complete file recovery.

2. The method according to claim 1, characterized in that, Step S1, obtaining the underlying binary image of the target storage medium, specifically includes: reading the underlying binary image of the target storage medium by physical extraction or by using a disk copying tool with the highest system privileges.

3. The method according to claim 1, characterized in that, Step S2 also includes parsing the file system structure of the image to obtain the superblock and block bitmap.

4. The method according to claim 1, characterized in that, Step S3 specifically includes: The disk layout of each index node in the index node table is analyzed. The disk layout is divided into a core metadata area, an encryption and identification area, and an extended attribute area. The core metadata area includes at least a file type and permission field for recording the deletion status, a file size field for recovery, a file block size field indicating the amount of data, and an array of pointers to data blocks for recovering file content. The encryption and identification area includes at least a suggestion information field containing encryption hint bits and a flag field containing encryption enable flag bits. The extended attribute area includes at least an encryption policy descriptor recording the encryption algorithm and a master key identifier linked to the system key ring. Check the file type and permission fields to confirm that the file is in a deleted state, check the flag field to confirm that the encryption enable flag has been set, extract the data block pointer array from the core metadata area, and extract the master key identifier and the encryption policy descriptor from the extended attribute area.

5. The method according to claim 4, characterized in that, Step S4, which involves obtaining the master key from the system kernel of the target storage medium based on the master key identifier, specifically includes searching for and extracting the cached master key from the operating system kernel environment or memory dump data associated with the target storage medium based on the master key identifier.

6. The method according to claim 4, characterized in that, The file content encryption key mentioned in step S4 is specifically calculated and generated based on the HKDF key derivation function algorithm, including: Using the master key identifier as the salt value and the master key as the input key, a pseudo-random key is generated by calculating using the SHA512 algorithm. Using the pseudo-random key as the input key and preset application context information as the information input, the original key material is generated by calculating using the SHA512 algorithm; wherein, the preset application context information is constructed by concatenating a preset prefix and a random number; The original key material is truncated according to the encryption policy descriptor to generate a file content encryption key.

7. The method according to claim 1, characterized in that, Step S4 also includes: The encryption algorithm object is initialized based on the file content encryption key according to the preset encryption algorithm identifier.

8. The method according to claim 7, characterized in that, Step S5 specifically includes: Based on the pointer to the data block, the encrypted data block is extracted from the image, and the encrypted data block is decrypted sequentially using the encryption algorithm object.

9. The method according to claim 1, characterized in that, Step S6 also includes using file signature verification technology to check whether the sequentially reconstructed file header signature meets the format requirements of the preset file type; if the sequentially reconstructed file metadata is incomplete, the decrypted data stream is analyzed and extracted using file engraving technology.

10. A key context-based encrypted file recovery system, characterized in that, include: The image acquisition module is configured to acquire the underlying binary image of the target storage medium; The file system parsing module is configured to parse the file system structure of the image, locate and extract the inode table; The metadata scanning module is configured to traverse the index node table, filter out encrypted file index nodes whose status is deleted, and extract key information from the encrypted file index nodes. The key information includes at least an array of pointers to data blocks, a master key identifier linked to the system key ring, and an encryption policy descriptor. The key recovery module is configured to obtain the master key from the system kernel of the target storage medium based on the master key identifier, and calculate and generate a file content encryption key based on the master key and the encryption policy descriptor; The data decryption module is configured to extract encrypted data blocks from the image based on the pointer to the data blocks, and decrypt the encrypted data blocks using the file content encryption key; The file reconstruction module is configured to reconstruct the decrypted data blocks in sequence to complete file recovery.

Images