Bytecode storage method, device and computer equipment for Android shelling machine

Abstract

The present invention relates to the field of bytecode unpacking and storage, and in particular to a bytecode storage method, device, and computer equipment for an Android unpacking machine. The method comprises the following steps: real-time monitoring of all applications in the system and pseudo-call dynamic class loading to generate bytecode structural feature information; identifying business modules based on the bytecode structural feature information and quantifying the module security sensitivity to obtain a security sensitivity quantified value for each business module; performing symmetric and obfuscated encryption on the bytecodes of multiple application business modules based on the security sensitivity quantified value of each business module to obtain a normalized module encryption code and an obfuscated encryption compression code; independently encapsulating the normalized module encryption code and the obfuscated encryption compression code one by one, and performing distributed storage to construct a distributed encryption unit storage structure. The present invention achieves complete and efficient unpacking and storage.

Description

Technical Field

[0001] The present invention relates to the field of bytecode unpacking and storage, and in particular to a bytecode storage method, device and computer equipment for an Android unpacking machine. Background Art

[0002] With the popularity of the Android system, the security and reversibility of applications have received increasing attention. As an important tool, Android depacketizers are widely used in security analysis, reverse engineering, and application debugging. Their functions are not limited to cracking software protection, but also involve the extraction and analysis of the bytecode inside the application. In this process, the effectiveness of the bytecode preservation method directly affects the quality and efficiency of subsequent analysis.

[0003] During the running process of Android applications, bytecode, as an intermediate representation, carries the logic and functions of the program. Traditional bytecode unpacking and preservation usually relies on static analysis tools. The process involves manual operation and multi-step conversion, which is easily limited by the operator's experience and tool efficiency. These methods often face the problems of inaccuracy and incompleteness when performing Android unpacking, especially when facing complex applications, resulting in the loss of important information or the inability to correctly parse it. Therefore, an efficient and intelligent Android unpacking bytecode preservation method is urgently needed. Summary of the Invention

[0004] In order to solve the above technical problems, the present invention proposes a bytecode storage method, device and computer equipment for an Android shelling machine to solve at least one of the above technical problems.

[0005] To achieve the above object, the present invention provides a bytecode storage method for an Android shelling machine, comprising the following steps:

[0006] Step S1: monitor all applications in the system in real time and perform pseudo-call dynamic class loading to generate bytecode structure feature information;

[0007] Step S2: Identify the business modules based on the bytecode structural feature information and quantify the module security sensitivity, thereby obtaining the security sensitivity quantification value of each business module;

[0008] Step S3: performing bytecode symmetric encryption and obfuscation encryption on multiple application business modules based on the security sensitive quantitative value of each business module, thereby obtaining normalized module encryption code and obfuscation encryption compression code;

[0009] Step S4: independently encapsulating the normalized module encryption code and the obfuscated encryption compression code one by one, and performing distributed storage to construct a distributed encryption unit storage structure;

[0010] Step S5: When the de-shelling instruction is obtained, the distributed encryption unit storage structure is decrypted and restored unit by unit, and the bytecode is merged and reconstructed to obtain the de-shelling and restored bytecode file;

[0011] Step S6: Make distortion optimization decisions on the unpacked and restored bytecode files, perform enhanced transfer learning, and build an intelligent bytecode unpacking model to complete the unpacking and restoration of the bytecode.

[0012] The present invention also provides a bytecode storage device for an Android shelling machine, comprising:

[0013] The class loading module is used to monitor all applications in the system in real time and perform pseudo-call dynamic class loading to generate bytecode structure feature information;

[0014] The sensitivity quantification module is used to identify business modules based on bytecode structural feature information and quantify module security sensitivity, thereby obtaining the security sensitivity quantification value of each business module;

[0015] The encoding and encryption module is used to perform bytecode symmetric encryption and obfuscation encryption on multiple application business modules based on the security sensitive quantitative value of each business module, thereby obtaining normalized module encryption code and obfuscation encryption compression code;

[0016] A distributed storage module is used to independently encapsulate the normalized module encryption code and the obfuscated encryption compression code one by one, and perform distributed storage to build a distributed encryption unit storage structure;

[0017] The de-shelling and restoration module is used to decrypt and restore the distributed encryption unit storage structure unit by unit when receiving the de-shelling instruction, and merge and reconstruct the bytecode to obtain the de-shelling and restoration bytecode file;

[0018] The distortion optimization module is used to make distortion optimization decisions for the unpacked and restored bytecode files, perform enhanced transfer learning, and build an intelligent bytecode unpacking model to complete the unpacking, restoration and storage of bytecodes.

[0019] The present invention also provides a computer device, comprising a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the steps of the bytecode saving method of the Android shelling machine described in any one of the above are implemented.

[0020] The beneficial effects of the present invention are specifically as follows: real-time monitoring of applications can help the system capture the dynamic behavior of applications and provide necessary information for subsequent security measures; pseudo-call dynamic class loading can generate bytecode structural feature information for subsequent business module identification and security sensitivity quantification; by identifying business modules and quantifying security sensitivity, the system can more accurately understand the security risk level of each module; the security sensitivity quantification value can be used for subsequent encryption and obfuscation decisions to improve the security of applications; encryption and obfuscation protect key modules of applications to prevent unauthorized access and reverse engineering; normalized module encryption and obfuscated encryption help enhance the security of applications and prevent information leakage or malicious tampering; distributed storage improves data security and reliability, prevents single point failures and data loss; constructing a distributed encryption unit storage structure helps manage and protect encrypted data, ensures security and integrity; distortion optimization improves the accuracy and efficiency of decryption and restoration, ensures the functional integrity of applications; and enhanced transfer learning helps the system continuously improve the intelligence level of bytecode unpacking and adapt to new security threats and attack methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A schematic flow chart of the steps of a bytecode storage method for an Android shelling machine according to the present invention;

