Encryption / decryption method and device, equipment, medium and product

Abstract

The invention discloses an encryption / decryption method and device, equipment, a medium and a product, and relates to the technical field of computers, and the method comprises the steps: generating a copy of a class file in a compiled file, encrypting the copy of the class file, and obtaining an encrypted class file; according to the method, the compiled file is compiled, and the method body of the class file in the compiled file is cleared to obtain the processed file, so that effective codes are difficult to obtain through decompilation under the unauthorized condition, and the code security is fundamentally enhanced; according to the method, the class file is encrypted by the user-defined class loader, the user-defined class loader with the decryption capability is packaged into the JAR package together, the encrypted class file can be decrypted in real time in the process of loading the JAR package, and the decrypted class file can ensure that the processed file can be normally loaded. According to the embodiment, the technical problem that codes cannot effectively resist reverse engineering and decompilation attacks in related technologies is solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to encryption / decryption methods, apparatus, devices, media and products thereof. Background Technology

[0002] Against the backdrop of the rapid development of the software industry, Java applications face increasingly severe code security challenges. Traditional code protection methods, such as code obfuscation, while increasing the difficulty of code analysis to some extent, do not fundamentally change the plaintext storage state of the code and cannot effectively resist reverse engineering and decompilation attacks.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide an encryption method that aims to solve the technical problem that code in related technologies cannot effectively resist reverse engineering and decompilation attacks.

[0005] To achieve the above objectives, this application proposes an encryption method, the method comprising: obtaining a compiled file, the compiled file including class files; generating a copy of the class files; encrypting the copy of the class files to obtain an encrypted class file; removing the method bodies of the class files in the compiled file to obtain a processed file; and packaging the encrypted class file, the processed file, and a custom class loader to obtain a JAR file, wherein the custom class loader is used to decrypt the encrypted class files during the loading of the JAR file.

[0006] In one embodiment, after obtaining the compiled file, the method further includes: automatically running a custom plugin; the custom plugin generating a copy of the class file during runtime; encrypting the copy of the class file to obtain an encrypted class file; and clearing the method bodies of the class file in the compiled file to obtain a processed file.

[0007] In this embodiment, when the custom plugin is executed, it automatically completes a series of operations such as file scanning, classification, encryption, method body cleanup, and JAR packaging without manual intervention. Moreover, this integration method does not require modification of the project source code or build logic; it only requires adding plugin configuration to the "pom.xml" file of the custom plugin, which greatly reduces the threshold for use and maintenance costs.

[0008] In one embodiment, generating a copy of the class file includes: obtaining configuration information of the custom plugin, the configuration information including a class name to be encrypted; determining a class file to be encrypted in the compiled file based on the class name to be encrypted in the configuration information; and generating a copy of the class file based on the class file to be encrypted.

[0009] In this solution, the configuration information of the custom plugin includes the name of the class to be encrypted. Based on the name of the class to be encrypted, the class file to be encrypted is accurately identified from the compiled file. Only these class files are copied and encrypted, which achieves targeted encryption and avoids full encryption. At the same time, the method body of the class file to be encrypted in the compiled file is cleared, which improves the build efficiency of JAR package while ensuring code security.

[0010] In one embodiment, encrypting a copy of the class file to obtain an encrypted class file includes: encrypting a copy of the class file according to a username and the class name of the class file to obtain an encrypted class file.

[0011] In this embodiment, the MD5 algorithm is used to generate an encryption key based on the user password and the class name of the copy of the class file. This ensures that each copy of the class file uses a unique key, so that even if some keys are leaked, it will not affect the security of other classes, thus enhancing the overall protection strength.

[0012] In one embodiment, encrypting a copy of the class file to obtain an encrypted class file includes: encrypting a copy of the class file according to a username and the class name of the class file to obtain an initial encrypted file; and encrypting the initial encrypted file a second time according to the device machine code to obtain the encrypted class file.

[0013] In this embodiment, the double encryption increases the difficulty of cracking. Even if the first-level key is cracked, an authorized device is still required to decrypt it, making it suitable for high-security scenarios. Furthermore, the secondary encryption based on machine code binds the encryption to the runtime environment, preventing the encrypted JAR package from being illegally copied to other environments for execution.

[0014] Furthermore, to achieve the above objectives, this application also proposes a decryption method, comprising: obtaining a JAR package, the JAR package comprising: an encrypted class file, a processed file, and a custom class loader, wherein the method bodies of the class files in the processed file are cleared; during the loading of the JAR package, the custom class loader decrypts the encrypted class file to obtain a decrypted class file; and the local class loader loads the decrypted class file into memory.

[0015] In addition, to achieve the above objectives, this application also proposes an encryption / decryption device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the encryption / decryption method in the above embodiments.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the encryption / decryption method as described above.

[0017] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the encryption / decryption method as described above.

[0018] Furthermore, to achieve the above objectives, this application also proposes an encryption device, comprising an acquisition module for acquiring a compiled file, the compiled file including a class file; a processing module for generating a copy of the class file; further for encrypting the copy of the class file to obtain an encrypted class file; further for removing the method bodies of the class file in the compiled file to obtain a processed file; and further for packaging the encrypted class file, the processed file, and a custom class loader to obtain a JAR file, wherein the custom class loader is used to decrypt the encrypted class file during the loading of the JAR file.

[0019] Furthermore, to achieve the above objectives, this application also proposes a decryption device, comprising: an acquisition module for acquiring a JAR package, the JAR package including: an encrypted class file, a processed file, and a custom class loader, wherein the method bodies of the class files in the processed file are cleared; a processing module for decrypting the encrypted class file by the custom class loader during the loading of the JAR package to obtain a decrypted class file; and a local class loader for loading the decrypted class file into memory.

[0020] One or more technical solutions proposed in this application have at least the following technical effects: By generating a copy of the class file in the compiled file, encrypting the copy, and obtaining an encrypted class file, and then removing the method bodies of the class files in the compiled file, a processed file is obtained. This makes it difficult to obtain valid code through decompilation without authorization, fundamentally enhancing code security. Furthermore, a custom class loader with decryption capabilities is packaged into the JAR file, allowing for real-time decryption of the encrypted class file during JAR loading. The decrypted class file ensures that the processed file can be loaded correctly. This embodiment solves the technical problem in related technologies where code cannot effectively resist reverse engineering and decompilation attacks. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the encryption / decryption method in the embodiments of this application; Figure 2 This is a flowchart illustrating an embodiment of the encryption method of this application. Figure 3 This is a simplified flowchart illustrating the encryption method of this application; Figure 4 This is a flowchart illustrating the second embodiment of the encryption method of this application; Figure 5 This is a flowchart illustrating an embodiment of the decryption method of this application. Figure 6 This is a flowchart illustrating Embodiment 2 of the decryption method of this application; Figure 7 This is a schematic diagram illustrating the interaction of each component in the decryption method of this application; Figure 8 This is a schematic diagram of the encryption device of this application; Figure 9 This is a schematic diagram of the decryption device of this application.

[0024] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0025] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0026] First, the terms used in the embodiments of this application will be uniformly explained.

[0027] (1) Java source code files Java source code files contain human-readable Java code that defines program logic and functionality; they are text files written by programmers. The file extension is ".java," and they must be compiled into ".class" files by a compiler before they can be run.

[0028] (2) Java class files Java class files are generated by the Java compiler from source code files (.java). They contain bytecode instructions, a constant pool, field and method information, and are binary files that the Java Virtual Machine (JVM) can directly execute. The file extension is ".class", and it stores the compiled program logic. It is also called a ".class file" or a bytecode file.

[0029] (3) JAR package JAR files are created by using the jar command to package one or more Java class files (.class files), resources (such as images and configuration files), and metadata into a single compressed file, supporting cross-platform execution. The file extension is ".jar".

[0030] (4) Java applications Java applications typically consist of multiple JAR files.

[0031] The Java application build process is as follows: 1. Write Java source code; 2. The Java compiler (javac) compiles Java source code to obtain ".class files", also known as bytecode files or Java class files; 3. After compilation, run the Java class file using the Java Virtual Machine (JVM); 4. Multiple compiled Java class files can be packaged into a single JAR (Java Archive) file using the jar command. JAR files are usually in compressed format, hence they are also known as JAR packages. 5. Running JAR files. The process of running a JAR file includes class loading and execution, which together constitute the complete process of a Java program from loading to execution. The class loading process is when the JVM class loader converts the class file (.class) into a runtime data structure and stores it in memory; execution is the process by which the execution engine converts the bytecode into native instructions and executes them.

[0032] Next, the technical solution of this application will be described.

[0033] Reference Figure 1 , Figure 1 This is a schematic diagram of the hardware operating environment of the encryption / decryption device involved in the embodiments of this application.

[0034] like Figure 1 As shown, the encryption / decryption device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen, and optionally, it may also include a standard wired interface or a wireless interface. In this application, the wired interface of the user interface 1003 may be a USB interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be a high-speed random access memory (RAM) or a non-volatile memory (NVM), such as a disk drive. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0035] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the encryption / decryption device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0036] like Figure 1 As shown, the memory 1005, which is identified as a computer storage medium, may include an operation method, a network communication module, a user interface module, and an encryption / decryption program.

[0037] exist Figure 1In the encryption / decryption device shown, the network interface 1004 is mainly used to connect to the backend server and communicate data with the backend server; the user interface 1003 is mainly used to connect to the user equipment; the encryption / decryption device calls the encryption / decryption program stored in the memory 1005 through the processor 1001 and executes the encryption / decryption method provided in the embodiments of this application.

[0038] It is feasible that the encryption / decryption device in the embodiments of this application can be an electronic device such as a computer, laptop, or personal computer.

[0039] Based on the above hardware structure, an embodiment of the encryption / decryption method of this application is proposed.

[0040] Against the backdrop of the rapid development of the software industry, Java applications face increasingly severe code security challenges. Traditional code protection methods, such as code obfuscation, while increasing the difficulty of code analysis to some extent, do not fundamentally change the plaintext storage state of the code and cannot effectively resist reverse engineering and decompilation attacks.

[0041] To address this, this application proposes an encryption method, comprising: obtaining a compiled file, the compiled file including class files; generating a copy of the class files; encrypting the copy of the class files to obtain an encrypted class file; removing the method bodies of the class files in the compiled file to obtain a processed file; and packaging the encrypted class file, the processed file, and a custom class loader to obtain a JAR file, wherein the custom class loader is used to decrypt the encrypted class files during the loading of the JAR file.

