Web application anti-debugging method based on dynamic code distribution and full-link verification

Abstract

The application discloses a web application anti-debugging method based on dynamic code distribution and full-link verification, comprising the following steps: segmenting front-end core code, performing dynamic code distribution; performing confusion and encryption on the segmented core code; generating device fingerprints and Token at regular time; performing WASM dynamic loading and execution; constructing an interface calling graph according to business logic on the server side, and performing full-link verification; obtaining device fingerprints on the terminal; generating and verifying dynamic Token when the server side accepts a request; dynamically encrypting the request content and returning the same to the front end for decryption; performing real-time connection of the front end and the server side, and performing defense based on distributed fuse control. In combination with various advanced technical means such as module dependency graph, interface calling graph constraint, dynamic Token and device fingerprint binding, the difficulty of code reverse engineering is significantly improved, illegal requests are intercepted, and a comprehensive defense method of all aspects and multiple levels is constructed for a web application.

Description

Technical Field

[0001] This invention relates to anti-debugging methods for web applications, and more particularly to anti-debugging methods for web applications based on dynamic code distribution and end-to-end verification. Background Technology

[0002] In today's era of rapid digital development, web applications have become the core hub for information exchange, widely used in data transmission scenarios between users and organizations; however, their open architecture brings a series of security risks: Web applications need to address numerous security issues, including application vulnerability protection, prevention of leakage of sensitive user information, protection of core logic, and assurance of system stability, to meet ever-increasing security demands. Modern web applications generally adopt single-page applications or progressive web application architectures, with a large amount of business logic migrating to the front end. Operations such as data validation and encrypted calculations are performed on the front end, making it a prime target for attackers and significantly increasing the risk of attack. Furthermore, attackers can leverage professional debugging tools such as Chrome DevTools and Fiddler to perform malicious operations such as code injection, parameter tampering, and request interception. They can also use web scraping techniques to steal data, posing significant security risks to web applications. Existing anti-debugging techniques have the following shortcomings: 1. Traditional code obfuscation tools, such as UglifyJS, can only perform basic operations such as variable name replacement and format compression. Through techniques such as Abstract Syntax Tree (AST) parsing, attackers can still restore the control flow structure of the code, reducing the effectiveness of code obfuscation. II. Common debugging and detection methods, such as using the debugger statement for detection, can be disabled by attackers by setting breakpoints; and when using performance monitoring functions to detect debugging behavior, attackers can easily bypass the detection by forging timestamps, causing the debugging and detection mechanism to fail. Third, the traditional static token mechanism uses a fixed token for authentication. The fixed token lacks dynamic binding with device characteristics or call context. Attackers can capture and reuse the token to forge legitimate requests. Fourth, the existing server-side interface verification mechanism only verifies the legitimacy of a single interface and does not establish rules for the order of calls between interfaces; attackers can bypass the verification by forging request sequences. Fifth, the protection strategies of the front end and the server end are independent of each other and lack an effective coordination mechanism. For example, when an attacker bypasses the front end debugging and detection, he can send a request with a forged signature to the server end. The server end cannot detect and block such attacks in time, and a comprehensive defense system is not formed, resulting in poor overall defense effect and failing to meet the growing security needs of web applications. Summary of the Invention

[0003] To address the shortcomings of the aforementioned technologies, this invention provides a web application anti-debugging method based on dynamic code distribution and end-to-end verification.

[0004] To solve the above technical problems, the technical solution adopted by this invention is: a web application anti-debugging method based on dynamic code distribution and full-link verification, specifically including the following steps: Step S1: Divide the core front-end code according to the functional cohesion rules and the principle of low coupling to obtain several atomic modules that can be independently loaded and executed on demand, and build a module dependency graph for dynamic code distribution and protection; Among them, a time window constraint mechanism is set between each atomization module; Step S2: Obfuscate and encrypt the segmented core code using JavaScript Obfuscato; Step S3: Collect hardware features based on Fingerprint JS, and periodically generate device fingerprints and bind them to tokens; Step S4: The core code, after being segmented, encrypted, and obfuscated, is dynamically loaded and executed using WASM for memory protection and circuit breaker protection. Step S5: The server constructs an interface call graph based on the business logic. When receiving requests, the server verifies the call graph in sequence to perform full-link verification. Step S6: The server obtains the device fingerprint; Step S7: When the server receives a request, it performs dynamic token generation and verification; Step S8: Dynamically encrypt the request content and return it to the front end, where the front end decrypts it; Step S9: Establish a real-time connection between the front-end and the server based on the WebSocket real-time channel, and perform defense based on distributed circuit breaker control.

[0005] Furthermore, step S1 involves dynamic code distribution and protection, specifically including the following steps: Step S11: Conduct a comprehensive analysis of the functional requirements of the Web application; Step S12: Based on the functional requirements analysis results obtained in step S11, the Web application is divided into several independent atomic modules, each of which has clear inputs and outputs; Step S13: Perform detailed design for each atomization module; Step S14: Code the modules according to the design to ensure that the functionality of each atomic module meets the actual requirements; Step S15: Perform unit testing and synthesis testing on each atomized module.

[0006] Furthermore, step S2 involves obfuscating the segmented core code, specifically including the following steps: Step A1: Convert the original sequential execution logic into a Switch-Case structure, insert several useless branches, and flatten the control flow. Step A2: Encrypt the plaintext string; Step A3: Insert a conditional branch that will never be executed; Step S2 involves encrypting the segmented core code, specifically including the following steps: Step B1: Encrypt the obfuscated code using the AES-256-GCM symmetric encryption algorithm; Step B2: The AES key is encrypted and transmitted based on the RSA-OAEP algorithm. The public key is built into the WASM module to effectively prevent key leakage.

[0007] Furthermore, in step S3, the device fingerprint is bound to the token, which specifically includes the following steps: Step S31: Collect various hardware characteristic information of the device; Step S32: Process the collected hardware feature information, concatenate the hash values ​​of multiple hardware feature information, perform hash calculation again, and generate a unique device fingerprint; Step S33: Generate original data by combining device fingerprint, timestamp and random number; and sign the original data using HMAC-SHA256 algorithm and bind the session validity period; Step S34: The server verifies and parses the Token to obtain the device fingerprint from the raw data; Step S35: Compare the device fingerprint of the current device with the device fingerprint in the Token in step S34; if they match, perform Token signature verification; if they do not match, trigger an exception.

[0008] Furthermore, step S4 involves dynamic loading and execution via WASM, specifically including the following steps: Step C1: Write the module call verification logic using the Rust language, and compile it into a WASM module using the wasm-pack tool; Step C2: The frontend initiates a module request, carrying the current device fingerprint and the call context; Step C3: After verifying the validity of the request, the server returns the module code encrypted with AES-256-GCM and the key encrypted with RSA-OAEP. Step C4: The WASM module decrypts and verifies the code integrity, and executes it dynamically through the Function constructor.

[0009] Furthermore, step S4 includes memory protection and circuit breaker protection, specifically comprising the following steps: Step D1: Allocate independent memory space for the WASM module using WebAssembly.Memory, and prohibit JavaScript from directly accessing this memory area; Step D2: If three consecutive rule violations are detected, a circuit breaker operation will be triggered. The circuit breaker operation includes clearing WASM memory, destroying the front-end encryption key, and notifying the server to terminate the current session via WebSocket.

[0010] Furthermore, the end-to-end verification in step S5 specifically includes the following steps: Step S51: Define the call dependencies between interfaces in detail according to the specific business scenario; Step S52: The server maintains a session state machine. When a request is received, it verifies the legality of the request in real time based on the interface call graph. For requests that are not initiated in the order of the graph, such as calling the data query interface without logging in, the server will reject the request, effectively blocking the illegal request chain.

[0011] Furthermore, step S8 involves dynamically encrypting the requested content and returning it to the front end, specifically including the following steps: Step S81: The server generates a unique AES-GCM key for each session; Step S82: Sensitive API response data is encrypted using AES-GCM, and the ciphertext is returned together with the authentication tag; Step S83: The front end decrypts the code using the WASM module.

[0012] Furthermore, step S9, which establishes a real-time connection between the front-end and the server based on the WebSocket real-time channel, specifically includes the following steps: Step E1: The front end establishes a WebSocket connection, and the server immediately sends a device fingerprint collection command to complete the device identity binding and initiate the session. Step E2: The call status of each atomic module on the front end is synchronized to the server in real time. The server updates the interface call permissions in a timely manner according to the status information to ensure the consistency between the front end and the server and the legality of the interface call. Step E3: Set the heartbeat cycle and send a liveness verification packet to the server according to the heartbeat cycle.

[0013] Furthermore, step S9, which involves defense based on distributed circuit breaker control, specifically includes the following steps: Step F1: When the server detects that the abnormal request rate of the same device fingerprint exceeds the set threshold, it automatically adds the device fingerprint to the blacklist and rejects all subsequent requests from that fingerprint. Step F2: The server sends a circuit breaker command to the front end via WebSocket; Step F3: After receiving the circuit breaker command, the front end immediately triggers a memory cleanup operation and locks the interface.

[0014] This invention discloses a web application anti-debugging method based on dynamic code distribution and end-to-end verification, which has the following beneficial effects: First, by using WASM modular execution and code loading technology, the core business logic is made "logic invisible" and ensures that the code runs in an isolated environment. At the same time, the core front-end technology business logic is divided into atomic modules according to function, and the dependencies and call order rules between modules are defined using a directed acyclic graph. Multi-layer obfuscation and encryption are used to process the core code, which significantly increases the difficulty of reverse engineering and makes it difficult for attackers to restore the code logic. In addition, the WASM isolated execution environment prevents JavaScript from directly accessing memory, effectively protecting the security of core code and user data. Second, by setting execution time thresholds for adjacent functional units, a circuit breaker mechanism is triggered upon timeout, actively blocking debugging interruption behavior, preventing the leakage of core code and user data, preventing attackers from maliciously tampering with the code execution rhythm through debugging tools, and ensuring the stability of system operation; Third, by combining device fingerprints with dynamic tokens, hardware features and real-time generated tokens are used to verify the legitimacy of the request source, ensuring the uniqueness and legitimacy of each request, completely blocking replay attacks, and significantly improving the legitimacy and accuracy of the request source. Fourth, by jointly verifying the interface call order in real time through front-end and back-end collaboration, a complete interface call graph is constructed, which effectively blocks illegal request chains, reduces the risk of man-in-the-middle attacks, and ensures the security and integrity of web application data interaction, preventing attackers from bypassing verification without making requests. Fifth, by using the WebSocket real-time channel to synchronize states during communication, we can prevent the front-end and back-end protection from being disconnected and build a holistic defense system. Through the distributed circuit breaker mechanism, we can effectively prevent malicious attacks from affecting the application and improve the stability and security of the application. Attached Figure Description

[0015] Figure 1 This is a framework diagram of the front-end and server-side in this invention.

[0016] Figure 2 This is an interaction diagram between the front-end and the server in this invention.

[0017] Figure 3 This is a flowchart illustrating the front-end dynamic code protection method in this invention.

[0018] Figure 4 This is the directed acyclic graph of the module dependency graph in this invention.

[0019] Figure 5 This is a flowchart of the code obfuscation and encryption process in this invention.

[0020] Figure 6 This is an interactive diagram of the dynamic loading and execution of WASM in this invention.

[0021] Figure 7 This is a flowchart of the server-side end-to-end verification process in this invention.

[0022] Figure 8 This is a flowchart of the generation and verification of the Token in this invention. Detailed Implementation

[0023] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0024] like Figure 1 and 2 The web application anti-debugging method shown is based on dynamic code distribution and end-to-end verification. Anti-debugging technology is a comprehensive technical system that uses a series of techniques, including code protection, environment monitoring, and request verification, to prevent or interfere with reverse analysis and debugging operations targeting web application logic. Specifically, it includes the following steps: Step S1: As Figures 3-6 As shown, the core front-end code is divided into several atomic modules according to functional cohesion rules and low coupling principles. A module dependency graph is constructed for dynamic code distribution and protection. This ensures that each atomic module can be loaded and executed independently and on demand, improving code flexibility and security, and overcoming the problem of control flow being easily restored in traditional code. The atomic modules include a data encryption module and a user authentication module, and the dependencies and call order rules between modules are clearly defined using an acyclic graph. As shown in the figure, data flows from module A to modules B and C. After being processed by module B, some data goes to module C and some data goes to module D. This embodiment provides a module dependency graph for constructing the payment process. Modules are called sequentially according to the authentication module, order generation module, and payment confirmation module. If the payment confirmation module is called directly without completing authentication, the system will immediately trigger an exception to ensure the correct execution of the business logic. The specific steps include: Step S11: Conduct a comprehensive analysis of the functional requirements of the Web application, that is, clarify the responsibilities and boundaries of each atomic module; for example, the responsibility of the order generation module is to obtain product information and generate an order based on this information, but does not include the order payment function; the responsibility of the payment confirmation module is to obtain order information and call payment, but does not include the order generation function. Step S12: Based on the functional requirements analysis results obtained in step S11, the Web application is divided into several independent atomic modules, and each atomic module has clear inputs and outputs to facilitate subsequent development and testing; for example, the order generation module takes product information as input and generates a completed order, including associated product information and price, as output. Step S13: Perform a detailed design for each atomic module, including module interface definition, internal logic structure, and data processing flow; the scalability and maintainability of the module should be fully considered during the design process; Step S14: Code the modules according to the design to ensure that the functionality of each atomic module meets the actual requirements; during the coding process, use some technical means to increase the difficulty of reverse engineering, such as code obfuscation and encryption; Step S15: Perform unit testing and integration testing on each atomic module to ensure the functional correctness and stability of each atomic module, and pay attention to the interface interaction and data transfer between modules during the integration testing process. The system employs a time window constraint mechanism between each atomized module, setting an execution time threshold Δt for adjacent functional units, where Δt ≤ 500ms. In actual operation, if module A completes its execution but fails to trigger a call to module B for a certain period (10 seconds in this embodiment), the system will determine that a debugging interruption may have occurred, thereby triggering the circuit breaker mechanism. This time window constraint mechanism can effectively monitor and prevent attackers from maliciously altering the code execution rhythm through debugging tools, proactively defend against debugging interruption behavior, overcome the problem of easy bypassing of debugging detection in existing technologies, and ensure the stability of system operation.

[0025] Dynamic code distribution is a model that involves finely dividing the core business logic code of a web application into several encrypted modules. These encrypted modules are dynamically loaded from the server and executed after the verification process is completed, thereby achieving code delivery.

[0026] Step S2: Obfuscate and encrypt the segmented core code using JavaScript Obfuscato; the combination of multi-layer obfuscation and encryption overcomes the limitations of traditional tools that only achieve surface obfuscation, significantly increasing the cost of reverse engineering. The core code after being split is obfuscated, specifically through the following steps: Step A1: Convert the original sequential execution logic into a Switch-Case structure and insert several useless branches to interfere with the attacker's reverse analysis and flatten the control flow; the Switch-Case structure is a multi-branch selection control structure. Step A2: Encrypt the plaintext string, convert it to Unicode encoding or a Hex array, and dynamically restore it at runtime; Step A3: Insert a conditional branch that will never be executed, increasing the complexity of static code analysis; in this embodiment, insert if(0).

[0027] The core code after being segmented is then encrypted, specifically through the following steps: Step B1: Encrypt the obfuscated code using the AES-256-GCM symmetric encryption algorithm to ensure the confidentiality and integrity of the code. The AES-256-GCM symmetric encryption algorithm is a symmetric encryption scheme that combines encryption and integrity verification. The 256-bit key version of the AES symmetric encryption algorithm uses a 256-bit key to encrypt data, which has a high level of security. The GCM mode allows the encryption to simultaneously provide confidentiality, integrity, and authenticity verification.

[0028] Step B2: The AES key is encrypted and transmitted using the RSA-OAEP algorithm. The public key is embedded in the WASM module, effectively preventing key leakage. The RSA-OAEP algorithm combines the RSA public-key encryption algorithm with OAEP optimal asymmetric encryption padding, which can solve the security flaws caused by the determinism of the original RSA encryption and meet higher security requirements. The WASM module, or WebAssembly module, is a program based on a binary instruction format, designed for efficient execution and secure sandboxing, running in browser and server environments.

[0029] Step S3: Based on Fingerprint JS, hardware features are collected, and device fingerprints are generated periodically and bound to tokens. These fingerprints are then compared with historical records on the server side to determine if any anomalies occur. This is used for server-side call uniqueness verification. In this embodiment, device fingerprints are generated every 30 minutes and compared with historical records on the server side. If the difference exceeds 10%, it is considered an anomaly, improving the legitimacy verification of the request source and overcoming the vulnerability of static token mechanisms to replay attacks. Fingerprint JS is a browser fingerprinting JavaScript library used for anonymous identification of user devices. The dimensions of hardware features include Canvas fingerprint, WebGL fingerprint, and audio fingerprint. The specific data for the Canvas fingerprint dimension is the pixel matrix of a 2D Canvas rendered grayscale image, which is hashed using the SHA-3-256 hash algorithm to obtain a fixed hash value. The specific data for the WebGL fingerprint dimension is the WebGL renderer version and extension support list, which is hashed using the MurmurHash hash algorithm to obtain a fixed hash value. The specific data for the audio fingerprint dimension is the AudioContext frequency response feature, which is hashed using the xxHash64 hash algorithm to obtain a fixed hash value.

[0030] Binding a device fingerprint to a token involves the following steps: Step S31: Collect various hardware characteristic information of the device; Step S32: Process the collected hardware feature information, concatenate the hash values ​​of multiple hardware feature information, and perform hash operation again to generate a unique device fingerprint; Step S33: Generate original data by combining device fingerprint, timestamp, and random number; and sign the original data using the HMAC-SHA256 algorithm and bind the session validity period; in this embodiment, the timestamp is set to 60 seconds to generate a dynamic token with device fingerprint information, which is unique and time-sensitive; the HMAC-SHA256 algorithm is a key-based hash message authentication code algorithm used to provide data integrity verification and authentication. Step S34: The server verifies and parses the Token to obtain the device fingerprint from the raw data; Step S35: Compare the device fingerprint of the current device with the device fingerprint in the Token in step S34; if they match, perform Token signature verification; if they do not match, trigger an exception.

[0031] Step S4: The core code, after being segmented, encrypted, and obfuscated, is dynamically loaded and executed using WASM to implement memory protection and circuit breaker mechanisms to ensure that the web application does not leak core code and user data when attacked; Dynamic loading and execution via WASM specifically includes the following steps: Step C1: Write the module call verification logic using the Rust language, and compile it into a WASM module using the wasm-pack tool; WASM modules have high performance and good security, and can provide a reliable environment for code execution; Step C2: The frontend initiates a module request, carrying the current device fingerprint and the call context; Step C3: After verifying the validity of the request, the server returns the module code encrypted with AES-256-GCM and the key encrypted with RSA-OAEP. Step C4: After the WASM module decrypts and verifies the code integrity, it executes dynamically through the Function constructor. By using WASM modular execution and real-time code loading, "logic invisibility" is achieved. The WASM module isolates the execution environment, overcoming the security risks of JavaScript directly accessing memory and significantly improving the cost of reverse engineering.

[0032] Implementing memory protection and circuit breaker mechanisms includes the following steps: Step D1: Use WebAssembly.Memory to allocate memory space independently for the WASM module and prohibit JavaScript from directly accessing this memory area; the WASM module itself controls the memory growth operation memory.grow, which effectively prevents illegal memory access behavior in the JavaScript environment and protects the security of core code and user data. Step D2: If three consecutive rule violations are detected, a circuit breaker defense operation will be triggered. The circuit breaker defense operation includes clearing WASM memory, destroying the front-end encryption key, and notifying the server to terminate the current session via WebSocket, so as to block the attack in time and prevent the further spread of data leakage and malicious operations. Through proactive defense, the lag of passive detection in the existing technology is overcome, and core code and user data leakage is effectively prevented.

[0033] Step S5: As Figure 7 , 8 As shown, the server constructs an interface call graph based on business logic. When receiving requests, the server verifies the call graph sequentially, performing end-to-end verification. Specifically, this includes the following steps: Step S51: Define the call dependencies between interfaces in detail according to the specific business scenario; for example, {“API1 (login)”:[“API2 (get permission)”,“API3 (query data)”],“API2”:[“API4 (submit operation)”],“API3”:[]}; Step S52: The server maintains a session state machine. When a request is received, it verifies the legality of the request in real time based on the interface call graph. For requests that are not initiated in the order of the graph, such as calling the data query interface directly without logging in, the server will reject the request, effectively blocking the illegal request chain. The call order is enforced to overcome the disorder problem of isolated interface verification and block the illegal request chain.

[0034] End-to-end verification is a protection mechanism that implements joint verification from multiple dimensions, such as code execution order, API call rules, and device identity characteristics, throughout the entire request lifecycle from the front end to the server's response, to ensure the security and legitimacy of the entire chain.

[0035] Step S6: The server obtains the device fingerprint; Step S7: Bind the device fingerprint to a unique token, and dynamically generate and verify the token when a request is received to ensure the legitimacy of calls made using the same device fingerprint; The device fingerprint is bound to a unique token for verification, which includes the following steps: Step S71: Associate and bind the device fingerprint with the dynamic token. When the server receives a request, it checks whether the device fingerprint and the token in the request match. If they do not match, the request is rejected to ensure the legitimacy of the request source and prevent unauthorized devices from accessing the device. This can overcome the vulnerability of static tokens to replay attacks and ensure the legitimacy of the request source. Step S72: Combine device fingerprint, timestamp and random number to generate original data, sign the original data using HMAC-SHA256 algorithm, and bind the session validity period; for example, set the session validity period to 60 seconds to generate a dynamic token with uniqueness and timeliness. Step S73: The front end obtains the token valid for the session through WebSocket and carries the token with each API request; Step S74: After receiving the request, the server verifies the consistency of the token's signature, timestamp, and device fingerprint. Step S75: The token expires immediately after use, effectively preventing replay attacks; this single-use token mechanism can overcome the risk of replay attacks and ensure the uniqueness and legitimacy of each request. Step S8: Dynamically encrypt the request content and return it to the frontend. The frontend decrypts the content to ensure data security during transmission. The dynamic encryption and return of the request content to the frontend specifically includes the following steps: Step S81: The server generates a unique AES-GCM key for each session; Step S82: Sensitive API response data is encrypted using AES-GCM, and the ciphertext is returned along with the authentication tag; Step S83: The front end decrypts the key using the WASM module to ensure that the key is not exposed in the JavaScript environment; the key isolation mechanism overcomes the risk of key leakage in existing technologies and ensures data security during transmission.

[0036] Step S9: Establish a real-time connection between the front-end and the server based on a WebSocket or HTTPS real-time channel, and defend against attacks based on distributed circuit breaker control; during the real-time connection process, synchronize identity information, request call information, and call permission information in real time; from the time the web application is opened in the browser to the time the browser window is closed, protect yourself from attacks through real-time verification, heartbeat mechanism, and circuit breaker mechanism. This embodiment establishes a real-time connection between the front-end and the server based on a WebSocket real-time channel, specifically including the following steps: Step E1: The front end establishes a WebSocket connection, and the server immediately issues a device fingerprint collection command to complete the device identity binding and initiate the session, laying the foundation for subsequent communication and verification. Step E2: The call status of each atomic module on the front end is synchronized to the server in real time. The server updates the interface call permissions in a timely manner according to the status information to ensure the consistency between the front end and the server and the legality of the interface call. Step E3: Set the heartbeat cycle. The front end sends a liveness verification packet to the server according to the heartbeat cycle. In this embodiment, the heartbeat cycle is 15 seconds to ensure the active state of the connection, detect connection anomalies in a timely manner, and ensure the stability of communication. Real-time communication and state synchronization overcome the problem of front-end and back-end protection being separated in the existing technology and build an overall defense system.

[0037] Defense is based on distributed circuit breaker control, which includes server-side circuit breaker and front-end circuit breaker, and specifically includes the following steps: Step F1: When the server detects that the abnormal request rate of the same device fingerprint exceeds the set threshold, it automatically adds the device fingerprint to the blacklist and rejects all subsequent requests from that fingerprint, effectively preventing malicious requests from continuously attacking the system; in this embodiment, the threshold is set to 5 times / minute, which means the server-side circuit breaker is triggered. Step F2: The server sends a circuit breaker command to the front end via WebSocket, thus triggering the circuit breaker at the front end; Step F3: After receiving the circuit breaker command, the front end immediately triggers a memory cleanup operation and locks the interface; this prevents the attack from spreading further and protects the security of the front end environment; through distributed circuit breaker control, the impact of malicious attacks on the application is effectively prevented, and the stability and security of the application are improved.

[0038] This invention relies on close collaboration between the front-end and server-side, deeply integrating a front-end dynamic code protection mechanism and a server-side end-to-end verification mechanism. It leverages a front-end / back-end collaborative protection system and is implemented based on dynamic code distribution and end-to-end verification technologies. The front-end dynamic code protection mechanism employs modular segmentation and layered encryption techniques, combined with dynamic loading based on the WebAssembly module dependency graph, to construct a front-end code anti-reverse engineering technology system. It focuses on obfuscating and encrypting the front-end, i.e., the JavaScript running on the front-end, and the WebAssembly modules, thereby improving code security and confidentiality. The server-side end-to-end verification mechanism is based on interface call graphs, device fingerprint binding, and dynamic token verification technology to accurately verify the legitimacy of server-side requests. By using dynamic token verification technology and device fingerprint binding, it verifies the legitimacy of interface requests received by the server, ensuring reliable request sources and compliant operations. The front-end and back-end collaborative protection system uses the real-time communication channel WebSocket to achieve real-time synchronization of execution status and verification results. Based on the module dependency graph and interface call graph, it can quickly circuit breakers handle abnormal operations and accurately trace the source. It uses WebSocket to achieve real-time communication between the front-end and back-end, and builds an abnormal circuit breaker mechanism based on this to achieve the goal of front-end and back-end collaborative defense.

[0039] With dynamic code distribution and end-to-end verification as core technologies, combined with advanced technologies such as module dependency graphs, interface call graph constraints, dynamic tokens and device fingerprint binding, it significantly increases the difficulty of code reverse engineering, can intercept illegal requests, and builds a comprehensive and multi-layered defense method for web applications, effectively ensuring the overall security of web applications and meeting the growing security needs of web applications.

[0040] The above embodiments are not intended to limit the present invention, and the present invention is not limited to the examples given above. Any changes, modifications, additions or substitutions made by those skilled in the art within the scope of the technical solution of the present invention are also within the protection scope of the present invention.

Claims

1. A web application anti-debugging method based on dynamic code distribution and end-to-end verification, characterized in that, Includes the following steps: Step S1: Divide the core front-end code according to the functional cohesion rules and the principle of low coupling to obtain several atomic modules that can be independently loaded and executed on demand, and build a module dependency graph for dynamic code distribution and protection; Among them, a time window constraint mechanism is set between each atomization module; Step S2: Obfuscate and encrypt the segmented core code using JavaScript Obfuscator; Step S3: Collect hardware features based on Fingerprint JS, and periodically generate device fingerprints and bind them to tokens; Step S4: The core code, after being segmented, encrypted, and obfuscated, is dynamically loaded and executed using WASM for memory protection and circuit breaker protection. Step S5: The server constructs an interface call graph based on the business logic. When receiving requests, the server verifies the call graph in sequence to perform full-link verification. Step S6: The server obtains the device fingerprint; Step S7: When the server receives a request, it performs dynamic token generation and verification; Step S8: Dynamically encrypt the request content and return it to the front end, where the front end decrypts it; Step S9: Establish a real-time connection between the front-end and the server based on the WebSocket real-time channel, and implement defense based on distributed circuit breaker control; the defense based on distributed circuit breaker control specifically involves: Step F1: When the server detects that the abnormal request rate of the same device fingerprint exceeds the set threshold, it automatically adds the device fingerprint to the blacklist and rejects all subsequent requests from that fingerprint. Step F2: The server sends a circuit breaker command to the front end via WebSocket; Step F3: After receiving the circuit breaker command, the front end immediately triggers a memory cleanup operation and locks the interface.

2. The web application anti-debugging method based on dynamic code distribution and end-to-end verification according to claim 1, characterized in that, The dynamic code distribution and protection in step S1 specifically includes the following steps: Step S11: Conduct a comprehensive analysis of the functional requirements of the Web application; Step S12: Based on the functional requirements analysis results obtained in step S11, the Web application is divided into several independent atomic modules, each of which has clear inputs and outputs; Step S13: Perform detailed design for each atomization module; Step S14: Code the modules according to the design to ensure that the functionality of each atomic module meets the actual requirements; Step S15: Perform unit testing and synthesis testing on each atomized module.

3. The Web application anti-debugging method based on dynamic code distribution and end-to-end verification according to claim 2, characterized in that: Step S2 involves obfuscating the segmented core code, specifically including the following steps: Step A1: Convert the original sequential execution logic into a Switch-Case structure, insert several useless branches, and flatten the control flow. Step A2: Encrypt the plaintext string; Step A3: Insert a conditional branch that will never be executed; Step S2 involves encrypting the segmented core code, specifically including the following steps: Step B1: Encrypt the obfuscated code using the AES-256-GCM symmetric encryption algorithm; Step B2: The AES key is encrypted and transmitted based on the RSA-OAEP algorithm. The public key is built into the WASM module to effectively prevent key leakage.

4. The web application anti-debugging method based on dynamic code distribution and end-to-end verification according to claim 3, characterized in that: In step S3, the device fingerprint is bound to the token, which specifically includes the following steps: Step S31: Collect various hardware characteristic information of the device; Step S32: Process the collected hardware feature information, concatenate the hash values ​​of multiple hardware feature information, perform hash calculation again, and generate a unique device fingerprint; Step S33: Generate original data by combining device fingerprint, timestamp and random number; and sign the original data using HMAC-SHA256 algorithm and bind the session validity period; Step S34: The server verifies and parses the Token to obtain the device fingerprint from the raw data; Step S35: Compare the device fingerprint of the current device with the device fingerprint in the Token in step S34; if they match, perform Token signature verification; if they do not match, trigger an exception.

5. The Web application anti-debugging method based on dynamic code distribution and end-to-end verification according to claim 4, characterized in that: Step S4 involves dynamic loading and execution via WASM, specifically including the following steps: Step C1: Write the module call verification logic using the Rust language, and compile it into a WASM module using the wasm-pack tool; Step C2: The frontend initiates a module request, carrying the current device fingerprint and the call context; Step C3: After verifying the validity of the request, the server returns the module code encrypted with AES-256-GCM and the key encrypted with RSA-OAEP. Step C4: The WASM module decrypts and verifies the code integrity, and executes it dynamically through the Function constructor.

6. The anti-debugging method for web applications based on dynamic code distribution and end-to-end verification according to claim 5, characterized in that: Step S4 involves memory protection and circuit breaker mechanism protection, specifically including the following steps: Step D1: Allocate independent memory space for the WASM module using WebAssembly.Memory, and prohibit JavaScript from directly accessing this memory space; Step D2: If three consecutive rule violations are detected, a circuit breaker operation will be triggered. The circuit breaker operation includes clearing WASM memory, destroying the front-end encryption key, and notifying the server to terminate the current session via WebSocket.

7. The Web application anti-debugging method based on dynamic code distribution and end-to-end verification according to claim 6, characterized in that: The end-to-end verification in step S5 specifically includes the following steps: Step S51: Define the call dependencies between interfaces in detail according to the specific business scenario; Step S52: The server maintains a session state machine. When a request is received, it verifies the legality of the request in real time based on the interface call graph. For requests that are not initiated in the order of the graph, such as calling the data query interface directly without logging in, the server will reject the request, effectively blocking the illegal request chain.

8. The anti-debugging method for web applications based on dynamic code distribution and end-to-end verification according to claim 7, characterized in that: The dynamic encryption and return of the requested content to the front end in step S8 specifically includes the following steps: Step S81: The server generates a unique AES-GCM key for each session; Step S82: Sensitive API response data is encrypted using AES-GCM, and the ciphertext is returned together with the authentication tag; Step S83: The front end decrypts the code using the WASM module.

9. The anti-debugging method for web applications based on dynamic code distribution and end-to-end verification according to claim 8, characterized in that: Step S9, which establishes a real-time connection between the front-end and the server based on the WebSocket real-time channel, specifically includes the following steps: Step E1: The front end establishes a WebSocket connection, and the server immediately sends a device fingerprint collection command to complete the device identity binding and initiate the session. Step E2: The call status of each atomic module on the front end is synchronized to the server in real time. The server updates the interface call permissions in a timely manner according to the status information to ensure the consistency between the front end and the server and the legality of the interface call. Step E3: Set the heartbeat cycle and send a liveness verification packet to the server according to the heartbeat cycle.

Images