A method and system for identifying, detecting and extracting a damaged squashfs file system

Abstract

The present invention provides a method and system for identifying, detecting and extracting a damaged squashfs file system, including scanning and decoding a compressed data block according to the header feature of a compressed data block in a squashfs file system structure, and then matching the compression type corresponding to the compressed data block; separating and extracting the inode table data block and the directory table data block in the area according to the features of the inode table data block and the directory table data block of the compressed data block; performing index verification on the fragment index structure of the fragment table data block according to the features of the fragment table data block of the compressed data block, thereby determining and extracting the fragment table data block in the squashfs file system data; and identifying, detecting and repairing the squashfs file system data according to the extracted inode table data block, directory table data block and fragment table data block. The present invention can realize the repair and extraction of a damaged file system to the greatest extent, and provide a basis for subsequent further data analysis.

Description

Technical Field

[0001] The present invention relates to the field of computer forensic security technology, in particular to a method and system based on identification, detection and extraction of a damaged squashfs file system. Background Art

[0002] Squashfs is a read-only compressed file system for the Linux kernel. It is widely used in data backup or embedded root file systems with tight system resources. It supports compression methods such as gzip, lzma1, lzma2 (xz), lz4, etc.

[0003] Since Squashfs data, directories, node information, etc. are compressed and stored separately, when the metadata parameters such as the header index are overwritten or damaged, the data cannot be recovered. Since squashfs implements separate compression management for data, directories, node information, etc., the file system header only retains its index information, compression type, compressed block size, etc. Once the header parameters are damaged or overwritten, it is extremely difficult to recover. At present, there is a lack of recovery methods for damaged squashfs file headers.

[0004] This solution analyzes the distribution structure of compressed data such as data, directories, node information, etc. in the file system and its related metadata characteristics. Based on the data characteristics of each compression type, it recognizes and detects a series of areas such as compression encoding type, data, directories, node information, etc., and finally realizes the repair and extraction of the damaged file system. Summary of the invention

[0005] The present invention proposes a method and system for identifying, detecting and extracting a damaged squashfs file system to solve the above-mentioned defects of the prior art.

[0006] In one aspect, the present invention provides a method for identifying, detecting and extracting a damaged squashfs file system, the method comprising the following steps:

[0007] S1: According to the header features of the compressed data block in the squashfs file system structure, the compressed data block is scanned and decoded, and then the compression type corresponding to the compressed data block is matched;

[0008] S2: determining the area range of the inode table data block and the directory table data block in the squashfs file system data according to the characteristics of the inode table data block and the directory table data block of the compressed data block; verifying the area boundary of the inode table data block by combining the node information obtained after decompression, and separating and extracting the inode table data block and the directory table data block in the area range;

[0009] S3: performing index verification according to the characteristics of the fragment table data block of the compressed data block and the fragment index structure of the decompressed fragmenttable data block, thereby determining and extracting the fragment table data block in the squashfs file system data;

[0010] S4: Identify, detect and repair the squashfs file system data according to the extracted inode table data blocks, directory table data blocks and fragment table data blocks.

[0011] The above method analyzes the distribution structure of compressed data such as data, directory, node information in the file system and its related metadata characteristics. Based on the data characteristics of each compression type, it realizes the identification and detection of compression encoding type, data, directory, node information and other areas, and finally realizes the repair and extraction of the damaged squashfs file system.

[0012] In a specific embodiment, S1 further includes: after matching the compression type corresponding to the compressed data block, determining whether a correct compression type is matched; if so, executing S2; if not, repeatedly executing S1.

[0013] In a specific embodiment, determining the area range of the inode table data block and the directory table data block in the squashfs file system data according to the characteristics of the inode table data block and the directory table data block of the compressed data block specifically includes:

[0014] According to the characteristics of the inode table data block and the directory table data block of the compressed data block, the actual decompressible compressed data length compress_len is obtained, and according to the header characteristics of the compressed data block, the subsequent compressed block byte length value Pre_len is obtained;

[0015] Combined with the decompressed data information of the compressed data block, a matching detection is performed at the same time to take the data area satisfying Pre_len=compress_len as the area range of the inode table data block and the directory table data block.

