Instruction-driven java runtime business logic protection method and system
By breaking down Java business logic into business units and using a dynamic instruction parser to execute instruction sequences, the problem of Java program logic being easily stolen is solved, achieving highly secure and covert protection of business logic.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- YANTAI HAIYI SOFTWARE
- Filing Date
- 2025-07-21
- Publication Date
- 2026-06-23
AI Technical Summary
Existing Java program protection technologies cannot effectively prevent attackers from stealing core business logic through decompilation and debugging, resulting in problems of logic exposure and insufficient protection strength.
The target business logic is broken down into multiple business units, and execution instruction sequences are generated through instructional description and encrypted storage. These units are then dynamically executed at runtime using a dynamic instruction parser, avoiding the exposure of business processes by static code.
It significantly improves the security of Java programs, preventing attackers from reconstructing business logic through static analysis and dynamic debugging, and enhancing the concealment and unpredictability of business processes.
Smart Images
Figure CN120850259B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of Java program protection technology, and in particular to a method and system for protecting Java runtime business logic based on instruction-driven principles. Background Technology
[0002] Java, with its platform independence and rich ecosystem, is widely used in enterprise application development. However, when Java is used as the development language in commercial products, its compiled JVM bytecode (.class files) retains relatively complete program structure information, and the JVM class file format is publicly transparent, making it extremely easy for various decompilation tools to restore it to a near-source code form. Attackers can use decompilation to obtain core business logic, analyze system implementation details, and even directly steal source code for their own products, leading to the leakage of trade secrets and core technologies, posing a serious challenge to the intellectual property protection of Java software.
[0003] Common Java program protection technologies currently include code obfuscation, class file encryption, custom class loading, local interface calls, and code signature verification.
[0004] Code obfuscation is the most commonly used static protection technique. It typically reduces the readability of decompiled code by renaming class names, method names, field names, altering code structure, and inserting redundant logic. Typical tools include ProGuard and Allatori. However, code obfuscation only delays the analysis process; it cannot truly hide the program structure and business processes. Attackers with reverse engineering experience can still reconstruct key logic through debugging and static analysis.
[0005] The class file encryption and custom class loading method involves encrypting and storing .class files before release, and then decrypting and loading them at runtime using a custom ClassLoader. This method avoids exposing the original class files directly to the disk. However, since the JVM still needs to load the decrypted bytecode, attackers can intercept the decrypted class content through debugging or memory dumping. For example, the jad command in the Arthas tool can decompile the bytecode of classes already loaded into the JVM into Java source code.
[0006] The Java Native Interface (JNI) and native encryption schemes enhance security by migrating core logic to a dynamic link library written in C / C++, combined with native layer protection techniques such as anti-debugging, code shells, and memory protection. While this method increases the difficulty of cracking, JNI development is complex, maintenance costs are high, and it sacrifices Java's cross-platform capabilities; therefore, it is typically only used in systems with extremely high security requirements. Furthermore, the native layer remains vulnerable to analysis by reverse engineering tools (such as IDA and Ghidra).
[0007] Code signing and integrity verification mechanisms are primarily used to prevent malicious tampering before or during program execution. A common approach is to sign class or JAR files and verify their integrity before loading or execution. While this method effectively prevents unauthorized modifications, it cannot prevent the theft of legitimate logic; attackers can still obtain complete business processes and algorithmic logic.
[0008] In summary, while existing technologies have enhanced the security of Java applications to some extent, issues such as logic exposure and insufficient protection strength remain. They cannot completely resolve the static readability problem of target business logic at the architectural level. Attackers can not only decompile and analyze static bytecode, but also observe the logic execution order during program runtime through debugging techniques, thus recovering system implementation details.
[0009] Therefore, there is a need for a Java runtime business logic protection method and system based on instruction driving that can dynamically protect against theft, has high security, and ensures the concealment and unpredictability of business processes. Summary of the Invention
[0010] To address the shortcomings of existing Java program protection technologies, which only offer static protection and are susceptible to cracking and theft, this invention provides a method and system for protecting Java runtime business logic based on instruction-driven principles. This method and system offers dynamic protection, strong anti-theft capabilities, high security, and high concealment and unpredictability of business processes.
[0011] The instruction-driven Java runtime business logic protection method of the present invention includes the following steps:
[0012] S1. Divide the target business logic into multiple business units;
[0013] S2. Protect the order of execution instructions of the business unit through instruction description to form an instruction file of the business unit; encrypt and store the instruction file to form an encrypted instruction file;
[0014] S3. When the target business logic needs to be executed, a dynamic instruction parser is first generated. The dynamic instruction parser loads the corresponding encrypted instruction file according to the current business scenario and restores the contents of the encrypted instruction file into a structured sequence of execution instructions through a decryption process.
[0015] S4. Extract the execution instructions from the decrypted execution instruction sequence, and dynamically complete the target business logic according to the order of the execution instructions and the control logic.
[0016] Further: In S1, the unitization split specifically includes:
[0017] The target business logic is divided into multiple business units, and these business units are called and parsed using a unified interface and startup program.
[0018] Furthermore: In S2, the instruction description refers to the execution description of each business unit, and the execution instruction includes the target business unit identifier, execution conditions, and loop control.
[0019] Further: In S2, the encrypted storage refers to generating a structured sequence of execution instructions from the execution instructions according to the execution order of the business units in the target business logic;
[0020] Specifically, the execution order of the business units is encrypted and numbered to ensure that the encrypted number of each business unit is different from the original execution order.
[0021] Furthermore: the sequence of execution instructions is organized in JSON format;
[0022] The execution instruction sequence is encrypted using a symmetric encryption algorithm and combined with a dynamically generated key mechanism to form an encrypted instruction file.
[0023] Furthermore, in S3, the decryption process is implemented through a built-in decryption module, which uses a symmetric encryption algorithm and derives the key in real time through a preset dynamic generation mechanism.
[0024] Furthermore: In S1, after the target business logic is modularly decomposed, the original static business units in the target business logic are deleted, and only the startup program and class definition structure are retained.
[0025] Furthermore: In S2, after the encrypted instruction file is generated, the original instruction file is deleted, and only the encrypted instruction file is retained.
[0026] The business logic protection system based on the instruction-driven Java runtime business logic protection method of the present invention includes a business unit splitting module, a startup program definition module, a business unit compiler, a dynamic instruction parser, and an instruction execution module;
[0027] The business unit splitting module is used to obtain the target business logic and split the target business logic into multiple relatively independent business units;
[0028] The startup program definition module is used to define a unified startup program for each business unit;
[0029] The business unit compiler is used to extract the execution instructions and calling order of each business unit and generate an encrypted instruction file;
[0030] The dynamic instruction parser is used to load the corresponding encrypted instruction file according to the current business scenario, and restore the contents of the encrypted instruction file into a structured sequence of execution instructions through a decryption process;
[0031] The instruction execution module is used to dynamically complete the target business logic according to the order of the execution instruction sequence and control logic.
[0032] The beneficial effects of this invention are:
[0033] This invention proposes a Java runtime business logic protection method based on instruction-driven approach. By splitting critical target business logic into multiple independent business units (LogicUnits), and encrypting and storing the execution order of the business units in an external instruction file in the form of instructions, the execution instructions of the business units are formed. During program execution, the external execution instructions are dynamically combined and executed. The Javassist bytecode manipulation technology is used to dynamically generate parsed instructions, and the execution order of the business units is controlled according to the content of the parsed execution instructions. This avoids static code exposing the complete business process and effectively hides the calling relationship of the business units.
[0034] Even in a debugging environment, attackers cannot directly deduce the business call chain, significantly improving the program's ability to resist static analysis, dynamic debugging, and reverse engineering, resulting in higher security and innovation. It effectively breaks the characteristics of traditional static programs—logical continuity, fixed structure, and ease of analysis—significantly improving the concealment and unpredictability of business processes.
[0035] This invention independently extracts the execution order and control logic of business units into a structured sequence of execution instructions, and protects the instruction files using symmetric encryption and dynamic key generation mechanisms. This avoids directly exposing business process information in the program's static resources, preventing attackers from reconstructing the target business logic through static analysis at the source. This invention solves the problem that target business logic exists statically in the compiled class file and is easily decompiled, preventing attackers from obtaining core algorithms and sensitive business processes through static analysis, thus improving the security of the program in a static decompilation environment.
[0036] This invention can hide the execution order of target business logic. By encrypting and storing the execution order in the form of instructions, it separates it from the main program and prevents attackers from inferring the complete business execution order through source code reading, bytecode analysis, and other means, thus protecting the confidentiality of system processes.
[0037] This invention utilizes Javassist bytecode manipulation technology to dynamically generate an instruction parser during program execution. This parser parses external execution instruction files in real time and dynamically schedules the execution of each business unit. The generated instruction parser class exists only in memory, and its class and method names use randomly generated, semantically neutral identifiers. This avoids static extraction and reduces the readability of debugging traces, effectively preventing dynamic debugging and reverse engineering attacks, and significantly improving the concealment and security of the system's runtime business logic. It solves the problem of traditional programs being easily traced by debuggers and their execution order being dynamically reconstructed during runtime. By using dynamic code generation technology to generate a dynamic instruction parser during program execution, the true call order is hidden, enhancing the program's protection against dynamic debugging and reverse engineering. Attached Figure Description
[0038] Figure 1 It is the target business logic flowchart;
[0039] Figure 2 This is a flowchart illustrating the process of instruction parsing and execution. Detailed Implementation
[0040] The following are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. The embodiments described below are only for explaining the present invention and should not be construed as limiting the present invention. The scope of protection of the present invention should be determined by the scope of the claims. The embodiments of the present invention are described in detail below. In order to facilitate the description of the present invention and simplify the description, the technical terms used in the specification of the present invention should be interpreted broadly, including but not limited to conventional alternatives not mentioned in this application, and including both direct and indirect implementation methods.
[0041] Example 1
[0042] Combination Figure 1 and Figure 2 This embodiment describes a Java runtime business logic protection method based on instruction-driven principles, which includes the following steps:
[0043] S1. Identify the target business logic and break it down into multiple business units.
[0044] Unit-based decomposition of target business logic:
[0045] During the application development phase, for the target business logic that needs protection, developers write business code according to unified specifications based on system requirements, dividing the target business logic into multiple relatively independent business units. Each business unit that needs protection uniformly adopts the following standard method interface, and the method is annotated with the special annotation @LogicUnit. The annotation parameters are used to define the execution control information of the business unit:
[0046] @LogicUnit(condition = "context.get('userVerified') == true",loopCount = "1")
[0047] public void methodName(Map<String, Object> context);
[0048] Here, `userVerified` is a conditional control parameter, which developers can define themselves. Its value is a boolean and is obtained from the context. `methodName` is the name of the business unit method, which developers can also define. `condition` describes the execution conditions; it's a conditional expression based on the context object to determine whether the business unit should execute. `loopCount` describes the number of executions and can be a fixed value or a dynamically calculated expression based on the context. All methods communicate through a shared Map.<String, Object> The type context object is used for data reading and writing, avoiding the direct passing of specific business objects, thereby reducing static dependencies between methods and improving the independence and composability of business logic decomposition.
[0049] Typically, business units are responsible for processing specific business logic, and the startup program calls these business units in a certain order to organize the complete business logic flow. A unified startup program, `startLogic(Map)`, is set up in the target business logic class.<String, Object> `context` is the context object, and `startLogic` is the unified startup method name. `context` is the context object, which is of type `Map`.<String, Object> The startup program invokes each business unit sequentially according to a predetermined order to complete the overall business process control. During the development phase, the execution order of the business units is organized by static invocation.
[0050] During the program compilation phase, the business unit compiler automatically parses the aforementioned target business logic classes. The business unit compiler scans all business units annotated with `@LogicUnit`, extracts each compliant business unit individually, and for each identified business unit, extracts its content and encapsulates it into a new, independent business unit class (the `LogicUnit` class), which serves as the base data source for subsequent splitting and instruction generation. Each generated `LogicUnit` class uniformly implements the predefined standard interface `LogicUnit#execute(Map...)`.<String, Object> The business logic of the original business unit method is migrated to the `execute` method. Each `LogicUnit` class is compiled into an independent class file, named with random, semantically neutral strings to avoid guessing the original business process. `execute` is the standard execution method of the new independent business unit class `LogicUnit`, and its internal business logic is the business logic migrated from the original business unit method `methodName`.
[0051] S2. Protect the order of execution instructions of the business unit through instruction description to form an instruction file of the business unit; encrypt and store the instruction file to form an encrypted instruction file;
[0052] To avoid inferring the original execution order from the business unit number, the business unit compiler uses unordered, unrelated random strings as a class naming strategy when generating LogicUnit classes, ensuring that the naming of business units has no direct correspondence with the actual business process.
[0053] During the extraction process, the business unit compiler not only extracts the calling order of each business unit, but also simultaneously parses the execution conditions and loop control parameters defined by the `@LogicUnit` annotation on each business unit, comprehensively generating a structured sequence of execution instructions. Each sequence of execution instructions contains the business unit identifier, execution conditions, loop control information, and jump relationships, fully describing the dynamic execution path of the business process. The generated sequence of execution instructions is stored in an external instruction file using encryption, providing a basis for dynamic loading and scheduling execution during program runtime.
[0054] After compilation, the `startLogic` function, which originally statically and sequentially called various business methods in the original target business logic class, will be replaced. Its internal content will be uniformly modified to call the dynamic instruction parser interface. At runtime, the dynamic instruction parser uses Javassist bytecode manipulation technology to dynamically generate anonymous classes, performing decryption of encrypted instruction files, instruction parsing, and dynamic scheduling of business units based on conditional control in memory. In this way, the dynamic restoration and execution of the original target business logic is achieved. Ultimately, the target business logic class itself no longer contains any actual business processing logic, retaining only the entry point for the startup instruction parsing, significantly improving the overall security and protection capabilities of the program.
[0055] Identifying Startup Programs and Business Units: The business unit compiler performs static analysis on the target business logic class to distinguish between startup programs and business units. Startup programs serve as the entry point for the business process, while business units are independent logical units; the identification relationship between the two will be handled separately in subsequent steps.
[0056] S3. When the target business logic needs to be executed, a dynamic instruction parser is first generated. The dynamic instruction parser loads the corresponding encrypted instruction file according to the current business scenario and restores the contents of the encrypted instruction file into a structured sequence of execution instructions through a decryption process.
[0057] Encrypted storage of the execution order of business units:
[0058] After completing the unitization of the target business logic, in order to prevent attackers from inferring the complete business process by analyzing the distribution, relationship or loading order of business unit classes, the execution order of business units is protected by instruction-based description and encrypted storage.
[0059] During the compilation phase, the business unit compiler extracts each business method and simultaneously parses the `@LogicUnit` annotation parameter information of each method. Combining this with the execution order of business units in the target business logic class, it generates a structured sequence of execution instructions. Each execution instruction corresponds to the execution description of a business unit, and the content of the instruction includes the target business unit identifier, execution conditions, loop control, and other information. The content of the instruction file can be represented in the following format:
[0060] {
[0061] "unit": "LogicUnit_random string",
[0062] "condition": "context.get('userVerified') == true",
[0063] "loopCount": "1"
[0064] }
[0065] The unit field represents the unique identifier of the current business unit, the condition field represents the execution judgment logic based on the context parameters, and the loopCount field represents the number of times the current business unit is executed (which can be a fixed value or a value dynamically determined based on the context).
[0066] The execution instruction sequence is organized in JSON format and arranged according to the execution order of methods in the target business logic class for subsequent dynamic parsing and execution. To prevent static analysis or tampering of the execution instruction sequence, a symmetric encryption algorithm is used to encrypt the entire sequence during the compilation phase, combined with a dynamically generated key mechanism to avoid directly exposing the decryption key in the program file. Additionally, an integrity signature can be appended to the encrypted instruction file to support runtime integrity verification and tamper-proof protection.
[0067] The encrypted instruction file is packaged and deployed along with the program as an independent file resource, ensuring that even if an attacker obtains the class file of the target business logic, they cannot directly recover the complete execution path of the critical business process through static analysis because it does not contain specific business implementation and business process information.
[0068] Runtime instruction parsing and dynamic execution:
[0069] During program execution, when the target business logic needs to be executed, a dynamic instruction parser is first generated using Javassist bytecode manipulation technology. This parser then loads the corresponding encrypted instruction file based on the current business scenario and uses a built-in decryption module to restore the instruction file content into a structured sequence of execution instructions. The decryption process employs a symmetric encryption algorithm, and the key is derived in real-time through a pre-defined dynamic generation mechanism, avoiding the direct exposure of a fixed key in the program file and further enhancing system security.
[0070] After decrypting and parsing the instruction file, the dynamic instruction parser dynamically organizes the overall business execution flow based on the business unit identifier, execution condition, and loop control information (loopCount) extracted from the execution instruction sequence, combined with the sequential definition of the target business logic methods. During execution, the dynamic instruction parser determines whether to execute the corresponding business unit based on the condition field of each instruction, and controls the number of executions based on the loopCount parameter, sequentially completing the invocation of each LogicUnit.
[0071] The generated dynamic instruction parser has the following characteristics:
[0072] The calling logic of the business unit is dynamically parsed and organized at runtime, rather than statically coded, to avoid being extracted by static analysis tools;
[0073] The dynamic instruction parser generates instructions dynamically as anonymous classes, with class and method names using random, semantically meaningless identifiers, reducing readability for debuggers to recognize and trace.
[0074] The parsed execution chain and scheduling logic exist only in memory and are not stored on disk to prevent extraction or restoration through static means;
[0075] The entire process of instruction parsing and business unit scheduling is completed in real time during runtime. Even if an attacker intervenes through debugging, it is difficult to directly deduce the complete business execution path and logical structure.
[0076] S4. Extract the execution instructions from the decrypted execution instruction sequence, and dynamically complete the target business logic according to the order of the execution instructions and the control logic.
[0077] After the dynamic instruction parser is generated, the program uses the unified entry point method execute(Map)<String,Object> The system initiates the business logic process using the context, dynamically completing the entire target business logic processing according to the execution order and control logic. Since the execution path, order, and condition control are all dynamically generated and parsed at runtime and are not reflected in static code, the system's ability to resist static analysis, dynamic debugging, and reverse engineering attacks is greatly improved.
[0078] Generate JSON-formatted instruction files: Based on the order in which business units are called in the startup program, and combined with metadata such as condition and loopCount defined on each business method, the business unit compiler generates a structured sequence of business process execution instructions. The execution instruction sequence is organized in JSON format, with each instruction corresponding to an execution description of a business unit, including the unit identifier, execution condition expression, loop control expression, etc.
[0079] Business unit deletion: After the business unit split is completed, all existing static business units in the target business logic class are deleted, retaining only the startup program and necessary class definition structures. In this way, the actual business processing logic is completely separated from the source code structure, preventing logic leaks.
[0080] Dynamic encryption and signing of instruction files: To prevent static analysis or tampering of instruction files during storage and distribution, the business unit compiler encrypts the entire generated JSON-formatted instruction file using a symmetric encryption algorithm. During encryption, the encryption key is dynamically generated to avoid hardcoding a fixed key in the code. Simultaneously, an integrity signature is appended to the encrypted file to ensure its trustworthiness and tamper-proof capabilities.
[0081] The startup body is replaced with a call to the dynamic instruction parser interface: After business unit extraction and instruction generation are completed, the startup body of the target business logic class is uniformly replaced. In the new startup body, the original code that statically called various business methods has been removed, and a unified interface for calling the dynamic instruction parser has been replaced. The dynamic instruction parser loads the encrypted instruction file at runtime, parses the instructions, and dynamically calls each LogicUnit to restore the original business process logic.
[0082] The original, unencrypted JSON instruction file is deleted, and only the encrypted instruction file is retained for deployment with the application. This ensures that even if an attacker obtains the application package contents, they cannot reconstruct critical business process information by analyzing the instruction file.
[0083] Example 2
[0084] This embodiment, described in conjunction with Example 1, discloses a Java runtime business logic protection method based on instruction-driven principles, comprising the following steps:
[0085] 1. Execute the startup program and call the dynamic instruction resolver: During the program execution phase, the unified startup program in the target business logic class is first called. The startup program itself no longer contains static business logic code, but instead calls the dynamic instruction resolver module through a standard interface to initiate the dynamic loading and execution process of the target business logic.
[0086] 2. Loading and Decrypting the Instruction File: Upon receiving the startup call, the dynamic instruction parser locates the encrypted instruction file according to the preset path or configuration parameters, loads the file data, and calls the built-in decryption module. The parser decrypts the instruction file based on a dynamically generated symmetric key, while simultaneously verifying the file integrity signature to ensure that the instruction file has not been tampered with. After successful decryption, the structured original execution instruction sequence data is obtained, ready to enter the instruction parsing stage.
[0087] 3. Parsing Instructions and Constructing Execution Plans: In the decrypted sequence of execution instructions, each instruction contains a business unit identifier (unit), execution condition (condition), and loop control information (loopCount). The dynamic instruction parser parses each instruction one by one, extracts execution parameters, and dynamically constructs an execution plan table or scheduling chain in memory based on the order of instructions and conditional jump rules, preparing for subsequent execution.
[0088] 4. Execution Instruction Scheduling Logic: Based on the parsed execution plan, the dynamic instruction parser sequentially schedules the execution of each LogicUnit business unit. For each business unit, it first dynamically determines whether to execute based on the condition defined in the instruction; if the condition is met, it executes the specified number of times according to the loopCount definition. During the execution of each business unit, a context object is used uniformly for data transfer and state sharing to ensure the continuity of business logic and data consistency.
[0089] 5. Complete execution and release resources: After all business units defined by the instructions have completed execution, the dynamic instruction parser releases the dynamically generated execution chain instance and related resources in memory, completing the dynamic execution of this critical business process. Since the entire execution chain and scheduling logic are dynamically generated and managed at runtime and are not reflected in static code, it effectively prevents the execution path from being statically extracted or dynamically debugged and traced.
[0090] Example 3
[0091] This embodiment is described in conjunction with Embodiment 1 and Embodiment 2. The business logic protection system disclosed in this embodiment, based on the instruction-driven Java runtime business logic protection method described in Embodiment 1 or Embodiment 2, includes a business unit splitting module, a startup program definition module, a business unit compiler, a dynamic instruction parser, and an instruction execution module.
[0092] The business unit splitting module is used to obtain the target business logic and split the target business logic into multiple relatively independent business units;
[0093] The startup program definition module is used to define a unified startup program for each business unit;
[0094] The business unit compiler is used to extract the execution instructions and calling order of each business unit and generate an encrypted instruction file;
[0095] The dynamic instruction parser is used to load the corresponding encrypted instruction file according to the current business scenario, and restore the contents of the encrypted instruction file into a structured sequence of execution instructions through a decryption process;
[0096] The instruction execution module is used to dynamically complete the target business logic according to the order of the execution instruction sequence and control logic.
Claims
1. A Java runtime business logic protection method based on instruction-driven principles, characterized in that: Includes the following steps: S1. Divide the target business logic into multiple business units; The business units are called and parsed using a unified interface and startup program. Each business unit is marked with an annotation, which includes at least execution condition parameters and loop control parameters. In S1, after unitization and splitting, the original static business units in the target business logic class are deleted, and only the startup program and class definition structure are retained; S2. Protect the order of execution instructions of the business unit through instruction description to form an instruction file of the business unit; encrypt and store the instruction file to form an encrypted instruction file; The sequence of execution instructions is organized in JSON format, and each execution instruction includes at least a business unit identifier, an execution condition expression, and a loop control expression; the encrypted storage uses a symmetric encryption algorithm combined with a dynamically generated key mechanism. In S2, after the encrypted instruction file is created, the original instruction file is deleted, and only the encrypted instruction file is kept. S3. When the target business logic needs to be executed, a dynamic instruction parser is first generated. The dynamic instruction parser loads the corresponding encrypted instruction file according to the current business scenario and restores the contents of the encrypted instruction file into a structured sequence of execution instructions through a decryption process. The dynamic instruction parser dynamically generates anonymous classes using Javassist bytecode manipulation technology. The class names and method names are randomly generated without semantic identifiers and exist only in memory. S4. Extract the execution instructions from the decrypted execution instruction sequence, and dynamically complete the target business logic according to the order of the execution instructions and the control logic.
2. The instruction-driven Java runtime business logic protection method according to claim 1, characterized in that, In S2, the instruction description refers to the execution description of each business unit, and the execution instruction includes the target business unit identifier, execution conditions, and loop control.
3. The instruction-driven Java runtime business logic protection method according to claim 1, characterized in that, In S2, the encrypted storage refers to generating a structured sequence of execution instructions based on the execution order of the business unit in the target business logic. Specifically, the execution order of the business units is encrypted and numbered to ensure that the encrypted number of each business unit is different from the original execution order.
4. The Java runtime business logic protection method based on instruction-driven approach according to claim 1, characterized in that, In S3, the decryption process is implemented through a built-in decryption module. The decryption process uses a symmetric encryption algorithm, and the key is derived in real time through a preset dynamic generation mechanism.
5. A business logic protection system based on the instruction-driven Java runtime business logic protection method as described in any one of claims 1-4, characterized in that, This includes a business unit splitting module, a startup program definition module, a business unit compiler, a dynamic instruction parser, and an instruction execution module; The business unit splitting module is used to obtain the target business logic and split the target business logic into multiple relatively independent business units; The startup program definition module is used to define a unified startup program for each business unit; The business unit compiler is used to extract the execution instructions and calling order of each business unit and generate an encrypted instruction file; The dynamic instruction parser is used to load the corresponding encrypted instruction file according to the current business scenario, and restore the contents of the encrypted instruction file into a structured sequence of execution instructions through a decryption process; The instruction execution module is used to dynamically complete the target business logic according to the order of the execution instruction sequence and control logic.