Application program processing method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides an application program processing method and device, electronic equipment and a storage medium, and relates to the technical field of software security. The method comprises the steps that in response to a starting instruction for a target Java application, an encrypted file of the target Java application is obtained; if the electronic equipment is connected with the key storage medium equipment, verifying the key storage medium equipment, determining a shelling program for the encrypted file under the condition that the verification is passed, and carrying out shelling processing on the encrypted file through the shelling program to obtain an encrypted application file corresponding to the target Java program; secret key information in the secret key storage medium equipment is used for decrypting the encrypted application file to obtain an application file corresponding to the target Java application, the application file is extracted to a temporary directory, the application file in the temporary directory is loaded to the virtual machine, and the application file comprises a Java file; and in response to a loading instruction for the target Java application, reflecting and calling the target Java class file corresponding to the loading instruction.

Description

Technical Field

[0001] The present invention relates to the field of software security technology, and in particular to a method for processing an application, a device for processing an application, an electronic device, and a computer-readable storage medium. Background Art

[0002] In today's application development field, Java language is widely used due to its cross-platform, object-oriented and rich class libraries. However, the bytecode files of Java programs are relatively easy to be decompiled, which poses a great challenge to the intellectual property protection and security of applications. However, in the process of protecting applications, there are still problems such as easy decompilation, insufficient security, and insufficient security in the loading process. Summary of the invention

[0003] The embodiments of the present invention provide a method, device, electronic device and computer-readable storage medium for processing an application program to solve or partially solve the problems of being easily decompiled, insufficiently secure and having an insecure loading process during the protection process of the application program.

[0004] An embodiment of the present invention discloses a method for processing an application program, which is applied to an electronic device. The method includes:

[0005] In response to a start instruction for a target Java application, an encrypted file of the target Java application is obtained, and it is detected whether the electronic device is currently connected to a key storage medium device for the target Java application, wherein the encrypted file is a file obtained by encapsulating the target Java application;

[0006] If the electronic device is connected to the key storage medium device, verify the key storage medium device, and if the verification passes, determine a deshelling program for the encrypted file, and deshell the encrypted file using the deshelling program to obtain an encrypted application file corresponding to the target Java program;

[0007] Decrypting the encrypted application file using the key information in the key storage medium device, obtaining an application file corresponding to the target Java application, extracting the application file to a temporary directory, and loading the application file in the temporary directory into the virtual machine, wherein the application file includes a Java class file;

[0008] In response to a loading instruction for the target Java application, a target Java class file corresponding to the loading instruction is reflectively called from the application file loaded into the virtual machine.

[0009] Some possible implementations also include:

[0010] In response to a shelling instruction for the target Java application, a Java class file of the target Java application is obtained, and the Java class file is shelled to generate an encrypted application file;

[0011] The encrypted application file is encapsulated into a Zip format and encrypted again using a preset algorithm to obtain an encrypted file corresponding to the target Java application.

[0012] Some possible implementations also include:

[0013] Obtain an unpacking program corresponding to the target Java application, and package the encrypted file with the unpacking program to obtain a deployment file corresponding to the target Java program.

[0014] In some feasible implementations, the verifying the key storage medium device and, if the verification passes, determining an unpacking program for the encrypted file includes:

[0015] Reading the key information in the key storage medium device;

[0016] Obtaining the verification logic built into the target Java application;

[0017] The key information is verified by the verification logic, and when the verification passes, a depacketizing program for the encrypted file is determined.

[0018] In some feasible implementations, the verifying the key storage medium device and, if the verification passes, determining an unpacking program for the encrypted file includes:

[0019] Reading verification information in the key storage medium device;

[0020] Obtaining the verification logic built into the target Java application;

[0021] The verification information is verified by the verification logic, and when the verification passes, a depacketizing program for the encrypted file is determined.

[0022] In some feasible implementations, loading the application file into the virtual machine includes:

[0023] Determining a class loader for the target Java application;

[0024] The application file is loaded into the virtual machine of the server through the class loader.

[0025] Some possible implementations also include:

[0026] In response to completion of calling the application file, deleting the application file in the temporary directory.

[0027] The embodiment of the present invention further discloses a device for processing an application program, which is applied to an electronic device, and the device includes:

[0028] a detection module, configured to, in response to a start instruction for a target Java application, obtain an encrypted file of the target Java application and detect whether the electronic device is currently connected to a key storage medium device for the target Java application, wherein the encrypted file is a file obtained by encapsulating the target Java application;

[0029] a verification module, configured to verify the key storage medium device if the electronic device is connected to the key storage medium device, and if the verification passes, determine a deshelling program for the encrypted file, and deshell the encrypted file using the deshelling program to obtain an encrypted application file corresponding to the target Java program;

[0030] A file decryption module, used to decrypt the encrypted application file using the key information in the key storage medium device, obtain the application file corresponding to the target Java application, extract it to a temporary directory, and load the application file in the temporary directory into the virtual machine, wherein the application file includes a Java class file;