[0016] In a specific embodiment, S2 further includes: after verifying the node information obtained after decompressing the inode table data block, determining whether the verification is completed; if so, executing subsequent steps, if not, continuing the verification.

[0017] In a specific embodiment, the index verification is performed according to the characteristics of the fragment table data block of the compressed data block in combination with the fragment index structure of the decompressed fragment table data block, specifically including:

[0018] According to the characteristics of the fragment table data block of the compressed data block, the actual decompressible compressed data length compress_len is obtained, and according to the header characteristics of the compressed data block, the subsequent compressed block byte length value Pre_len is obtained;

[0019] For the data area where Pre_len is not equal to compress_len, index verification is performed in combination with the fraction index structure of the decompressed fraction table data block, and the area that meets the fraction index structure is used as the area of ​​the fraction table data block.

[0020] In a specific embodiment, S3 also includes: after performing index verification on the fraction index structure of the decompressed fraction table data block, determining whether the index verification is completed; if so, executing subsequent steps, if not, continuing the index verification.

[0021] In a specific embodiment, the data compression types include: gzip, lzma1, lzma2 and lz4.

[0022] In a specific embodiment, the node information obtained after decompression of the inode table data block specifically includes: the node type, mode, uid, guid, modification time and node number of each node.

[0023] According to a second aspect of the present invention, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a computer processor, the above method is implemented.

[0024] According to a third aspect of the present invention, a system based on identification, detection and extraction of damaged squashfs file systems is proposed, the system comprising:

[0025] A compression data type matching module: configured to scan and decode the compressed data block according to the header features of the compressed data block in the squashfs file system structure and then match the compression type corresponding to the compressed data block;

[0026] A node information verification module is configured to determine the area range of the inode table data block and the directory table data block in the squashfs file system data according to the characteristics of the inode table data block and the directory table data block of the compressed data block; and then verify the node information obtained after the inode table data block is decompressed to determine the boundary point of the area of ​​the inode table data block, and separate and extract the inode table data block and the directory table data block in the area range;

[0027] Index verification module: configured to perform index verification according to the characteristics of the fragment table data block of the compressed data block and the fragment index structure of the decompressed fragment table data block, so as to determine and extract the fragment table data block in the squashfs file system data;

[0028] Detection and repair module: configured to identify, detect and repair the squashfs file system data based on the extracted inode table data blocks, directory table data blocks and fragment table data blocks.

[0029] The present invention scans the compressed data block according to the header features of the compressed data block in the squashfs file system structure, decodes the compressed data block, and then matches the compression type corresponding to the compressed data block; according to the features of the inodetable data block and the directory table data block of the compressed data block, the inode table data block and the directory table data block are separated and extracted in the area range; according to the features of the fragment table data block of the compressed data block, the index verification is performed in combination with the fragment index structure of the decompressed fragment table data block, so as to determine and extract the fragment table data block in the squashfs file system data; according to the extracted inodetable data block, directory table data block and fragment table data block, the squashfs file system data is identified, detected and repaired. The present invention realizes the identification, detection and extraction of key areas of the damaged file system by identifying the regional metadata compression blocks such as data, directory, node information, etc. in the squashfs file system. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated into and constitute a part of this specification. The accompanying drawings illustrate the embodiments and together with the description are used to explain the principles of the present invention. Other embodiments and many expected advantages of the embodiments will be readily appreciated as they become better understood by reference to the following detailed description. Other features, objects and advantages of the present application will become more apparent by reading the detailed description of the non-limiting embodiments made with reference to the following drawings:

[0031] Figure 1 is an exemplary system architecture diagram to which the present application may be applied;

[0032] Figure 2 It is a flow chart of a method for identifying, detecting and extracting a damaged squashfs file system according to an embodiment of the present invention;

[0033] Figure 3 It is a structural block diagram of a squashfs file system of a specific embodiment of the present invention;

[0034] Figure 4 It is a datablocks&fragments structure block diagram of a specific embodiment of the present invention;

[0035] Figure 5 is a block diagram of an inode table structure of a specific embodiment of the present invention;

[0036] Figure 6 It is a block diagram of the inode node information structure of a specific embodiment of the present invention;

[0037] Figure 7 It is a structural block diagram of the fragment table index information of a specific embodiment of the present invention;