[0042] In this embodiment, a copy of the class file in the compiled file is generated, and this copy is encrypted to obtain an encrypted class file. The method bodies of the class files in the compiled file are then removed to obtain a processed file. This makes it difficult to obtain valid code through decompilation without authorization, fundamentally enhancing code security. Furthermore, a custom class loader with decryption capabilities is packaged into the JAR file, allowing for real-time decryption of the encrypted class file during JAR loading. The decrypted class file ensures that the processed file can be loaded correctly. This embodiment solves the technical problem in related technologies where code cannot effectively resist reverse engineering and decompilation attacks.

[0043] First, the encryption method provided in the embodiments of this application will be described in detail with reference to the accompanying drawings.

[0044] Figure 2 This is a flowchart illustrating the first embodiment of the encryption method of this application, including steps S101 to S104.

[0045] Step S101: Obtain the compiled files, which include class files.

[0046] The Java source code is compiled to obtain compiled files, which include one or more class files (.class files) and configuration files (such as application.yml and spring.xml). This example obtains all compilation output files, including class files and configuration files.

[0047] Step S102: Generate a copy of the class file.

[0048] Step S103: Encrypt the copy of the class file to obtain the encrypted class file.

[0049] For class files that need to be encrypted, a copy is generated and encrypted using an encryption algorithm to obtain the encrypted class file. For example, the AES encryption algorithm can be used to encrypt the copy of the class file.

[0050] In one implementation, encrypting a copy of the class file to obtain an encrypted class file includes: encrypting a copy of the class file based on the username and the class name of the class file to obtain an encrypted class file.

[0051] For each class file, a 128-bit encryption key is generated using the MD5 hash algorithm based on the user's password and the class name of the copy of the class file; the copy of the class file is then encrypted using the AES encryption algorithm and the key, and the encrypted class file is output.

[0052] In this embodiment, the MD5 algorithm is used to generate an encryption key based on the user password and the class name of the copy of the class file. This ensures that each copy of the class file uses a unique key, so that even if some keys are leaked, it will not affect the security of other classes, thus enhancing the overall protection strength.

[0053] In another implementation, a copy of the class file is encrypted to obtain an encrypted class file. This includes: encrypting a copy of the class file based on the username and the class name of the class file to obtain an initial encrypted file; and then encrypting the initial encrypted file a second time based on the device machine code to obtain the encrypted class file.

[0054] The copy of the class file is encrypted using a key generated from the username and the class name of the copy of the class file to obtain the initial encrypted file; then, the device machine code is read (such as obtaining the CPU serial number or hard disk ID through the Native library), and the machine code is used as the key to encrypt the initial encrypted file a second time.

[0055] In this embodiment, the double encryption increases the difficulty of cracking. Even if the first-level key is cracked, an authorized device is still required to decrypt it, making it suitable for high-security scenarios. Furthermore, the secondary encryption based on machine code binds the encryption to the runtime environment, preventing the encrypted JAR package from being illegally copied to other environments for execution.

[0056] Step S104: Remove the method bodies of class files in the compiled file to obtain the processed file.

[0057] The Javassist bytecode framework is used to parse the original class file, precisely removing the contents of all method bodies (replacing them with empty implementations), but retaining metadata such as method signatures, annotations, and exception tables, resulting in a processed class file.

[0058] It is worth noting that the configuration files in the compiled files can also be encrypted in the same way, supporting formats such as YAML, XML, and Properties.

[0059] Step S105: Package the encrypted class file, the processed file, and the custom class loader to obtain a JAR file.

[0060] A custom class loader is used to decrypt encrypted class files during the loading of a JAR package. The encrypted class files, configuration files, processed class files (with empty method bodies), and the custom class loader (which implements the decryption logic) are packaged into a JAR package. In this way, the encrypted class files are decrypted in real-time during the JAR package loading process, ensuring that the processed files can be loaded correctly.

[0061] In this embodiment, a copy of the class file in the compiled file is generated, and this copy is encrypted to obtain an encrypted class file. The method bodies of the class files in the compiled file are then removed to obtain a processed file. This makes it difficult to obtain valid code through decompilation without authorization, fundamentally enhancing code security. Furthermore, a custom class loader with decryption capabilities is packaged into the JAR file, allowing for real-time decryption of the encrypted class file during JAR loading. The decrypted class file ensures that the processed file can be loaded correctly. This embodiment solves the technical problem in related technologies where code cannot effectively resist reverse engineering and decompilation attacks.

[0062] In one feasible implementation, steps S102 to S105 can be achieved by automatically running a pre-set custom plugin. Specifically, after obtaining the compiled file, the process includes: automatically running the custom plugin; generating a copy of the class file during the custom plugin's execution; encrypting the copy of the class file to obtain an encrypted class file; and removing the method bodies of the class files from the compiled file to obtain the processed file.

[0063] See Figure 3 In this embodiment, the custom plugin can be implemented using a Maven plugin. A Maven plugin is an executable component used to extend the functionality of Maven. It performs specific tasks (such as compilation, testing, packaging, etc.) through predefined goals, helping to automate the build process and unify project standards.

[0064] (1) Maven plugin preparation stage The JAR package generation process includes: compiling Java source code to obtain class files (.class files) and configuration files; then, packaging the class files (.class files) and configuration files to obtain a JAR package; finally, testing the JAR, etc. In other words, the JAR generation cycle includes: compilation, packaging, and testing.

[0065] Maven plugins adhere to the Maven standard plugin development specification and are automatically registered in the JAR generation lifecycle via the Service Provider Interface (SPI). Specifically, Maven plugins are bound to the packaging phase of the JAR generation process, ensuring that they are automatically invoked during JAR generation. SPI is a service discovery mechanism provided by Java, used to define the decoupling specifications between service interfaces and implementation classes, allowing third-party developers to extend service functionality in a standardized manner.