[0031] The file loading module is used to respond to the loading instruction for the target Java application and reflectively call the target Java class file corresponding to the loading instruction from the application file loaded into the virtual machine.

[0032] Some possible implementations also include:

[0033] A shell module, configured to, in response to a shell instruction for the target Java application, obtain a Java class file of the target Java application, and perform shell processing on the Java class file to generate an encrypted application file;

[0034] The encapsulation module is used to encapsulate the encrypted application file into a Zip format and perform secondary encryption using a preset algorithm to obtain an encrypted file corresponding to the target Java application.

[0035] Some possible implementations also include:

[0036] The packaging module is used to obtain a shell removal program corresponding to the target Java application, and to package the encrypted file with the shell removal program to obtain a deployment file corresponding to the target Java program.

[0037] In some feasible implementations, the verification module is specifically used to:

[0038] Reading the key information in the key storage medium device;

[0039] Obtaining the verification logic built into the target Java application;

[0040] The key information is verified by the verification logic, and when the verification passes, a depacketizing program for the encrypted file is determined.

[0041] In some feasible implementations, the verification module is specifically used to:

[0042] Reading verification information in the key storage medium device;

[0043] Obtaining the verification logic built into the target Java application;

[0044] The verification information is verified by the verification logic, and when the verification passes, a depacketizing program for the encrypted file is determined.

[0045] In some feasible implementations, the file decryption module is specifically used to:

[0046] Determining a class loader for the target Java application;

[0047] The application file is loaded into the virtual machine of the server through the class loader.

[0048] Some possible implementations also include:

[0049] The deleting module is used to delete the application file in the temporary directory in response to completion of calling the application file.

[0050] The embodiment of the present invention further discloses an electronic device, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus;

[0051] The memory is used to store computer programs;

[0052] The processor is used to implement the method described in the embodiment of the present invention when executing the program stored in the memory.

[0053] The embodiment of the present invention further discloses a computer-readable storage medium having instructions stored thereon, which, when executed by one or more processors, enables the processors to execute the method described in the embodiment of the present invention.

[0054] The embodiments of the present invention include the following advantages:

[0055] In an embodiment of the present invention, during the process of processing an application, an encrypted file of the target Java application can be obtained by responding to a startup instruction for the target Java application, and it can be detected whether the electronic device is currently connected to a key storage medium device for the target Java application. The encrypted file is a file obtained by shelling the target Java application. If the electronic device is connected to a key storage medium device, the key storage medium device is verified, and if the verification passes, a shelling program for the encrypted file is determined, and the encrypted file is shelled by the shelling program to obtain the encrypted application file corresponding to the target Java program, and then the encrypted application file is decrypted using the key information in the key storage medium device. The application file corresponding to the target Java application is obtained and extracted to a temporary directory, and the application file in the temporary directory is loaded into the virtual machine, where the application file includes a Java class file. Then, in response to the loading instruction for the target Java application, the target Java class file corresponding to the loading instruction is reflectively called from the application file loaded into the virtual machine. Thus, in the process of reinforcing the application, the security of the application file is effectively guaranteed through shelling and unshelling, and the encryption key is stored by hardware devices such as key storage media devices, thereby realizing physical isolation of the encryption key, further improving the security of the application, and dynamically loading the class file during the running of the application, thereby improving the flexibility and scalability of the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Figure 1 is a flowchart of a method for processing an application program provided in an embodiment of the present invention;

[0057] Figure 2 is a processing flow chart of an application program provided in an embodiment of the present invention;

[0058] Figure 3 is a processing sequence diagram of an application provided in an embodiment of the present invention;

[0059] Figure 4 is a structural block diagram of a processing device for an application provided in an embodiment of the present invention;

[0060] Figure 5 It is a block diagram of an electronic device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0061] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.

[0062] As an example, in today's application development field, Java language is widely used due to its advantages such as cross-platform, object-oriented and rich class libraries. However, the bytecode files of Java programs are relatively easy to be decompiled, which poses a great challenge to the intellectual property protection and security of applications. Traditional application protection methods mainly include code obfuscation and encryption. Although code obfuscation can increase the difficulty of decompilation, it cannot completely prevent decompilation. Encryption technology can protect applications to a certain extent, but if the encryption algorithm is cracked or the key is stolen, the application still faces the risk of being decompiled. In addition, with the continuous improvement of application security requirements, simple static protection can no longer meet the needs. Dynamic loading technology can load classes or resources as needed when the program is running, increasing the flexibility and security of the application. However, the current dynamic loading technology also has some problems, such as the loaded class is easy to be decompiled and the loading process is not safe enough.