[0038] Figure 8 It is a schematic diagram of squashfs key area identification and detection according to a specific embodiment of the present invention;

[0039] Fig. 9 It is a flow chart of squashfs file system data identification, detection and repair according to a specific embodiment of the present invention;

[0040] Fig.10 It is a framework diagram of a system based on damaged squashfs file system identification, detection and extraction according to an embodiment of the present invention;

[0041] Fig.11 It is a structural diagram of a computer system suitable for implementing an electronic device of an embodiment of the present application. DETAILED DESCRIPTION

[0042] The present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It is also necessary to explain that, for ease of description, only the parts related to the relevant invention are shown in the accompanying drawings.

[0043] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0044] Figure 1 An exemplary system architecture 100 to which an embodiment of the present application can be applied is shown, which is based on a method for identifying, detecting and extracting a damaged squashfs file system.

[0045] like Figure 1 As shown, the system architecture 100 may include terminal devices 101, 102, 103, a network 104 and a server 105. The network 104 is used to provide a medium for communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0046] Users can use terminal devices 101, 102, 103 to interact with server 105 through network 104 to receive or send messages, etc. Various applications can be installed on terminal devices 101, 102, 103, such as data processing applications, data visualization applications, web browser applications, etc.

[0047] Terminal devices 101, 102, 103 can be hardware or software. When terminal devices 101, 102, 103 are hardware, they can be various electronic devices, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, etc. When terminal devices 101, 102, 103 are software, they can be installed in the electronic devices listed above. They can be implemented as multiple software or software modules (for example, software or software modules used to provide distributed services), or they can be implemented as a single software or software module. No specific limitation is made here.

[0048] The server 105 may be a server providing various services, such as a background information processing server providing support for the squashfs file system data displayed on the terminal devices 101, 102, and 103. The background information processing server may process the obtained fragment index structure and generate processing results (such as detection and repair results).

[0049] It should be noted that the method provided in the embodiment of the present application can be executed by the server 105, and can also be executed by the terminal devices 101, 102, 103. The corresponding device is generally set in the server 105, and can also be set in the terminal devices 101, 102, 103.

[0050] It should be noted that the server can be hardware or software. When the server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or it can be implemented as a single server. When the server is software, it can be implemented as multiple software or software modules (for example, software or software modules used to provide distributed services), or it can be implemented as a single software or software module. No specific limitation is made here.

[0051] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0052] According to an embodiment of the present invention, a method for identifying, detecting and extracting a damaged squashfs file system is provided. Figure 2 FIG. 1 is a flow chart showing a method for identifying, detecting and extracting a damaged squashfs file system according to an embodiment of the present invention. Figure 2 As shown, the method comprises the following steps:

[0053] S1: According to the header features of the compressed data block in the squashfs file system structure, the compressed data block is scanned and decoded, and then the compression type corresponding to the compressed data block is matched;

[0054] S2: determining the area range of the inode table data block and the directory table data block in the squashfs file system data according to the characteristics of the inode table data block and the directory table data block of the compressed data block; verifying the area boundary of the inode table data block by combining the node information obtained after decompression, and separating and extracting the inode table data block and the directory table data block in the area range;

[0055] S3: performing index verification according to the characteristics of the fragment table data block of the compressed data block and the fragment index structure of the decompressed fragmenttable data block, thereby determining and extracting the fragment table data block in the squashfs file system data;

[0056] S4: Identify, detect and repair the squashfs file system data according to the extracted inode table data blocks, directory table data blocks and fragment table data blocks.

[0057] In a specific embodiment, S1 further includes: after matching the compression type corresponding to the compressed data block, determining whether a correct compression type is matched; if so, executing S2; if not, repeatedly executing S1.

[0058] In a specific embodiment, determining the area range of the inode table data block and the directory table data block in the squashfs file system data according to the characteristics of the inode table data block and the directory table data block of the compressed data block specifically includes:

[0059] According to the characteristics of the inode table data block and the directory table data block of the compressed data block, the actual decompressible compressed data length compress_len is obtained, and according to the header characteristics of the compressed data block, the subsequent compressed block byte length value Pre_len is obtained;