[0066] Maven plugins can receive user configurations via the "pom.xml" file, allowing users to flexibly define the encryption scope. The encryption scope includes, but is not limited to: encryption algorithms, the paths to packages to be encrypted, excluded classes, and internal dependency JARs and configuration files to be encrypted. For example, it can be configured via... <packages>The tag specifies the path to the packet that needs to be encrypted; it can be accessed via... <excludes>The tag specifies the specific class files to be excluded; through... <libjars>The "" tag specifies the internal dependency JAR files that need to be encrypted; it can be accessed via " <cfgfiles>The "tag" specifies the configuration file that needs to be encrypted.

[0067] The Maven plugin supports multiple password input methods, including command-line arguments, environment variables, and configuration files.

[0068] (2) Maven plugin runtime phase After obtaining the compiled class files (.class files) and configuration files, the packaging phase begins. At this point, the custom Maven plugin is automatically activated. The Maven plugin scans all class files (.class files) and configuration files in the JAR package and generates copies of the class files accordingly.

[0069] Based on the configured package paths and exclusion rules, determine whether copies of various file types need to be encrypted. Specifically, filter class files that need encryption based on the configured package path prefix and encrypt copies of those class files; exclude class files that do not need encryption by class name; identify and process dependency library files within JAR packages; and identify configuration files that need encryption.

[0070] For copies of class files that require encryption, an encryption algorithm is used to encrypt them. The MD5 algorithm is used to generate an encryption key based on the user password and the class name of the copy of the class file, ensuring that each copy of the class file is encrypted with a unique key. Even if some keys are leaked, it will not affect the security of other classes, thus enhancing the overall protection strength.

[0071] Optionally, secondary encryption based on machine code is supported, binding encryption to the runtime environment. That is, the device machine code is read (such as obtaining the CPU serial number or hard disk ID through a native library), and the machine code is used as the key to perform a second encryption on the initially encrypted file.

[0072] Optionally, in this embodiment, the Maven plugin also supports a passwordless mode, automatically generating and hiding the password in the JAR package.

[0073] To further enhance security, the Javassist bytecode framework is used to clear the method body content of the original class file (replacing it with an empty implementation), while fully preserving metadata information such as method signatures and annotations; maintaining the integrity of debugging information such as exception tables and local variable tables; and automatically adding dependent libraries to the ClassPool path to ensure the correctness of bytecode operations.

[0074] The Javassist bytecode framework is a Java bytecode engineering toolkit that supports source code-level and bytecode-level operations. It is primarily used for dynamically modifying class structures or generating new classes without directly processing virtual machine instructions or requiring in-depth knowledge of JVM instructions. The ClassPool path refers to the path used in the Javassist tool to store and load classes, typically pointing to the directory where compiled class files (.class) are stored.

[0075] After encryption is complete and the method body content of the original class file is cleared, the packaging operation is automatically performed to obtain a JAR package. The JAR package includes: the processed class file (method body has been cleared), a copy of the encrypted class file (stored in the META-INF / .classes / directory), and a custom class loader (added to the MANIFEST.MF file).

[0076] META-INF is a standard directory in a JAR package, mainly used to store metadata files that describe JAR package attributes, dependencies, or extension mechanisms; MFMANIFEST.MF is located in the META-INF directory and is used to define extensions and package description information, such as the main class, dependency paths, version information, etc.

[0077] It is worth noting that the original package hierarchy is strictly maintained during the automatic packaging of JAR files to ensure that the class loader can be located correctly.

[0078] It is worth noting that it supports encryption and automatic decryption injection of configuration files for frameworks such as Spring.

[0079] In this embodiment, when the Maven plugin is executed, it automatically completes a series of operations such as file scanning, classification, encryption, method body cleanup, and JAR packaging without manual intervention. Moreover, this integration method does not require modification of the project source code or build logic; it only requires adding plugin configuration to the Maven plugin's "pom.xml", which greatly reduces the threshold for use and maintenance costs.

[0080] Figure 4 This is a flowchart illustrating the second embodiment of the encryption method of this application, which includes steps S201 to S207.

[0081] Step S201: Obtain the compiled files, which include class files.

[0082] Step S201 described above is the same as step S101 in the first embodiment, and will not be repeated here to avoid repetition.

[0083] Step S202: Obtain the configuration information of the custom plugin, which includes the class name to be encrypted.

[0084] Step S203: Determine the class file to be encrypted in the compiled file based on the class name to be encrypted in the configuration information.

[0085] Step S204: Generate a copy of the class file based on the class file to be encrypted.

[0086] Step S205: Encrypt the copy of the class file to obtain the encrypted class file.

[0087] Step S206: Remove the method bodies of class files in the compiled file to obtain the processed file.

[0088] Step S207: Package the encrypted class file, the processed file, and the custom class loader to obtain a JAR file.

[0089] In this solution, the configuration information of the custom plugin includes the name of the class to be encrypted. Based on the name of the class to be encrypted, the class file to be encrypted is accurately identified from the compiled file. Only these class files are copied and encrypted, which achieves targeted encryption and avoids full encryption. At the same time, the method body of the class file to be encrypted in the compiled file is cleared, which improves the build efficiency of JAR package while ensuring code security.

[0090] Figure 5 This is a flowchart illustrating the first embodiment of the decryption method of this application, which includes steps S401 to S403.

