Detailed Description
The technical scheme provided by the application has the following overall thought:
The embodiment of the application provides a method, a device, equipment and a storage medium for encrypting and deploying a byte code file. First, a Java source file is obtained and compiled, and a target archive file set is generated, which contains a plurality of bytecode files. Archive files to be encrypted and unencrypted are then identified and distinguished according to business requirements. And (3) for the file to be encrypted, performing encryption processing by using the generated encryption key and a DES algorithm. The encrypted and unencrypted file sets are then deployed to a designated directory of the target server. And executing decryption and loading processes of the encrypted file by using a custom class loader on the server, wherein the loader supports decryption of the encrypted file and loading of the standard file, thereby ensuring file security and normal operation of application programs.
Having described the basic principles of the present application, various non-limiting embodiments of the present application will now be described in detail with reference to the accompanying drawings.
An embodiment of the present application provides a method for encrypting and deploying a bytecode file, as shown in fig. 1, where the method includes:
Step S100, generating a key file under a Java running environment directory of a target server, acquiring the creation time of the key file and the physical address of the target server, generating an encryption key based on the creation time and the physical address, and storing the encryption key into the key file, wherein the key file is a 32-bit random character.
Specifically, the target server refers to a computer or server running a Java application, here for storing and executing Java bytecode files. Java runtime Environment directory refers to the installation path of Java runtime environment, and typically includes JVM, java class libraries, and related configuration files. The key file is a file for storing the generated encryption key, and is an indispensable element in the encryption and decryption operations. The file is identified by a 32-bit random character, ensuring that the key file generated on each server is unique. The creation time refers to the generated time stamp of the key file, and specific creation date and time can be recorded, so that the uniqueness and timeliness of the file are ensured. The physical Address, i.e., MAC Address (MEDIA ACCESS Control Address), is the hardware Address of the network interface card, and is used to uniquely identify a network device. The encryption key uses a password string generated at creation time and physical address for encrypting the Java bytecode file. The encryption key ensures confidentiality of the bytecode file. The 32-bit random character refers to an identifier of the key file, consists of 32 randomly generated characters, and increases security and unpredictability.
Firstly, a key file is generated under the Java running environment directory of the target server, the file is named by 32-bit random characters, next, the creation time of the key file and the physical address (MAC address) of the target server are obtained, the information (the creation time and the physical address) are spliced into a character string, and then encryption is carried out through an MD5 encryption algorithm to generate a unique encryption key.
In summary, the method enhances the security of the Java bytecode file by generating a unique encryption key, and ensures the security and effectiveness of the encryption process by using various technical tools.
Step 200, acquiring a Java source file, compiling and packaging the Java source file to obtain a target archive file set, wherein the target archive file comprises a plurality of byte code files.
Specifically, the target archive file set refers to a final generated set containing a plurality of bytecode files, typically packaged into one or more JAR files, for deployment and execution.
First, a developer writes Java source files that contain specific business logic and function implementations.
Java source files are compiled into bytecode files using a Java compiler (javac). For example, the run command javac MyApp.java may generate a bytecode file named MyApp.class. Compilation is typically performed in a command line environment or Integrated Development Environment (IDE), commonly used IDEs include Eclipse, intelliJ IDEA, netBeans, etc., which automate the compilation process. The compiler converts the source code into bytecodes, which can be executed across platforms because they rely on the JVM instead of the operating system.
A plurality of bytecode files are packaged into a JAR file using a Java archive tool (JAR). Running the command jar cvfMyApp.jarMyApp.class generates an archive file named MyApp.jar, which contains MyApp.class. JAR files may contain multiple files and directories, similar to ZIP files. The directory structure is preserved during the packing process so that packet dependencies between classes are not lost. In addition to bytecode files, JAR files may also contain other resources such as configuration files, icons, and documents. These files are compressed and stored with the bytecode at the time of packaging.
Through the step, a developer can successfully convert the Java source file into a target archive file set which can be executed in various environments, so that cross-platform deployment and running of the application program are realized.
Step S300, identifying a target archive file set, and determining an archive file set to be encrypted and a non-encrypted archive file set, wherein the archive file to be encrypted is an archive file related to a preset business index.
In particular, the archive file set to be encrypted refers to a file set selected from the target archive file set, and the files contain information related to key business logic or sensitive information and need encryption protection. An unencrypted archive file set refers to a collection of files that do not involve sensitive information, and that do not require encryption and can be deployed and executed directly. The predetermined business criteria are criteria or rules for determining which archive files need to be encrypted, and typically involve enterprise core business logic, proprietary algorithms, or sensitive data processing, etc.
Java decompilation tools (e.g., JD-GUI, CFR) and archive management tools (e.g., JAR commands) are used to analyze the contents of the JAR file. The decompilation tool is used for checking each class and package in the JAR file to know the functions and business logic of the JAR file.
Which functions or data need special protection is defined according to business requirements and data security policies of enterprises. The key class files in the target archive file set are identified using business metrics (e.g., sensitive data processing, algorithmic implementation). The files are divided into a set of files to be encrypted and non-encrypted according to the identified business criticality. The process may be automated using scripts (e.g., python or Bash), automatically identified and categorized by file name or package name rules. A list of files to be encrypted is generated, which files need to be encrypted is recorded. May be saved using text files or configuration files.
By identifying and dividing files in the target archive file set, enterprises can ensure that sensitive business logic is effectively protected, and potential risks caused by code leakage are reduced. In this process, reasonable business index definition is a key to ensure that the identification process is accurate and efficient.
And step S400, symmetrically encrypting the archive file to be encrypted by utilizing a DES data encryption algorithm based on the encryption key in the key file to obtain an encrypted archive file set.
Specifically, the DES data encryption algorithm is a symmetric encryption algorithm, i.e., the same key is used for encryption and decryption. DES implements encryption of data by performing multiple permutation and substitution operations on the data. Symmetric encryption is one of encryption methods, and uses the same key for encryption and decryption, mainly for protecting confidentiality of data. An encrypted archive file set refers to a set of files that have been encrypted, which contain sensitive information in the archive file set to be encrypted, and which cannot be directly read or decompiled without authorization.
DES encryption is implemented using the Java. First, a DES key object is initialized, and an encryption key object is created using the generated encryption key through SECRETKEYSPEC. And configuring a DES encryption algorithm by utilizing a Cipher class, and encrypting the byte code files to be encrypted one by one. The encrypted data is stored as new encrypted archive files, and the encrypted files are packaged into an encrypted archive file set, and the files can be safely deployed on a server to prevent unauthorized access and reverse engineering.
By utilizing the encryption key in the key file and the DES data encryption algorithm, the enterprise can effectively protect archive files containing sensitive information in the Java application. The encryption process ensures the safe transmission and deployment of the file, and reduces the risks of information leakage and unauthorized access.
And S500, copying the non-encrypted archive file set and the encrypted archive file set to a designated directory of a target server to obtain a target binary file set.
In particular, a specified directory refers to a particular file path on a target server for storing Java archive files, typically a working directory or a deployment directory of an application. The target binary file set refers to a set containing all Java archive files under a specified directory, ready for execution in a Java Virtual Machine (JVM).
A specified directory for storing archive files is created on the target server. The local non-encrypted archive file set and encrypted archive file set are uploaded to the target server's designated directory using a file transfer tool (e.g., scp, rsync, or FTP client). Ensuring that all archive files (encrypted and unencrypted) have been properly copied to the target directory, forming a complete target binary file set. Checking the integrity and correctness of the file ensures that all necessary files are present and not damaged, and can be verified by a file hash check (e.g., md5sum or sha256 sum). On the target server, the appropriate permissions to archive the files are set to ensure that the Java application can properly access and execute the files. And setting file authority by using a Linux command line, and setting stricter access authority for an encrypted file containing sensitive information to prevent an unauthorized user from accessing. After the file replication is completed, a simple test run is performed to ensure that all files can be loaded and executed correctly. The application log is reviewed to ensure that no errors are loaded or executed.
By copying the unencrypted and encrypted archive file set to the target server's designated directory, the enterprise is able to efficiently deploy Java applications. The process comprises the steps of preparing a target directory, uploading a file, verifying the integrity of the file, setting rights, testing operation and the like. The security and reliability of the application program can be ensured, and errors and potential safety hazards possibly occurring in the deployment process are reduced.
And step S600, data decryption of the target binary file set is executed under the appointed directory of the target server, and the archive files which are successfully decrypted and the unencrypted archive files are loaded into the JVM memory of the target server by utilizing a custom class loader, wherein the custom class loader is constructed based on C++ language.
Specifically, the decryption operation of the DES encrypted file is realized by using a Java. Cryptio library or a third party library in Java. It is necessary to generate a decryption key by reading the key file and decrypt the encrypted class. And reading the content of the encrypted file into the memory, decrypting the file content by using the generated decryption key through a DES decryption algorithm, and recovering the original byte code data. The decryption key is generated by MD5 using information in the key file, such as creation time and physical address.
Since the target JVM is a custom version, the custom class loader is written in C++, compatible with loading encrypted class. Sec and normal class files. The custom class loader interacts with the C++ code through JNI (Java NATIVE INTERFACE) to realize decryption and loading logic of the encrypted file. And the class loader judges whether the file is encrypted or not according to the file extension, if the file is encrypted, the class loader firstly executes decryption, and then loads the decrypted byte code into the JVM memory.
And loading and executing Java application programs by using a custom class loader, and loading all required class files through a custom ClassLoader instance. The customized class loader supports loading of unencrypted common byte code files, and ensures compatibility with a standard Java class loader. The application is started and critical functions are tested to ensure that all class files (encrypted and unencrypted) are loaded and executed correctly.
By performing data decryption on the target server and loading the Java bytecode file using the custom class loader, the enterprise can effectively protect the security of its Java applications. The customized class loader is compatible with the standard class loader, and meanwhile, a decryption function is added, so that an application program can utilize the cross-platform characteristic of Java and ensure the security of core logic of the application program.
Further, generating the encryption key comprises the steps of obtaining creation time of the key file under the Java running environment directory, reading a physical address of a target server, splicing the creation time and the physical address, encrypting spliced content by utilizing an MD5 encryption algorithm, and generating the encryption key.
Specifically, the MD5 encryption algorithm is a hash algorithm that converts input data into a fixed-length hash value, typically used for data integrity verification.
In the process of secure deployment of a Java application, in order to generate a unique encryption key, first, the creation time of a key file under the Java running environment directory and the physical address of the server need to be obtained from the target server. Creation time may be obtained by file properties or operating system commands, e.g., on a Linux system, the detailed information of the file may be viewed using a stat command, while physical addresses may be obtained by system commands such as ipconfig/all (Windows) or ifconfig (Linux). Suppose the key file is created at a time of "2024-08-0110:30:45" and the physical address is "00:1A:2B:3C:4D:5E".
Next, the creation time and physical address are concatenated into a string of "2024-08-0110:30:4500:1A:2B:3C:4D:5E". The splice string combines time and hardware identification information of the device, ensuring its uniqueness. The string is then encrypted using the MD5 encryption algorithm to generate a hash of the 32-bit character as the encryption key. The use of the MD5 algorithm may be implemented by library functions in various programming languages, for example in Java, MD5 encryption may be implemented using the Java security. Assume that the generated MD5 hash value is "e99a18c428cb38d5f260853678922e03", which is the key used to encrypt the bytecode file.
By obtaining the creation time of the key file and the physical address of the server and generating the encryption key using the MD5 algorithm, the enterprise is able to generate a unique and secure encryption key for its Java application. Security and protection of the application is ensured and unauthorized access and use is prevented.
Further, determining the archive file set to be encrypted and the non-encrypted archive file set comprises configuring a preset business index based on business logic of a target enterprise, screening the target archive file set according to the preset business index, setting target archive files related to the preset business index as archive files to be encrypted, and setting target archive files not related to the preset business index as non-encrypted archive files to obtain the archive file set to be encrypted and the non-encrypted archive file set.
In particular, target enterprise business logic, which refers to the specific functions and operational rules implemented by an enterprise in its applications, is generally closely related to the core business and competitiveness of the enterprise.
The enterprise's core business processes and application architecture are analyzed to identify which functions and logic are critical or sensitive. Such as transaction processing modules in financial software, customer information management modules, and the like.
Based on the analysis results, which files need encryption protection is defined. The business indicia may include modules related to financial calculations, user authentication and authorization modules, data encryption and decryption algorithms, and the like.
The screening process is automated using code analysis tools or scripts. For example, files related to a particular package or class are identified using Java analysis tools (e.g., JDepend or SonarQube). And scanning and analyzing the byte code files in the target archive file set, and marking out files matched with the preset business indexes. Tools such as regular expressions are used to search for file names or package names to help identify files that need to be encrypted.
And marking the file matched with the business index as a file to be encrypted. Files that do not meet the business criteria are marked as unencrypted files. The manifest of the files to be encrypted and unencrypted are recorded for subsequent encryption and deployment use. And encrypting the file to be encrypted by using the encryption key generated before according to the generated file list to be encrypted. The encrypted and unencrypted file sets are prepared for deployment to the target server.
For example, in an online payment system, businesses recognize modules involved in transaction processing and customer authentication as sensitive components. The bytecode files of these modules are screened as files to be encrypted, ensuring protection at deployment time. Medical software companies have developed an electronic health record management system in which logic that handles patient data and medical decision support is identified as requiring encryption protection. Through analysis of business logic, companies screen out the key modules for encryption, and patient privacy and data security are ensured.
By configuring predetermined business metrics and screening the target archive file set based on the business logic of the enterprise, the enterprise can efficiently identify and encrypt the byte code files that need to be protected. The process ensures that key business logic and sensitive information of enterprises are protected in the deployment process, and reduces risks caused by code leakage. By using an automation tool and an explicit business index, enterprises can efficiently realize the protection measure and ensure the safety and reliability of Java application programs of the enterprises.
Further, as shown in FIG. 4, the method comprises the steps of loading the successfully decrypted archive file and the unencrypted archive file into the JVM memory of the target server by using a custom class loader, wherein the custom class loader comprises the steps of respectively judging whether a plurality of target binary files in the target binary file set are encrypted or not under the appointed directory of the target server, and if the target binary files are the encrypted archive files, carrying out data decryption on the encrypted archive files, and loading the successfully decrypted archive files into the JVM memory of the target server by using the custom class loader according to an encryption loading mode, wherein the custom class loader is constructed based on C++ language writing, and can execute an original loading mode and an encryption loading mode.
In particular, it is ensured that all target binary files (including encrypted and unencrypted files) are stored in a specified directory of the server. Whether the file is an encrypted archive file is determined by a file extension (e.g., class. Sec) or a file header identification. This can be achieved by simple file traversal and extension checking.
Data decryption is achieved using encryption libraries in Java or C++ (e.g., openSSL, bouncy Castle, etc.). By reading the contents of the encrypted file, it is decrypted into the original bytecode using the generated encryption key. After reading the encrypted file, the data is converted into a loadable original byte code form through a customized decryption algorithm so as to be loaded by a customized class loader.
Custom class loaders are written in c++, interacting with JVM using JNI. An appropriate loading policy can be selected according to the encryption status of the file. For encrypted files, the custom class loader first invokes a decryption function and then loads the decrypted bytecode into the JVM memory.
By loading the encrypted Java bytecode file on the target server using a custom class loader, the enterprise can ensure the security and functionality of the application. Custom class loaders combine decryption and loading functions so that applications can run securely in different environments.
Further, as shown in fig. 4, if the target binary file is an unencrypted archive file, the unencrypted archive file is loaded into the JVM memory of the target server by using a custom class loader according to the original loading mode.
Specifically, for unencrypted files, the custom class loader directly invokes the standard loading method, loading the bytecode into the JVM memory. The original loading mode is a loading flow of a standard Java class loader and is used for loading an unencrypted byte code file.
Further, as shown in fig. 4, the data decryption of the encrypted archive file includes reading a second creation time of a key file under a Java running environment directory and a second physical address of a current server, splicing the second creation time and the second physical address, encrypting the second spliced content by using an MD5 encryption algorithm to generate a decryption key, decrypting the data of the encrypted archive file by using a DES data encryption algorithm based on the decryption key, and reporting and exiting if decryption fails.
In particular, the second creation time refers to the last creation or modification time of the key file on the server, which is typically used to generate the decryption key. The second physical address refers to the MAC address of the current network interface card of the target server, providing a hardware unique identifier.
And on the target server, acquiring the second creation time and the physical address of the current server by reading the key file under the Java running environment directory. This information is used to generate a decryption key. The second creation time is obtained and file attributes may be read using a file system command or programming interface. For example, on Linux, a stat command may be used to obtain the creation or modification time of a file. Acquiring the second physical address acquires the MAC address of the server through a system command or an API. Ipconfig/all can be used on Windows and ifconfig or ip addr commands can be used on Linux.
And splicing the second creation time and the second physical address into a character string, and encrypting the spliced content by using an MD5 algorithm to generate a hash value of 32-bit characters as a decryption key. Splice format, for example, assume that the creation time is "2024-08-01:30:45", the physical address is "00:1A:2B:3C:4D:5E", and the splice result is "2024-08-01 10:30:4500:1A:2B:3C:4D:5E".
The concatenated string is MD5 encrypted using java.security.messagedigest of Java or a hash library of other programming languages to generate a decryption key (e.g., "e99a18c428cb38d5f260853678922e 03").
The encrypted byte code file is decrypted by the DES algorithm, and its original content is restored for loading. Decryption is performed using Java. Crypto package of Java or other encryption library (such as OpenSSL). During decryption, the key length and the format need to be ensured to meet the requirements of a DES algorithm. The encrypted file is read, its contents are passed to a decryption function, and the decryption key is used to restore the encrypted byte code.
If the decryption process fails, the system needs to report an error and exit to ensure that the file in the unauthorized or erroneous environment cannot be loaded. Anomalies in the decryption process (e.g., key mismatch, file corruption, etc.) are captured, journaled, and the load operation is terminated. It is ensured that the application program does not continue to load incomplete or erroneous bytecode files when decryption fails.
By decrypting the encrypted archive file, the scheme ensures secure deployment and execution of the Java application on the target server. The decryption key is generated by using the creation time of the key file and the physical address of the server, and a flexible and safe loading solution is provided by combining the DES decryption algorithm. Through a strict decryption process and error handling, enterprises can reduce the risks of code leakage and unauthorized access while ensuring the security of application programs. The scheme effectively enhances the safety and deployment flexibility of Java application programs, and is suitable for various complex enterprise environments.
In summary, the method for encrypting and deploying the byte code file provided by the embodiment of the application has the following technical effects:
1. By generating a key file under the Java running environment directory of the target server and generating an encryption key based on the file creation time and the physical address, the key uniqueness of each server is ensured, thereby increasing the security of the application program. The method can effectively prevent the reuse and leakage of the encryption key, and improves the security of the system, especially when different servers are deployed. The method has the technical effects that a unique encryption key is provided for each deployment environment, unauthorized environments are prevented from accessing and using the byte code files of the application program, and the safety and reliability of the whole deployment are enhanced.
2. By splicing the creation time of the key file and the physical address of the target server and generating the encryption key by utilizing the MD5 algorithm, the automation and the uniqueness of the generation process are realized. The hash value generated by the MD5 is used as an encryption key, so that the uniqueness and the security of the key are ensured, and the key collision and counterfeiting are effectively prevented. The technical effect of the method is that the encryption key is bound with the specific server, so that the difficulty of unauthorized access is increased, the safe deployment of Java byte code files on different servers is guaranteed, and the confidentiality of an application program is improved.
3. By identifying and categorizing the set of archive files to be encrypted and unencrypted in a Java application, an enterprise is able to centrally protect critical business logic and sensitive information. And screening files to be encrypted according to the preset business indexes, and ensuring that the core functions and the proprietary algorithms of enterprises are not leaked. The method has the technical effects of optimizing the use of encryption resources, reducing the processing overhead of encryption and decryption, ensuring that sensitive information is effectively protected, and improving the safety and performance of application programs.
4. By using a custom class loader to decrypt and load encrypted archive files, it is ensured that only authorized files are loaded and executed in the correct environment. The custom class loader can recognize the encrypted file and automatically decrypt the encrypted file, so that the deployment process is safer and more automated. The technical effect is that the transparency and the control force of the decryption process are increased, so that the safety of the application program is improved, unauthorized file loading and execution are avoided, and the safe operation of the Java application program under different environments is ensured.
In a second embodiment, based on the same inventive concept as the method for encrypting and deploying a bytecode file in the foregoing embodiment, as shown in fig. 2, an embodiment of the present application provides an apparatus for encrypting and deploying a bytecode file, where the apparatus includes:
The encryption key generation module is used for generating a key file under a Java running environment directory of the target server, acquiring the creation time of the key file and the physical address of the target server, generating an encryption key based on the creation time and the physical address, and storing the encryption key into the key file, wherein the key file is a 32-bit random character;
the compiling and packaging module is used for obtaining a Java source file, compiling and packaging the Java source file to obtain a target archive file set, wherein the target archive file comprises a plurality of byte code files;
the archive file set identification module is used for identifying a target archive file set and determining an archive file set to be encrypted and a non-encrypted archive file set, wherein the archive file to be encrypted is an archive file related to a preset business index;
The symmetric encryption module is used for symmetrically encrypting the archive file to be encrypted by utilizing a DES data encryption algorithm based on the encryption key in the key file to obtain an encrypted archive file set;
the binary file set obtaining module is used for copying the non-encrypted archive file set and the encrypted archive file set to a designated directory of a target server to obtain a target binary file set;
And the data decryption module is used for executing data decryption of the target binary file set under the appointed directory of the target server, and loading the archive files successfully decrypted and the unencrypted archive files into the JVM memory of the target server by utilizing the custom class loader, wherein the custom class loader is constructed based on C++ language.
Embodiment three fig. 3 is a schematic structural diagram of an electronic device provided in embodiment three of the present invention, and shows a block diagram of an exemplary electronic device suitable for implementing an embodiment of the present invention. The electronic device shown in fig. 3 is only an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention. As shown in fig. 3, the electronic device includes a processor 31, a memory 32, an input device 33 and an output device 34, where the number of processors 31 in the electronic device may be one or more, and in fig. 3, one processor 31 is taken as an example, and the processor 31, the memory 32, the input device 33 and the output device 34 in the electronic device may be connected by a bus or other manners, and in fig. 3, the connection by a bus is taken as an example.
The memory 32 is used as a computer readable storage medium for storing software programs, computer executable programs and modules, such as program instructions/modules corresponding to a method for encrypting a deployment of a bytecode file in an embodiment of the present invention. The processor 31 executes various functional applications of the computer device and data processing, namely, implements the above-described method of byte code file encryption deployment by running software programs, instructions and modules stored in the memory 32.
The application provides a byte code file encryption deployment device, wherein the method is applied to the byte code file encryption deployment device, the method comprises the steps of firstly obtaining Java source files, compiling and packaging the Java source files into a target archive file set, and then identifying the file set needing to be encrypted according to a preset business index. These files are encrypted using the encryption key and DES algorithm in the key file, and the encrypted and unencrypted files are deployed to the target server. Custom class loaders are used to load these files on a server, which can perform decryption and loading operations based on the encryption status of the files. By reading the creation time of the key file and the physical address of the server, the system generates a decryption key to securely decrypt the file, ensuring that these bytecode files are only accessible and executable in the correct environment. The scheme effectively protects the key business logic and sensitive information of enterprises, prevents unauthorized access and reverse engineering, and enhances the safety and deployment flexibility of application programs.
Note that the above is only a preferred embodiment of the present invention and the technical principle applied. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, while the invention has been described in connection with the above embodiments, the invention is not limited to the embodiments, but may be embodied in many other equivalent forms without departing from the spirit or scope of the invention, which is set forth in the following claims.