[0060] Combined with the decompressed data information of the compressed data block, a matching detection is performed at the same time to take the data area satisfying Pre_len=compress_len as the area range of the inode table data block and the directory table data block.

[0061] In a specific embodiment, S2 further includes: after verifying the node information obtained after decompressing the inode table data block, determining whether the verification is completed; if so, executing subsequent steps, if not, continuing the verification.

[0062] In a specific embodiment, the index verification is performed according to the characteristics of the fragment table data block of the compressed data block in combination with the fragment index structure of the decompressed fragment table data block, specifically including:

[0063] According to the characteristics of the fragment table data block of the compressed data block, the actual decompressible compressed data length compress_len is obtained, and according to the header characteristics of the compressed data block, the subsequent compressed block byte length value Pre_len is obtained;

[0064] For the data area where Pre_len is not equal to compress_len, index verification is performed in combination with the fraction index structure of the decompressed fraction table data block, and the area that meets the fraction index structure is used as the area of ​​the fraction table data block.

[0065] In a specific embodiment, S3 also includes: after performing index verification on the fraction index structure of the decompressed fraction table data block, determining whether the index verification is completed; if so, executing subsequent steps, if not, continuing the index verification.

[0066] In a specific embodiment, the data compression types include: gzip, lzma1, lzma2 and lz4.

[0067] In a specific embodiment, the node information obtained after decompression of the inode table data block specifically includes: the node type, mode, uid, guid, modification time and node number of each node.

[0068] The method of the present invention is described below in conjunction with the squashfs file system structure and a specific embodiment.

[0069] File system structure

[0070] Figure 3: is a block diagram of a squashfs file system structure of a specific embodiment of the present invention, such as Figure 3 The structures of the squashfs file system shown are Superblock, Datablocks & Fragments, Inode Table, Iirectory Table, Frament Table, etc. The specific structure of the squashfs file system is as follows:

[0071] Superblock: The header area of ​​squashfs is the superblock, including squashfs Magic (hsqs), the number of file nodes, the creation time of this file system, the block size, the number of fragments, the compression method used by the file system, the file system version and data, directory, the starting index information of the node information area, etc.

[0072] Datablocks&fragments: mainly stores a series of compressed data blocks of file contents and compressed data blocks of fragment data; Figure 4 is a structural block diagram of datablocks&fragments of a specific embodiment of the present invention. The compressed block structural features of datablocks&fragments are as follows Figure 4 As shown, it includes the corresponding characteristic field of the compression type (taking the gzip compression type as an example, its value is 0x78DA, taking the XZ compression type as an example, its value is 0XFD37) and subsequent compressed data.

[0073] Inode table: mainly stores a series of compressed data of file directory link files and corresponding node information. Its compressed block structure features are as follows: Figure 5 As shown, Figure 5 It is a block diagram of the inode table structure of a specific embodiment of the present invention, including a flag bit indicating whether the subsequent data is compressed, the subsequent data length, a characteristic field corresponding to the compression type (taking the gzip compression type as an example, its value is 0xFD78, taking the XZ compression type as an example, its value is 0XFD37) and subsequent compressed data. Figure 6 It is a block diagram of the inode node information structure of a specific embodiment of the present invention, such as Figure 6 The inode node information shown includes node type, mode, uid, gid, modification time, node number and other information.

[0074] Directory table: Mainly stores a series of data information such as file directory name length, file name and directory name.

[0075] Frament table: mainly stores the compressed data of the index structure corresponding to a series of fragments compression blocks. Its compression block structure features are as follows: Figure 4 As shown, the decompressed data structure of the fragments table is as follows Figure 7 The structure shown, Figure 7 It is a structural block diagram of the fragment table index information of a specific embodiment of the present invention, including a series of fragments compression block position information, compression block size and unused length.

[0076] Figure 8 FIG. 1 is a schematic diagram of squashfs key area identification and detection according to a specific embodiment of the present invention. Figure 8 As shown in the figure, the recognition and detection principle is to scan and extract the corresponding data blocks of the characteristic fields of each data compression type (such as gzip, lzma1, lzma2 (xz), lz4, etc.) to decompress and match to determine the compression type; determine the inode table and directory table areas according to the characteristics of the inode table and directory table compression blocks (whether it is a compression flag, the subsequent data length, and the corresponding characteristic field of the compression type), and verify and confirm the boundary points of the inodetable area in combination with the series of node information after the inode table is decompressed to separate the inode table and directory table area data; according to the characteristics of the fragment table compression block combined with the decompressed fragment index structure, index verification is performed to confirm and extract the fragment table, and finally the recognition, detection and repair of each key area of ​​squashfs are realized according to the node table, directory table and fragment table.

[0077] Fig. 9 This is a flow chart of squashfs file system data identification, detection and repair in a specific embodiment of the present invention. In this embodiment, the specific detection and extraction process is as follows:

[0078] 1. First, the conceptual assumptions are as follows:

[0079] 1) Assume that HT = {HT1, HT2, HT3, ..., HTN} represents a set of header features of compressed blocks of compression types such as gzip, lzma1, lzma2 (xz), and lz4, where each element represents the header feature data corresponding to its compression type;

[0080] 2) Assume that CT = {CT1, CT2, CT3, ..., CTN} represents a set of compression types such as gzip, lzma1, lzma2 (xz), lz4, etc. Each element represents a compression type;

[0081] 3) Assume that the judgment rule of inode table and directory table compressed data blocks is I DT, where Pre_len represents the byte length value of the subsequent compressed block before the HT header feature; compress_len represents the actual decompressible compressed data length, and the compressed blocks in the inode table and directory table areas are judged to meet the conditions of Pre_len = compress_len and combined with the decompressed data information;

[0082] 4) Assume that BK = {BK1, BK2, BK3, ..., BKN} represents a set of compressed data blocks of inode table and directory table, where each element represents an inode table or directory table compressed data block;

[0083] 5) Assume that IBK = {IBK1, IBK2, IBK3, ..., IBKN} represents a set of inode table compressed data blocks, where each element represents an inode table compressed data block;

[0084] 6) Assume that IBD = {IBD1, IBD2, IBD3, ..., IBDN} represents the set of INODE after the inode table compressed data block is decompressed, where each element represents an inode node, which is represented by node type, mode, uid, guid, modification time, node number, etc.;

[0085] 7) Assume that DBK = {DBK1, DBK2, DBK3, ..., DBKN} represents a set of directory table compressed data blocks, where each element represents a directory table compressed data block;

[0086] 8) Assume that BFK = {BFK1, BFK2, BFK3, ..., BFKN} represents a set of fragments region compressed data blocks, where each element represents a fragments compressed data block;

[0087] 9) Assume that the judgment rule of the fragment table compressed data block is FDT, where Pre_len represents the byte length value of the subsequent compressed block before the HT header feature; compress_len represents the actual length of the decompressed compressed data. If the condition that Pre_len is not equal to compress_len is met, the index value in the decompressed data of the fragment table is combined with BFK ​​for verification and is determined to be a compressed block in the fragment table area;

[0088] 10) Assume that FBK = {FBK1, FBK2, FBK3, ..., FBKN} represents a set of compressed data blocks of a fraction table, where each element represents a compressed data block of a fraction table;

[0089] 2. Analysis of identification detection and extraction process methods based on the above conceptual assumptions:

[0090] 1) According to the header features of each compression type data block, record it as HT, scan the data block for decompression and match the compression type, record it as CT;

[0091] 2) Determine whether the correct compression type is matched, if yes, proceed to the next step, if not, proceed to the previous step;

[0092] 3) Scan and detect the data blocks in the inode table and directory table area according to the rule I DT according to CT, and determine whether the scan is completed. If so, jump to the next step, otherwise continue with the current step;

[0093] 4) The scanned inode table and directory table area data blocks are recorded as BK;

[0094] 5) BK is matched and checked according to the node parameters of IBD and the inode table area data block and directory table are separated, which are recorded as IBK and DBK respectively;

[0095] 6) According to the data of the area behind the IBK and DBK areas in the CT scan and the FDT rule, it is judged and recorded as FBK;

[0096] 7) Complete the identification, detection and extraction of the squashfs file system with damaged header based on IBK, DBK and FBK.

[0097] Fig.10The framework diagram of a system for identifying, detecting and extracting a damaged squashfs file system according to an embodiment of the present invention is shown. The system includes a compression data type matching module 1001, a node information verification module 1002, an index verification module 1003 and a detection and repair module 1004.