[0091] Step S401: Obtain the JAR package, which includes: encrypted class files, processed files, and a custom class loader. The method bodies of the class files in the processed files are removed.

[0092] The first device generates a JAR package based on the encryption method of any of the above embodiments and distributes the JAR package to other devices. If the second device obtains the JAR package, the second device will decrypt the JAR package.

[0093] The JAR package includes encrypted class files, processed files, and a custom class loader. The method bodies of the class files in the processed files are removed.

[0094] In one implementation, the custom class loader is implemented based on JVM bytecode enhancement technology.

[0095] The custom class loader uses the Java Instrumentation API to implement non-intrusive runtime decryption. The Java Instrumentation API is a runtime bytecode modification mechanism introduced in Java SE 5 (JDK 5), providing the ability to dynamically modify class definitions through the java.lang.instrument package. It allows developers to modify the bytecode of a class when it is loaded by the JVM or at runtime, without restarting the application or modifying the source code.

[0096] Custom class loaders complete initialization early in JVM startup through the Premain mechanism, preempting class loading priority; and custom class loaders support obtaining passwords from various sources such as command-line arguments, environment variables, configuration files, and JAR packages.

[0097] In step S402, during the JAR package loading process, a custom class loader decrypts the encrypted class files to obtain the decrypted class files. When the JVM starts loading the JAR package, the custom class loader containing the decryption logic is loaded via the `-javaagent` parameter. The `premain` method of the custom class loader completes initialization and registers a custom `ClassFileTransformer`.

[0098] ClassFileTransformer is an interface provided by the Java Virtual Machine (JVM) for dynamically modifying the bytecode of class files. It allows developers to modify the bytecode of a class before or after it is loaded into the JVM without altering the original code. By registering a ClassFileTransformer instance, class loading requests are intercepted, and Transformer methods are used to transform the bytecode. The transformed bytecode is then reloaded into the JVM, achieving dynamic modification.

[0099] During the JVM class loading process, the registered ClassFileTransformer intercepts class loading requests. When it detects that the class to be loaded is an encrypted class (located in META-INF / .classes / ), it dynamically performs a decryption operation and returns the decrypted bytecode to the JVM for loading.

[0100] For frameworks like Spring, decryption code is injected into their key classes to ensure that encrypted configuration files are automatically decrypted when the framework is loaded.

[0101] Step S403: The decrypted class file is loaded into memory by the local class loader.

[0102] After the JVM receives the decrypted bytecode, the JVM's native class loader loads the decrypted class file into memory.

[0103] Since the decryption process is implemented during class loading, the decrypted bytecode is only stored in memory. What users actually see are only the class files with their method bodies removed and encrypted copies of the class files in the JAR package. This makes it impossible to crack the code in the JAR package through reverse engineering and decompilation attacks, thus improving code security.

[0104] In one implementation, during the loading of the JAR package, a custom class loader decrypts the encrypted class file to obtain the decrypted class file. Then, the method further includes: temporarily storing the decrypted class file in a cache. After the local class loader loads the decrypted class file into memory, the method further includes: clearing the temporarily stored decrypted class file in the cache.

[0105] Successfully decrypted class bytecode is temporarily stored in a cache. When the same class is requested again, it can be read directly from the cache, avoiding repeated decryption. After the class is successfully loaded into the JVM, the plaintext bytecode data left in the cache and in memory during the decryption process is immediately and completely cleared (e.g., by overwriting memory areas). Techniques such as distributed memory storage are used to increase the difficulty for attackers to obtain complete decrypted class data through memory snapshots.

[0106] In this embodiment, the caching mechanism reduces the impact of decryption operations on runtime performance, which is especially beneficial for frequently loaded classes; real-time memory cleanup effectively defends against attacks that steal code through memory analysis, achieving a good balance between security and performance.

[0107] Figure 6 This is a flowchart illustrating the second embodiment of the decryption method of this application, which includes steps S501 to S504.

[0108] Step S501: Obtain the JAR package, which includes: encrypted class files, processed files, and a custom class loader. The method bodies of the class files in the processed files are removed.

[0109] The above steps S501 are largely the same as those of S401. To avoid repetition, they will not be described again in this embodiment.

[0110] In step S502, if the custom class loader determines that the class file to be loaded is an encrypted class file based on the processed file, the custom class loader decrypts the encrypted class file to obtain the decrypted class file.

[0111] Step S503: The decrypted class file is loaded into memory by the local class loader.

[0112] Step S504: If the custom class loader determines that the class file to be loaded is not an encrypted class file based on the processed file, the local class loader loads the class file to be loaded into memory.

[0113] In this embodiment, the custom ClassFileTransformer intercepts every class loading request initiated by the JVM and checks the name and path of the requested class. If the class is determined to be an encrypted class (for example, its path matches a specific pattern under META-INF / .classes / , or its metadata contains encryption tokens), the decryption process begins.

[0114] For identified encrypted classes, the custom class loader performs decryption and then loads them.

[0115] For non-encrypted classes (such as JDK system classes or excluded classes), the loading is directly delegated to the JVM's native class loader without any processing.

[0116] In this embodiment, intelligent recognition avoids unnecessary processing of non-encrypted classes, significantly reducing runtime performance overhead.

[0117] In one implementation, a custom class loader decrypts the encrypted class file to obtain a decrypted class file, including: initially decrypting the encrypted class file based on the device machine code to obtain an initial decrypted file; and then decrypting the initial decrypted file a second time based on the username and the class name of the class file to obtain the decrypted class file.