[0063] In this regard, in the present invention, a method for implementing a class of secure shell reinforcement and shell removal dynamic loading based on Java is constructed. Specifically, in the process of processing the application, the encrypted file of the target Java application can be obtained by responding to the startup instruction for the target Java application, and it is detected whether the electronic device is currently connected to a key storage medium device for the target Java application. The encrypted file is a file obtained by shelling the target Java application. If the electronic device is connected to a key storage medium device, the key storage medium device is verified, and if the verification passes, the shell removal program for the encrypted file is determined, and the encrypted file is shelled by the shell removal program to obtain the encrypted application file corresponding to the target Java program, and then the key storage medium device is used to detect whether the key storage medium device is currently connected to the electronic device. The encrypted application file is decrypted with the key information in the backup, the application file corresponding to the target Java application is obtained, and the application file is extracted to a temporary directory, and the application file in the temporary directory is loaded into the virtual machine, where the application file includes a Java class file, and then in response to the loading instruction for the target Java application, the target Java class file corresponding to the loading instruction is reflectively called from the application file loaded into the virtual machine, so that in the process of reinforcing the application, the security of the application file is effectively guaranteed through processing such as shelling and unshelling, and the key is stored by hardware devices such as key storage medium devices, so as to realize the physical isolation of the encryption key, further improve the security of the application, and dynamically load the class file during the running of the application, so as to improve the flexibility and scalability of the application.

[0064] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, some technical features involved in the embodiments of the present invention are explained and illustrated below:

[0065] JAVA SDK: Software Development Kit, which is an application development kit, provides various tools and libraries required for Java development and is used to develop Java applications.

[0066] Shelling: It is a technical means to protect applications. By encrypting, compressing or transforming executable files, it is decrypted and restored by a specific shelling program before running, so as to increase the security of the application and prevent it from being decompiled and tampered with.

[0067] Hardening: A series of security enhancement measures are taken on the application. In addition to shelling, these measures may also include code obfuscation, anti-debugging, and other measures to improve the application's ability to resist attacks.

[0068] Unpacking: Corresponding to packing, it is the process of restoring the packed file to an executable state when the application is running.

[0069] Dynamic loading: During program execution, classes or resources are dynamically loaded as needed, rather than loading all at once when the program starts.

[0070] Class loader: In Java, it is responsible for loading the bytecode of a class into memory and generating the corresponding Class object.

[0071] Reflection: A mechanism in Java that allows a program to inspect and manipulate information about classes, methods, fields, etc., and to call them at runtime.

[0072] Key storage medium: A secure storage device used to store keys or decryption programs, providing higher security, similar to the USB shield used by banks.

[0073] Reference Figure 1 , shows a flowchart of a method for processing an application program provided in an embodiment of the present invention, which is applied to an electronic device and may specifically include the following steps:

[0074] Step 101, in response to a start instruction for a target Java application, obtaining an encrypted file of the target Java application, and detecting whether the electronic device is currently connected to a key storage medium device for the target Java application, wherein the encrypted file is a file obtained by encapsulating the target Java application;

[0075] In the process of processing a Java application (hereinafter referred to as a Java application), the following process can be executed to shell and harden the Java application and dynamically load the implementation class: ① shelling process; ② key storage medium device verification; ③ unshelling process; ④ dynamic loading and calling; ⑤ security cleaning, etc., so that in the process of hardening the application, the security of the application file is effectively guaranteed through shelling and unshelling, and the key is stored by hardware devices such as key storage medium devices, so as to realize the physical isolation of encryption keys, further improve the security of the application, and in the process of application operation, the class file is dynamically loaded, which improves the flexibility and scalability of the application.

[0076] It should be noted that for Java applications, the corresponding architecture may include:

[0077] APP: an example demo for calling the SDK interface, which depends on the unpackshelllib and commonInteface modules; CaculateSDK: the implementation of the SDK, which depends on the commonInteface module; crypylib: an encryption and decryption library, which requires obfuscation during the actual development process and can be implemented using C / C++; shelllib: a script project for shelling CaculateSDK; unpackshelllib: the shelling project that APP actually depends on, which includes decryption and shelling, and dynamic loading; commonInteface: a piling interface that APP needs to embed in advance.

[0078] In some feasible implementations, for the shelling process of Java applications, the electronic device can respond to the shelling instruction for the target Java application, obtain the Java class file of the target Java application, and perform shelling on the Java class file to generate an encrypted application file, then encapsulate the encrypted application file into a Zip format, and perform secondary encryption using a preset algorithm to obtain an encrypted file corresponding to the target Java application. In addition, by obtaining a shelling program corresponding to the target Java application and packaging the encrypted file with the shelling program, a deployment file corresponding to the target Java program is obtained.

[0079] In the specific implementation, for the shelling process of Java application, first obtain the Java class file of the target Java application, which can be located in the target directory or build directory of the project. After obtaining the class file, you can use professional obfuscation tools (such as ProGuard, DashO, Allatori, etc.) to confuse the Java class file and configure the obfuscation rules, including the obfuscation of class name, method name, and field name. Then, use encryption algorithms (such as AES (Advanced Encryption Standard, Advanced Encryption Standard), DES (Data Encryption Standard)) to encrypt the obfuscated Java class file to generate an encrypted Java class file. The encrypted Java class file is packaged into an encrypted application file (such as JAR or EXE file), and then the encrypted application file is packaged into Zip format using the Zip tool. The packaged Zip file is encrypted twice, and the preset encryption algorithm (such as RSA (RSA algorithm, encryption algorithm), AES) is used to increase the difficulty of cracking, and the final encrypted file is generated, thereby realizing the separation of the main implementation class code and the interface layer of the project, and improving the maintainability and security of the software. After the interface layer is packaged, it is encrypted into a Zip file through a packer to increase the security of the interface layer and prevent malicious tampering.

[0080] After completing the above shelling process, you can further obtain the shelling program corresponding to the target Java application, which is responsible for decrypting and loading the encrypted application file at runtime. By packaging the encrypted file with the shelling program to generate the final deployment file, this series of steps can significantly improve the security of the Java application and prevent decompilation and reverse engineering.

[0081] Through the above process, the Java application is shelled and reinforced, and the processed Java application can be deployed on an electronic device. When the user enters a startup instruction for the target Java application, the electronic device can obtain the encrypted file of the target Java application and detect whether the electronic device is currently connected to a key storage medium device for the target Java application, so that before decrypting the target Java application, it is first detected whether the electronic device is connected to a corresponding key storage medium device, so as to perform verification through the key storage medium device, thereby increasing the security of the decryption process and preventing the key from being stolen or cracked.

[0082] It should be noted that the key storage medium device may be a hardware device that stores the corresponding key or verification information. Through the combination of software and hardware, the physical isolation of the encryption key is achieved, thereby improving the security of the system.

[0083] Step 102: if the electronic device is connected to the key storage medium device, verify the key storage medium device, and if the verification passes, determine a deshelling program for the encrypted file, and deshell the encrypted file using the deshelling program to obtain an encrypted application file corresponding to the target Java program;

[0084] Before decrypting the target Java application, the electronic device can detect whether a key storage medium device is connected. If the electronic device is connected to the key storage medium device, the key storage medium device is verified, and if the verification passes, an unpacking program for the encrypted file is determined, and the encrypted file is unpacked by the unpacking program to obtain the encrypted application file corresponding to the target Java program; if the electronic device is not connected to the key storage medium, a prompt message for the target Java application is output, and the user is prompted through the prompt message that the target Java application cannot be decrypted at present to ensure data security.

[0085] In the case where it is detected that the electronic device is connected to a corresponding key storage medium device, the electronic device may further detect whether the key storage medium device is a legitimate key storage medium device, so as to improve the security of the application.

[0086] In some feasible implementations, the key information in the key storage medium device can be read, and the verification logic built into the target Java application can be obtained, and then the key information can be verified by the verification logic, and if the verification passes, the de-shelling program for the encrypted file can be determined. In other feasible implementations, the verification information in the key storage medium device can be read, and the verification logic built into the target Java application can be obtained, and then the verification information can be verified by the verification logic, and if the verification passes, the de-shelling program for the encrypted file can be determined.

[0087] Among them, the key information can be a decryption key stored in a key storage medium device, which is used to verify the legitimacy of the device and ensure that only authorized devices can decrypt and use the target Java application; the verification information can be algorithm information stored in a key storage medium device, which is used to verify the legitimacy of the device and also to ensure that only authorized devices can decrypt and use the target Java application; the verification logic can be logic information built into the target Java application, which is used to verify the legitimacy of the key information or verification information and ensure that only legitimate keys or verification information can pass the verification to prevent access by unauthorized devices; the unpacking program can be a program responsible for decrypting and loading encrypted application files at runtime. After the key storage medium device is verified, the unpacking program is started and the application is decrypted and loaded based on the unpacking program, thereby ensuring the security of the application.

[0088] In one example, for the verification process of the key storage medium device, the smart card device or USB device can be detected by using the Java javax.smartcardio package to obtain the connection object of the device. Then, the key information or verification information is read from the device through the APDU (Application Protocol Data Unit) command, and the read information is stored in the memory for subsequent verification. The verification logic is pre-defined in the target Java application, usually a method or a group of methods. The verification logic can include an encryption algorithm (such as HMAC (Hashed Message Authentication Code, message authentication code), digital signature) and comparison logic. Based on the defined verification logic, the key information or verification information read from the device is passed in by calling the built-in verification logic method. The verification logic method performs encryption and comparison operations to determine whether the information is legal. If the verification passes, true is returned, indicating that the device is legal; if the verification fails, false is returned, indicating that the device is illegal. Then, if the verification passes, the pre-defined shelling program can be started, and the encrypted file is shelled by the shelling program to obtain the encrypted application file corresponding to the target Java program.

[0089] Step 103, decrypting the encrypted application file using the key information in the key storage medium device, obtaining the application file corresponding to the target Java application, extracting the application file to a temporary directory, and loading the application file in the temporary directory into the virtual machine, wherein the application file includes a Java class file;

[0090] After decrypting the encrypted file of the target Java application by unpacking to obtain the encrypted application file, the corresponding key information can be further extracted from the key storage medium device to perform secondary decryption on the encrypted application file to obtain the application file corresponding to the target Java application, and the application file is extracted to a temporary directory, and then the application file in the temporary directory is loaded into the virtual machine of the electronic device to start the target Java application. Optionally, the virtual machine can be a Java virtual machine.

[0091] During the loading process, the electronic device can start the target Java application by determining a class loader for the target Java application and then loading the application file into the Java virtual machine of the server through the class loader.

[0092] Step 104 : In response to a loading instruction for the target Java application, reflectively call a target Java class file corresponding to the loading instruction from the application file loaded into the virtual machine.

[0093] After the target Java application is started, the user can execute the corresponding functions in the target Java application, and the target Java application needs to call the corresponding Java class file when providing the corresponding functions. Specifically, in response to the loading instruction for the target Java application, the target Java class file corresponding to the loading instruction is reflected and called from the application file loaded into the virtual machine to implement the corresponding application function, thereby realizing dynamic loading and calling of class files by using class loaders and reflection technology, and enhancing the flexibility and scalability of the system. In addition, the electronic device can also delete the application file in the temporary directory in response to the completion of the call of the application file, thereby effectively preventing the leakage of the source code by deleting the corresponding file, and improving the overall security of the application.

[0094] In one example, referring to Figure 2 , showing a processing flow chart of an application provided in an embodiment of the present invention, referring to Figure 3 , shows a processing sequence diagram of an application provided in an embodiment of the present invention. The processing process of the application may include:

[0095] (1) Shelling process:

[0096] Use professional packing tools to confuse and encrypt the core classes in the JAVA SDK to generate encrypted JAR files.

[0097] The encrypted JAR file is encapsulated into ZIP format and re-encrypted using a custom algorithm to increase the difficulty of cracking.

[0098] Package the encrypted ZIP file with the packer program and prepare for deployment.

[0099] (2) Key storage medium verification:

[0100] At the beginning of software startup, check whether the authorized key storage media device has been inserted.

[0101] The legitimacy of the device is ensured by matching the key or specific algorithm in the key storage medium with the verification logic built into the software.

[0102] (3) Shelling process:

[0103] If the key storage medium is verified, the unpacking procedure is started.

[0104] The unpacker reads the encrypted ZIP file and decrypts it using the key in the key storage medium or the built-in decryption algorithm.

[0105] After decryption, the JAR file inside the ZIP file is extracted to a temporary directory and prepared to be loaded.

[0106] (4) Dynamic loading and calling:

[0107] Use a custom class loader to dynamically load the decrypted JAR file into the JVM.

[0108] Through the reflection mechanism, the methods in the implementation class are dynamically called according to the requirements of the interface layer.

[0109] (5)Safety cleaning:

[0110] After the class is loaded and called, the JAR file in the temporary directory is deleted immediately to prevent source code leakage.

[0111] Record and monitor the entire process of packing, unpacking and loading to ensure the safety and traceability of operations.

[0112] In the above process, the encryption key is stored in hardware devices such as key storage media, which realizes the physical isolation of encryption keys and improves the security of the system. The class loader and reflection technology are used to realize the dynamic loading and calling of encrypted JAR files, which enhances the flexibility and scalability of the system. The JAR files are deleted immediately after unpacking, which effectively prevents the leakage of source code and improves the overall security of the software. In addition, during the application processing, the entire packing, unpacking and loading process can be recorded and monitored to ensure the safety and traceability of the operation, which is convenient for troubleshooting and locating problems.

[0113] It should be noted that the embodiments of the present invention include but are not limited to the above examples. It is understandable that those skilled in the art can also make settings according to actual needs under the guidance of the ideas of the embodiments of the present invention, and the present invention is not limited to this.

[0114] In an embodiment of the present invention, during the process of processing an application, an encrypted file of the target Java application can be obtained by responding to a startup instruction for the target Java application, and it can be detected whether the electronic device is currently connected to a key storage medium device for the target Java application. The encrypted file is a file obtained by shelling the target Java application. If the electronic device is connected to a key storage medium device, the key storage medium device is verified, and if the verification passes, a shelling program for the encrypted file is determined, and the encrypted file is shelled by the shelling program to obtain the encrypted application file corresponding to the target Java program, and then the encrypted application file is decrypted using the key information in the key storage medium device. The application file corresponding to the target Java application is obtained and extracted to a temporary directory, and the application file in the temporary directory is loaded into the virtual machine, where the application file includes a Java class file. Then, in response to the loading instruction for the target Java application, the target Java class file corresponding to the loading instruction is reflectively called from the application file loaded into the virtual machine. Thus, in the process of reinforcing the application, the security of the application file is effectively guaranteed through shelling and unshelling, and the encryption key is stored by hardware devices such as key storage media devices, thereby realizing physical isolation of the encryption key, further improving the security of the application, and dynamically loading the class file during the running of the application, thereby improving the flexibility and scalability of the application.

[0115] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the following examples are used for exemplary description:

[0116] Taking a JAVA-based financial transaction system as an example, the specific implementation steps are as follows:

[0117] (1) Preparation stage:

[0118] Use professional tools to obfuscate and encrypt the core logic classes of the trading system and generate encrypted JAR files.

[0119] Encapsulate the encrypted JAR file into ZIP format and perform secondary encryption using a custom algorithm.

[0120] Package the encrypted ZIP file, the shell program, and necessary configuration files into an installation package.

[0121] (2) Deployment phase:

[0122] Install the financial transaction system on the server and insert the authorized key storage media device.

[0123] Run the installation package and start the shell program for initialization.

[0124] (3) Start-up phase:

[0125] When the system starts, the packer checks whether the key storage media device has been inserted and verifies its legitimacy.

[0126] If the verification is successful, the unpacking program is started to decrypt the ZIP file and extract the JAR file to a temporary directory.

[0127] (4) Operation phase:

[0128] The custom class loader loads the decrypted JAR file into the JVM.

[0129] The trading system calls the methods in the implementation class through the interface layer to complete the transaction logic processing.

[0130] (5) Cleaning phase:

[0131] After the transaction is completed, delete the JAR file in the temporary directory immediately to ensure the security of the source code.

[0132] Record and monitor the entire transaction process to ensure the security and traceability of operations.

[0133] Through the above process, the main implementation class code and interface layer of the project are separated, which improves the maintainability and security of the software. After the interface layer is packaged, it is encrypted into a Zip file through the shell program to increase the security of the interface layer and prevent malicious tampering. When the project starts, the shell program is used to decrypt the class Zip shell file into a Jar package, and the class method is implemented through the class loader and reflection call to achieve dynamic loading, which improves the flexibility and operation efficiency of the software. Before decryption, a device similar to a U shield needs to be inserted into the server. During decryption, the decryption program or key in the U disk is read to increase the security of the decryption process and prevent the key from being stolen or cracked. After the shell is decompiled, the Jar file is deleted after the Jar file is loaded to prevent decompilation to obtain the source code, further improving the security of the software.

[0134] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0135] Reference Figure 4 , shows a structural block diagram of a processing device for an application provided in an embodiment of the present invention, which may specifically include the following modules:

[0136] The detection module 401 is used to obtain an encrypted file of the target Java application in response to a startup instruction for the target Java application, and detect whether the electronic device is currently connected to a key storage medium device for the target Java application, wherein the encrypted file is a file obtained by encapsulating the target Java application;

[0137] The verification module 402 is used to verify the key storage medium device if the electronic device is connected to the key storage medium device, and if the verification passes, determine the deshelling program for the encrypted file, and deshell the encrypted file by the deshelling program to obtain the encrypted application file corresponding to the target Java program;

[0138] A file decryption module 403 is used to decrypt the encrypted application file using the key information in the key storage medium device, obtain the application file corresponding to the target Java application, extract it to a temporary directory, and load the application file in the temporary directory into the virtual machine, wherein the application file includes a Java class file;

[0139] The file loading module 404 is used to, in response to a loading instruction for the target Java application, reflectively call a target Java class file corresponding to the loading instruction from the application file loaded into the virtual machine.

[0140] Some possible implementations also include:

[0141] A shell module, configured to, in response to a shell instruction for the target Java application, obtain a Java class file of the target Java application, and perform shell processing on the Java class file to generate an encrypted application file;

[0142] The encapsulation module is used to encapsulate the encrypted application file into a Zip format and perform secondary encryption using a preset algorithm to obtain an encrypted file corresponding to the target Java application.

[0143] Some possible implementations also include:

[0144] The packaging module is used to obtain a shell removal program corresponding to the target Java application, and to package the encrypted file with the shell removal program to obtain a deployment file corresponding to the target Java program.

[0145] In some feasible implementations, the verification module 402 is specifically used to:

[0146] Reading the key information in the key storage medium device;

[0147] Obtaining the verification logic built into the target Java application;

[0148] The key information is verified by the verification logic, and when the verification passes, a depacketizing program for the encrypted file is determined.

[0149] In some feasible implementations, the verification module 402 is specifically used to:

[0150] Reading verification information in the key storage medium device;

[0151] Obtaining the verification logic built into the target Java application;

[0152] The verification information is verified by the verification logic, and when the verification passes, a depacketizing program for the encrypted file is determined.

[0153] In some feasible implementations, the file decryption module 403 is specifically used to:

[0154] Determining a class loader for the target Java application;

[0155] The application file is loaded into the virtual machine of the server through the class loader.

[0156] Some possible implementations also include:

[0157] The deleting module is used to delete the application file in the temporary directory in response to completion of calling the application file.

[0158] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0159] In addition, an embodiment of the present invention further provides an electronic device, comprising: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, the various processes of the processing method embodiment of the above-mentioned application program are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be described here.

[0160] The embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each process of the processing method embodiment of the above-mentioned application program is implemented, and the same technical effect can be achieved. To avoid repetition, it is not repeated here. The computer-readable storage medium is, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0161] Figure 5 A schematic diagram of the hardware structure of an electronic device for implementing various embodiments of the present invention.

[0162] The electronic device 500 includes but is not limited to: a radio frequency unit 501, a network module 502, an audio output unit 503, an input unit 504, a sensor 505, a display unit 506, a user input unit 507, an interface unit 508, a memory 509, a processor 510, and a power supply 511. Those skilled in the art will appreciate that the electronic device structure involved in the embodiments of the present invention does not constitute a limitation on the electronic device, and the electronic device may include more or fewer components than shown in the figure, or combine certain components, or arrange components differently. In the embodiments of the present invention, the electronic device includes but is not limited to a mobile phone, a tablet computer, a laptop computer, a PDA, a vehicle-mounted terminal, a wearable device, and a pedometer.

[0163] It should be understood that in the embodiment of the present invention, the radio frequency unit 501 can be used for receiving and sending signals during information transmission or communication. Specifically, after receiving downlink data from the base station, it is sent to the processor 510 for processing; in addition, uplink data is sent to the base station. Generally, the radio frequency unit 501 includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, etc. In addition, the radio frequency unit 501 can also communicate with the network and other devices through a wireless communication system.

[0164] The electronic device provides users with wireless broadband Internet access through the network module 502, such as helping users to send and receive emails, browse web pages, and access streaming media.

[0165] The audio output unit 503 can convert the audio data received by the RF unit 501 or the network module 502 or stored in the memory 509 into an audio signal and output it as sound. Moreover, the audio output unit 503 can also provide audio output related to a specific function performed by the electronic device 500 (for example, a call signal reception sound, a message reception sound, etc.). The audio output unit 503 includes a speaker, a buzzer, a receiver, etc.

[0166] The input unit 504 is used to receive audio or video signals. The input unit 504 may include a graphics processor (GPU) 5041 and a microphone 5042. The graphics processor 5041 processes the image data of a static picture or video obtained by an image capture device (such as a camera) in a video capture mode or an image capture mode. The processed image frame can be displayed on the display unit 506. The image frame processed by the graphics processor 5041 can be stored in the memory 509 (or other storage medium) or sent via the radio frequency unit 501 or the network module 502. The microphone 5042 can receive sound and can process such sound into audio data. The processed audio data can be converted into a format output that can be sent to a mobile communication base station via the radio frequency unit 501 in the case of a telephone call mode.

[0167] The electronic device 500 also includes at least one sensor 505, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor and a proximity sensor, wherein the ambient light sensor can adjust the brightness of the display panel 5061 according to the brightness of the ambient light, and the proximity sensor can turn off the display panel 5061 and / or the backlight when the electronic device 500 is moved to the ear. As a type of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally three axes), and can detect the magnitude and direction of gravity when stationary, which can be used to identify the posture of the electronic device (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; the sensor 505 can also include a fingerprint sensor, a pressure sensor, an iris sensor, a molecular sensor, a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, etc., which will not be repeated here.

[0168] The display unit 506 is used to display information input by the user or information provided to the user. The display unit 506 may include a display panel 5061, which may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like.

[0169] The user input unit 507 can be used to receive input digital or character information, and to generate key signal input related to user settings and function control of the electronic device. Specifically, the user input unit 507 includes a touch panel 5071 and other input devices 5072. The touch panel 5071, also known as a touch screen, can collect the user's touch operation on or near it (such as the user's operation on the touch panel 5071 or near the touch panel 5071 using any suitable object or accessory such as a finger, stylus, etc.). The touch panel 5071 may include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the user's touch orientation, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into the contact point coordinates, and then sends it to the processor 510, receives the command sent by the processor 510 and executes it. In addition, the touch panel 5071 can be implemented using multiple types such as resistive, capacitive, infrared and surface acoustic waves. In addition to the touch panel 5071, the user input unit 507 may also include other input devices 5072. Specifically, other input devices 5072 may include but are not limited to a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, and a joystick, which are not described in detail here.

[0170] Further, the touch panel 5071 may be covered on the display panel 5061. When the touch panel 5071 detects a touch operation on or near it, it is transmitted to the processor 510 to determine the type of the touch event, and then the processor 510 provides a corresponding visual output on the display panel 5061 according to the type of the touch event. It can be understood that in one embodiment, the touch panel 5071 and the display panel 5061 are used as two independent components to implement the input and output functions of the electronic device, but in some embodiments, the touch panel 5071 and the display panel 5061 can be integrated to implement the input and output functions of the electronic device, which is not limited here.

[0171] The interface unit 508 is an interface for connecting an external device to the electronic device 500. For example, the external device may include a wired or wireless headset port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device with an identification module, an audio input / output (I / O) port, a video I / O port, a headphone port, etc. The interface unit 508 may be used to receive input (e.g., data information, power, etc.) from an external device and transmit the received input to one or more elements within the electronic device 500 or may be used to transmit data between the electronic device 500 and an external device.