[0098] In a specific embodiment, the compression data type matching module 1001 is configured to scan the compressed data block and decode it according to the header characteristics of the compressed data block in the squashfs file system structure, and then match the compression type corresponding to the compressed data block;

[0099] The node information verification module 1002 is configured to determine the area range of the inode table data block and the directory table data block in the squashfs file system data according to the characteristics of the inode table data block and the directory table data block of the compressed data block; and then verify the node information obtained after the inode table data block is decompressed to determine the boundary point of the area of ​​the inode table data block, and separate and extract the inode table data block and the directory table data block in the area range;

[0100] The index verification module 1003 is configured to perform index verification according to the characteristics of the fragment table data block of the compressed data block and the fragment index structure of the decompressed fragment table data block, so as to determine and extract the fragment table data block in the squashfs file system data;

[0101] The detection and repair module 1004 is configured to identify, detect and repair the squashfs file system data according to the extracted inode table data blocks, directory table data blocks and fragment table data blocks.

[0102] According to the header features of the compressed data blocks in the squashfs file system structure, the system scans the compressed data blocks, decodes them, and then matches the compression type corresponding to the compressed data blocks; according to the features of the inodetable data blocks and the directory table data blocks of the compressed data blocks, the inode table data blocks and the directory table data blocks are separated and extracted in the area range; according to the features of the fragment table data blocks of the compressed data blocks, the fragment index structure of the fragment table data blocks performs index verification, thereby determining and extracting the fragment table data blocks in the squashfs file system data; according to the extracted inode table data blocks, directory table data blocks and fragment table data blocks, the squashfs file system data is identified, detected and repaired. The present invention realizes the identification, detection and extraction of key areas of a damaged file system by identifying regional metadata compression blocks such as data, directory, and node information in the squashfs file system.

[0103] Reference below Fig.11 , which shows a schematic diagram of the structure of a computer system 1100 suitable for implementing an electronic device of an embodiment of the present application. Fig.11 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0104] like Fig.11 As shown, the computer system 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1102 or a program loaded from a storage part 1108 into a random access memory (RAM) 1103. In the RAM 1103, various programs and data required for the operation of the system 1100 are also stored. The CPU 1101, the ROM 1102, and the RAM 1103 are connected to each other via a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

[0105] The following components are connected to the I / O interface 1105: an input section 1106 including a keyboard, a mouse, etc.; an output section 1107 including a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN card, a modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to the I / O interface 1105 as needed. A removable medium 1111, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1110 as needed, so that a computer program read therefrom is installed into the storage section 1108 as needed.

[0106] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1109, and / or installed from the removable medium 1111. When the computer program is executed by the central processing unit (CPU) 1101, the above functions defined in the method of the present application are executed. It should be noted that the computer-readable storage medium described in the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection with one or more conductors, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or device. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable storage medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, device, or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wireless, wireline, optical cable, RF, etc., or any suitable combination of the foregoing.

[0107] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0108] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0109] The modules involved in the embodiments described in the present application may be implemented by software or hardware. The units described may also be arranged in a processor, and the names of these units do not constitute limitations on the units themselves in certain circumstances.

[0110] An embodiment of the present invention further relates to a computer-readable storage medium having a computer program stored thereon, which implements the method described above when the computer program is executed by a computer processor. The computer program includes program code for executing the method shown in the flowchart. It should be noted that the computer-readable medium of the present application may be a computer-readable signal medium or a computer-readable medium or any combination of the above two.

[0111] The present invention scans the compressed data block according to the header features of the compressed data block in the squashfs file system structure, decodes the compressed data block, and then matches the compression type corresponding to the compressed data block; according to the features of the inodetable data block and the directory table data block of the compressed data block, the inode table data block and the directory table data block are separated and extracted in the area range; according to the features of the fragment table data block of the compressed data block, the fragment index structure of the fragment table data block performs index verification, thereby determining and extracting the fragment table data block in the squashfs file system data; according to the extracted inode table data block, directory table data block and fragment table data block, the squashfs file system data is identified, detected and repaired. The present invention realizes the identification, detection and extraction of key areas of a damaged file system by identifying regional metadata compression blocks such as data, directory, node information, etc. in the squashfs file system.

