Application program shelling method and device, electronic equipment and storage medium
By obtaining the memory segment of the target application, calling the memory scanning function and the preset file discrimination model to process the memory block, the problem of low application unpacking efficiency in the existing technology is solved, and an efficient and automated unpacking method is realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-06
- Publication Date
- 2026-03-27
AI Technical Summary
Existing application unpacking methods are inefficient and lack automation, making them difficult to effectively deal with unpacked variants.
By obtaining the memory segment of the target application, calling the memory scanning function to obtain the memory block, determining the candidate executable file based on the data structure characteristics, processing it using a preset file discrimination model, and repairing and re-signing the valid executable file to generate an unpacked application.
It improves the efficiency and accuracy of application unpacking methods, automates the unpacking process, and ensures that executable files can be parsed and executed normally.
Smart Images
Figure CN121744274A_ABST
Abstract
Description
[0001] The present application claims priority to the Chinese patent application No. 202511439259.0, filed on October 9, 2025, and entitled "Application unpacking method and device, electronic equipment and storage medium", the whole content of which is incorporated herein by reference. TECHNICAL FIELD
[0002] The present application relates to the technical field of Internet, and in particular to an application unpacking method and device, electronic equipment and storage medium. BACKGROUND
[0003] With the rapid development of mobile Internet, the packing technology of mobile application for evading security detection is increasingly rampant, which poses a serious threat to the safety of user information and seriously affects the user experience of using the application.
[0004] In the related art, the traditional unpacking method often has poor universality and low automation, and it is difficult to effectively deal with the endless packing variants of the application.
[0005] Therefore, how to improve the efficiency of the application unpacking method has become a technical problem to be solved. SUMMARY
[0006] The embodiments of the present application provide an application unpacking method and device, electronic equipment and storage medium to solve the problem of the efficiency of the application unpacking method in the related art.
[0007] In a first aspect, the embodiments of the present application provide an application unpacking method, comprising:
[0008] obtaining a memory segment of a target application;
[0009] calling a memory scanning function to obtain a memory block in the memory segment;
[0010] determining a data block meeting the executable file format feature according to the data structure feature of the memory block, and taking a file corresponding to the data block as a candidate executable file;
[0011] processing the candidate executable file by using a preset file discrimination model to obtain an effective executable file;
[0012] performing repair processing on the effective executable file to obtain a target executable file;
[0013] obtaining an unpacked application corresponding to the target application based on the target executable file and the target application.
[0014] In a possible implementation, the memory segment of the target application is obtained, comprising:
[0015] The preset function is called through the control script to enumerate the readable memory segment in the target application program, and the memory segment is obtained.
[0016] In a possible implementation, the preset file discrimination model is used to process the candidate executable file, and an effective executable file is obtained, including:
[0017] The state of the data block is detected to obtain a candidate memory block.
[0018] The feature vector of the candidate memory block is obtained.
[0019] The feature vector of the candidate memory block is input into the preset file discrimination model to obtain a probability that the candidate memory block is an executable file.
[0020] When the probability that the candidate memory block is an executable file is greater than a preset threshold, the candidate memory block is determined as an effective executable file.
[0021] The whole block byte stream of the effective executable file is read through a remote procedure call memory reading function.
[0022] In a possible implementation, the state of the data block is detected to obtain a candidate memory block, including:
[0023] The preset byte of the data block, the preset field of the data block, and the byte sequence label of the data block are respectively detected to determine whether the preset byte meets a preset standard, whether the preset field meets a preset range, and whether the byte sequence label meets a preset format, and a state detection result is obtained.
[0024] When the state detection result is that all meet, the data block is determined as a candidate memory block.
[0025] In a possible implementation, the effective executable file is repaired to obtain a target executable file, including:
[0026] The effective executable file that does not meet the preset format is repaired to obtain a repaired executable file.
[0027] When it is determined that the check code and the signature in the repaired executable file are missing, the repaired executable file is corrected in the check code and the signature to obtain a corrected executable file.
[0028] An index table is generated based on the corrected executable file to obtain a target executable file.
[0029] In a possible implementation, the repaired executable file is corrected in the check code and the signature to obtain a corrected executable file, including:
[0030] Clear the checksum field of the repair executable file, perform a consistency correction algorithm on the bytes in the repair executable file except for the magic number byte sequence, and fill the checksum field with the calculation result of the consistency correction algorithm to perform checksum correction on the repair executable file;
[0031] The signature field of the repaired executable file is cleared. The consistency correction algorithm is re-executed on the bytes in the repaired executable file except for the magic number byte sequence. The calculation result of the consistency correction algorithm is then filled back into the signature field to perform signature correction on the repaired executable file.
[0032] In one possible implementation, based on the target executable file and the target application, an unpacked application corresponding to the target application is obtained, including:
[0033] The target executable file and other resources in the target application are repackaged to obtain a package file; where other resources refer to other sub-sections in the target application besides the sub-sections contained in the target executable file.
[0034] The packaged file is re-signed using a custom keystore to obtain the unpacked application corresponding to the target application.
[0035] Secondly, embodiments of this application provide an application unpacking device, comprising:
[0036] The acquisition module is used to acquire the memory segment of the target application;
[0037] The acquisition module is also used to call memory scanning functions to obtain memory blocks in memory segments;
[0038] The determination module is used to determine data blocks that conform to the executable file format characteristics based on the data structure characteristics of memory blocks, and to select the files corresponding to the data blocks as candidate executable files;
[0039] The determination module is also used to process candidate executable files using a preset file discrimination model to obtain valid executable files;
[0040] The processing module is used to repair valid executable files to obtain the target executable file;
[0041] The determination module is also used to obtain the unpacked application corresponding to the target application based on the target executable file and the target application.
[0042] In one possible implementation, the acquisition module is specifically used for:
[0043] The script calls a preset function to enumerate the readable memory segments in the target application, thus obtaining the memory segments.
[0044] In one possible implementation, the determining module is specifically used for:
[0045] Perform status checks on the data blocks to obtain candidate memory blocks;
[0046] Obtain the feature vectors of candidate memory blocks;
[0047] The feature vectors of candidate memory blocks are input into a preset file discrimination model to obtain the probability that a candidate memory block is an executable file;
[0048] When the probability that a candidate memory block is an executable file is greater than a preset threshold, the candidate memory block is determined to be a valid executable file;
[0049] The entire byte stream of a valid executable file is read using a remote procedure call memory read function.
[0050] In one possible implementation, the determining module is specifically used for:
[0051] The status detection results are obtained by checking whether the preset bytes of the data block conform to the preset standard, whether the preset fields of the data block conform to the preset range, and whether the byte order label of the data block conforms to the preset format.
[0052] If the status detection results are all met, the data block is identified as a candidate memory block.
[0053] In one possible implementation, the processing module is specifically used for:
[0054] Repair valid executable files that do not conform to the preset format to obtain repaired executable files;
[0055] When it is determined that the checksum and signature are missing in the repair executable file, the checksum and signature of the repair executable file are corrected to obtain the corrected executable file;
[0056] An index table is generated based on the corrected executable file, and the target executable file is obtained.
[0057] In one possible implementation, the processing module is specifically used for:
[0058] Clear the checksum field of the repair executable file, perform a consistency correction algorithm on the bytes in the repair executable file except for the magic number byte sequence, and fill the checksum field with the calculation result of the consistency correction algorithm to perform checksum correction on the repair executable file;
[0059] The signature field of the repaired executable file is cleared. The consistency correction algorithm is re-executed on the bytes in the repaired executable file except for the magic number byte sequence. The calculation result of the consistency correction algorithm is then filled back into the signature field to perform signature correction on the repaired executable file.
[0060] In one possible implementation, the determining module is specifically used for:
[0061] The target executable file and other resources in the target application are repackaged to obtain a package file; where other resources refer to other sub-sections in the target application besides the sub-sections contained in the target executable file.
[0062] The packaged file is re-signed using a custom keystore to obtain the unpacked application corresponding to the target application.
[0063] Thirdly, embodiments of this application provide an electronic device, including: a processor, and a memory communicatively connected to the processor;
[0064] The memory stores the instructions that the computer executes;
[0065] The processor executes computer-executable instructions stored in memory to implement the method as described in the first aspect or any of the above.
[0066] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in the first aspect or any of the above-mentioned methods.
[0067] Fifthly, embodiments of this application provide a computer program. The computer program product includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When the at least one processor executes the computer program, it can implement the methods described in the first aspect or any of the above-mentioned methods.
[0068] The application unpacking method, apparatus, electronic device, and storage medium provided in this application embodiment first obtain the memory segment of the target application, calls a memory scanning function to obtain memory blocks in the memory segment, then determines data blocks that conform to the executable file format characteristics based on the data structure characteristics of the memory blocks, and uses the files corresponding to the data blocks as candidate executable files. A preset file discrimination model is used to process the candidate executable files to obtain valid executable files, reducing the impact of invalid data on the overall unpacking method speed and improving the accuracy of the unpacking method. Valid executable files are repaired to ensure that the executable files can be parsed and executed normally to obtain the target executable file. Finally, based on the target executable file and the target application, an unpacked application corresponding to the target application is obtained, realizing the automation of the unpacking method and improving the efficiency of the application unpacking method. Attached Figure Description
[0069] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0070] Figure 1 Flowchart of the application unpacking method provided in the embodiments of this application Figure 1 ;
[0071] Figure 2 Flowchart of the application unpacking method provided in the embodiments of this application Figure 2 ;
[0072] Figure 3 Flowchart of the application unpacking method provided in the embodiments of this application Figure 3 ;
[0073] Figure 4 This is a schematic diagram of the structure of the application unpacking device provided in the embodiments of this application;
[0074] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
[0075] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0076] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0077] Before introducing the embodiments of this application, the application background of the embodiments of this application will be explained first:
[0078] With the rapid development of the mobile internet, the use of obfuscation techniques to evade security detection in mobile applications has become increasingly rampant, posing a serious threat to the security of user information and severely impacting the user experience.
[0079] In related technologies, unpacking methods are mainly divided into two major technical paths: static analysis and dynamic analysis. Static analysis extracts structural information and key data from the application by parsing its binary code, while dynamic analysis executes the application in a controlled environment and monitors its runtime behavior in real time, such as the application programming interface (API) call sequence and memory access patterns.
[0080] For example, Frida Dalvik ExecutableDumper (frida_dexdump) is an Android application unpacking tool developed based on Frida. It uses a heuristic search principle to extract executable files from memory. Unlike traditional unpacking methods that rely on intercepting system loading functions, frida_dexdump locates and extracts executable files by directly searching for regions in memory that match the structural characteristics of the executable file. This method avoids the compatibility and stability issues common in traditional methods caused by system differences, function signature changes, and strict requirements for injection timing.
[0081] For example, a cracked Android package (Capk) is an interpreter-intercepting unpacking framework that enables functions such as obtaining executable files at the Android remote code layer, active function-level calls, interception and unpacking at the interpreter level, and automatic repair of the generated executable file after unpacking.
[0082] For example, PackerGrind is an adaptive unpacking framework that uses three steps—dynamic monitoring, restoration, and restoration analysis—to perform adaptive cyclic unpacking. During application execution, PackerGrind analyzes the application's behavior, determines the type of packer and selects the unpacking point, and finally analyzes the unpacking result. If the unpacking result is satisfactory, the unpacking is complete; otherwise, it will continue to cycle through unpacking.
[0083] Nevertheless, research on applying artificial intelligence to the field of mobile application unpacking is still in the exploratory stage and faces many challenges and key issues that need to be addressed. For example, the aforementioned unpacking methods have poor versatility and low automation, making it difficult to effectively deal with the ever-increasing number of unpacked variants of applications.
[0084] Therefore, improving the efficiency of application unpacking has become an urgent technical problem to be solved.
[0085] To address the technical problems existing in related technologies, the inventors of this application propose the following solution: To address the issue of low application unpacking efficiency, the system enumerates and scans the memory segments of the target application to locate data blocks conforming to DEX format characteristics from the readable memory segments of the target application. Then, it filters candidate memory blocks through multi-layered verification mechanisms such as magic number, field range, and byte order tags. Finally, it calculates the probability of a valid executable file by combining the feature vectors of the candidate memory blocks with a preset file discrimination model, accurately identifying the valid executable file and extracting the byte stream completely. For valid executable files that do not conform to the preset format, the system repairs and corrects them to obtain the target executable file. Then, based on the target executable file and the resources of the target application, the system repackages and signs the file to generate a normally installable and runnable unpacked application. This dynamic memory extraction and intelligent identification of valid executable files improve the application unpacking efficiency.
[0086] The parts not described in detail are disclosed in the following embodiments.
[0087] The technical solution of this application will now be described in detail through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.
[0088] The subject of this application is an electronic device, which may specifically be a server, terminal device, etc.
[0089] Figure 1 Flowchart of the application unpacking method provided in the embodiments of this application Figure 1 ,like Figure 1 As shown, the method may include the following steps:
[0090] Step 11: Obtain the memory segment of the target application.
[0091] In this step, the target application is installed and run on the agent (e.g., a smartphone), and the control end (e.g., a computer) obtains the memory segments generated during the execution of the target application on the agent.
[0092] The target application is an application that has been processed with packing technology. The core executable file of the packed application is decrypted and loaded into memory at runtime, and can only be accessed in the readable memory segment.
[0093] Before obtaining the memory segment of the target application, the Android application package (APK) file is parsed. The file path characteristics are obtained based on the file name to obtain the APK hardening vendor. If the APK file has a hardening vendor, the target application is automatically installed and launched. If the APK file does not have a hardening vendor, it is checked whether the missing rate of executable files in the declared components of the APK file exceeds the threshold. If it exceeds the threshold, it means that the APK file has been hardened, and the target application is automatically installed and launched. The control terminal obtains the memory segment during the execution of the target application.
[0094] Specifically, step 11 includes the following implementation methods:
[0095] The script calls a preset function to enumerate the readable memory segments in the target application, thus obtaining the memory segments.
[0096] In this implementation, the control end calls the Frida framework's preset functions through the control script to enumerate the process memory of the target application during runtime, filter out all memory segments with read permissions, and locate all memory regions that may store decrypted executable files through the enumeration operation, providing basic data for subsequent memory scanning.
[0097] The default function can be the process enumeration memory range (Process.enumerateRanges) function.
[0098] Step 12: Call the memory scan function to obtain the memory blocks in the memory segment.
[0099] In this step, the control end uses the Frida framework to call the memory scanning function to traverse the data in the memory segment at a fixed byte granularity (such as 4 bytes or 8 bytes) and extract consecutive memory blocks. During the scanning process, the focus is on areas that may contain executable file characteristics. At the same time, the starting address, length and original byte stream of each memory block are recorded to ensure that suspected data blocks can be completely extracted during subsequent analysis.
[0100] For example, a memory scanning function refers to a function used to traverse the memory space of a target process, read memory data according to rules, and detect specific characteristics (such as executable file characteristics). For example, it could be the Memory.scan function.
[0101] Step 13: Based on the data structure characteristics of the memory block, determine the data block that conforms to the executable file format characteristics, and use the file corresponding to the data block as a candidate executable file.
[0102] In this step, the data features of the memory blocks extracted in step 12 are validated to identify data blocks that conform to the executable file format features. Then, the files corresponding to the data blocks that conform to the executable file format features are selected as candidate executable files.
[0103] For example, first check if the starting position of the memory block has the magic number characteristics of an executable file (e.g., conforming to the format dex\n035\0), and whether the string identifier offset (string_ids_off) conforms to the characteristics of an executable file. If both conform, the memory block is identified as a data block, and the file containing the data block is identified as a candidate executable file.
[0104] Step 14: Process the candidate executable files using a preset file discrimination model to obtain valid executable files.
[0105] In this step, candidate executable files are double-verified. First, heuristic rules are used to check whether the first 8 bytes of the data block in the candidate executable file conform to the magic number feature. Then, it is confirmed whether the size of the candidate executable file and the size of the header file are within a reasonable range. Finally, it is verified whether the endian tag is in the preset format. The data block that passes all three format verifications is input into the preset file discrimination model. The data features of valid executable files learned in the preset file discrimination model are used to determine the valid executable file.
[0106] For example, the preset file discrimination model can be a binary classifier.
[0107] Step 15: Repair the valid executable file to obtain the target executable file.
[0108] In this step, the valid executable file may have structural damage such as missing header fields, disordered index table, invalid checksums, etc. It is necessary to repair the valid executable file. First, the damaged header fields are completed or corrected. Then, the core index table is rebuilt to ensure that data segments such as string table and type table can be correctly located. Finally, the checksum and signature are recalculated and backfilled to obtain a target executable file with complete structure and valid format.
[0109] Step 16: Based on the target executable file and the target application, obtain the unpacked application corresponding to the target application.
[0110] In this step, the original packed application (i.e. the target application) is unpacked, and other resources except for the encrypted executable file are extracted. Then, the target executable file obtained in step 15 replaces the encrypted DEX in the original packed application, and it is repackaged into an unsigned unpacked application file. Finally, the unpacked application file is resigned using a custom keystore to obtain the final unpacked application.
[0111] Specifically, step 16 includes the following implementation methods:
[0112] Step 1: Repackage the target executable file and other resources in the target application to obtain a packaged file.
[0113] Other resources refer to sub-sections in the target application other than those contained in the target executable file.
[0114] In this implementation, the original installation package of the target application is first unpacked, and non-DEX resources (i.e., sub-segments other than those contained in the target executable file) are extracted. These include, but are not limited to, layout files, images, string resources in the res directory, the AndroidManifest.xml configuration file, native libraries in the lib directory, and binary resources in the assets directory. Then, the repaired target executable file replaces the encrypted or corrupted executable file in the original installation package. The target DEX and other extracted resources are then reorganized according to the standard directory structure of Android applications, and an unsigned package file is generated using a packaging tool.
[0115] Step 2: Use a custom keystore to re-sign the packaged file to obtain the unpacked application corresponding to the target application.
[0116] In this implementation, a pre-created custom keystore is used to perform a re-signing operation on the packaged file. The signing tool calls the private key in the keystore to encrypt and sign the packaged file. After signing, the generated unpacked application supports both V1 (based on JAR signing) and V2 (based on the overall signing of the installation package) signing schemes, ensuring that the unpacked application can pass the signature verification mechanism of the Android system when it is installed. Finally, an unpacked application that can be installed and run normally and contains complete original logic is obtained.
[0117] The application unpacking method provided in this application embodiment first obtains the memory segment of the target application, calls a memory scanning function to obtain memory blocks in the memory segment, then determines data blocks that conform to the executable file format characteristics based on the data structure characteristics of the memory blocks, and uses the files corresponding to the data blocks as candidate executable files. A preset file discrimination model is used to process the candidate executable files to obtain valid executable files, reducing the impact of invalid data on the overall unpacking method speed and improving the accuracy of the unpacking method. The valid executable files are repaired to ensure that the executable files can be parsed and executed normally to obtain the target executable file. Finally, based on the target executable file and the target application, an unpacked application corresponding to the target application is obtained, realizing the automation of the unpacking method and improving the efficiency of the application unpacking method.
[0118] Based on the above embodiments, Figure 2 Flowchart of the application unpacking method provided in the embodiments of this application Figure 2 ,like Figure 3 As shown, step 14 may include the following steps:
[0119] Step 21: Perform status checks on the data blocks to obtain candidate memory blocks.
[0120] In this step, a multi-dimensional format compliance check is performed on the data block to obtain candidate memory blocks.
[0121] For example, first, verify whether the sequence of magic number bytes at the beginning of the memory block is complete and unaltered; second, check whether the key header fields are within the preset range; and finally, confirm whether the storage format corresponding to the byte order label is consistent with the executable file specification. Data blocks that meet all the preset standards are marked as candidate memory blocks.
[0122] For example, the method for determining whether a key header field is within a preset range is as follows: whether the format of the endian tag at offset 0x08 is 0x12345678, whether the format of the header size at offset 0x20 is 0x70, and whether the file size at offset 0x24 is greater than the header file size.
[0123] Specifically, step 21 includes the following implementation methods:
[0124] Step 1: Check whether the preset bytes of the data block conform to the preset standard, whether the preset fields of the data block conform to the preset range, and whether the byte order label of the data block conforms to the preset format, and obtain the status detection results.
[0125] Under this implementation, a three-layer structured inspection is performed on the data block. First, it checks whether the 8-byte magic number (i.e. the preset byte) at the beginning of the executable file header is completely consistent with the magic number of the executable file to ensure that the memory block has the basic identifier of the executable file. Second, it checks whether the preset field value is within a reasonable range. Finally, it checks whether the byte order label is in the preset format to obtain the status inspection result.
[0126] Among them, the preset fields are key fields such as header file size at offset 0x20, file size at offset 0x24, and checksum at offset 0x28.
[0127] For example, the header file size is 0x70, and the file size needs to be greater than the header file size but not exceed the total length of the memory block.
[0128] Step 2: If the status detection results are all met, the data block is identified as a candidate memory block.
[0129] In this implementation, if all status detection results are met, it indicates that the data block fully conforms to the structural characteristics of an executable file in terms of basic format, and the data block is identified as a candidate memory block. If any detection item does not meet the requirements, it is determined to be an invalid memory block and is excluded.
[0130] Step 22: Obtain the feature vectors of the candidate memory blocks.
[0131] In this step, feature vectors that reflect the essential characteristics of executable files are extracted from candidate memory blocks. By quantitatively analyzing the byte distribution, structural logic, and format regularity of candidate memory blocks, they are transformed into numerical feature vectors that can be recognized by machine learning models, providing a data foundation for the subsequent unpacking of applications.
[0132] The feature vectors include basic format features such as header field integrity and key offset rationality; structural features such as matching degree between index table number and file size and index table structure integrity; entropy statistical features such as byte entropy value and frequency of occurrence of specific key fields; and abnormal pattern features such as encryption traces and data block breakage indicators.
[0133] Step 23: Input the feature vector of the candidate memory block into the preset file discrimination model to obtain the probability that the candidate memory block is an executable file.
[0134] In this step, the feature vector of the candidate memory block is input into the preset file discrimination model. The file discrimination model calculates the feature vector of the candidate memory block by weighting it based on the feature patterns of valid executable files in the historical samples it has learned, and outputs the probability value that the block belongs to a valid executable file.
[0135] The preset file discrimination model is trained using a machine learning model on a large number of positive samples of valid and legal executable files and negative samples including a large amount of memory garbage and fake structures. It can classify the feature vectors of candidate memory blocks.
[0136] Step 24: When the probability that a candidate memory block is an executable file is greater than a preset threshold, the candidate memory block is determined as a valid executable file.
[0137] In this step, when the probability that a candidate memory block is an executable file is greater than a preset threshold, it indicates that the candidate memory block highly matches the valid executable file in terms of feature distribution, and the candidate memory block is determined to be a valid executable file.
[0138] For example, the preset threshold is 0.9.
[0139] If the probability that a candidate memory block is an executable file is less than or equal to a preset threshold, the candidate memory block is marked as invalid data and excluded.
[0140] Step 25: Read the entire byte stream of the valid executable file using a remote procedure call memory read function.
[0141] In this step, the remote procedure call mechanism of the Frida framework is used to trigger the JavaScript Agent injected into the target process to execute the memory read function, which completely reads the entire block of byte stream data of the valid executable file from the target process memory, and transfers the entire block of byte stream data to a temporary directory storage on the control end (such as the local computer), ensuring that the memory data is extracted without loss or tampering, and providing a complete data source for subsequent repair processing.
[0142] The application unpacking method provided in this application first performs state detection on data blocks to obtain candidate memory blocks, eliminating obviously invalid memory noise from the source to reduce data redundancy for subsequent analysis. It then obtains feature vectors of the candidate memory blocks and inputs them into a preset file discrimination model. The model utilizes the generalization ability of machine learning to identify executable files in modified or special packed scenarios, obtaining the probability that a candidate memory block is an executable file. When the probability of a candidate memory block being an executable file is greater than a preset threshold, the candidate memory block is determined as a valid executable file. This method reduces false positives while ensuring recognition accuracy, avoids interfering data from entering subsequent processing, and improves the overall efficiency of unpacking. Finally, it uses a remote procedure call memory read function to read the entire byte stream of the valid executable file and transmits the entire byte stream to a local temporary directory, ensuring that all application data is preserved.
[0143] Based on the above embodiments, Figure 3Flowchart of the application unpacking method provided in the embodiments of this application Figure 4 ,like Figure 4 As shown, step 15 may include the following steps:
[0144] Step 31: Repair valid executable files that do not conform to the preset format to obtain repaired executable files.
[0145] In this step, key fields in the header of a valid executable file are parsed. If a field value is found to be inconsistent with the actual data (e.g., the file size is smaller than the actual memory block length), the field value is corrected according to the actual size and structural characteristics of the memory block. Next, the offset addresses of each data segment are checked to see if they point to valid regions. Offsets that point to abnormal regions are recalculated and corrected. Finally, any missing header fields are added to ensure that the basic structure of the executable file conforms to the format specifications, resulting in a structurally complete and repaired executable file.
[0146] Step 32: When it is determined that the checksum and signature are missing in the repair executable file, the checksum and signature of the repair executable file are corrected to obtain the corrected executable file.
[0147] In this step, the checksum and signature fields in the repair executable file are checked to see if they are empty or invalid. If the checksum is missing, the original checksum field is cleared, and the consistency correction algorithm is re-executed on all bytes in the file except for the magic number byte sequence (i.e., the first 8 bytes of the memory block in the file). The calculation result is then filled back into the checksum field. If the signature is missing, the original signature field is cleared, and the consistency correction algorithm is re-executed on all bytes except for the magic number byte sequence to generate a hash value. The generated hash value result is then filled back into the signature field, resulting in the repaired executable file.
[0148] Specifically, step 32 can be implemented in the following ways:
[0149] Step 1: Clear the checksum field of the repair executable file, perform a consistency correction algorithm on the bytes in the repair executable file except for the magic number byte sequence, and fill the checksum field with the calculation result of the consistency correction algorithm to perform checksum correction on the repair executable file.
[0150] In this implementation, the checksum field at offsets 0x28-0x2B in the repair executable file is first located and cleared to zero to avoid interference from the original invalid value to the new calculation result. Then, starting from offset 0x08 in the repair executable file, all subsequent bytes of data are read, and the checksum of these bytes is calculated using a consistency correction algorithm. The calculated checksum value is written to the checksum field in little-endian format to complete the checksum correction.
[0151] For example, the consistency correction algorithm can be the Adler-32 checksum algorithm (Adler-32).
[0152] Step 2: Clear the signature field of the repaired executable file, re-execute the consistency correction algorithm on the bytes in the repaired executable file except for the magic number byte sequence, and fill the signature field with the calculation result of the consistency correction algorithm to perform signature correction on the repaired executable file.
[0153] Among them, the consistency correction algorithm can be the Secure Hash Algorithm 1 (SHA-1) algorithm.
[0154] In this implementation, the signature field at offsets 0x2C-0x4B in the executable file is first located and repaired. All 20 bytes of data in the signature field are cleared to zero, removing the original invalid signature information. Starting from offset 0x08, all bytes are read. The SHA-1 algorithm is used to fill, divide, and compress all bytes, ultimately generating a 160-bit hash value. Then, the hash value is written into the signature field in byte order to complete the signature correction.
[0155] Step 33: Generate an index table based on the corrected executable file to obtain the target executable file.
[0156] In this step, all data segments in the file are traversed first to obtain the starting offset, length, and type identifier of each segment. Then, according to the DEX format specification, this information is organized into a map item (map_item) structure array. The storage offset of the structure array in the file is calculated and updated to the file header. Finally, it is verified whether the offset recorded in the index table is consistent with the actual data segment position to ensure that the application can accurately locate each data segment through the index table when it runs and loads. After the index table is rebuilt, a target executable file with a complete structure, compliant format, and can be parsed normally is obtained.
[0157] The application unpacking method provided in this application first repairs valid executable files that do not conform to a preset format to obtain repaired executable files. This solves problems such as structural breaks and field anomalies that may occur when extracting files from memory, providing a data foundation for the subsequent generation of target executable files. Then, when it is determined that the checksum and signature are missing in the repaired executable file, the checksum and signature are corrected to obtain a corrected executable file, which improves the legality and credibility of the executable file. Finally, an index table is generated based on the corrected executable file to obtain the target executable file. This provides a core data foundation for the unpacking and reconstruction of applications and improves the accuracy of application unpacking.
[0158] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.
[0159] Figure 5 This is a schematic diagram of the structure of the application unpacking device provided in an embodiment of this application. Figure 5 As shown, the device includes:
[0160] Module 41 is used to obtain the memory segment of the target application;
[0161] Module 41 is also used to call the memory scan function to obtain memory blocks in the memory segment;
[0162] The determination module 42 is used to determine the data blocks that conform to the executable file format characteristics based on the data structure characteristics of the memory blocks, and to use the files corresponding to the data blocks as candidate executable files;
[0163] The determination module 42 is also used to process candidate executable files using a preset file discrimination model to obtain valid executable files;
[0164] Processing module 43 is used to repair valid executable files to obtain target executable files;
[0165] The determination module 42 is also used to obtain the unpacked application corresponding to the target application based on the target executable file and the target application.
[0166] In one possible implementation, the acquisition module 41 is specifically used for:
[0167] The script calls a preset function to enumerate the readable memory segments in the target application, thus obtaining the memory segments.
[0168] In one possible implementation, the determining module 42 is specifically used for:
[0169] Perform status checks on the data blocks to obtain candidate memory blocks;
[0170] Obtain the feature vectors of candidate memory blocks;
[0171] The feature vectors of candidate memory blocks are input into a preset file discrimination model to obtain the probability that a candidate memory block is an executable file;
[0172] When the probability that a candidate memory block is an executable file is greater than a preset threshold, the candidate memory block is determined to be a valid executable file;
[0173] The entire byte stream of a valid executable file is read using a remote procedure call memory read function.
[0174] In one possible implementation, the determining module 42 is specifically used for:
[0175] The status detection results are obtained by checking whether the preset bytes of the data block conform to the preset standard, whether the preset fields of the data block conform to the preset range, and whether the byte order label of the data block conforms to the preset format.
[0176] If the status detection results are all met, the data block is identified as a candidate memory block.
[0177] In one possible implementation, the processing module 43 is specifically used for:
[0178] Repair valid executable files that do not conform to the preset format to obtain repaired executable files;
[0179] When it is determined that the checksum and signature are missing in the repair executable file, the checksum and signature of the repair executable file are corrected to obtain the corrected executable file;
[0180] An index table is generated based on the corrected executable file, and the target executable file is obtained.
[0181] In one possible implementation, the processing module 43 is specifically used for:
[0182] Clear the checksum field of the repair executable file, perform a consistency correction algorithm on the bytes in the repair executable file except for the magic number byte sequence, and fill the checksum field with the calculation result of the consistency correction algorithm to perform checksum correction on the repair executable file;
[0183] The signature field of the repaired executable file is cleared. The consistency correction algorithm is re-executed on the bytes in the repaired executable file except for the magic number byte sequence. The calculation result of the consistency correction algorithm is then filled back into the signature field to perform signature correction on the repaired executable file.
[0184] In one possible implementation, the determining module 42 is specifically used for:
[0185] The target executable file and other resources in the target application are repackaged to obtain a package file; where other resources refer to other sub-sections in the target application besides the sub-sections contained in the target executable file.
[0186] The packaged file is re-signed using a custom keystore to obtain the unpacked application corresponding to the target application.
[0187] The apparatus provided in this application embodiment can be used to execute the determination method in any of the above embodiments. Its implementation principle and technical effect are similar, and will not be described again here.
[0188] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented in software via processing element calls, while others are implemented in hardware. Additionally, these modules can be fully or partially integrated together, or implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through the integrated logic circuits in the hardware of the processor element or through software instructions.
[0189] This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application, such as... As shown, the electronic device may include: a processor 51, a memory 52, and computer program instructions stored in the memory 52 and executable on the processor 51. When the processor 51 executes the computer program instructions, it implements the method provided in any of the foregoing embodiments.
[0190] Optionally, the various components of the electronic device can be connected via a system bus.
[0191] The memory 52 can be a separate storage unit or a storage unit integrated into the processor 51. The number of processors 51 can be one or more.
[0192] It should be understood that the processor 51 can be a Central Processing Unit (CPU), or other general-purpose processors 51, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor 51 can be a microprocessor 51, or any conventional processor 51. The steps of the method disclosed in this application can be directly manifested as being executed by the hardware processor 51, or being executed by a combination of hardware and software modules within the processor 51.
[0193] The system bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Memory 52 may include random access memory (RAM) 52, and may also include non-volatile memory (NVM) 52, such as at least one disk storage device 52.
[0194] All or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory 52. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned memory 52 (storage medium) includes: read-only memory 52 (ROM), RAM, flash memory 52, hard disk, solid-state hard disk, magnetic tape, floppy disk, optical disk, and any combination thereof.
[0195] The electronic device provided in this application embodiment can be used to execute the method provided in any of the above method embodiments. Its implementation principle and technical effect are similar, and will not be repeated here.
[0196] This application provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the above-described method.
[0197] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory, electrically erasable programmable read-only memory, erasable programmable read-only memory, programmable read-only memory, read-only memory, magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.
[0198] Optionally, a readable storage medium can be coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Alternatively, the readable storage medium can be an integral part of the processor. Both the processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components within the device.
[0199] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and the at least one processor can implement the above-described method when executing the computer program.
[0200] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.
Claims
1. A method for unpacking an application, characterized in that, include: Obtain the memory segment of the target application; Call the memory scan function to obtain the memory blocks in the memory segment; Based on the data structure characteristics of the memory block, data blocks that conform to the executable file format characteristics are identified, and the files corresponding to the data blocks are selected as candidate executable files. The candidate executable files are processed using a preset file discrimination model to obtain valid executable files; The valid executable file is repaired to obtain the target executable file; Based on the target executable file and the target application, an unpacked application corresponding to the target application is obtained.
2. The method according to claim 1, characterized in that, The acquisition of the target application's memory segment includes: The memory segments are obtained by enumerating readable memory segments in the target application through a pre-defined function called by the control script.
3. The method according to claim 1, characterized in that, The process of using a preset file discrimination model to process the candidate executable files to obtain valid executable files includes: Perform state detection on the data block to obtain candidate memory blocks; Obtain the feature vector of the candidate memory block; The feature vector of the candidate memory block is input into the preset file discrimination model to obtain the probability that the candidate memory block is an executable file; When the probability that the candidate memory block is an executable file is greater than a preset threshold, the candidate memory block is determined to be a valid executable file; The entire byte stream of the valid executable file is read using a remote procedure call memory read function.
4. The method according to claim 3, characterized in that, The step of performing state detection on the data block to obtain candidate memory blocks includes: The status detection results are obtained by detecting whether the preset bytes of the data block conform to the preset standard, whether the preset fields of the data block conform to the preset range, and whether the byte order label of the data block conforms to the preset format. When the status detection results are all met, the data block is determined as the candidate memory block.
5. The method according to claim 1, characterized in that, The process of repairing the valid executable file to obtain the target executable file includes: Repair the valid executable file that does not conform to the preset format to obtain a repaired executable file; When it is determined that the checksum and signature are missing in the repaired executable file, the checksum and signature are corrected in the repaired executable file to obtain the corrected executable file; An index table is generated based on the corrected executable file to obtain the target executable file.
6. The method according to claim 5, characterized in that, The process of performing verification code and signature correction on the repaired executable file to obtain a corrected executable file includes: The checksum field of the repair executable file is cleared, a consistency correction algorithm is executed on the bytes of the repair executable file except for the magic number byte sequence, and the calculation result of the consistency correction algorithm is backfilled into the checksum field to perform the checksum correction on the repair executable file; The signature field of the repaired executable file is cleared, the consistency correction algorithm is re-executed on the bytes of the repaired executable file except for the magic number byte sequence, and the calculation result of the consistency correction algorithm is backfilled into the signature field to perform the signature correction on the repaired executable file.
7. The method according to claim 1, characterized in that, The process of obtaining an unpacked application corresponding to the target application based on the target executable file and the target application includes: The target executable file and other resources in the target application are repackaged to obtain a packaged file; wherein, the other resources refer to other sub-sections in the target application besides the sub-sections contained in the target executable file; The packaged file is re-signed using a custom keystore to obtain the unpacked application corresponding to the target application.
8. An application unpacking device, characterized in that, include: The acquisition module is used to acquire the memory segment of the target application; The acquisition module is also used to call a memory scanning function to acquire memory blocks in the memory segment; The determination module is used to determine data blocks that conform to the executable file format characteristics based on the data structure characteristics of the memory blocks, and to use the files corresponding to the data blocks as candidate executable files; The determining module is further configured to process the candidate executable files using a preset file discrimination model to obtain valid executable files; The processing module is used to repair the valid executable file to obtain the target executable file; The determining module is further configured to obtain an unpacked application corresponding to the target application based on the target executable file and the target application.
9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.