Application starting method and system based on double-layer encryption, terminal and storage medium

Abstract

This application discloses an application startup method, system, terminal, and storage medium based on dual-layer encryption. The application startup method includes: obtaining an encrypted package and distributing it to the device to be deployed; decrypting and parsing the encrypted package according to a pre-set outer launcher on the device to be deployed, and loading the core classes of the boot namespace in the application resource package into the Java Virtual Machine through a class loader; obfuscating the application package resources to obtain an obfuscated application package, and constructing a memory holding model and dependency libraries based on the obfuscated application package; performing memory class loading and resource access processing based on the memory holding model and dependency libraries; and after completing the memory class loading and resource access processing, reading the startup class attributes and completing the application startup based on the startup class attributes. This application can avoid plaintext write-to-disk and, through dual-layer protection, reduce the runtime plaintext write-to-disk window, thereby improving the security of application startup.

Description

Technical Field

[0001] This application relates to the field of data encryption technology, and in particular to an application startup method, system, terminal and computer-readable storage medium based on two-layer encryption. Background Technology

[0002] Java (a programming language) applications are typically launched directly using the JAVA-JAR method, such as Spring BootFatJar (a method of packaging the compiled artifacts of a Java application and all its dependencies into a single JAR file).

[0003] While this method facilitates application deployment, it suffers from serious security deficiencies in software protection scenarios: First, application packages are often distributed in plaintext, making them easy to unpack, decompile, and repackage; second, the traditional method of "decrypting to disk before startup and then running" creates a window period for plaintext to be written to disk; and third, the loading chain of standard classes is relatively fixed, making it easy for attackers to locate key processes and perform debugging or process restoration by analyzing external startup entry points.

[0004] In this situation, JAVA application packages lack effective protection during transmission and use, making them easy to decompile and difficult to truly achieve effective protection of core software intellectual property rights.

[0005] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0006] The main purpose of this application is to provide an application startup method, system, terminal and storage medium based on double encryption, which aims to solve the technical problem that existing technologies are easily decompiled during transmission and use, and cannot effectively protect the core intellectual property rights of software.

[0007] To achieve the above objectives, this application provides an application startup method based on double-layer encryption, the application startup method comprising: Obtain the application package to be encrypted, encrypt the application package to obtain a ciphertext package, and distribute the ciphertext package to the device to be deployed; According to the preset outer launcher on the device to be deployed, the encrypted package is decrypted and parsed to obtain the application package resources, and the core class of the boot namespace in the application resource package is loaded into the JAVA virtual machine through the class loader. The application package resources are obfuscated to obtain an obfuscated application package. A memory holding model and dependency library are then constructed based on the obfuscated application package. Memory class loading and resource access processing are performed based on the memory holding model and the dependent libraries. After the memory class loading process and the resource access process are completed, the startup class attribute is read, and the application is started according to the startup class attribute.

[0008] Optionally, the step of obtaining the application package to be encrypted, encrypting the application package to obtain a ciphertext package, and distributing the ciphertext package to the device to be deployed specifically includes: Receive application packets to be encrypted sent by users; The application packet to be encrypted is subjected to symmetric encryption to obtain a ciphertext packet; Receive a deployment request and send the encrypted packet to the device to be deployed according to the deployment request.

[0009] Optionally, the step of decrypting and parsing the encrypted package according to the preset outer launcher on the device to be deployed to obtain the application package resources, and loading the core classes of the boot namespace in the application resource package into the Java Virtual Machine through the class loader, specifically includes: Obtain the preset outer launcher on the device to be deployed, read the encrypted package based on the outer launcher, and call the JNI native entry point; The encrypted packet is decrypted based on the JNI native entry point to obtain the plaintext byte stream corresponding to the encrypted packet. The central directory of the plaintext byte stream is parsed to read the application package resources in the plaintext byte stream, wherein the application package resources include protected classes and resource bytes; The core classes of the bootstrap namespace in the protected class are loaded into the Java Virtual Machine through the class loader.

[0010] Optionally, the step of obfuscating the application package resources to obtain an obfuscated application package, and constructing a memory holding model and dependency library based on the obfuscated application package, specifically includes: The application package resources are obfuscated to obtain an obfuscated application package; The obfuscated application package is passed as a parameter to the inner startup entry point. A protocol processor is registered based on the inner startup entry point, and a tree structure of the classes contained in the obfuscated application package is constructed to obtain the memory holding model. The obfuscated application package is recursively parsed to obtain the external dependency libraries corresponding to the obfuscated application package.