[0172] The memory 509 can be used to store software programs and various data. The memory 509 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory 509 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0173] The processor 510 is the control center of the electronic device. It uses various interfaces and lines to connect various parts of the entire electronic device. By running or executing software programs and / or modules stored in the memory 509 and calling data stored in the memory 509, it performs various functions of the electronic device and processes data, thereby monitoring the electronic device as a whole. The processor 510 may include one or more processing units; preferably, the processor 510 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 510.

[0174] The electronic device 500 may also include a power supply 511 (such as a battery) for supplying power to each component. Preferably, the power supply 511 may be logically connected to the processor 510 through a power management system, thereby implementing functions such as charging, discharging, and power consumption management through the power management system.

[0175] In addition, the electronic device 500 includes some functional modules not shown, which will not be described in detail here.

[0176] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0177] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for enabling a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present invention.

[0178] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation modes, which are merely illustrative rather than restrictive. Under the guidance of the present invention, ordinary technicians in this field can also make many forms without departing from the scope of protection of the present invention and the claims, all of which are within the protection of the present invention.

[0179] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the embodiments of the present invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

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

[0181] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0182] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0183] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0184] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, ROM, RAM, magnetic disks, or optical disks.

[0185] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. A method for processing an application, characterized in that: Applied to electronic equipment, the method comprises: In response to a start instruction for a target Java application, an encrypted file of the target Java application is obtained, and it is detected whether the electronic device is currently connected to a key storage medium device for the target Java application, wherein the encrypted file is a file obtained by encapsulating the target Java application; If the electronic device is connected to the key storage medium device, verify the key storage medium device, and if the verification passes, determine a deshelling program for the encrypted file, and deshell the encrypted file using the deshelling program to obtain an encrypted application file corresponding to the target Java program; Decrypting the encrypted application file using the key information in the key storage medium device, obtaining an application file corresponding to the target Java application, extracting the application file to a temporary directory, and loading the application file in the temporary directory into the virtual machine, wherein the application file includes a Java class file; In response to a loading instruction for the target Java application, a target Java class file corresponding to the loading instruction is reflectively called from the application file loaded into the virtual machine.

2. The method according to claim 1, characterized in that Also includes: In response to a shelling instruction for the target Java application, a Java class file of the target Java application is obtained, and the Java class file is shelled to generate an encrypted application file; The encrypted application file is encapsulated into a Zip format and encrypted again using a preset algorithm to obtain an encrypted file corresponding to the target Java application.

3. The method according to claim 2, characterized in that Also includes: Obtain an unpacking program corresponding to the target Java application, and package the encrypted file with the unpacking program to obtain a deployment file corresponding to the target Java program.

4. The method according to claim 1, characterized in that: The step of verifying the key storage medium device and, if the verification is successful, determining an unpacking program for the encrypted file includes: Reading the key information in the key storage medium device; Obtaining the verification logic built into the target Java application; The key information is verified by the verification logic, and when the verification passes, a depacketizing program for the encrypted file is determined.

5. The method according to claim 1, characterized in that The step of verifying the key storage medium device and, if the verification is successful, determining an unpacking program for the encrypted file includes: Reading verification information in the key storage medium device; Obtaining the verification logic built into the target Java application; The verification information is verified by the verification logic, and when the verification passes, a depacketizing program for the encrypted file is determined.

6. The method according to claim 1, characterized in that The step of loading the application file into the virtual machine includes: Determining a class loader for the target Java application; The application file is loaded into the virtual machine of the server through the class loader.

7. The method according to any one of claims 1 to 6, characterized in that: Also includes: In response to completion of calling the application file, deleting the application file in the temporary directory.

8. A device for processing an application, characterized in that: Applied to electronic equipment, the device comprises: a detection module, configured to, in response to a start instruction for a target Java application, obtain an encrypted file of the target Java application and detect whether the electronic device is currently connected to a key storage medium device for the target Java application, wherein the encrypted file is a file obtained by encapsulating the target Java application; a verification module, configured to verify the key storage medium device if the electronic device is connected to the key storage medium device, and if the verification passes, determine a deshelling program for the encrypted file, and deshell the encrypted file using the deshelling program to obtain an encrypted application file corresponding to the target Java program; A file decryption module, used to decrypt the encrypted application file using the key information in the key storage medium device, obtain the application file corresponding to the target Java application, extract it to a temporary directory, and load the application file in the temporary directory into the virtual machine, wherein the application file includes a Java class file; The file loading module is used to respond to the loading instruction for the target Java application and reflectively call the target Java class file corresponding to the loading instruction from the application file loaded into the virtual machine.

9. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; The memory is used to store computer programs; The processor is used to implement the method according to any one of claims 1 to 7 when executing the program stored in the memory.

10. A computer-readable storage medium having instructions stored thereon, which, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 7.

Images