CN116881035B - File repair method, storage medium and electronic device - Google Patents
File repair method, storage medium and electronic device Download PDFInfo
- Publication number
- CN116881035B CN116881035B CN202310897381.7A CN202310897381A CN116881035B CN 116881035 B CN116881035 B CN 116881035B CN 202310897381 A CN202310897381 A CN 202310897381A CN 116881035 B CN116881035 B CN 116881035B
- Authority
- CN
- China
- Prior art keywords
- file
- repairing
- central directory
- apk
- content
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 57
- 230000008439 repair process Effects 0.000 title claims abstract description 27
- 230000006835 compression Effects 0.000 claims description 18
- 238000007906 compression Methods 0.000 claims description 18
- 230000006837 decompression Effects 0.000 claims description 17
- 238000004590 computer program Methods 0.000 claims description 11
- 230000008569 process Effects 0.000 claims description 11
- 238000004891 communication Methods 0.000 claims description 6
- 238000013507 mapping Methods 0.000 claims description 5
- 238000012986 modification Methods 0.000 description 7
- 230000004048 modification Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 5
- 238000012545 processing Methods 0.000 description 4
- 238000013500 data storage Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000006073 displacement reaction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000001502 supplementing effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/14—Details of searching files based on file metadata
- G06F16/148—File search processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/174—Redundancy elimination performed by the file system
- G06F16/1744—Redundancy elimination performed by the file system using compression, e.g. sparse files
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Library & Information Science (AREA)
- Human Computer Interaction (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application provides a file repairing method, a storage medium and electronic equipment. The file repairing method comprises the following steps: repairing an APK file according to a central directory of the APK file to obtain a first APK file; reading a manifest file of the first APK file; and repairing the code blocks of the manifest file to obtain a second APK file. The file repairing method can repair the APK file.
Description
Technical Field
The present application relates to a file repair method, and more particularly, to a file repair method, a storage medium, and an electronic device.
Background
In the context of rapid development and wide application of mobile applications, android application packages (Android application package, APK) play an important role as core formats of applications in the android operating system. The APK file contains all necessary components of the application, including code, resources, and configuration files.
In some application scenarios, for example, in survey forensics, a staff member needs to parse an APK file to obtain information in the file. However, many APK files have errors and tampered portions, making them difficult to parse. Therefore, how to repair these files has become one of the technical problems that the related technicians need to solve.
Disclosure of Invention
The application aims to provide a file repairing method, a storage medium and electronic equipment, which are used for repairing an APK file.
In a first aspect, an embodiment of the present application provides a file repair method, where the file repair method includes: repairing an APK file according to a central directory of the APK file to obtain a first APK file; reading a manifest file of the first APK file; and repairing the code blocks of the manifest file to obtain a second APK file.
In one implementation manner of the first aspect, repairing an APK file according to a central directory of the APK file includes: sequentially reading the file header of the central directory and recording the number of the read files; reading a local file header through the central directory, and correcting encryption marks of the central directory and the local file header; reading the local file content through the local file header, and repairing the compression mode and/or the size of the compressed file according to the decompression condition of the local file content; and repairing the end section content of the central directory according to the file number and the signature block of the APK file.
In one implementation manner of the first aspect, sequentially reading the central directory file header and recording the number of files read includes: locating a start position of the central directory; and circularly reading the central directory file header from the initial position until all the central directory file headers are read, and recording the file number in the reading process.
In one implementation of the first aspect, locating the start position of the central directory includes: sequentially reading data forwards from the data end of the APK file until a central directory end mark is acquired; and positioning the starting position of the central directory according to the central directory ending mark.
In an implementation manner of the first aspect, repairing the compression mode and/or the compressed file size according to the decompression condition of the local file content includes: and decompressing the local file content by adopting a specific decompression mode, if the decompression is successful, repairing the compression mode according to the specific decompression mode, otherwise, determining whether the local file content is compressed or not, and if the local file content is not compressed, repairing the size of the compressed file according to the uncompressed file size.
In one implementation manner of the first aspect, repairing the code block of the manifest file includes: when the number of the character strings in the code block header is tampered, repairing the number of the character strings in the code block header by utilizing the character string starting position and the style starting position in the code block header.
In an implementation manner of the first aspect, the manifest file is an XML file, and repairing the code blocks of the manifest file includes: recording a start mark in the list file by using a stack; and when the content of the list file is restored, restoring a start mark and an end mark of the list file according to the start mark recorded by the stack.
In one implementation manner of the first aspect, repairing the code block of the manifest file includes: when the character string of the character string pool is replaced, repairing the character string of the character string pool according to the mapping relation between ResourceIDs and the index of the character string pool.
In a second aspect, embodiments of the present application provide a computer readable storage medium having stored thereon a computer program which when executed by a processor implements the method of any of the first aspects of the present application.
In a third aspect, an embodiment of the present application provides an electronic device, including: a memory storing a computer program; a processor, in communication with the memory, for executing the method according to any one of the first aspects of the application when the computer program is invoked.
The file repairing method provided by the embodiment of the application can repair the APK file according to the central directory of the APK file, and can repair the code blocks of the manifest file of the repaired APK file, thereby obtaining the final repairing file.
Drawings
Fig. 1 is a schematic diagram of an application scenario of a file repair method according to an embodiment of the application.
FIG. 2A is a flow chart of a method for repairing a file according to an embodiment of the application.
Fig. 2B is a schematic diagram of an APK file according to an embodiment of the application.
FIG. 3 is a flow chart of repairing APK files according to a central directory in accordance with an embodiment of the present application.
FIG. 4 is a flow chart of sequentially reading the header of the central directory file according to an embodiment of the application.
Fig. 5 is a schematic diagram of a string code block according to an embodiment of the application.
FIG. 6 is a flow chart illustrating repairing code blocks of a manifest file according to an embodiment of the present application.
Description of element reference numerals
100. Electronic equipment
101. Processor and method for controlling the same
102. Output device
103. Input device
104. Memory cell
105. Communication interface
106. Storage medium
107. Processor and method for controlling the same
S21 to S23 steps
S31 to S34 steps
S41 to S42 steps
S61 to S62 steps
Detailed Description
Other advantages and effects of the present application will become apparent to those skilled in the art from the following disclosure, which describes the embodiments of the present application with reference to specific examples. The application may be practiced or carried out in other embodiments that depart from the specific details, and the details of the present description may be modified or varied from the spirit and scope of the present application. It should be noted that the following embodiments and features in the embodiments may be combined with each other without conflict.
It should be noted that the illustrations provided in the following embodiments merely illustrate the basic concept of the present application by way of illustration, and only the components related to the present application are shown in the drawings and are not drawn according to the number, shape and size of the components in actual implementation, and the form, number and proportion of the components in actual implementation may be arbitrarily changed, and the layout of the components may be more complicated.
The information in the APK file has higher analysis value. However, some developers often re-encrypt APK files by means of pseudo-encryption, feature modification, character replacement, etc. in order to protect sensitive information in the files. After the encryption means are adopted, the general tool is difficult to normally extract the information in the APK file. For example, some APK files cannot be opened due to the encryption method, staff cannot know the code content of the file, and parsing errors may occur in the manifest file.
At least in view of the above problems, an embodiment of the present application provides a method for repairing a file. According to the method, the APK file can be repaired according to the central directory of the APK file, and the code blocks of the manifest file of the repaired APK file can be repaired, so that the final repair file is obtained. The staff can obtain the information in the final repair file by analyzing the final repair file.
The following describes the technical solution in the embodiment of the present application in detail with reference to the drawings in the embodiment of the present application.
The file repairing method provided by the embodiment of the application can be applied to electronic equipment.
Fig. 1 is a diagram illustrating a structure of an electronic device 100 according to an embodiment of the present application. As shown in fig. 1, an electronic device 100 includes a processor 101 coupled to one or more data storage units. The data storage units may include storage media 106 and memory units 104. The storage medium 106 may be Read-Only Memory (ROM), or readable and writable, such as a hard disk or flash Memory. The memory unit 104 may be a random access memory (Random Access Memory, RAM). Memory unit 104 may be integral to processor 101 or may be a separate component. The processor 101 is a control center of the electronic device 100 for executing program code to realize functions corresponding to the program instructions. Optionally, the processor 101 includes one or more central processing units (Central Processing Unit, CPU), such as CPU0 and CPU1 as shown in FIG. 1. Optionally, the electronic device 100 includes more than one processor, such as processors 101 and 107 shown in FIG. 1. Processors 101 and 107 may both be single-core processors or multi-core processors. The term "processor" as used herein refers to one or more devices, circuits, and/or processing cores for processing data, such as computer program instructions.
The CPU of the processor 101 and/or 107 stores the executed program code in the memory unit 104 or the storage medium 106. In the alternative, program code stored in storage medium 106 may be copied into memory unit 104 for execution by the processor. The processor may control the operation of the electronic device 100 by controlling the execution of other programs, controlling communication with peripheral devices, and controlling the use of resources of the electronic device 100 through the kernel.
The electronic device 100 may also include a communication interface 105 through which the electronic device 100 may communicate with another device or system, either directly or through an external network.
Optionally, the electronic device 100 further comprises an output device 102 and an input device 103. An output device 102 is coupled to the processor 101 and is capable of displaying output information in one or more ways. One example of the output device 102 is a visual display device, such as a Liquid crystal display (Liquid CRYSTAL DISPLAY, LCD), a Light-Emitting Diode (LED) display, a Cathode Ray Tube (CRT), or a projector. An input device 103 is coupled to the processor 101 and is capable of receiving user input in one or more ways. Examples of input devices 103 include a mouse, keyboard, touch screen device, sensing device, and the like.
The above-described elements of the electronic device 100 may be interconnected by a combination of any one or more of a data bus, an address bus, a control bus, an expansion bus, and a local bus.
The electronic device 100 may be a general purpose electronic device or an application specific electronic device. As a practical example, the electronic device 100 described above may be a storage array, an application server, an supercomputer, a desktop computer, a notebook computer, a Personal digital assistant (Personal DIGITAL ASSISTANT, PDA), a mobile phone, a tablet computer, a wireless terminal device, a telecommunication device, or any other device having a similar structure as shown in fig. 1. However, the present application is not limited to any particular type of electronic device. Program codes stored in the memory 104 having different functions are formed into processes after being executed by a processor (the processor 101 or the processor 107), and when the processes are executed, the processor needs to allocate a memory space to each process to store data generated during the execution of the processes.
FIG. 2A is a flow chart of a file repair method according to an embodiment of the application, which is applicable to the processor 101 and/or the processor 107 shown in FIG. 1. As shown in fig. 2A, the file repair method provided by the embodiment of the present application includes the following steps S21 to S23.
S21, repairing the APK file according to the central directory of the APK file to obtain a first APK file.
Fig. 2B shows a schematic structure of an APK file. As shown in fig. 2B, the APK file includes a data area and a central directory.
The data area includes a series of local file records. The local file record is used for recording metadata of files before and after compression and storing the files after compression. Each local file record includes a local file header, file data, and a file description. Table 1 shows one structure of the local header, where n and m are positive integers.
TABLE 1 local header composition table
| Offset amount | Bytes | Description of the invention |
| 0 | 4 | File header identification |
| 4 | 2 | Decompressing a desired version of a file |
| 6 | 2 | Universal bit marking |
| 8 | 2 | Compression method |
| 10 | 2 | File last modification time |
| 12 | 2 | Date of last modification of file |
| 14 | 4 | CRC-32 check code |
| 18 | 4 | Size after compression |
| 22 | 4 | Uncompressed size |
| 26 | 2 | File name Length |
| 28 | 2 | Extension zone length |
| 30 | n | File name |
| 30+n | m | File annotation length |
The central directory includes a central directory record area and a central directory record tail area. The central directory record area includes a series of central directory records. Each central directory record corresponds to a compressed file record in the data area. The central directory record tail area is used for locating the starting position of the central directory record area and recording the annotation content of the compressed package. Table 2 shows a structure recorded as a central directory, where n, m and k are positive integers.
TABLE 2 Central directory record formation Table
| Offset amount | Bytes | Description of the invention |
| 0 | 4 | Central directory file header identification |
| 4 | 2 | Version for compression |
| 6 | 2 | Decompression of desired versions |
| 8 | 2 | Universal bit marking |
| 10 | 2 | Compression method |
| 12 | 2 | File last modification time |
| 14 | 2 | Date of last modification of file |
| 16 | 4 | CRC-32 check code |
| 20 | 4 | Size after compression |
| 24 | 4 | Uncompressed size |
| 28 | 2 | File name Length |
| 30 | 2 | Extension zone length |
| 32 | 2 | File annotation length |
| 34 | 2 | Disk numbering of file start position |
| 36 | 2 | Internal file attributes |
| 38 | 4 | External file attributes |
| 42 | 4 | Relative displacement of local headers |
| 46 | n | File name |
| 46+n | m | Extension region |
| 46+n+m | k | File annotation |
S22, reading a manifest file of the first APK file. In some possible implementations, the manifest file is a manifest. The manifest file contains basic information, component declarations, authority requirements and the like of the APK file, and is used for describing the structure and configuration of the APK file.
In some possible implementations, the first APK file may be read in ZIP format, thereby obtaining a manifest file for the first APK file.
S23, repairing the code block (chunk) of the manifest file to obtain a second APK file.
In some possible implementations, all code blocks in the manifest file may be individually repaired by traversal.
Fig. 3 is a flowchart of repairing an APK file according to a central directory of the APK file according to an embodiment of the present application. As shown in fig. 3, repairing an APK file according to a central directory of the APK file in an embodiment of the present application includes the following steps S31 to S34.
S31, sequentially reading the file header of the central directory and recording the number of the read files. Specifically, each central directory file header corresponds to a compressed file record in the data area. The file number of the compressed file can be obtained by reading all the central directory file headers.
S32, reading the local file header through the central directory, and correcting the encryption marks of the central directory and the local file header.
S33, reading the local file content through the local file header, and repairing the compression mode and/or the size of the compressed file according to the decompression condition of the local file content.
In some possible implementations, repairing the compression mode and/or the compressed file size according to the decompression condition of the local file content includes: decompressing the local file content by adopting a specific decompression mode; if decompression is successful, repairing the compression mode according to the specific decompression mode, for example, the specific decompression mode can be written into data to complete repairing the compression mode; if decompression fails, it is determined whether the local file content is compressed, and if the local file content is not compressed, the compressed file size is restored according to the uncompressed file size, for example, the compressed file size may be corrected to the uncompressed file size.
Illustratively, one method of determining whether local file content is compressed includes: judging whether the two parameters of the uncompressed size in the local file header and the compressed file size are equal or not; if so, determining that the local file content is not compressed, otherwise, determining that the local file content is compressed.
S34, repairing the end section content of the central directory according to the file number and the signature block of the APK file.
In some possible implementations, repairing the end segment content of the central directory includes: writing the number of files recorded in step S31 into the end section of the central directory, adding signature fast data extracted from the APK file to the data end of the file, and thereafter adding the end section content of the central directory to the file end.
Referring to fig. 4, in some possible implementations, sequentially reading the header of the central directory file and recording the number of files read includes the following steps S41 and S42.
S41, positioning the starting position of the central directory. The location of the start position of the central directory may be achieved by a central directory end flag, for example.
Illustratively, locating the starting location of the central directory includes: sequentially reading data forwards from the data end of the APK file until a central directory end mark is acquired; and locating the starting position of the central directory according to the central directory ending mark.
S42, circularly reading the central directory file header from the initial position until all the central directory file headers are read, and recording the file number in the reading process. Specifically, 1 file number is added to each reading of the central directory file header in the above-mentioned circulation process, in this way, the file number can be obtained after the circulation is completed.
In one embodiment of the present application, repairing code blocks of a manifest file includes: when the number of character strings (StringCount) in the code block header is tampered, repairing the number of character strings in the code block header by using the character string starting position and the style starting position in the code block header. Specifically, when the string data in the code block header is tampered, the data in the code block header may be directly read to analyze the string data, which may exceed the length of the string pool, thereby causing analysis failure. For this problem, the number of strings may be corrected using the string start position and the style start position in the code block header in the embodiment of the present application.
Illustratively, FIG. 5 shows a block diagram of a String code block (String Chunk). StringPoolOffset for String Chunk is the relative offset with respect to String Chunk. For the first 7 entries StringPool, each entry occupies 4 bytes, and StylePoolOffset occupies 4× styleCount bytes. StringPoolOffset occupies 4 x StringPoolOffset bytes. If the offset position StringPool is 2036, the true data of StringCount can be calculated from the offset position to be 502. If StringCount's data is different from the real data, then it is indicated that StringCount is tampered with.
In one embodiment of the present application, the manifest file is an XML file. FIG. 6 is a flow chart illustrating the repair of code blocks of a manifest file in an embodiment of the present application. As shown in fig. 6, repairing a code block of a manifest file in an embodiment of the present application includes the following steps S61 and S62.
S61, recording a start mark in the list file by using the stack. The stack follows the principles of Last-In-First-Out (LIFO), and finally the elements put into the stack will be accessed and removed First.
S62, when restoring the content of the list file, restoring the start mark and the end mark of the list file according to the start mark recorded by the stack.
Specifically, as each code block is traversed, there may be a start flag for a node and no end flag, which may result in parsing of the manifest file with errors. In order to solve the problem, in the embodiment of the application, a stack is used for recording the occurrence time of the start mark of each XML node, and no record is made for the end of the node. When restoring the file content, the start flag and the end flag of the list file are restored according to the appearance time of the start flag, and the start flag and the section number flag are written in pairs. That is, when a start flag a1 is encountered, the file content is written. When the next new start mark a2 is encountered during writing, writing an end mark corresponding to a1. By the method, the problems of node deletion and attribute tampering can be solved.
In one embodiment of the present application, repairing code blocks of a manifest file includes: when the character string of the character string pool is replaced, repairing the character string of the character string pool according to the mapping relation between ResourceIDs and the index of the character string pool.
Specifically, resouceId Chunk has a body ResourceIDs. ResourceIDs is a section of continuous 32-bit array in which index IDs corresponding to system attributes used in the entire document are recorded. The index corresponds to the index of the String pool in the String Chunk, that is, there is a mapping relationship between the two indexes. The index ID of the first String in the String Chunk is the first index ID in ResourceIDs. Therefore, the character string of the character string pool can be repaired according to the mapping relation between ResourceIDs and the index of the character string pool.
The protection scope of the file repairing method according to the embodiment of the present application is not limited to the execution sequence of the steps listed in the embodiment, and all the schemes implemented by adding or removing steps and replacing steps according to the prior art made by the principles of the present application are included in the protection scope of the present application.
Those of ordinary skill would further appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The embodiment of the application also provides a computer readable storage medium, on which a computer program is stored, which when executed by a processor implements the file repair method provided by any embodiment of the application. Those of ordinary skill in the art will appreciate that all or part of the steps in a method implementing the above embodiments may be implemented by a program to instruct a processor, where the program may be stored in a computer readable storage medium, where the storage medium is a non-transitory (non-transitory) medium, such as a random access memory, a read only memory, a flash memory, a hard disk, a solid state disk, a magnetic tape (MAGNETIC TAPE), a floppy disk (floppy disk), a compact disk (optical disk), and any combination thereof. The storage media may be any available media that can be accessed by a computer or a data storage device such as a server, data center, or the like that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital video disc (digital video disc, DVD)), or a semiconductor medium (e.g., a Solid State Drive (SSD)), or the like.
The descriptions of the processes or structures corresponding to the drawings have emphasis, and the descriptions of other processes or structures may be referred to for the parts of a certain process or structure that are not described in detail.
The embodiment of the application also provides electronic equipment. The electronic device includes a memory and a processor. The memory is used for storing a computer program. In some possible implementations, the memory may include: various media capable of storing program codes, such as ROM, RAM, magnetic disk, U-disk, memory card, or optical disk. The processor is in communication with the memory and is configured to execute the computer program stored in the memory, so that the electronic device executes the file repair method provided by the embodiment of the application.
In some possible implementations, the electronic device provided by the embodiments of the present application may further include a display. A display 830 is communicatively coupled to the memory and the processor for displaying an associated graphical user interface (GRAPHICAL USER INTERFACE, GUI) for the text repair method.
In summary, the embodiments of the present application provide a file repairing method, a storage medium, and an electronic device, which can solve a file content parsing error caused by means of pseudo encryption, file header tampering, string replacement, compression tampering, and the like. The method can normally decompress the APK file by repairing the structure of the APK file to extract the resource file and the code. In addition, by determining the specific position and type of the error, including pseudo encryption, file header tampering, character string replacement, compression mode tampering and the like, the method adopts a corresponding data restoration strategy to repair tampered or damaged data, and ensures the integrity and accuracy of file contents. Furthermore, in the text repair method provided by the embodiment of the application, when the android management file is analyzed, the integrity of the content of the manifest file can be ensured by supplementing the missing nodes and restoring the replaced character strings. Meanwhile, the analyzed android management XML content can be stored locally in an XML structure, and the user can check the content conveniently. Therefore, the application effectively overcomes various defects in the prior art and has higher industrial value.
The above embodiments are merely illustrative of the principles of the present application and its effectiveness, and are not intended to limit the application. Modifications and variations may be made to the above-described embodiments by those skilled in the art without departing from the spirit and scope of the application. Accordingly, it is intended that all equivalent modifications and variations of the application be covered by the claims, which are within the ordinary skill of the art, be within the spirit and scope of the present disclosure.
Claims (8)
1. A method of repairing a file, the method comprising:
Repairing an APK file according to a central directory of the APK file to obtain a first APK file;
Reading a manifest file of the first APK file;
repairing the code blocks of the manifest file to obtain a second APK file;
the method for repairing the APK file according to the central directory of the APK file to obtain the first APK file comprises the following steps:
sequentially reading the file header of the central directory and recording the number of the read files;
reading a local file header through the central directory, and correcting encryption marks of the central directory and the local file header;
reading the content of the local file through the local file header;
Repairing the compression mode and/or the compressed file size according to the decompression condition of the local file content, including:
decompressing the local file content by adopting a specific decompression mode, if the decompression is successful, repairing the compression mode according to the specific decompression mode, otherwise determining whether the local file content is compressed or not, and if the local file content is not compressed, repairing the compressed file size according to the uncompressed file size;
And repairing the end section content of the central directory according to the file number and the signature block of the APK file to obtain the first APK file.
2. The file repair method according to claim 1, wherein sequentially reading the central directory file header and recording the number of files read comprises:
locating a start position of the central directory;
and circularly reading the central directory file header from the initial position until all the central directory file headers are read, and recording the file number in the reading process.
3. The file repair method of claim 2 wherein locating a starting location of the central directory comprises:
sequentially reading data forwards from the data end of the APK file until a central directory end mark is acquired;
and positioning the starting position of the central directory according to the central directory ending mark.
4. The file repair method of claim 1, wherein repairing the code blocks of the manifest file comprises:
when the number of the character strings in the code block head is tampered, repairing the number of the character strings in the code block head by utilizing the character string starting position and the style starting position in the code block head.
5. The file repair method according to claim 1, wherein the manifest file is an XML file, and repairing code blocks of the manifest file includes:
recording a start mark in the list file by using a stack;
and when the content of the list file is restored, restoring a start mark and an end mark of the list file according to the start mark recorded by the stack.
6. The file repair method of claim 1, wherein repairing the code blocks of the manifest file comprises:
When the character string of the character string pool is replaced, repairing the character string of the character string pool according to the mapping relation between ResourceIDs and the index of the character string pool.
7. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the method of any one of claims 1 to 6.
8. An electronic device, the electronic device comprising:
a memory storing a computer program;
A processor in communication with the memory, the method of any one of claims 1 to 6 being performed when the computer program is invoked.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310897381.7A CN116881035B (en) | 2023-07-20 | 2023-07-20 | File repair method, storage medium and electronic device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310897381.7A CN116881035B (en) | 2023-07-20 | 2023-07-20 | File repair method, storage medium and electronic device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116881035A CN116881035A (en) | 2023-10-13 |
| CN116881035B true CN116881035B (en) | 2024-06-14 |
Family
ID=88271179
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310897381.7A Active CN116881035B (en) | 2023-07-20 | 2023-07-20 | File repair method, storage medium and electronic device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116881035B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110598379A (en) * | 2019-09-23 | 2019-12-20 | 北京智游网安科技有限公司 | Method, system, equipment and storage medium for implementing character string confusion |
| CN111984597A (en) * | 2020-08-19 | 2020-11-24 | 安徽鸿程光电有限公司 | File storage method, device, equipment and medium |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6522268B2 (en) * | 2000-01-05 | 2003-02-18 | Realnetworks, Inc. | Systems and methods for multiple-file data compression |
| US20030191938A1 (en) * | 2002-04-09 | 2003-10-09 | Solarsoft Ltd. | Computer security system and method |
| CN1700180A (en) * | 2005-04-14 | 2005-11-23 | 上海交通大学 | Data file restoration and password cracking system |
| US7603390B2 (en) * | 2005-07-15 | 2009-10-13 | Microsoft Corporation | Methods and systems for recovering data from corrupted archives |
| US9420070B2 (en) * | 2013-01-17 | 2016-08-16 | Apple Inc. | Streaming zip |
| CN105391717B (en) * | 2015-11-13 | 2019-01-04 | 福建联迪商用设备有限公司 | A kind of APK signature authentication method and its system |
| KR101727860B1 (en) * | 2016-05-23 | 2017-04-17 | 주식회사 한컴지엠디 | Recovery apparatus and method of document file |
| US11100225B2 (en) * | 2018-12-28 | 2021-08-24 | Mcafee, Llc | Scanning of encrypted zip files |
| KR102340981B1 (en) * | 2020-06-25 | 2021-12-21 | 신영에스아이(주) | Method for checking file validity |
-
2023
- 2023-07-20 CN CN202310897381.7A patent/CN116881035B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110598379A (en) * | 2019-09-23 | 2019-12-20 | 北京智游网安科技有限公司 | Method, system, equipment and storage medium for implementing character string confusion |
| CN111984597A (en) * | 2020-08-19 | 2020-11-24 | 安徽鸿程光电有限公司 | File storage method, device, equipment and medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116881035A (en) | 2023-10-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7617451B2 (en) | Structuring data for word processing documents | |
| US9530006B2 (en) | Method and system for performing a memory safety check of a program written in an unmanaged programming language | |
| US20070022128A1 (en) | Structuring data for spreadsheet documents | |
| US20060277452A1 (en) | Structuring data for presentation documents | |
| CN110413439B (en) | Method, apparatus and computer readable medium for detecting incomplete writing of data | |
| JP2003256202A (en) | Compatibility check support program, compatibility check support method and compatibility check support device | |
| CN102662789A (en) | Method for adding CRC (cyclic redundancy check) to ELF (executable linkable format) file | |
| CN106445815A (en) | Automated testing method and device | |
| CN111258666A (en) | Reading method and device of computer file, computer system and storage medium | |
| CN114860745B (en) | Database expansion method based on artificial intelligence and related equipment | |
| US7197706B1 (en) | Method and system for ensuring accurate font matching in documents | |
| CN110765152B (en) | SQL extraction method, SQL extraction device, computer equipment and storage medium | |
| US10678864B2 (en) | Analysis model preparing system, programming apparatus, and analysis model preparing method | |
| US20100242027A1 (en) | Identifying groups and subgroups | |
| US8595271B1 (en) | Systems and methods for performing file system checks | |
| CN116881035B (en) | File repair method, storage medium and electronic device | |
| CN105404828A (en) | Method and system for data security | |
| CN107533614B (en) | Device for storing data and storage medium | |
| CN111241096A (en) | Text extraction method, system, terminal and storage medium for EXCEL document | |
| CN112650645B (en) | Heap memory use condition monitoring method and device and 5G base station equipment | |
| CN102567210B (en) | Method and device for reorganizing data analysis environment of flash memory chip | |
| US9412412B2 (en) | Logical block protection for tape interchange | |
| CN114924947A (en) | Code testing method and device, electronic equipment and storage medium | |
| JP4897359B2 (en) | MEMORY MANAGEMENT DEVICE, MEMORY MANAGEMENT METHOD, AND PROGRAM | |
| US8549488B2 (en) | Validating a variable data item in a software routine |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |