Byte code storage method and device of Android huller and computer equipment

Abstract

The invention relates to the field of byte code unshelling storage, in particular to a byte code storage method and device of an Android unshelling machine and computer equipment. The method comprises the following steps: monitoring all application programs in a system in real time, and carrying out pseudo-call dynamic class loading to generate byte code structure feature information; performing service module identification on the byte code structure feature information, and performing module security sensitivity quantification so as to obtain a security sensitivity quantized value of each service module; based on the security sensitive quantized value of each service module, performing byte code symmetric encryption and confusion encryption on the multiple application program service modules so as to obtain a normalized module encryption code and a confusion encryption compression code; and carrying out code-by-code independent packaging processing on the normalized module encryption code and the confusion encryption compression code, and carrying out distributed storage so as to construct a distributed encryption unit storage structure. According to the invention, complete and efficient shelling preservation is realized.

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 of an Android unpacking machine. Background Art

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

[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, and 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 inaccurate and incomplete problems when performing Android unpacking, especially when facing complex applications, resulting in the loss of important information or failure to parse correctly. Therefore, there is an urgent need for an efficient and intelligent Android unpacking bytecode preservation method. 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 of 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: 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 structure feature information, and quantify the module security sensitivity, so as to obtain 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 encapsulate the normalized module encryption codes and the obfuscated encryption compression codes one by one, and perform distributed storage to construct a distributed encryption unit storage structure; Step S5: when the shelling instruction is obtained, the distributed encryption unit storage structure is decrypted and restored unit by unit, and the bytecode is merged and reconstructed, so as to obtain the shelling and restoration 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.

[0006] The present invention also provides a bytecode storage device for an Android shelling machine, comprising: 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 the business module based on the bytecode structure feature information and quantify the module security sensitivity, thereby obtaining the security sensitivity quantification value of each business module; The coding 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, so as to obtain normalized module encryption code and obfuscation encryption compression code; A distributed storage module is used to independently encapsulate the normalized module encryption codes and obfuscated encryption compression codes one by one, and perform distributed storage to build a distributed encryption unit storage structure; The shelling and restoring module is used to decrypt and restore the distributed encryption unit storage structure unit by unit when receiving the shelling instruction, and merge and reconstruct the bytecode to obtain the shelling and restoring bytecode file; The distortion optimization module is used to make distortion optimization decisions for the unpacking and restoration of bytecode files, and to perform enhanced transfer learning to build an intelligent bytecode unpacking model to complete the unpacking, restoration and preservation of bytecodes.

[0007] The present invention also provides a computer device, including 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.

[0008] 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 structure 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 obfuscation encryption help enhance the security of applications and prevent information leakage or malicious tampering; distributed storage improves data security and reliability and prevents single point failures and data loss; building a distributed encryption unit storage structure helps manage and protect encrypted data and ensure security and integrity; distortion optimization improves the accuracy and efficiency of decryption and restoration and ensures the functional integrity of applications; and enhanced transfer learning helps the system continuously improve the level of intelligence for bytecode unpacking and adapt to new security threats and attack methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 A schematic diagram of the steps of a bytecode storage method of an Android shelling machine of the present invention; Figure 2 Detailed implementation flow chart of step S1; Figure 3 Detailed implementation flow chart of step S2; Figure 4 Detailed implementation flow chart of step S3. DETAILED DESCRIPTION

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

[0011] The present 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 the following: mechanical equipment, data processing platform, cloud server node, network upload device, etc. that are equipped with the system can be regarded as the general computing node of the present application, and 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.

[0012] 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: 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 structure feature information, and quantify the module security sensitivity, so as to obtain 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 encapsulate the normalized module encryption codes and the obfuscated encryption compression codes one by one, and perform distributed storage to construct a distributed encryption unit storage structure; Step S5: when the shelling instruction is obtained, the distributed encryption unit storage structure is decrypted and restored unit by unit, and the bytecode is merged and reconstructed, so as to obtain the shelling and restoration 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.

[0013] 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 structure 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 obfuscation 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, and builds a distributed encryption unit storage structure to help manage and protect encrypted data, ensure security and integrity. Distortion optimization improves the accuracy and efficiency of decryption and restoration, ensures the functional integrity of the application, and strengthens transfer learning to help the system continuously improve the intelligence level of bytecode unpacking and adapt to new security threats and attack methods.

[0014] In the embodiment of the present invention, refer to 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: Step S1: monitor all applications in the system in real time and perform pseudo-call dynamic class loading to generate bytecode structure feature information; In this embodiment, an appropriate monitoring tool is evaluated and selected, such as Android Profiler, VisualVM, or a custom JavaAgent, to ensure that the tool supports real-time monitoring of application performance indicators (such as CPU, memory, threads, etc.), a monitoring agent or script is deployed in the system to ensure that all target applications can be monitored, monitoring parameters such as sampling frequency, monitoring indicators (CPU usage, memory occupancy, etc.) and data storage methods (such as memory, files, or databases) are set, the monitoring tool is started and real-time data collection begins, and the collected data is stored in a structured format (such as JSON, CSV) for subsequent analysis, using Java's Instrumentation API or Android's Reflection API. Use the system to dynamically load the target class, write pseudo-call logic to call specific methods in the target application to trigger class loading, capture class loading events during the pseudo-call process to record the bytecode structure, use bytecode analysis libraries (such as ASM, BCEL, or DexClassLoader) to analyze the loaded classes, 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 real-time monitoring data with 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 specified location for subsequent analysis and auditing.

[0015] Step S2: Identify the business modules based on the bytecode structure feature information, and quantify the module security sensitivity, so as to obtain the security sensitivity quantification value of each business module; In this embodiment, the characteristics of the business module are defined, such as functional similarity, namespace, dependency between classes, etc., and 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, and a group of classes with similar functions are identified as candidate sets of 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 method information of the module are recorded. The quantitative standards of security sensitivity are defined, including: the importance of the module (such as the priority of the core business module); ), sensitivity of data processing (such as user data, financial data), call frequency (such as the number of times a module is called), complexity (such as the number of methods in the module, the complexity of the dependencies), 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.

[0016] 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; In this embodiment, a symmetric encryption algorithm (such as AES, DES, or ChaCha20) is selected to ensure its security and efficiency. Select an obfuscation algorithm (such as control flow obfuscation, naming obfuscation, data obfuscation, etc.), 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 encryption keys: 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, and stores 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.

[0017] Step S4: independently encapsulate the normalized module encryption codes and the obfuscated encryption compression codes one by one, and perform distributed storage to construct a distributed encryption unit storage structure; In this embodiment, a compressed file format (such as ZIP, TAR) or a custom format is selected, and it is ensured that the selected format supports metadata storage in order to record relevant information of the encoding (such as module name, encryption type, version number, etc.), traverse the encrypted encoding and obfuscated encrypted compressed encoding of all normalized modules, and create an independent package for each code: use a programming language (such as Python or Java) to implement the encapsulation logic, write the code and its metadata into the encapsulation file, ensure that data integrity verification is performed during the encapsulation process (such as using SHA-256 hash), evaluate and select a distributed storage system (such as HDFS, AmazonS3, Ceph, etc.), ensure that it supports high availability, data redundancy and easy scalability, and determine how to organize storage 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 discover and handle problems in the storage system, regularly back up 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.

[0018] Step S5: when the shelling instruction is obtained, the distributed encryption unit storage structure is decrypted and restored unit by unit, and the bytecode is merged and reconstructed, so as to obtain the shelling and restoration bytecode file; In this embodiment, the system is listened or monitored to receive the shelling instruction, which is implemented through a message queue, Webhook or other communication mechanism, confirms the validity of the shelling instruction, and records the source and time of the instruction for subsequent auditing. The distributed storage system is accessed using an appropriate API or client (such as AWSSDK, Hadoop client), and the specific coding units that need to be decrypted are determined based on the information in the shelling instruction. These units are extracted one by one. For each extracted encrypted unit, the previously generated encryption key and the selected symmetric encryption algorithm (such as AES) are used for decryption: the decryption function is called, the encrypted bytecode is input, and the restored bytecode file is generated. Ensure that exception handling is performed during the decryption process, record any decryption failures, collect all restored bytecode files, and organize them according to logical relationships, which includes: determining the relationship between classes. Dependencies are grouped by modules or functions, and merged using bytecode processing tools (such as ASM, Javassist, and DexClassLoader): merge all restored bytecode files to ensure that the definitions of classes and methods do not conflict, generate a new merged bytecode file, ensure that its format is complete and executable, use bytecode verification tools (such as JavaClassFileValidator) to verify the merged bytecode to check whether it complies with the bytecode specification, run simple test cases to ensure that the merged bytecode can run normally in the expected environment, save the merged bytecode file to the specified directory or storage system, and assign it a unique identifier, and record each step of the merge process (such as file name, path, processing time, success / failure status) for subsequent auditing and analysis.

[0019] 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.

[0020] 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 the readability of the code, reducing redundancy, and restoring the original logic. The bytecode files restored after unpacking 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 data set 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; and according to the optimized effects (such as code running efficiency, availability, 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, learns the best optimization strategy under different distortion conditions, and uses the test set to verify the optimization effect of the model to ensure that it can effectively reduce distortion and improve bytecode quality. According to the evaluation results, the model parameters and training process are adjusted 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, generates the final restored bytecode file, records the decisions and results of the optimization process, and establishes a feedback mechanism. The decision-making 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 in order to further improve the model performance.

[0021] In this embodiment, refer to Figure 2 , is a flowchart of detailed implementation steps of step S1. In this embodiment, the detailed implementation steps of step S1 include: Step S11: monitor all applications in the system in real time and extract operation monitoring data of all applications; Step S12: performing a preset target program judgment on all application program operation monitoring data, and extracting the target application program when 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.

[0022] 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, and 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), and it is determined which programs meet the preset goals. For example, conditional statements are used to filter out applications that meet specific conditions, and the relevant information of the successfully judged target application (such as package name, process ID, etc.) is extracted and stored in a new data structure for subsequent processing, and Android's Instrumentation API or Reflection mechanism is used to pseudo-call the target application. The purpose of the pseudo-call is to simulate the running environment of the application. During the pseudo-call process, obtain the APK file path of the target application, extract the APK file to the specified directory through the file system API, save the extracted APK file to the local storage or database, and record relevant information (such as file path, version number, etc.), prepare the running environment, ensure that the 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 the ZIP decompression tool to decompress it to ensure that all DEX files are extracted. If there are multiple DEX files, store the extracted DEX bytecode files in the specified directory for subsequent parsing and analysis. Select a suitable bytecode parsing library (such as smali, baksmali, dex-tools) or a custom parser to parse the DEX file. Use the selected tool to parse all DEX bytecode files, extract structural information such as classes, methods, and fields, and record the structural features of the bytecode, such as method call relationships, class inheritance relationships, field types, etc. The parsed bytecode structural feature information is stored in a structured format (such as JSON, XML or database) for subsequent analysis and processing.

[0023] In this embodiment, 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.

[0024] In this embodiment, it is ensured that the extracted DEX bytecode file is available, usually classes.dex or other DEX files, and bytecode parsing tools (such as smali, baksmali, dexlib2, dexlib3, etc.) are used to traverse the classes. These tools provide APIs or command line interfaces to read DEX files and traverse the classes therein. Scripts (using languages ​​such as Java and Python) are written to call the parsing library to read the class information in each DEX file. For example, the DexReader class in dexlib2 is used to read the names and definitions of all classes. Determine the basic definition information of the class that needs to be extracted, including the class name, package name, parent class, interface, and access modifiers (such as public and private). For each class traversed, use the parsing tool to extract its basic definition information. For example, use the smali API to obtain the class modifier and parent class information. 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, and access modifier. Traverse the member variables of each class and use the parsing tool 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 the variable name, type, and modifier information are included. Determine the method information that needs to be extracted, including method name, parameter type, return type, and access modifier. Perform method traversal on each class and use parsing tools to extract the information of 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. Analyze the relationship between classes based on the extracted class definition information, member variable data, and method data. 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, including all class definitions, member variables, and method features, to facilitate subsequent analysis and research. In this embodiment, refer to Figure 3 , is a flowchart of detailed implementation steps of step S2. In this embodiment, the detailed implementation steps of step S2 include: Step S21: performing a structural topological analysis on the bytecode structural feature information to obtain bytecode structural topological data; Step S22: identifying the 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's operation call frequency and each module's business logic, thereby obtaining a security sensitivity quantification value of each business module.

[0025] In this embodiment, it is ensured that the extracted bytecode structural feature information is available, including class definition, member variables, method information and their relationships, and a suitable topology analysis tool or library (such as NetworkX, Graphviz, etc.) is selected to construct and analyze the structural topology, and 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, and 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 the bytecode structural topology data is stored in a structured format (such as JSON, XML or a database) for subsequent analysis. The identification criteria for business modules are defined, for example, based on the calling relationships between functions, namespaces or classes, and business modules are analyzed using topological data: classes with similar functions or interdependence are identified as a business module, and classes are grouped by 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., and application Runtime call data to ensure that the call information of each module can be obtained. For each business module, calculate its call frequency during the operation of the application: use log analysis tools (such as ELKStack) to analyze the call records and extract the frequency, record the number of times each module is called, determine the business logic features that need to be analyzed, such as input-output relationships, execution paths, key algorithms, etc., and perform logical analysis on the business modules of multiple applications: combine the methods and member variables of the class to draw a flowchart or call diagram, analyze the logical flow of the module, use tools (such as UML tools, flowchart software) to help visualize and understand the business logic, and store the business logic analysis results of each module in a structured format, including input and output, execution paths and key logic, determine the quantitative standards for security sensitivity, such as based on call frequency, business logic complexity, data processing sensitivity, etc., and quantify the security sensitivity of each business module: combine the module's operating 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 the database, and generate a report to facilitate subsequent security analysis and risk assessment.