[0118] In this embodiment, before decryption begins, it is first verified whether the machine code of the current device matches the hash value stored in the JAR file. If they do not match, decryption is aborted and a security exception is thrown.

[0119] Using the device machine code as the key, the encrypted class file data is decrypted using AES for the first time to obtain the initial decrypted file; using the key derived from "user password + class name", the initial decrypted file is decrypted using AES for the second time to restore the original class bytecode.

[0120] In this embodiment, it is ensured that the encrypted code can only run on authorized specific devices; and the dual decryption process corresponds to the encryption process, forming a complete security closed loop.

[0121] For the decryption method in the embodiments of this application, please refer to [link / reference]. Figure 7 It is based on a custom class loader in the JAR package, and the custom class loader uses the Java Instrumentation API to implement non-intrusive runtime decryption.

[0122] The premain method completes initialization early in the JVM startup process, thereby preempting class loading priority.

[0123] In the premain method, a custom class that implements the ClassFileTransformer interface is loaded and registered into the JVM's Instrumentation mechanism.

[0124] The custom class loader ClassFileTransformer registered with the JVM becomes the core engine of the decryption process. This Transformer is designed to be called before the JVM loads each class, thereby achieving dynamic interception of the class loading process.

[0125] The custom class loader supports retrieving passwords from various sources, including command-line arguments, environment variables, configuration files, and JAR files. It verifies the correctness of the user's input password using a stored password hash. When other methods fail to retrieve the password, a GUI password input interface is provided for the user to enter it.

[0126] A custom class loader can accurately locate the project's runtime path where class files reside, specifically checking if they are located in a specific directory storing encrypted classes (such as META-INF / .classes / ). It uses bytecode terminal characteristics as one of the criteria for determining whether decryption was successful or if the format is encrypted. It also correctly handles path separator conversions in class names (e.g., converting "." to " / "). Once the class to be loaded is identified as an encrypted class, if machine code binding was enabled during encryption, two-stage decryption is supported, first using machine code decryption and then using password decryption; the decryption operation is performed to restore the encrypted bytecode data to the original bytecode that can be recognized by the JVM.

[0127] The decrypted bytecode is returned to the JVM by ClassFileTransformer, and the JVM's native class loader completes the final loading and definition process, ensuring that the decrypted class file's bytecode is dynamically decrypted at runtime and loaded into the JVM. This process guarantees compatibility between the custom class loader and the VM's native class loader, preventing class conflicts.

[0128] Furthermore, to prevent plaintext classes from leaking in memory, the system implements strict memory control measures and adopts an immediate cleanup mechanism to promptly clean up temporary data in memory after decryption is completed and the class is successfully loaded.

[0129] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0130] This application provides an encryption device, such as Figure 8 As shown, it includes: an acquisition module 101, used to acquire the compiled file, the compiled file including class files.

[0131] Processing module 102 is used to generate a copy of the class file; to encrypt the copy of the class file to obtain an encrypted class file; to remove the method bodies of the class file in the compiled file to obtain a processed file; and to package the encrypted class file, the processed file, and a custom class loader to obtain a JAR file, wherein the custom class loader is used to decrypt the encrypted class file during the loading of the JAR file.

[0132] It is achievable that, after obtaining the compiled file, the processing module 102 is also used to automatically run a custom plugin; the custom plugin generates a copy of the class file when it runs; the copy of the class file is encrypted to obtain an encrypted class file; and the method bodies of the class file in the compiled file are cleared to obtain the processed file.

[0133] It is feasible that the processing module 102 is used to obtain the configuration information of the custom plugin, the configuration information including the class name to be encrypted; it is also used to determine the class file to be encrypted in the compiled file according to the class name to be encrypted in the configuration information; and it is also used to generate a copy of the class file according to the class file to be encrypted.

[0134] It is feasible that the processing module 102 is used to encrypt a copy of the class file according to the username and the class name of the class file to obtain an encrypted class file.

[0135] It is feasible that the processing module 102 is used to encrypt a copy of the class file according to the username and the class name of the class file to obtain an initial encrypted file; it is also used to perform a second encryption on the initial encrypted file according to the device machine code to obtain the encrypted class file.

[0136] This application provides a decryption device, such as Figure 9 As shown, it includes: an acquisition module 201, used to acquire a JAR package, the JAR package including: an encrypted class file, a processed file and a custom class loader, wherein the method bodies of the class files in the processed file are cleared.

[0137] The processing module 202 is used to decrypt the encrypted class file by the custom class loader during the loading of the JAR package to obtain the decrypted class file; it is also used to load the decrypted class file into memory by the local class loader.

[0138] The processing module 202 is configured to, when the custom class loader determines, based on the processed file, that the class file to be loaded is the encrypted class file, decrypt the encrypted class file to obtain the decrypted class file; it is also configured to, when the custom class loader determines, based on the processed file, that the class file to be loaded is not the encrypted class file, load the class file to be loaded, into memory by the local class loader.

[0139] It is feasible that the processing module 202 is used to perform an initial decryption of the encrypted class file according to the device machine code to obtain an initial decrypted file; and is also used to perform a second decryption of the initial decrypted file according to the username and the class name of the class file to obtain a decrypted class file.

[0140] It is achievable that, during the loading of the JAR package, the processing module 202 decrypts the encrypted class file using the custom class loader, and after obtaining the decrypted class file, it also temporarily stores the decrypted class file in a cache; after the local class loader loads the decrypted class file into memory, the processing module 202 also clears the temporarily stored decrypted class file in the cache.