[0011] Optionally, the process of obfuscating the application package resources to obtain an obfuscated application package further includes: The cached data corresponding to the application package resources is cleared and released.

[0012] Optionally, the step of performing memory class loading and resource access processing based on the memory holding model and the dependent library specifically includes: Based on a preset custom class loader, the core classes required to launch the obfuscated application package are loaded into the Java Virtual Machine according to the memory holding model. Resource access processing for external resources located at a URL is completed based on a custom protocol. Resource access processing is performed on the inner classes of the obfuscated application package.

[0013] Optionally, after the memory class loading process and the resource access process are completed, the startup class attribute is read, and the application startup is completed according to the startup class attribute, specifically including: After completing the memory class loading process and the resource access process, read the startup class attribute in the obfuscated application package; Reflection is used based on the startup class attribute to obtain the main class of the obfuscated application package; The main class is run according to the preset startup code, and the thread context class loader is set to the memory class loader to complete the application startup of the obfuscated application package.

[0014] Furthermore, to achieve the above objectives, this application also provides an application startup system based on dual-layer encryption, wherein the application startup system is used to implement the application startup method described in any of the above claims, and the application startup system includes: An application encryption module is used to obtain an application package to be encrypted, encrypt the application package to obtain a ciphertext package, and distribute the ciphertext package to the device to be deployed. The decryption and parsing module is used to decrypt and parse the encrypted package according to the preset outer launcher on the device to be deployed, to obtain the application package resources, and to load the core class of the boot namespace in the application resource package into the JAVA virtual machine through the class loader. The environment setup module is used to obfuscate the application package resources to obtain an obfuscated application package, and to build a memory holding model and dependency library based on the obfuscated application package; The memory loading module is used to perform memory class loading and resource access processing based on the memory holding model and the dependent library. The application startup module is used to read the startup class attributes and complete the application startup based on the startup class attributes after the memory class loading process and the resource access process are completed.

[0015] In addition, to achieve the above objectives, this application also provides a terminal, wherein the terminal includes: a memory, a processor, and an application launcher stored in the memory and executable on the processor, wherein when the application launcher is executed by the processor, it implements the steps of the application launch method as described in any of the preceding claims.

[0016] In addition, to achieve the above objectives, this application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores an application startup program, which, when executed by a processor, implements the steps of the application startup method as described in any of the preceding claims.

[0017] In this application, the application startup method includes: obtaining an application package to be encrypted; encrypting the application package to obtain a ciphertext package; distributing the ciphertext package to a device to be deployed; decrypting and parsing the ciphertext package according to a pre-set outer launcher on the device to be deployed to obtain application package resources; loading the core class of the boot namespace in the application resource package into the Java Virtual Machine through a class loader; obfuscating the application package resources to obtain an obfuscated application package; constructing a memory holding model and dependency libraries based on the obfuscated application package; performing memory class loading and resource access processing based on the memory holding model and the dependency libraries; after completing the memory class loading and resource access processing, reading the startup class attributes and completing the application startup based on the startup class attributes. This application can avoid plaintext disk writing, increase the difficulty of static unpacking, decompiling, and process restoration, and at the same time reduce the runtime plaintext disk writing window through double-layer protection, improve the security of application startup, prevent code and data leakage, and achieve effective protection of core software intellectual property rights. Attached Figure Description

[0018] Figure 1 This is a flowchart of a preferred embodiment of the application startup method based on double-layer encryption provided in this application; Figure 2 This is a schematic diagram of a preferred embodiment of the application startup system based on double-layer encryption provided in this application.

[0019] Figure 3 This is a schematic diagram of the operating environment of a preferred embodiment of the terminal of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer and more explicit, the following detailed description of this application is provided with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0021] In existing technologies, bytecode obfuscation can be used, which involves renaming class / method names and obfuscating control flow to increase the readability of decompiled code. However, obfuscation is not encryption and cannot prevent decompilation. Alternatively, a single-layer encrypted JAR (a type of software package file format) startup scheme can be used, which encrypts the JAR during the build phase and decrypts it once during runtime using a launcher or Agent (a mechanism in Java). However, single-layer encryption schemes often create plaintext temporary files or complete plaintext memory windows at startup. Another option is a custom ClassLoader decryption and loading scheme, which reads the encrypted class (a class in Java) from findClass / loadClass (file paths in Java code), decrypts it, and then definesClass (a method responsible for converting byte arrays into Class objects). However, many schemes only cover class loading and do not fully cover the resources and nested dependency semantics of FatJar.

[0022] Therefore, to solve the above problems, this application proposes an application startup method based on double-layer encryption. The preferred embodiment of this application describes an application startup method based on double-layer encryption, such as... Figure 1 As shown, the application startup method based on double-layer encryption includes the following steps: Step S10: Obtain the application package to be encrypted, encrypt the application package to obtain a ciphertext package, and distribute the ciphertext package to the device to be deployed.

[0023] Specifically, the application package to be encrypted, which needs to be deployed on the target device (the device to be deployed, such as a computer), is obtained. This application package is then encrypted as a whole. After the encryption is complete, a corresponding ciphertext package is output. This ciphertext package is used to distribute the application to the device to be deployed. This is because the encrypted ciphertext package cannot be directly recognized or decompressed using JAVA-JAR, and therefore cannot be directly analyzed by conventional decompilation tools, thus avoiding the direct delivery of plaintext packages. It should be noted that the device to be deployed can be one or more; this application does not impose a specific limitation.

[0024] In one embodiment, the steps of obtaining the application package to be encrypted, encrypting the application package to obtain a ciphertext package, and distributing the ciphertext package to the device to be deployed specifically include: Receive an application package to be encrypted sent by a user; perform symmetric encryption on the application package to be encrypted to obtain a ciphertext package; receive a deployment request, and send the ciphertext package to the device to be deployed according to the deployment request.

[0025] Specifically, the system first receives the application package to be encrypted sent by the user (developer). The application package to be encrypted is actually an executable JAR file produced by packaging with a plugin, which contains standard structures such as BOOT-INF / classes, BOOT-INF / lib, and META-INF / MANIFEST.MF.

[0026] The application package to be encrypted is subjected to full-packet symmetric encryption (such as AES symmetric encryption). In fact, the application package to be encrypted is encrypted as a binary file. The resulting ciphertext package is no longer a file that can be directly recognized or decompressed by JAVA-JAR. Even if the ciphertext package is intercepted later, without the decryption key and the corresponding launcher, it is impossible to restore the executable JAVA source program. This achieves static protection of the application package to be encrypted and reduces the risk of leakage.

[0027] Subsequently, a deployment request is received from the device to be deployed. Based on this deployment request, an encrypted package is sent to the device to be deployed. The device to be deployed receives an encrypted JAR file and does not provide any plaintext bytecode.

[0028] Step S20: According to the preset outer launcher on the device to be deployed, the encrypted package is decrypted and parsed to obtain the application package resources, and the core class of the boot namespace in the application resource package is loaded into the JAVA virtual machine through the class loader.

[0029] Specifically, each device to be deployed is equipped with a preset outer launcher, which is an independent, lightweight JAVA program responsible for triggering the decryption process.

[0030] The outer initiator reads the encrypted packet. After reading the encrypted packet, it is then decrypted and parsed to obtain the application package resources contained in the encrypted packet. The application package resources include the protected classes and resource bytes of the application to be deployed.

[0031] Finally, the bootstrap namespace core classes from the application package resources are loaded into the Java Virtual Machine (JVM) through the class loader. The bootstrap namespace core classes refer to the collection of classes that are pre-installed in the application package to be encrypted before compilation and are used to load and start the main class of the application package to be encrypted.

[0032] In one embodiment, the step of decrypting and parsing the encrypted package according to the preset outer launcher on the device to be deployed to obtain the application package resource, and loading the core class of the boot namespace in the application resource package into the Java Virtual Machine through the class loader, specifically includes: Obtain the preset outer launcher on the device to be deployed, read the encrypted package based on the outer launcher, and call the JNI native entry point; decrypt the encrypted package based on the JNI native entry point to obtain the plaintext byte stream corresponding to the encrypted package; parse the central directory of the plaintext byte stream to read the application package resources in the plaintext byte stream, wherein the application package resources include protected classes and resource bytes; load the boot namespace core class in the protected class into the Java Virtual Machine through the class loader.