[0026] In this embodiment, refer to Figure 4 , is a flowchart of detailed implementation steps of step S3. In this embodiment, the detailed implementation steps of step S3 include: Step S31: classifying multiple application business modules into core business modules based on the security sensitivity quantified value of each business module to obtain normalized business modules and core business modules; Step S32: performing bytecode symmetrical encryption on 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.

[0027] In this embodiment, the security sensitive 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 sensitive 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, and 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, and 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.), 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, encrypt the module compression code: combine 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.

[0028] In this embodiment, step S4 includes the following steps: 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 multiple encryption code units with sequential numbers to obtain 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 of the distributed encryption unit storage structure based on the characteristics of the operating environment changes, thereby constructing a dynamic storage adjustment strategy.

[0029] 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 as 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, and 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, AmazonS3, 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 mark, ensure data integrity verification during the storage process, select appropriate monitoring tools (such as Prometheus, Nagios, Zabbix, etc.) to collect indicator data of the operating environment, collect environmental variable change data of the target application during operation, including CPU usage, memory usage, network latency, etc., analyze the collected data, and extract the characteristics of operating environment changes, such as: identifying peak load periods, abnormal changes detected (such as sudden increase in memory usage), and designing dynamic storage adjustment strategies based on the characteristics of operating environment changes, such as: increasing the distribution of data copies under high load, adjusting the read load of storage nodes according to access frequency, and writing scripts or using automation tools to implement dynamic storage adjustments based on the changing characteristics of the operating environment: monitoring environmental change data, adjusting the distribution and load of storage nodes in real time, and recording the implementation of dynamic storage adjustment strategies in logs for subsequent analysis and optimization.

[0030] In this embodiment, step S5 includes the following steps: Step S51: when the shelling instruction is obtained, the distributed encryption unit storage structure is decomposed into units to extract each encryption coding unit; Step S52: decrypt and restore each encrypted coding unit one by one to generate a restored bytecode file; Step S53: tracing and locating the original file of the restored bytecode file to obtain the restored bytecode position data; Step S54: Based on the restored bytecode position data, bytecode merging and reconstruction are performed on the restored bytecode file and all dex bytecode files, thereby obtaining an unpacked restored bytecode file.

[0031] 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, 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. After decryption, the corresponding restored bytecode file should be generated 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 source analysis on the restored bytecode file: analyze the metadata of the restored bytecode file, extract its creation time, modification time, and other feature information, search for the original file in the file system based on the feature information, and record the original location data of the restored bytecode file in the 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 definitions of methods and classes do not conflict, generate a new merged bytecode file, ensure that its format is complete and runs normally, save the final generated unpacked restored bytecode file to the specified directory, and record its metadata (such as file name, generation time, included classes, etc.).

[0032] In this embodiment, step S6 includes the following steps: Step S61: Perform restoration distortion analysis on the de-shelled restored bytecode file, and extract the bytecode restoration distortion part; Step S62: making a distortion optimization decision for the bytecode restoration distorted 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.

[0033] In this embodiment, a suitable analysis tool (such as JavaDecompiler, JEBDecompiler or a custom bytecode analyzer) is selected to analyze the restored bytecode file, and the bytecode file restored by unpacking is analyzed to identify the distorted part: the distorted part usually includes incomplete class definition, missing method implementation or erroneous bytecode instruction. The tool is used to generate a visual diagram of the bytecode structure to help identify the abnormal structure. The identified distorted part is extracted, and its specific location and content are recorded for subsequent optimization. The standard for optimizing the bytecode distortion is determined, such as restoring integrity, improving readability or reducing redundancy. An optimization strategy is formulated for the extracted distorted part: for example, static analysis techniques (such as data flow analysis and control flow analysis) are used to infer the missing method implementation, and template matching or pattern recognition methods are used to identify common distortion patterns and provide repair suggestions. According to the optimization strategy, the distorted part is optimized. Modify and repair, gradually apply the optimization strategy, record the changes at each step, and evaluate its effect, ensure that the optimized bytecode can run normally and its functions are consistent with the original logic, collect data related to 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, the model learns the best decision-making strategy in different situations, verifies the performance of the intelligent bytecode unpacking model on the test set, ensures that it can effectively perform distortion optimization and storage adjustment, adjusts model parameters according to the verification results, optimizes the learning process, and saves the trained intelligent bytecode unpacking model and its parameters for subsequent use and deployment.