[0141] This is achievable, as the defined class loader is implemented based on JVM bytecode enhancement technology.

[0142] This application provides an encryption / decryption device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the encryption / decryption method in the above embodiments.

[0143] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the encryption / decryption methods in the above embodiments.

[0144] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor methods, approaches, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution method, approach, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

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

[0146] This application provides a computer program product, which includes a computer program that, when executed by a processor, implements the encryption / decryption method described in the above embodiments.

[0147] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods, approaches, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based method to perform the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0148] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0149] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or approach that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or approach. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or approach that includes that element.

[0150] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0151] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as a read-only memory image (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0152] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

[0153] This application discloses A1, an encryption method, the method comprising: Obtain the compiled files, including class files; Generate a copy of the class file; Encrypt a copy of the class file to obtain an encrypted class file; Remove the method bodies of the class files in the compiled file to obtain the processed file; The encrypted class file, the processed file, and the custom class loader are packaged together to obtain a JAR file, wherein the custom class loader is used to decrypt the encrypted class file during the loading of the JAR file.

[0154] A2. As described in A1, after obtaining the compiled file, the method further includes: automatically running the custom plugin; The custom plugin executes the following steps: generating a copy of the class file at runtime; encrypting the copy of the class file to obtain an encrypted class file; and removing the method bodies of the class file from the compiled file to obtain a processed file.

[0155] A3. As described in A2, generating a copy of the class file includes: Obtain the configuration information of the custom plugin, including the class name to be encrypted; Based on the class name to be encrypted in the configuration information, determine the class file to be encrypted in the compiled file; Generate a copy of the class file based on the class file to be encrypted.

[0156] A4. The method described in any one of A1-A3, wherein encrypting a copy of the class file to obtain an encrypted class file includes: Based on the username and the class name of the class file, a copy of the class file is encrypted to obtain the encrypted class file.

[0157] A5. The method according to any one of claims A1-A3, wherein encrypting the copy of the class file to obtain the encrypted class file includes: Based on the username and the class name of the class file, a copy of the class file is encrypted to obtain an initial encrypted file; The initial encrypted file is then encrypted a second time based on the device machine code to obtain the encrypted class file.

[0158] B6. A decryption method, comprising: Obtain a JAR package, which includes: encrypted class files, processed files, and a custom class loader, wherein the method bodies of the class files in the processed files are cleared; During the loading of the JAR package, the custom class loader decrypts the encrypted class file to obtain the decrypted class file; the local class loader loads the decrypted class file into memory.

[0159] B7. As described in B6, during the loading of the JAR package, the custom class loader decrypts the encrypted class file to obtain the decrypted class file, including: If the custom class loader determines that the class file to be loaded is the encrypted class file based on the processed file, the custom class loader decrypts the encrypted class file to obtain the decrypted class file. The decrypted class file is loaded into memory by the local class loader; If the custom class loader determines, based on the processed file, that the class file to be loaded is not the encrypted class file, the local class loader loads the class file to be loaded into memory.

[0160] B8. As described in B6 or B7, the step of decrypting the encrypted class file by the custom class loader to obtain the decrypted class file includes: The encrypted class file is initially decrypted based on the device machine code to obtain the initial decrypted file; The initial decryption file is decrypted a second time based on the username and the class name of the class file to obtain the decrypted class file.

[0161] B9. The method described in any one of B6-B8, wherein during the loading of the JAR package, after the custom class loader decrypts the encrypted class file to obtain the decrypted class file, the method further includes: The decrypted class file is temporarily stored in the cache; After the decrypted class file is loaded into memory by the local class loader, the method further includes: clearing the decrypted class file temporarily stored in the cache.

[0162] B10. The method described in any one of B6-B9, wherein the custom class loader is implemented based on JVM bytecode enhancement technology.

[0163] C11. A computer device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform steps of an encryption method as described in any one of A1 to A5, or to perform steps of a decryption method as described in any one of B6 to B10.

[0164] D12. A storage medium, said storage medium being a computer-readable storage medium, said storage medium storing a computer program, said computer program, when executed by a processor, implementing the steps of an encryption method as described in any one of A1 to A5, or implementing the steps of a decryption method as described in any one of B6 to B10. E13. A computer program product comprising a computer program that, when executed by a processor, implements the steps of an encryption method as described in any one of A1 to A5, or implements the steps of a decryption method as described in any one of B6 to B10.

[0165] F14. An encryption device, the device comprising: The acquisition module is used to acquire the compiled files, including class files; A processing module is used to generate a copy of the class file; It is also used to encrypt a copy of the class file to obtain an encrypted class file; It is also used to remove the method bodies of the class files in the compiled file to obtain the processed file; It is also used to package the encrypted class file, the processed file, and the custom class loader to obtain a JAR package, wherein the custom class loader is used to decrypt the encrypted class file during the loading of the JAR package.

[0166] F15. The apparatus as described in F14, wherein the processing module, after acquiring the compiled file, is further configured to automatically run a custom plugin; The custom plugin executes the following steps: generating a copy of the class file at runtime; encrypting the copy of the class file to obtain an encrypted class file; and removing the method bodies of the class file from the compiled file to obtain a processed file.