[0112] The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above invention concept. For example, the above features are replaced with the technical features with similar functions disclosed in this application (but not limited to) by each other to form a technical solution.

Claims

1. A method for identifying, detecting and extracting a damaged squashfs file system, characterized in that: The following steps are involved: S1: According to the header features of the compressed data block in the squashfs file system structure, scan the compressed data block, decode it, and then match the compression type corresponding to the compressed data block; S2: according to the characteristics of the inode table data block and the directory table data block of the compressed data block, the actual decompressible compressed data length compress_len is obtained, and according to the header characteristics of the compressed data block, the subsequent compressed block byte length value Pre_len is obtained, and in combination with the data information after the compression of the compressed data block, a matching detection is performed at the same time to take the data area satisfying Pre_len=compress_len as the area range of the inode table data block and the directory table data block in the squashfs file system data; and then the node information obtained after the inode table data block is decompressed is verified to determine the boundary point of the area of ​​the inode table data block, and the inode table data block and the directory table data block are separated and extracted in the area range; S3: performing index verification according to the characteristics of the fragment table data block of the compressed data block and the fragment index structure of the decompressed fragmenttable data block, thereby determining and extracting the fragment table data block in the squashfs file system data; S4: Identify, detect and repair the squashfs file system data according to the extracted inode table data blocks, directory table data blocks and fragment table data blocks.

2. The method according to claim 1, characterized in that The S1 further includes: after matching the compression type corresponding to the compressed data block, determining whether a correct compression type is matched; if so, executing S2; if not, repeatedly executing S1.

3. The method according to claim 1, characterized in that The S2 also includes: after verifying the node information obtained after decompressing the inode table data block, determining whether the verification is completed; if so, executing subsequent steps, if not, continuing the verification.

4. The method according to claim 1, characterized in that: The index verification is performed according to the characteristics of the fragment table data block of the compressed data block and in combination with the fragment index structure of the decompressed fragment table data block, specifically including: According to the characteristics of the fragment table data block of the compressed data block, the actual decompressible compressed data length compress_len is obtained, and according to the header characteristics of the compressed data block, the subsequent compressed block byte length value Pre_len is obtained; For the data area where Pre_len is not equal to compress_len, index verification is performed in combination with the fragment index structure of the decompressed fragment table data block, and the area that meets the fragment index structure is used as the area of ​​the fragment table data block.

5. The method according to claim 1, characterized in that S3 also includes: after performing index verification on the fraction index structure of the decompressed fractiontable data block, determining whether the index verification is completed; if so, executing subsequent steps, if not, continuing the index verification.

6. The method according to claim 1, characterized in that The data compression types include: gz ip, l zma1, lzma2 and l z4.

7. The method according to claim 1, characterized in that The node information obtained after decompression of the inode table data block specifically includes: the node type, mode, uid, guid, modification time and node number of each node.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a computer processor, the method according to any one of claims 1 to 7 is implemented.

9. A system based on identification, detection and extraction of damaged squashfs file systems, characterized in that: include: A compression data type matching module: configured to scan and decode the compressed data block according to the header features of the compressed data block in the squashfs file system structure and then match the compression type corresponding to the compressed data block; Node information verification module: configured to obtain the actual decompressible compressed data length compress_len according to the characteristics of the inode table data block and the directory table data block of the compressed data block, and obtain the subsequent compressed block byte length value Pre_len according to the header characteristics of the compressed data block, and combine the data information after the compression of the compressed data block, and perform matching detection at the same time to take the data area that satisfies Pre_len=compress_len as the area range of the inode table data block and the directory table data block in the squashfs file system data; and then perform verification in combination with the node information obtained after the inode table data block is decompressed to determine the boundary point of the area of ​​the inode table data block, and separate and extract the inode table data block and the directory table data block in the area range; Index verification module: configured to perform index verification according to the characteristics of the fragment table data block of the compressed data block and the fragment index structure of the decompressed fragment table data block, so as to determine and extract the fragment table data block in the squashfs file system data; Detection and repair module: configured to identify, detect and repair the squashfs file system data based on the extracted inode table data blocks, directory table data blocks and fragment table data blocks.

Images