[0034] In this embodiment, a bytecode storage device for an Android shelling machine is also provided, including: 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 the business module based on the bytecode structure feature information and quantify the module security sensitivity, thereby obtaining the security sensitivity quantification value of each business module; The coding 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, so as to obtain normalized module encryption code and obfuscation encryption compression code; A distributed storage module is used to independently encapsulate the normalized module encryption codes and obfuscated encryption compression codes one by one, and perform distributed storage to build a distributed encryption unit storage structure; The shelling and restoring module is used to decrypt and restore the distributed encryption unit storage structure unit by unit when receiving the shelling instruction, and merge and reconstruct the bytecode to obtain the shelling and restoring bytecode file; The distortion optimization module is used to make distortion optimization decisions for the unpacking and restoration of bytecode files, and to perform enhanced transfer learning to build an intelligent bytecode unpacking model to complete the unpacking, restoration and preservation of bytecodes.

[0035] The present invention also provides a computer device, including 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.

[0036] Those skilled in the art 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.

[0037] 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 partly or all or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions for a computer device (a personal computer, a server, or a 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 USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks or optical disks.

[0038] Therefore, the embodiments should be regarded as illustrative and non-restrictive from all points, and the scope of the present invention is limited by the appended claims rather than the above description, and it is therefore intended that all changes falling within the meaning and range of equivalent elements of the application documents are included in the present invention.

[0039] The above is only a specific embodiment of the present invention, so that those skilled in the art can understand or implement the present invention. Various modifications to these embodiments will be 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 will not be limited to the embodiments shown herein, but should conform to the widest scope consistent with the principles and novel features invented 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 structure feature information, and quantify the module security sensitivity, so as to obtain 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 encapsulate the normalized module encryption codes and the obfuscated encryption compression codes one by one, and perform distributed storage to construct a distributed encryption unit storage structure; Step S5: when the shelling instruction is obtained, the distributed encryption unit storage structure is decrypted and restored unit by unit, and the bytecode is merged and reconstructed, so as to obtain the shelling and restoration 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, characterized in that: The specific steps of step S1 are: Step S11: monitor all applications in the system in real time and extract operation monitoring data of all applications; Step S12: performing a preset target program judgment on all application program operation monitoring data, and extracting the target application program when 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, characterized in that: 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, characterized in that: The specific steps of step S2 are: Step S21: performing a structural topological analysis on the bytecode structural feature information to obtain bytecode structural topological data; Step S22: identifying the 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's operation call frequency and each module's business logic, 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, characterized in that: The specific steps of step S3 are: Step S31: classifying multiple application business modules into core business modules based on the security sensitivity quantified value of each business module to obtain normalized business modules and core business modules; Step S32: performing bytecode symmetrical encryption on 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, characterized in that: 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 multiple encryption code units with sequential numbers to obtain 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 of the distributed encryption unit storage structure 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, characterized in that: 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 coding unit; Step S52: decrypt and restore each encrypted coding unit one by one to generate a restored bytecode file; Step S53: tracing and locating the original file of the restored bytecode file to obtain the restored bytecode position data; Step S54: Based on the restored bytecode position data, bytecode merging and reconstruction are performed on the restored bytecode file and all dex bytecode files, thereby obtaining an unpacked restored bytecode file.

8. The bytecode storage method of the Android shelling machine according to claim 1, characterized in that: The specific steps of step S6 are: Step S61: Perform restoration distortion analysis on the de-shelled restored bytecode file, and extract the bytecode restoration distortion part; Step S62: making a distortion optimization decision for 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 as claimed in 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 the business module based on the bytecode structure feature information and quantify the module security sensitivity, thereby obtaining the security sensitivity quantification value of each business module; The coding 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, so as to obtain normalized module encryption code and obfuscation encryption compression code; A distributed storage module is used to independently encapsulate the normalized module encryption codes and obfuscated encryption compression codes one by one, and perform distributed storage to build a distributed encryption unit storage structure; The shelling and restoring module is used to decrypt and restore the distributed encryption unit storage structure unit by unit when receiving the shelling instruction, and merge and reconstruct the bytecode to obtain the shelling and restoring bytecode file; The distortion optimization module is used to make distortion optimization decisions for the unpacking and restoration of bytecode files, and to perform enhanced transfer learning to build an intelligent bytecode unpacking model to complete the unpacking, restoration and preservation 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