[0167] F16. The apparatus as described in F15, wherein the processing module is configured to obtain configuration information of the custom plugin, the configuration information including the class name to be encrypted; It is also used to determine the class file to be encrypted in the compiled file based on the class name to be encrypted in the configuration information; It is also used to generate a copy of the class file based on the class file to be encrypted.

[0168] F17. The apparatus of any one of F14-F16, wherein the processing module is configured to encrypt a copy of the class file according to the username and the class name of the class file to obtain an encrypted class file.

[0169] F18. The apparatus of any one of F14-F16, wherein the processing module is configured to encrypt a copy of the class file according to the username and the class name of the class file to obtain an initial encrypted file; It is also used to perform secondary encryption on the initial encrypted file based on the device machine code to obtain the encrypted class file.

[0170] G19. A decryption device, the device comprising: The acquisition module is used to acquire a JAR package, which includes: encrypted class files, processed files, and a custom class loader, wherein the method bodies of the class files in the processed files are cleared; The processing module is used to decrypt the encrypted class file by the custom class loader during the loading of the JAR package to obtain the decrypted class file; it is also used to load the decrypted class file into memory by the local class loader.

[0171] G20. The apparatus as described in G19, wherein the processing module is configured to, when the custom class loader determines, based on the processed file, that the class file to be loaded is the encrypted class file, have the custom class loader decrypt the encrypted class file to obtain the decrypted class file; It is also used to load the decrypted class file into memory by the local class loader; It is also used to load the class file to be loaded into memory by the local class loader when the custom class loader determines, based on the processed file, that the class file to be loaded is not the encrypted class file.

[0172] G21. The apparatus as described in G19 or G20, wherein the processing module is configured to perform an initial decryption of the encrypted class file based on the device machine code to obtain an initial decrypted file; It is also used to perform a second decryption of the initial decryption file based on the username and the class name of the class file to obtain the decrypted class file.

[0173] G22. The apparatus as described in any one of G19-G21, wherein during the loading of the JAR package, the processing module decrypts the encrypted class file using the custom class loader, and after obtaining the decrypted class file, it is further used to temporarily store the decrypted class file in a cache; After the decrypted class file is loaded into memory by the local class loader, the processing module is also used to clear the decrypted class file temporarily stored in the cache.

[0174] G23. The apparatus as described in any one of G19-G21, wherein the class loader is implemented based on JVM bytecode enhancement technology.< / cfgfiles> < / libjars> < / excludes> < / packages>

Claims

1. An encryption method, characterized in that, The method includes: Obtain the compiled files, including class files; Generate a copy of the class file; Encrypt a copy of the class file to obtain an encrypted class file; Remove the method bodies of the class files in the compiled file to obtain the processed file; The encrypted class file, the processed file, and the custom class loader are packaged together to obtain a JAR file, wherein the custom class loader is used to decrypt the encrypted class file during the loading of the JAR file.

2. The method as described in claim 1, characterized in that, After obtaining the compiled file, the process also includes: automatically running the custom plugin; The custom plugin executes the following steps: generating a copy of the class file at runtime; encrypting the copy of the class file to obtain an encrypted class file; and removing the method bodies of the class file from the compiled file to obtain a processed file.

3. The method as described in claim 1 or 2, characterized in that, The step of encrypting a copy of the class file to obtain an encrypted class file includes: Based on the username and the class name of the class file, a copy of the class file is encrypted to obtain an initial encrypted file; The initial encrypted file is then encrypted a second time based on the device machine code to obtain the encrypted class file.

4. A decryption method, characterized in that, include: Obtain a JAR package, which includes: encrypted class files, processed files, and a custom class loader, wherein the method bodies of the class files in the processed files are cleared; During the loading of the JAR package, the custom class loader decrypts the encrypted class file to obtain the decrypted class file; the local class loader loads the decrypted class file into memory.

5. The method as described in claim 4, characterized in that, During the loading of the JAR package, the custom class loader decrypts the encrypted class file to obtain the decrypted class file, which includes: If the custom class loader determines that the class file to be loaded is the encrypted class file based on the processed file, the custom class loader decrypts the encrypted class file to obtain the decrypted class file. The decrypted class file is loaded into memory by the local class loader; If the custom class loader determines, based on the processed file, that the class file to be loaded is not the encrypted class file, the local class loader loads the class file to be loaded into memory.

6. A computer device, characterized in that, The computer device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps of the encryption method as described in any one of claims 1 to 3, or to perform the steps of the decryption method as described in claim 4 or 5.

7. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the encryption method as described in any one of claims 1 to 3, or implements the steps of the decryption method as described in claim 4 or 5.

8. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the encryption method as described in any one of claims 1 to 3, or implements the steps of the decryption method as described in claim 4 or 5.

9. An encryption device, characterized in that, The device includes: The acquisition module is used to acquire the compiled files, including class files; A processing module is used to generate a copy of the class file; It is also used to encrypt a copy of the class file to obtain an encrypted class file; It is also used to remove the method bodies of the class files in the compiled file to obtain the processed file; It is also used to package the encrypted class file, the processed file, and the custom class loader to obtain a JAR package, wherein the custom class loader is used to decrypt the encrypted class file during the loading of the JAR package.

10. A decryption device, characterized in that, The device includes: The acquisition module is used to acquire a JAR package, which includes: encrypted class files, processed files, and a custom class loader, wherein the method bodies of the class files in the processed files are cleared; The processing module is used to decrypt the encrypted class file by the custom class loader during the loading of the JAR package to obtain the decrypted class file; it is also used to load the decrypted class file into memory by the local class loader.

Images