[0033] Specifically, the outer launcher preset on each device to be deployed is first obtained. This outer launcher is usually not encrypted and exists in plaintext. It does not contain business logic or decryption content. The entire ciphertext package is read into memory through this outer launcher to obtain the corresponding ciphertext data.

[0034] Subsequently, the outer launcher calls the JNI (Java Native Interface, a standard programming interface for the Java platform) native entry point, which is a native function written in C++. In this case, the outer launcher only acts as a bridge and does not handle the startup details of the application package. Even if this outer launcher is decompiled, the contents of the encrypted package cannot be obtained, greatly increasing the difficulty of reverse engineering and improving the security of application startup.

[0035] The encrypted packet is decrypted through the native JNI entry point. This means that the encrypted packet is decrypted using the same algorithm and key as the encryption stage, which can then restore the complete, unencrypted plaintext byte stream. In this case, the plaintext byte stream is stored entirely in the memory of the device to be deployed and is not written to the disk, thus avoiding the plaintext write-to-disk window that could lead to resource leaks.

[0036] The plaintext byte stream is actually a JAR file with a central directory at the end. This central directory is parsed, and each entry within it is analyzed to obtain the application package resources from the plaintext byte stream. These application package resources include protected classes and resource bytes. It's important to note that this process only reads and decompresses the application package resources; it does not actually load them into the Java Virtual Machine.

[0037] Finally, using a pre-defined class loader, the necessary bootstrap namespace core classes for the main startup class are selected from the protected classes of the application package resources. These bootstrap namespace core classes are then loaded into the Java Virtual Machine via JNI by calling the DefineClass method. In this scenario, neither the decryption nor parsing of the encrypted package leaves any plaintext on disk. Attackers cannot intercept the application's resource data by monitoring the file system of the computer to be deployed, preventing information leakage and further ensuring data security.

[0038] Step S30: Obfuscate the application package resources to obtain an obfuscated application package, and construct a memory holding model and dependency library based on the obfuscated application package.

[0039] Specifically, based on the JNI native entry point, the application package resources are obfuscated, which is actually a lightweight encapsulation of the application package resources.

[0040] After obfuscating the application package resources, an obfuscated application package is obtained. Then, a memory holding model and dependency libraries are built based on the obfuscated application package. The memory holding model refers to the tree structure of the classes contained in the application package, and the dependency libraries refer to the external dependency libraries of the external JAR packages that the application package needs to use when it starts up.

[0041] In one embodiment, the process of obfuscating application package resources to obtain an obfuscated application package, and constructing a memory holding model and dependency library based on the obfuscated application package, specifically includes: The application package resources are obfuscated to obtain an obfuscated application package; the obfuscated application package is passed as a parameter to the inner startup entry point, a protocol processor is registered based on the inner startup entry point, and a tree structure of the classes contained in the obfuscated application package is constructed to obtain a memory holding model; the obfuscated application package is recursively parsed to obtain the external dependency library corresponding to the obfuscated application package.

[0042] Specifically, the application package resources are obfuscated based on the JNI native entry point. This includes adding a magic number header (adding a few fixed special bytes at the beginning of the byte array), adding a session key area (reserving a small area to store the session key temporarily generated for this run), and payload obfuscation (performing simple transformations such as byte rearrangement, compression segmentation, and XOR random masking on the plaintext). After the obfuscation of the application package resources is completed, an obfuscated application package is obtained. Although the obfuscated application package has been obfuscated, it still contains complete application package resources.

[0043] The obfuscated application package obtained through obfuscation is passed as a parameter to the inner startup entry point. Here, "inner" refers to the obfuscated application package, and the inner startup entry point is a static Java method used to launch the obfuscated application package, such as `launch(byte[], String[])`. It's important to note that this method belongs to the code within the obfuscated application package. At this point, most classes in the obfuscated application package are not yet loaded into the Java Virtual Machine (JVM), but the inner startup entry point has already been loaded into the JVM as a core class of the bootstrap namespace. It should be noted that the inner startup method executes entirely in memory and does not depend on any disk files.

[0044] Based on the inner startup entry being called, a memory protocol processor is registered. The memory protocol processor is actually a processor that can read protected classes, dependency libraries and resource files in memory in the form of byte arrays via URL (Uniform Resource Locator), so that when accessing resources later, data can be read from the byte array in memory.

[0045] After registering the memory protocol processor, the obfuscated application package is parsed again to obtain a tree structure of the classes contained in the obfuscated application package, thus obtaining the memory holding model. It should be noted that before processing the obfuscated application package, it needs to be deobfuscated, such as removing the magic number head, extracting the session key, and deobfuscating.

[0046] Finally, the BOOT-INF / lib directory in the obfuscated application package is parsed. From this BOOT-INF / lib directory, the byte data corresponding to all the external JAR packages contained are recursively read, and all the byte data are integrated to obtain the external dependency library corresponding to the obfuscated application package. The external dependency library contains the index of the external JAR packages that the obfuscated application package needs to use when it starts up.

[0047] Furthermore, the process of obfuscating the application package resources to obtain an obfuscated application package further includes: The cached data corresponding to the application package resources is cleared and released.

[0048] Specifically, the application package resources are obfuscated at the JNI native entry point. After obtaining the obfuscated application package, the cached data corresponding to the application package resources in memory is cleared and released. In detail, the memory area can be written to 0 by the preset memory initialization function (memset) and the free function is called to return the memory.

[0049] In this scenario, the time between the initial decryption and obfuscation is extremely short (microseconds or milliseconds), and the cached data is immediately cleared and released after obfuscation. This prevents the decrypted plaintext byte stream from residing in memory for an extended period, shortens the plaintext residency window, reduces the risk of attackers directly obtaining the application package's original code through memory dumping, and improves the security of launching the application package.

[0050] Step S40: Perform memory class loading and resource access processing based on the memory holding model and the dependent library.

[0051] Specifically, after building the memory holding model and dependency libraries, it is necessary to perform corresponding memory class loading and resource access processing. The purpose of these two processes is to complete all the classes and resources required to start the obfuscated application package.

[0052] In one embodiment, the process of performing memory class loading and resource access processing based on the memory holding model and the dependent library specifically includes: Based on a preset custom class loader, the core classes required to launch the obfuscated application package are loaded into the Java Virtual Machine according to the memory holding model; resource access processing for external resources at the URL location is completed based on a custom protocol; and resource access processing is performed on the internal classes of the obfuscated application package.

[0053] Specifically, based on a pre-defined custom class loader—a class that inherits from ClassLoader—when the Java Virtual Machine (JVM) needs to load a class, the custom class loader can retrieve the corresponding data from the memory holding model, without reading from a disk file, and then call DefineClass to load it into the JVM. In detail, the custom class loader can load all the core classes required to launch the obfuscated application package into the JVM.

[0054] Subsequently, resource access processing for external resources at the URL location can be completed based on a custom protocol. This is because applications often need to read external resource files (such as external JAR packages) during startup. By using a custom URL protocol, the application can obtain the corresponding external resources from a specific location during startup, such as accessing getResource / getResources through the form jar:inmemory:...! / entry.

[0055] Finally, resource access processing is performed on the inner classes of the obfuscated application package. The only difference between the obfuscated application package and the application package to be deployed is that the data is obfuscated; however, the information and structure are identical. Therefore, the obfuscated application package also contains the standard directory structure of BOOT-INF / classes, which contains all the classes that come with the obfuscated application package. During application startup, the necessary inner classes need to be retrieved from this directory. In essence, this means it can support short path mapping, mapping class names to actual paths, for example, mapping com.example.App to BOOT-INF / classes / com / example / App.class, thus enabling quick retrieval of inner classes in BOOT-INF / classes.

[0056] Step S50: After the memory class loading process and the resource access process are completed, read the startup class attribute and complete the application startup according to the startup class attribute.

[0057] Specifically, after all memory class loading and resource access processing are completed, the startup class attribute in the obfuscated application package is read, and the main class is called by reflection based on the startup class attribute. Then, the application is started through the main class.

[0058] In one embodiment, after the memory class loading process and the resource access process are completed, the startup class attribute is read, and the application startup is completed according to the startup class attribute, specifically including: After completing the memory class loading process and the resource access process, the startup class attribute in the obfuscated application package is read; reflection is performed based on the startup class attribute to obtain the main class of the obfuscated application package; the main class is run according to the preset startup code, and the thread context class loader is set to the memory class loader to complete the application startup of the obfuscated application package.