[0022] Figure 2 Detailed implementation flow chart of step S1;

[0023] Figure 3 Detailed implementation flow chart of step S2;

[0024] Figure 4 Schematic diagram of the detailed implementation steps of step S3. DETAILED DESCRIPTION

[0025] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0026] This application example provides a bytecode storage method, device, and computer equipment for an Android sheller. The execution subjects of the bytecode storage method, device, and computer equipment for an Android sheller include, but are not limited to, mechanical equipment, data processing platforms, cloud server nodes, network upload devices, etc. equipped with the system, which can be regarded as general computing nodes of this application. The data processing platform includes, but is not limited to, at least one of an audio and image management system, an information management system, and a cloud data management system.

[0027] See also Figures 1 to 4 The present invention provides a bytecode storage method for an Android shelling machine, and the bytecode storage method for an Android shelling machine comprises the following steps:

[0028] Step S1: monitor all applications in the system in real time and perform pseudo-call dynamic class loading to generate bytecode structure feature information;

[0029] Step S2: Identify the business modules based on the bytecode structural feature information and quantify the module security sensitivity, thereby obtaining the security sensitivity quantification value of each business module;

[0030] Step S3: performing bytecode symmetric encryption and obfuscation encryption on multiple application business modules based on the security sensitive quantitative value of each business module, thereby obtaining normalized module encryption code and obfuscation encryption compression code;

[0031] Step S4: independently encapsulating the normalized module encryption code and the obfuscated encryption compression code one by one, and performing distributed storage to construct a distributed encryption unit storage structure;

[0032] Step S5: When the de-shelling instruction is obtained, the distributed encryption unit storage structure is decrypted and restored unit by unit, and the bytecode is merged and reconstructed to obtain the de-shelling and restored bytecode file;

[0033] Step S6: Make distortion optimization decisions on the unpacked and restored bytecode files, perform enhanced transfer learning, and build an intelligent bytecode unpacking model to complete the unpacking and restoration of the bytecode.

[0034] Real-time monitoring of applications can help the system capture the dynamic behavior of applications and provide necessary information for subsequent security measures. Pseudo-call dynamic class loading can generate bytecode structural feature information for subsequent business module identification and security sensitivity quantification. By identifying business modules and quantifying security sensitivity, the system can more accurately understand the security risk level of each module. The security sensitivity quantification value can be used for subsequent encryption and obfuscation decisions to improve the security of the application. Encryption and obfuscation protect the key modules of the application to prevent unauthorized access and reverse engineering. Normalized module encryption and obfuscation encryption help enhance the security of the application and prevent information leakage or malicious tampering. Distributed storage improves data security and reliability, prevents single point failures and data loss, and builds a distributed encryption unit storage structure to help manage and protect encrypted data, ensuring security and integrity. Distortion optimization improves the accuracy and efficiency of decryption and restoration, ensuring the functional integrity of the application. Strengthening transfer learning helps the system continuously improve the intelligence level of bytecode unpacking and adapt to new security threats and attack methods.

[0035] In the embodiment of the present invention, see Figure 1 , is a schematic flow chart of the steps of a bytecode storage method of an Android shelling machine of the present invention. In this example, the steps of the bytecode storage method of the Android shelling machine include:

[0036] Step S1: monitor all applications in the system in real time and perform pseudo-call dynamic class loading to generate bytecode structure feature information;

[0037] In this embodiment, we evaluate and select a suitable monitoring tool, such as Android Profiler, VisualVM, or a custom JavaAgent, ensure that the tool supports real-time monitoring of application performance indicators (such as CPU, memory, threads, etc.), deploy monitoring agents or scripts in the system to ensure that all target applications can be monitored, set monitoring parameters such as sampling frequency, monitoring indicators (CPU usage, memory occupancy, etc.) and data storage methods (such as memory, files, or databases), start the monitoring tool and start real-time data collection, store the collected data in a structured format (such as JSON, CSV) for subsequent analysis, and use Java's Instrumentation API or Android's Reflection API to collect data. The system is used to dynamically load the target class, write pseudo-call logic to call a specific method in the target application, trigger the loading of the class, capture the class loading event during the pseudo-call process to record the bytecode structure, use the bytecode analysis library (such as ASM, BCEL, or DexClassLoader) to analyze the loaded class, extract the structural features of each class, including class name, method, field, access modifier, inheritance relationship, etc., store the extracted bytecode structural feature information in a structured format (such as a database or JSON file) for subsequent analysis and processing, associate the real-time monitoring data with the bytecode structural feature information to form a comprehensive report, generate visual charts (such as class relationship diagrams, method call diagrams) to help understand the bytecode structure, and store the final report in a designated location for subsequent analysis and auditing.

[0038] Step S2: Identify the business modules based on the bytecode structural feature information and quantify the module security sensitivity, thereby obtaining the security sensitivity quantification value of each business module;

[0039] In this embodiment, the characteristics of the business module are defined, such as functional similarity, namespace, and dependencies between classes. A clustering algorithm (such as K-means, hierarchical clustering) or a rule-based method (such as regular expression matching) is used to identify the module. A graph analysis tool (such as NetworkX) is used to build a relationship graph between classes, identify groups of classes with similar functions, and use them as candidate sets for business modules. The identified business modules are classified and grouped according to functions, call relationships, or hierarchical structures. A unique identifier is assigned to each module, and the component classes and methods of the module are recorded. Quantitative standards for security sensitivity are defined, including: the importance of the module (such as the priority of the core business module); ), data processing sensitivity (such as user data, financial data), call frequency (such as the number of times the module is called), complexity (such as the number of methods in the module, the complexity of the dependency relationship), evaluate the security sensitivity of each business module one by one: analyze the importance of the module, sensitive data processing, call frequency and complexity, calculate the security sensitivity quantitative value of each module according to the pre-set standards, use the weighted average method to integrate various factors, generate the final security sensitivity quantitative value, store the business module information and its security sensitivity quantitative value in a database or structured file (such as JSON, CSV), and generate a report containing business module information and security sensitivity quantitative value to facilitate subsequent audit and analysis.

[0040] Step S3: performing bytecode symmetric encryption and obfuscation encryption on multiple application business modules based on the security sensitive quantitative value of each business module, thereby obtaining normalized module encryption code and obfuscation encryption compression code;

[0041] In this embodiment, a symmetric encryption algorithm (such as AES, DES, or ChaCha20) is selected to ensure its security and efficiency.

[0042] Select an obfuscation algorithm (such as control flow obfuscation, naming obfuscation, data obfuscation, etc.), and analyze the security-sensitive quantitative value of each business module: set a threshold, and decide whether to encrypt based on the quantitative value. For modules with high sensitivity, give priority to encryption and obfuscation; for modules with low sensitivity, consider reducing the encryption strength or choosing a simple obfuscation method. For modules that need to be encrypted, generate an encryption key: use a secure key generation algorithm (such as PBKDF2, bcrypt) to generate a strong key, and use the selected symmetric encryption algorithm to encrypt the module's bytecode: input the bytecode data into the encryption algorithm to generate the encrypted bytecode, ensure that abnormal situations are handled during the encryption process, record any errors, use the encrypted bytecode as input, and apply the selected obfuscation algorithm :Implement control flow obfuscation to increase the difficulty of reverse engineering by modifying the method call order and logic, implement naming obfuscation to replace class names, method names, and variable names with meaningless names, generate obfuscated encrypted compressed codes, ensure that the obfuscation process does not affect the functionality of the bytecode, and perform lossless compression on the encrypted and obfuscated bytecode (such as using Zlib or LZMA): Compression reduces storage space and improves data transmission efficiency, store the compressed bytecode code in a secure location (such as a database, cloud storage): ensure that the storage structure is easily accessible and assign a unique identifier to each module, record the encryption information of each module (such as encryption algorithm, key management method, obfuscation strategy) in the log, and generate a report containing encryption and obfuscation code information for subsequent auditing and analysis.

[0043] Step S4: independently encapsulating the normalized module encryption code and the obfuscated encryption compression code one by one, and performing distributed storage to construct a distributed encryption unit storage structure;

[0044] In this embodiment, a compressed file format (such as ZIP, TAR) or a custom format is selected, and metadata storage is ensured to be supported in the selected format in order to record relevant information of the encoding (such as module name, encryption type, version number, etc.). The encrypted encoding and obfuscated encrypted compressed encoding of all normalized modules are traversed, and a separate package is created for each encoding: the encapsulation logic is implemented using a programming language (such as Python or Java), and the encoding and its metadata are written to the encapsulation file. Data integrity verification is ensured during the encapsulation process (such as using SHA-256 hashing). A distributed storage system (such as HDFS, Amazon S3, Ceph, etc.) is evaluated and selected to ensure that it supports high availability, data redundancy, and scalability, and how to organize storage is determined. For example, group the coding units by module name, encryption type, or creation time, design redundancy and backup strategies to ensure data security and recoverability, write upload scripts, use APIs (such as AWS SDK, Hadoop API, etc.) to upload each packaged file to distributed storage, perform data integrity verification during the upload process to ensure that each file is uploaded correctly, configure monitoring tools (such as Prometheus, Grafana) to monitor the status, storage capacity, and access frequency of storage nodes, set up alarm mechanisms to promptly detect and handle problems in the storage system, regularly back up the coding units in distributed storage to reduce the risk of data loss, and develop recovery processes to ensure that data can be quickly restored in the event of a failure.

[0045] Step S5: When the de-shelling instruction is obtained, the distributed encryption unit storage structure is decrypted and restored unit by unit, and the bytecode is merged and reconstructed to obtain the de-shelling and restored bytecode file;

[0046] In this embodiment, the system is monitored or monitored to receive the unpacking instruction, which is implemented through a message queue, Webhook or other communication mechanism to confirm the validity of the unpacking instruction and record the source and time of the instruction for subsequent audit. The distributed storage system is accessed using an appropriate API or client (such as AWSSDK, Hadoop client). Based on the information in the unpacking instruction, the specific coding units that need to be decrypted are determined, and these units are extracted one by one. For each extracted encryption unit, the previously generated encryption key and the selected symmetric encryption algorithm (such as AES) are used to decrypt: the decryption function is called, the encrypted bytecode is input, and the restored bytecode file is generated. Exception handling is ensured during the decryption process, and any decryption failure is recorded. All restored bytecode files are collected and organized according to logical relationships, which includes: determining the relationships between classes. Dependencies are grouped by modules or functions, and merged using bytecode processing tools (such as ASM, Javassist, and DexClassLoader): All restored bytecode files are merged to ensure that the definitions of classes and methods do not conflict, and a new merged bytecode file is generated to ensure that its format is complete and executable. The merged bytecode is verified using a bytecode verification tool (such as JavaClassFileValidator) to check whether it complies with the bytecode specification. Simple test cases are run to ensure that the merged bytecode can run normally in the expected environment. The merged bytecode file is saved to a specified directory or storage system and assigned a unique identifier. Each step of the merge process (such as file name, path, processing time, success / failure status) is recorded for subsequent auditing and analysis.

[0047] Step S6: Make distortion optimization decisions on the unpacked and restored bytecode files, perform enhanced transfer learning, and build an intelligent bytecode unpacking model to complete the unpacking and restoration of the bytecode.

[0048] In this embodiment, the types and characteristics of distortion are defined, such as structural distortion (such as missing classes and methods) and functional distortion (such as logical errors), and optimization standards are formulated, such as improving code readability, reducing redundancy, and restoring original logic. The bytecode files restored after decompression are analyzed to identify the distorted parts: static analysis tools (such as ProGuard and Soot) are used to check the bytecode structure and identify potential problems. According to the defined optimization standards, distortion optimization strategies are formulated: for example, for missing methods, implementations are inferred based on existing call relationships; for redundant codes, code streamlining techniques are used for optimization; historical bytecode distortion cases and corresponding optimization decisions are collected, a dataset for training is constructed, and a suitable reinforcement learning algorithm (such as DQN and PPO) is selected for optimizing the decision-making process, including information such as the structural characteristics of the bytecode and the distortion type. According to the optimized effects (such as code running efficiency, reliability, etc.), the optimization strategy is optimized. Readability) gives positive or negative rewards, and uses the collected data to train the model: During the training process, the model continuously tries and adjusts to learn the best optimization strategy under different distortion conditions. The test set is used to verify the optimization effect of the model to ensure that it can effectively reduce distortion and improve bytecode quality. The model parameters and training process are adjusted according to the evaluation results to improve the accuracy and efficiency of the model. The trained model is integrated into the automated unpacking tool to form a complete unpacking and restoration process. When the user submits the bytecode file, the model automatically identifies the distortion and makes optimization suggestions, automatically applies the optimization strategy, and generates the final restored bytecode file. The decisions and results of the optimization process are recorded and a feedback mechanism is established. The decision process, optimization results and effects of each unpacking and restoration are recorded in the database for subsequent analysis. A feedback mechanism is established to allow users to evaluate the optimization suggestions of the model to further improve model performance.

[0049] In this embodiment, refer to Figure 2 , is a flowchart of the detailed implementation steps of step S1. In this embodiment, the detailed implementation steps of step S1 include:

[0050] Step S11: monitor all applications in the system in real time and extract all application operation monitoring data;

[0051] Step S12: performing a preset target application judgment on all application operation monitoring data, and extracting the target application if the judgment is successful;

[0052] Step S13: Make a pseudo call to the target application and extract the APK file to obtain the APK file of the application;

[0053] Step S14: Dynamically load the APK file of the application and extract all dex bytecode files;

[0054] Step S15: bytecode structure analysis is performed on all dex bytecode files to generate bytecode structure feature information.

[0055] In this embodiment, a suitable monitoring tool or framework (such as Android Studio Profiler, Gradle plug-in, or custom script) is selected to monitor the running status of all applications in the system, and the monitoring tool is used to collect the runtime information of the application, including CPU usage, memory usage, thread status, network activity, etc., and the monitoring interval is set. The data is extracted regularly and recorded in a log file or database. All the extracted application operation monitoring data is stored in a structured format (such as JSON, CSV or database) for subsequent analysis, and the standards of the target program to be monitored (such as a specific package name, memory usage threshold, CPU occupancy, etc.) are determined. The stored monitoring data is traversed and analyzed using a programming language (such as Python, Java) to determine which programs meet the preset goals. For example, conditional statements are used to filter out applications that meet specific conditions. The relevant information of the target application that is successfully judged (such as package name, process ID, etc.) is extracted and stored in a new data structure for subsequent processing. The target application is pseudo-called using Android's Instrumentation API or Reflection mechanism. The purpose of the pseudo-call is to simulate the running environment of the application. During the pseudo-call process, obtain the target application's APK file path, extract the APK file to a specified directory using the file system API, save the extracted APK file to local storage or a database, and record relevant information (such as the file path and version number). Prepare the runtime environment to ensure that classes in the APK can be dynamically loaded. Use Android's ClassLoader class to decompress the extracted APK file and obtain the classes.dex file. The APK file is essentially a ZIP file. Use a ZIP decompression tool to decompress it, ensuring that all DEX files are extracted. If multiple DEX files exist, store the extracted DEX bytecode files in a specified directory for subsequent parsing and analysis. Select an appropriate bytecode parsing library (such as smali, baksmali, dex-tools) or a custom parser to parse the DEX files. Use the selected tool to parse all DEX bytecode files, extracting structural information such as classes, methods, and fields. Record the structural features of the bytecode, such as method call relationships, class inheritance relationships, and field types. Store the parsed bytecode structural feature information in a structured format (such as JSON, XML, or a database) for subsequent analysis and processing.

[0056] In this embodiment, the specific steps of step S15 are:

[0057] Traverse all dex bytecode files and extract all classes;

[0058] Parse class information for all classes and extract basic definition information for each class;

[0059] Perform class member variable analysis on all dex bytecode files to generate class member variable data;

[0060] Extract member methods from all dex bytecode files to obtain class member methods;

[0061] The bytecode deep structural feature mining is performed on the basic definition information, class member variable data and class member methods of each class to generate bytecode structural feature information.

[0062] In this embodiment, ensure that the extracted DEX bytecode file is available, usually classes.dex or other DEX files, and use bytecode parsing tools (such as smali, baksmali, dexlib2, dexlib3, etc.) to traverse the classes. These tools provide APIs or command line interfaces to read DEX files and traverse the classes therein. Write scripts (using languages ​​such as Java and Python) to call the parsing library and read the class information in each DEX file. For example, use the DexReader class in dexlib2 to read the names and definitions of all classes to confirm Determine the basic definition information of the class that needs to be extracted, including class name, package name, parent class, interface, access modifiers (such as public, private), and use parsing tools to extract the basic definition information of each class traversed. For example, use smali's API to obtain the class modifiers and parent class information, and store the extracted basic definition information (such as class name, package name, parent class, interface, etc.) in a structured format (such as JSON, XML or database). Determine the member variable information that needs to be analyzed, including variable name, type, access modifier, traverse the member variables of each class, and use parsing tools to extract all members. For example, use the dexlib library to read the field list of the class and extract the name and type of each field. Store the member variable data of all classes in a structured format, ensuring that information such as variable name, type and modifiers are included. Determine the method information that needs to be extracted, including method name, parameter type, return type, and access modifiers. Perform method traversal on each class and use parsing tools to extract information about all member methods. For example, use the method list interface in dexlib to extract the name, parameters and return type of each method. Store the extracted member method data in a structured format for subsequent analysis. Determine the bytecode structural features that need to be mined, including class inheritance relationships, method call relationships and member variable usage. Based on the extracted class definition information, member variable data and method data, analyze the relationship between classes. For example, build a class inheritance graph and method call graph. Analyze the scope and access frequency of member variables. Organize the mined bytecode structural feature information into a structured format (such as JSON, XML or database) for subsequent analysis and visualization. Generate a final bytecode structural feature information report containing all class definitions, member variables and method features to facilitate subsequent analysis and research.

[0063] In this embodiment, refer to Figure 3 , is a flowchart of the detailed implementation steps of step S2. In this embodiment, the detailed implementation steps of step S2 include:

[0064] Step S21: performing a structural topology analysis on the bytecode structural feature information to obtain bytecode structural topology data;

[0065] Step S22: identifying business modules based on the bytecode structure topology data, and extracting multiple application business modules;

[0066] Step S23: Calculating the operation call frequency of multiple application business modules to obtain the operation call frequency of each module;

[0067] Step S24: performing business logic analysis on multiple application business modules to generate business logic for each module;

[0068] Step S25: quantify the module security sensitivity of each module based on the operation call frequency of each module and the business logic of each module, thereby obtaining a security sensitivity quantification value of each business module.

[0069] In this embodiment, it is ensured that the extracted bytecode structural feature information is available, including class definitions, member variables, method information and their relationships. An appropriate topology analysis tool or library (such as NetworkX, Graphviz, etc.) is selected to construct and analyze the structural topology. A topology graph is constructed: the bytecode structural feature information is converted into a graph structure: nodes represent classes, and edges represent relationships between classes (such as inheritance, method calls, dependencies, etc.). A programming language (such as Python) is used to implement graph construction and relationship representation. A topological analysis is performed on the graph to extract structural features (such as degree centrality, clustering coefficient, etc.). Bytecode structural topology data is generated and stored in a structured format (such as JSON, XML or a database) to facilitate subsequent analysis. The identification criteria for business modules are defined, for example, based on the calling relationships between functions, namespaces or classes. The business modules are analyzed using topological data: classes with similar functions or mutual dependence are identified as a business module. Classes are grouped using a clustering algorithm (such as K-means or hierarchical clustering). The identified multiple application business module information is stored in a structured format, including module names, included classes, etc. Applications are collected. Runtime call data ensures that call information for each module can be obtained. For each business module, calculate its call frequency during application operation: use log analysis tools (such as ELKStack) to analyze call records and extract frequencies, record the number of times each module is called, and determine the business logic features that need to be analyzed, such as input-output relationships, execution paths, key algorithms, etc. Perform logical analysis on the business modules of multiple applications: combine class methods and member variables to draw flowcharts or call graphs to analyze the logical flow of the modules. Use tools (such as UML tools and flowchart software) to help visualize and understand business logic. Store the business logic analysis results of each module in a structured format, including input and output, execution paths, and key logic. Determine quantitative standards for security sensitivity, such as those based on call frequency, business logic complexity, data processing sensitivity, etc. Quantify the security sensitivity of each business module: combine the module's runtime call frequency and business logic characteristics to calculate the security sensitivity quantitative value. Use weighted methods, such as the weighted average of frequency and complexity. Store the security sensitivity quantitative value of each business module in a database and generate a report to facilitate subsequent security analysis and risk assessment.

[0070] In this embodiment, refer to Figure 4 , is a flowchart of the detailed implementation steps of step S3. In this embodiment, the detailed implementation steps of step S3 include:

[0071] Step S31: classifying multiple application business modules into core business modules based on the security sensitivity quantitative value of each business module to obtain normalized business modules and core business modules;

[0072] Step S32: performing symmetrical encryption on the bytecode of the normalized service module to obtain the normalized module encryption code;

[0073] Step S33: performing lossless compression encoding on the core business module to obtain module compression encoding;

[0074] Step S34: Obtain a random filling value, and perform obfuscated encryption on the module compression code based on the random filling value, thereby obtaining an obfuscated encrypted compression code.

[0075] In this embodiment, the security sensitivity quantitative value of each business module is collected, and a classification standard is defined. For example, a threshold is set, and modules exceeding this value are regarded as core business modules. All business modules are traversed and classified according to their security sensitivity quantitative values: if the quantitative value is higher than the set threshold, it is marked as a core business module; otherwise, it is marked as a normalized business module. A suitable symmetric encryption algorithm (such as AES, DES, etc.) is selected to ensure that the algorithm meets the security standards. The bytecode of the normalized business module is symmetrically encrypted: a key is generated to ensure the secure storage and management of the key. The bytecode of the normalized module is encrypted using the selected encryption algorithm. The encrypted bytecode (normalized module encrypted code) is stored in a safe place to ensure access at any time. A suitable lossless compression algorithm (such as Zlib, LZ77, L ZMA, etc.), to ensure that data is not lost during the compression process, and perform lossless compression on the bytecode of the core business module: use the selected compression algorithm to compress the bytecode of the core module to ensure that the original bytecode can be completely restored after compression, generate random filling values, and use a cryptographically secure random number generator to ensure the strength of randomness. Based on the generated random filling value, the module compression code is obfuscated and encrypted: combining the compression code and the random filling value, use an appropriate obfuscation algorithm (such as XOR obfuscation, permutation encryption, etc.) to process the compression code, increase the complexity of the compression code, and make it more difficult to be reverse analyzed, store the obfuscated encrypted compression code (obfuscated encrypted compression code) in a safe place for subsequent use, and store the obfuscated encrypted compression code (obfuscated encrypted compression code) in a safe place for subsequent use.

[0076] In this embodiment, step S4 includes the following steps:

[0077] Step S41: independently encapsulating the normalized module encryption code and the obfuscated encryption compression code one by one, thereby obtaining a plurality of encryption code units;

[0078] Step S42: marking the plurality of encryption code units with sequential numbers, thereby obtaining encryption code marking units;

[0079] Step S43: Distributed storage of the encrypted code marking units to construct a distributed encryption unit storage structure;

[0080] Step S44: Analyze the dynamic running environment changes of the target application to obtain the running environment change characteristics;

[0081] Step S45: Dynamically adjust the distributed storage structure of the distributed encryption unit based on the characteristics of the operating environment changes, thereby constructing a dynamic storage adjustment strategy.

[0082] In this embodiment, ensure that the generated normalized module encryption code and obfuscated encryption compression code are available, prepare for independent packaging, write scripts or use tools to independently package each encryption code: package each encryption code into an independent unit, use a container format (such as ZIP, TAR) or a custom format, each packaging unit should contain metadata (such as version, module identifier, encryption type, etc.), store the metadata and content of each encryption code unit in a database or structured file for subsequent management, design a marking system, determine the format and rules of the marking, such as using UUID or sequential numbering to identify each encryption code unit, mark each encryption code unit with a sequential number: traverse all encryption code units, assign a unique identifier to each unit, associate the identifier with the corresponding encryption code unit, select a suitable distributed storage system (such as HDFS, Amazon S3, Ceph, etc.), ensure that it supports high availability and data redundancy, design the structure of distributed storage, determine data sharding and storage strategies, such as sharding storage by module or encryption tag, Upload the encrypted coding marking unit to the distributed storage system: Write an upload script to ensure that each encrypted coding unit is stored in the corresponding distributed node according to the label, ensure data integrity verification during the storage process, select appropriate monitoring tools (such as Prometheus, Nagios, Zabbix, etc.) to collect operating environment indicator data, collect environmental variable change data during the operation of the target application, including CPU usage, memory usage, network latency, etc., analyze the collected data, and extract the characteristics of the operating environment changes. For example, identify peak load periods and monitor abnormal changes (such as sudden increases in memory usage). Design dynamic storage adjustment strategies based on the changing characteristics of the operating environment. For example, increase the distribution of data copies during high loads and adjust the read load of storage nodes based on access frequency. Write scripts or use automated tools to implement dynamic storage adjustments based on the changing characteristics of the operating environment: monitor environmental change data, adjust the distribution and load of storage nodes in real time, and record the implementation of dynamic storage adjustment strategies in logs for subsequent analysis and optimization.

[0083] In this embodiment, step S5 includes the following steps:

[0084] Step S51: When the shelling instruction is obtained, the distributed encryption unit storage structure is decomposed into units to extract each encryption code unit;

[0085] Step S52: decrypting and restoring each encrypted coding unit one by one to generate a restored bytecode file;

[0086] Step S53: tracing the original file source of the restored bytecode file to obtain the restored bytecode location data;

[0087] Step S54: Based on the restored bytecode position data, the restored bytecode file and all dex bytecode files are bytecode merged and reconstructed to obtain the unpacked restored bytecode file.

[0088] In this embodiment, it is ensured that the system receives the unpacking instruction, which is a signal from the security audit or dynamic analysis tool, indicating that the encrypted coding unit needs to be decrypted and restored, access the distributed encryption unit storage structure, use the appropriate API or storage client (such as HDFS client, S3API, etc.) to obtain the stored encryption coding unit list, traverse each encryption coding unit, and extract its content: use the tag information to download the corresponding encryption coding unit from the distributed storage on demand, store each unit in a local temporary directory, and prepare for subsequent processing, ensure that the selected decryption algorithm is consistent with the previous encryption algorithm, such as AES or DES, and decrypt each extracted encryption coding unit: use the generated key and the selected decryption algorithm to decrypt the encryption coding unit, and generate the corresponding restored bytecode file after decryption to ensure integrity, store the restored bytecode file locally, and record the name, path and corresponding original encryption coding unit of each file, select a suitable file tracing tool (such as f ind command, file system index, etc.) or build a custom script to locate the original file location and perform traceability analysis on the restored bytecode file: analyze the metadata of the restored bytecode file, extract its creation time, modification time, and other characteristic information, search for the original file in the file system based on the characteristic information, record the original location data of the restored bytecode file in a database or log for subsequent verification and comparison, collect the restored bytecode file and all DEX bytecode files, prepare for merging, and use bytecode processing tools (such as dex-tools, smali / baksmali) to merge and reconstruct the bytecode files: merge the restored bytecode file with the DEX bytecode file as needed to ensure that the method and class definitions do not conflict, generate a new merged bytecode file, ensure its format is complete and runs normally, save the final unpacked restored bytecode file to the specified directory, and record its metadata (such as file name, generation time, included classes, etc.).

[0089] In this embodiment, step S6 includes the following steps:

[0090] Step S61: performing restoration distortion analysis on the de-shelled bytecode file and extracting the bytecode restoration distortion part;

[0091] Step S62: performing distortion optimization decision on the bytecode restoration distortion part and constructing a bytecode distortion optimization strategy;

[0092] Step S63: Perform enhanced transfer learning on the dynamic storage adjustment strategy and the bytecode distortion optimization strategy, and build an intelligent bytecode unpacking model to complete the bytecode unpacking, restoration and storage operation.

[0093] In this embodiment, a suitable analysis tool (such as JavaDecompiler, JEBDecompiler or a custom bytecode analyzer) is selected to analyze the restored bytecode file, analyze the bytecode file restored by unpacking, and identify the distorted part: the distorted part usually includes incomplete class definition, missing method implementation or wrong bytecode instruction, and use the tool to generate a visual diagram of the bytecode structure to help identify abnormal structure, extract the identified distorted part, and record its specific location and content for subsequent optimization, determine the standard for optimizing bytecode distortion, such as restoring integrity, improving readability or reducing redundancy, and formulate an optimization strategy for the extracted distorted part: for example, use static analysis technology (such as data flow analysis, control flow analysis) to infer missing method implementation, adopt template matching or pattern recognition method to identify common distortion patterns, and provide repair suggestions, and optimize the distorted part according to the optimization strategy. Modify and repair, gradually apply the optimization strategy, record the changes at each step, and evaluate its effect to ensure that the optimized bytecode can run normally and its functions are consistent with the original logic. Collect data related to the dynamic storage adjustment strategy and bytecode distortion optimization strategy, including historical optimization cases, environmental change characteristics and optimization effects, select appropriate reinforcement learning algorithms (such as DeepQ-Learning, ProximalPolicyOptimization) for model training, use distortion optimization decisions and storage adjustment strategies as state inputs, and optimization effects as reward signals. Through training, enable the model to learn the best decision-making strategies in different situations, verify the performance of the intelligent bytecode unpacking model on the test set, ensure that it can effectively perform distortion optimization and storage adjustment, adjust model parameters according to the verification results, optimize the learning process, and save the trained intelligent bytecode unpacking model and its parameters for subsequent use and deployment.

[0094] In this embodiment, a bytecode storage device for an Android shelling machine is also provided, including:

[0095] The class loading module is used to monitor all applications in the system in real time and perform pseudo-call dynamic class loading to generate bytecode structure feature information;

[0096] The sensitivity quantification module is used to identify business modules based on bytecode structural feature information and quantify module security sensitivity, thereby obtaining the security sensitivity quantification value of each business module;

[0097] The encoding and encryption module is used to perform bytecode symmetric encryption and obfuscation encryption on multiple application business modules based on the security sensitive quantitative value of each business module, thereby obtaining normalized module encryption code and obfuscation encryption compression code;

[0098] A distributed storage module is used to independently encapsulate the normalized module encryption code and the obfuscated encryption compression code one by one, and perform distributed storage to build a distributed encryption unit storage structure;

[0099] The de-shelling and restoration module is used to decrypt and restore the distributed encryption unit storage structure unit by unit when receiving the de-shelling instruction, and merge and reconstruct the bytecode to obtain the de-shelling and restoration bytecode file;

[0100] The distortion optimization module is used to make distortion optimization decisions for the unpacked and restored bytecode files, perform enhanced transfer learning, and build an intelligent bytecode unpacking model to complete the unpacking, restoration and storage of bytecodes.

[0101] The present invention also provides a computer device, comprising a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the steps of the bytecode saving method of the Android shelling machine described in any one of the above are implemented.

[0102] Those skilled in the art will clearly understand that for the convenience and brevity of description, the specific working processes of the above-described systems, systems and units refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0103] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it is stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution is embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media for storing program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0104] The present invention is therefore intended to be illustrative and non-restrictive in all respects, with the scope of the invention being defined by the appended claims rather than the foregoing description, and all changes that come within the meaning and range of equivalents of the application documents are intended to be embraced within the present invention.

[0105] The foregoing description is intended only to provide specific embodiments of the present invention, which are intended to enable those skilled in the art to understand and implement the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not intended to be limited to the embodiments shown herein, but is to be construed in the widest manner consistent with the principles and novel features disclosed herein.

Claims

1. A bytecode storage method for an Android shelling machine, characterized in that: The following steps are involved: Step S1: monitor all applications in the system in real time and perform pseudo-call dynamic class loading to generate bytecode structure feature information; Step S2: Identify the business modules based on the bytecode structural feature information and quantify the module security sensitivity, thereby obtaining the security sensitivity quantification value of each business module; Step S3: performing bytecode symmetric encryption and obfuscation encryption on multiple application business modules based on the security sensitive quantitative value of each business module, thereby obtaining normalized module encryption code and obfuscation encryption compression code; Step S4: independently encapsulating the normalized module encryption code and the obfuscated encryption compression code one by one, and performing distributed storage to construct a distributed encryption unit storage structure; Step S5: When the de-shelling instruction is obtained, the distributed encryption unit storage structure is decrypted and restored unit by unit, and the bytecode is merged and reconstructed to obtain the de-shelling and restored bytecode file; Step S6: Make distortion optimization decisions on the unpacked and restored bytecode files, perform enhanced transfer learning, and build an intelligent bytecode unpacking model to complete the unpacking and restoration of the bytecode.

2. The bytecode storage method of the Android shelling machine according to claim 1, wherein The specific steps of step S1 are: Step S11: monitor all applications in the system in real time and extract all application operation monitoring data; Step S12: performing a preset target application judgment on all application operation monitoring data, and extracting the target application if the judgment is successful; Step S13: Make a pseudo call to the target application and extract the APK file to obtain the APK file of the application; Step S14: Dynamically load the APK file of the application and extract all dex bytecode files; Step S15: bytecode structure analysis is performed on all dex bytecode files to generate bytecode structure feature information.

3. The bytecode storage method of the Android shelling machine according to claim 2, wherein The specific steps of step S15 are: Traverse all dex bytecode files and extract all classes; Parse class information for all classes and extract basic definition information for each class; Perform class member variable analysis on all dex bytecode files to generate class member variable data; Extract member methods from all dex bytecode files to obtain class member methods; The bytecode deep structural feature mining is performed on the basic definition information, class member variable data and class member methods of each class to generate bytecode structural feature information.

4. The bytecode storage method of the Android shelling machine according to claim 1, wherein The specific steps of step S2 are: Step S21: performing a structural topology analysis on the bytecode structural feature information to obtain bytecode structural topology data; Step S22: identifying business modules based on the bytecode structure topology data, and extracting multiple application business modules; Step S23: Calculating the operation call frequency of multiple application business modules to obtain the operation call frequency of each module; Step S24: performing business logic analysis on multiple application business modules to generate business logic for each module; Step S25: quantify the module security sensitivity of each module based on the operation call frequency of each module and the business logic of each module, thereby obtaining a security sensitivity quantification value of each business module.

5. The bytecode storage method of the Android shelling machine according to claim 1, wherein The specific steps of step S3 are: Step S31: classifying multiple application business modules into core business modules based on the security sensitivity quantitative value of each business module to obtain normalized business modules and core business modules; Step S32: performing symmetrical encryption on the bytecode of the normalized service module to obtain the normalized module encryption code; Step S33: performing lossless compression encoding on the core business module to obtain module compression encoding; Step S34: Obtain a random filling value, and perform obfuscated encryption on the module compression code based on the random filling value, thereby obtaining an obfuscated encrypted compression code.

6. The bytecode storage method of the Android shelling machine according to claim 1, wherein: The specific steps of step S4 are: Step S41: independently encapsulating the normalized module encryption code and the obfuscated encryption compression code one by one, thereby obtaining a plurality of encryption code units; Step S42: marking the plurality of encryption code units with sequential numbers, thereby obtaining encryption code marking units; Step S43: Distributed storage of the encrypted code marking units to construct a distributed encryption unit storage structure; Step S44: Analyze the dynamic running environment changes of the target application to obtain the running environment change characteristics; Step S45: Dynamically adjust the distributed storage structure of the distributed encryption unit based on the characteristics of the operating environment changes, thereby constructing a dynamic storage adjustment strategy.

7. The bytecode storage method of the Android shelling machine according to claim 1, wherein: The specific steps of step S5 are: Step S51: When the shelling instruction is obtained, the distributed encryption unit storage structure is decomposed into units to extract each encryption code unit; Step S52: decrypting and restoring each encrypted coding unit one by one to generate a restored bytecode file; Step S53: tracing the original file source of the restored bytecode file to obtain the restored bytecode location data; Step S54: Based on the restored bytecode position data, the restored bytecode file and all dex bytecode files are bytecode merged and reconstructed to obtain the unpacked restored bytecode file.

8. The bytecode storage method of the Android shelling machine according to claim 1, wherein: The specific steps of step S6 are: Step S61: performing restoration distortion analysis on the de-shelled bytecode file and extracting the bytecode restoration distortion part; Step S62: performing distortion optimization decision on the bytecode restoration distortion part and constructing a bytecode distortion optimization strategy; Step S63: Perform enhanced transfer learning on the dynamic storage adjustment strategy and the bytecode distortion optimization strategy, and build an intelligent bytecode unpacking model to complete the bytecode unpacking, restoration and storage operation.

9. A bytecode storage device for an Android shelling machine, characterized in that: The bytecode storage method for executing the Android shelling machine according to claim 1 comprises: The class loading module is used to monitor all applications in the system in real time and perform pseudo-call dynamic class loading to generate bytecode structure feature information; The sensitivity quantification module is used to identify business modules based on bytecode structural feature information and quantify module security sensitivity, thereby obtaining the security sensitivity quantification value of each business module; The encoding and encryption module is used to perform bytecode symmetric encryption and obfuscation encryption on multiple application business modules based on the security sensitive quantitative value of each business module, thereby obtaining normalized module encryption code and obfuscation encryption compression code; A distributed storage module is used to independently encapsulate the normalized module encryption code and the obfuscated encryption compression code one by one, and perform distributed storage to build a distributed encryption unit storage structure; The de-shelling and restoration module is used to decrypt and restore the distributed encryption unit storage structure unit by unit when receiving the de-shelling instruction, and merge and reconstruct the bytecode to obtain the de-shelling and restoration bytecode file; The distortion optimization module is used to make distortion optimization decisions for the unpacked and restored bytecode files, perform enhanced transfer learning, and build an intelligent bytecode unpacking model to complete the unpacking, restoration and storage of bytecodes.

10. A computer device comprising a memory and a processor, wherein a computer program is stored in the memory, wherein: When the processor executes the computer program, the steps of the bytecode storage method of the Android shelling machine described in any one of claims 1 to 8 are implemented.

Images