[0059] Specifically, after completing the memory class loading and resource access processing, the Start-Class property in the META-INF / MANIFEST.MF directory of the obfuscated application package is read. The Start-Class property specifies the main business class that actually contains the main method. In fact, the Start-Class property is obtained by parsing the memory holding model.

[0060] Subsequently, reflection is used through the startup class attribute to obtain the main class (main(String[])). Before calling the main class to start the obfuscated application package, the thread context class loader needs to be set to the memory class loader. Finally, the main class is called to start the obfuscated application package.

[0061] Furthermore, such as Figure 2As shown, based on the above-described application startup method based on double-layer encryption, this application also provides an application startup system based on double-layer encryption, wherein the application startup system based on double-layer encryption includes: The application encryption module 51 is used to obtain the application package to be encrypted, encrypt the application package to be encrypted to obtain a ciphertext package, and distribute the ciphertext package to the device to be deployed; The decryption and parsing module 52 is used to decrypt and parse the encrypted package according to the preset outer launcher on the device to be deployed, to obtain the application package resources, and to load the core class of the boot namespace in the application resource package into the JAVA virtual machine through the class loader. The environment module 53 is used to obfuscate the application package resources to obtain an obfuscated application package, and to build a memory holding model and dependency library based on the obfuscated application package. Memory loading module 54 is used to perform memory class loading and resource access processing according to the memory holding model and the dependent library; The application startup module 55 is used to read the startup class attributes and complete the application startup based on the startup class attributes after the memory class loading process and the resource access process are completed.

[0062] Furthermore, such as Figure 3 As shown, based on the above application startup method and system, this application also provides a terminal, which includes a processor 10, a memory 20 and a display 30. Figure 3 Only some of the terminal components are shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0063] In some embodiments, the memory 20 may be an internal storage unit of the terminal, such as a hard disk or memory. In other embodiments, the memory 20 may be an external storage device of the terminal, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc. Further, the memory 20 may include both internal and external storage devices. The memory 20 is used to store application software and various types of data installed on the terminal, such as the program code installed on the terminal. The memory 20 can also be used to temporarily store data that has been output or will be output. In one embodiment, the memory 20 stores an application startup program 40, which can be executed by the processor 10 to implement the application startup method of this application.

[0064] In some embodiments, the processor 10 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in the memory 20 or process data, such as executing the application startup method.

[0065] In some embodiments, the display 30 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. The display 30 is used to display information on the terminal and to display a visual user interface. The terminal's processor 10, memory 20, and display 30 communicate with each other via a system bus.

[0066] In one embodiment, the steps of the application startup method described above are implemented when the processor 10 executes the application startup program 40 in the memory 20.

[0067] This application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores an application startup program, which, when executed by a processor, implements the steps of the application startup method described above.

[0068] In summary, this application provides an application startup method, system, terminal, and storage medium. The application startup method includes: obtaining an application package to be encrypted; encrypting the application package to obtain an encrypted package; and distributing the encrypted package to a device to be deployed; decrypting and parsing the encrypted package according to a pre-set outer launcher on the device to be deployed to obtain application package resources; loading the core class of the boot namespace in the application resource package into the Java Virtual Machine through a class loader; obfuscating the application package resources based on the Java Virtual Machine to obtain an obfuscated application package; constructing a memory holding model and dependency libraries based on the obfuscated application package; performing memory class loading and resource access processing based on the memory holding model and the dependency libraries; and after completing the memory class loading and resource access processing, reading the startup class attributes and completing the application startup based on the startup class attributes. This application avoids plaintext write-to-disk, increases the difficulty of static unpacking, decompiling, and process restoration, and reduces the runtime plaintext write-to-disk window through double-layer protection, improving the security of application startup, preventing code and data leakage, and achieving effective protection of core software intellectual property rights.

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

[0070] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0071] Of course, those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.). The program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The computer-readable storage medium can be a memory, magnetic disk, optical disk, etc.

[0072] It should be understood that the application of this application is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. An application startup method based on two-layer encryption, characterized in that, The application launch method includes: Obtain the application package to be encrypted, encrypt the application package to obtain a ciphertext package, and distribute the ciphertext package to the device to be deployed; According to the preset outer launcher on the device to be deployed, the encrypted package is decrypted and parsed to obtain the application package resources, and the core class of the boot namespace in the application resource package is loaded into the JAVA virtual machine through the class loader. The application package resources are obfuscated to obtain an obfuscated application package. A memory holding model and dependency library are then constructed based on the obfuscated application package. Memory class loading and resource access processing are performed based on the memory holding model and the dependent libraries. After the memory class loading process and the resource access process are completed, the startup class attribute is read, and the application is started according to the startup class attribute.

2. The application launch method according to claim 1, characterized in that, The process of obtaining the application package to be encrypted, encrypting the application package to obtain a ciphertext package, and distributing the ciphertext package to the device to be deployed specifically includes: Receive application packets to be encrypted sent by users; The application packet to be encrypted is subjected to symmetric encryption to obtain a ciphertext packet; Receive a deployment request and send the encrypted packet to the device to be deployed according to the deployment request.

3. The application launch method according to claim 1, characterized in that, The process involves decrypting and parsing the encrypted package according to the preset outer launcher on the device to be deployed, obtaining the application package resources, and loading the core classes of the boot namespace in the application resource package into the Java Virtual Machine through a class loader. Specifically, this includes: Obtain the preset outer launcher on the device to be deployed, read the encrypted package based on the outer launcher, and call the JNI native entry point; The encrypted packet is decrypted based on the JNI native entry point to obtain the plaintext byte stream corresponding to the encrypted packet. The central directory of the plaintext byte stream is parsed to read the application package resources in the plaintext byte stream, wherein the application package resources include protected classes and resource bytes; The core classes of the bootstrap namespace in the protected class are loaded into the Java Virtual Machine through the class loader.

4. The application launch method according to claim 1, characterized in that, The process of obfuscating application package resources to obtain an obfuscated application package, and constructing a memory holding model and dependency library based on the obfuscated application package, specifically includes: The application package resources are obfuscated to obtain an obfuscated application package; The obfuscated application package is passed as a parameter to the inner startup entry point. A protocol processor is registered based on the inner startup entry point, and a tree structure of the classes contained in the obfuscated application package is constructed to obtain the memory holding model. The obfuscated application package is recursively parsed to obtain the external dependency libraries corresponding to the obfuscated application package.

5. The application launch method according to claim 1, characterized in that, The process of obfuscating the application package resources to obtain an obfuscated application package further includes: The cached data corresponding to the application package resources is cleared and released.

6. The application launch method according to claim 1, characterized in that, The process of memory class loading and resource access based on the memory holding model and the dependent library specifically includes: Based on a preset custom class loader, the core classes required to launch the obfuscated application package are loaded into the Java Virtual Machine according to the memory holding model. Resource access processing for external resources located at a URL is completed based on a custom protocol. Resource access processing is performed on the inner classes of the obfuscated application package.

7. The application launch method according to claim 1, characterized in that, After the memory class loading process and the resource access process are completed, the startup class attribute is read, and the application startup is completed according to the startup class attribute, specifically including: After completing the memory class loading process and the resource access process, read the startup class attribute in the obfuscated application package; Reflection is used based on the startup class attribute to obtain the main class of the obfuscated application package; The main class is run according to the preset startup code, and the thread context class loader is set to the memory class loader to complete the application startup of the obfuscated application package.

8. An application startup system based on dual-layer encryption, characterized in that, The application launch system is used to implement the application launch method as described in any one of claims 1-7, and the application launch system includes: An application encryption module is used to obtain an application package to be encrypted, encrypt the application package to obtain a ciphertext package, and distribute the ciphertext package to the device to be deployed. The decryption and parsing module is used to decrypt and parse the encrypted package according to the preset outer launcher on the device to be deployed, to obtain the application package resources, and to load the core class of the boot namespace in the application resource package into the JAVA virtual machine through the class loader. The environment setup module is used to obfuscate the application package resources to obtain an obfuscated application package, and to build a memory holding model and dependency library based on the obfuscated application package; The memory loading module is used to perform memory class loading and resource access processing based on the memory holding model and the dependent library. The application startup module is used to read the startup class attributes and complete the application startup based on the startup class attributes after the memory class loading process and the resource access process are completed.

9. A terminal, characterized in that, The terminal includes: a memory, a processor, and an application launcher stored in the memory and executable on the processor, wherein when the application launcher is executed by the processor, it implements the steps of the application launch method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an application launcher that, when executed by a processor, implements the steps of the application launch method as described in any one of claims 1-7.

Images