A WASM hot update method for mini-games based on virtual machine hardening

Abstract

This invention discloses a method for hot-updating a mini-game using a virtual machine-hardened WASM (Web Application Support Module), relating to the field of game engineering technology. The method includes: S1: Verifying the integrity of the obtained hot-update patch and temporarily storing the verified patch in an asynchronous thread of the game's main thread. Simultaneously, identifying a corresponding interruptible safety point in the main thread and entering an update critical section at that point based on the verified patch; S2: Setting a synchronization barrier flag in the update critical section to pause task scheduling in the main thread, and simultaneously performing snapshot data conversion between the old and new versions of the WASM instance using a preset data migration protocol; S3: Verifying the new version of the WASM instance after the snapshot data conversion, and updating the global context handle using atomic operations based on the verified new version of the WASM instance. This invention ensures the continuity and consistency of the game state before and after the update.

Description

Technical Field

[0001] This invention relates to the field of game engineering technology, specifically to a method for hot-updating mini-games using WASM based on virtual machine hardening. Background Technology

[0002] In the current technical architecture, WebAssembly (WASM) has gradually become the mainstream encoding and decoding target for the logic layer code of mini-games due to its near-native execution efficiency, cross-platform compatibility, and robust security sandbox mechanism. Compared to traditional JavaScript, the WASM binary format not only improves runtime performance but also increases the difficulty of reverse engineering.

[0003] However, with the widespread application of WASM in commercial games, the security threats it faces are becoming increasingly severe. Although WASM itself has a certain degree of anti-tampering capability, attackers can still extract core algorithms, crack payment logic, or create cheats through methods such as memory packet sniffing and binary reverse engineering, resulting in the theft of game code, disruption of business logic, and consequently, user churn and brand damage.

[0004] Traditional code protection methods, such as code obfuscation, while increasing the difficulty of reading code to some extent, are often insufficient to protect against highly skilled attackers. Therefore, the industry urgently needs a more advanced security hardening solution. Virtual Machine Protection (VM Protection) technology has emerged to address this need. This technology achieves deep hiding of code logic by converting standard instruction sets into custom private instruction sets, which are then executed at runtime by a dedicated interpreter.

[0005] Chinese invention patent CN102073528A discloses a method for obtaining the dynamic update time point of a traditional operating system. The proposed security point monitoring module M10 is used to discover the opportunity to perform a secure dynamic update of the operating system kernel M30 using the traditional dynamic update mechanism M20. The method comprises the security point monitoring module M10, which includes an initialization submodule M100, an event injection submodule M101, a security point generation submodule M102, a system service interface submodule M103, and a security point creation submodule M104. This invention guarantees the absolute security of the found dynamic update points, can quickly find secure dynamic update points, and will not affect the normal operation of user tasks.

[0006] However, the above and similar technical solutions still have the following shortcomings: Since hot updates are usually triggered by asynchronous events such as network downloads, their execution timing is uncertain, making them highly susceptible to race conditions with the game's main thread's critical execution flow (such as rendering loops, logic ticks, and settlement processes). If the old logic has not yet completed state reading and writing, and the context has not converged uniformly, forcibly switching WASM function pointers or replacing code segments will destroy the integrity of the runtime state machine, leading to variable value conflicts, memory layout misalignment, or data semantic inconsistencies between the old and new logic, thereby causing business anomalies such as reward calculation errors and archive corruption. Summary of the Invention

[0007] The purpose of this invention is to provide a method for hot-updating mini-games using WASM based on virtual machine hardening, in order to solve the problems mentioned in the background art above.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a method for hot-updating mini-games using WASM based on virtual machine hardening, comprising:

[0009] S1: Safety Point Detection Suspension: Perform integrity verification on the obtained hot update patch, and temporarily store the verified hot update patch in the asynchronous thread of the game's main thread. At the same time, determine the corresponding interruptible safety point from the game's main thread, and at the interruptible safety point, enter the update critical section according to the verified hot update patch.

[0010] S2: Update Critical Section Construction: In the update critical section, a synchronization barrier flag is set, the task scheduling of the game's main thread is paused, a new version of WASM instance is constructed, and the snapshot data of the old and new versions of WASM instance is converted through a preset data migration protocol;

[0011] S3: Verified Atomic Switching: Verify the new version of the WASM instance after the snapshot data conversion, and update the global context handle through atomic operations based on the new version of the WASM instance after successful verification.

[0012] Furthermore, entering the update critical region includes:

[0013] S1.1: Constructing a request queue: By setting a hot update event listener, the corresponding hot update trigger signal is received and obtained, and the integrity of the hot update trigger signal is verified. The verified hot update trigger signal is obtained, and the verified hot update trigger signal is temporarily stored in the set request buffer area to construct the corresponding hot update request queue.

[0014] S1.2: Safety Point Determination: By setting the state probe, the corresponding frame period, atomic transaction state and commit state are determined. By using the call stack monitoring hook, the preset safety breakpoint is determined in the game's main thread call stack. Based on the frame period, atomic transaction and commit state, the preset safety breakpoint is determined to identify the corresponding interruptible safety point.

[0015] S1.3: Suspend scheduling: When there is a verified hot update trigger signal in the hot update request queue and the corresponding call stack position is not an interruptible safe point, the control flow of the main thread continues to run, and the corresponding state of the verified hot update trigger signal is set to the suspended state.

[0016] When there is a verified hot update trigger signal in the hot update request queue, and the corresponding call stack position is an interruptible safe point, the hot update trigger signal with the highest priority is determined according to the priority in the hot update request queue, and the update critical section is entered according to the hot update trigger signal with the highest priority.

[0017] Furthermore, the corresponding interruptible safety points are identified, including:

[0018] S1.2.1: State determination: By setting the frame period probe, atomic transaction probe and state commit probe, state probes are implanted in the game engine or application framework to obtain the corresponding frame period, atomic transaction state and commit state.

[0019] S1.2.2: Determine the preset breakpoint: By monitoring the current execution context through the monitoring code set at the beginning of the plotting function, obtain all functions existing in the current execution context, and determine the state of the call stack and the preset safe breakpoint by comparing the obtained functions with the plotting function;

[0020] S1.2.3: Breakpoint Judgment: Based on the frame period, a basic security window is set, and within the basic security window, when the atomic transaction state is in an inactive state and the operation call point is in a committed state, the corresponding preset security breakpoint is an interruptible security point.

[0021] Furthermore, at the beginning and end of the game logic frame processing loop, corresponding frame start probes and frame end probes are set respectively to construct frame period probes and determine the boundaries of the identified frames.

[0022] Based on the game's business process, corresponding atomic transactions are written, and corresponding transaction entry probes and transaction exit probes are set at the entry point and exit path of the atomic transaction processing function, respectively, to construct atomic transaction probes and determine the progress status of the game's business process.

[0023] A state entry probe and a state exit probe are set up before and after the operation call point, respectively, to construct a state submission probe and determine the state of the operation call point.

[0024] Furthermore, all acquired functions and plotted functions are compared, and based on the comparison results, the corresponding call stack state and preset safe breakpoints are determined, specifically as follows:

[0025] If a plotted function exists among all the retrieved functions, the corresponding call stack is in an idle state, and the corresponding position on the call stack is the preset safe breakpoint; otherwise, the corresponding call stack is in a busy state, and the corresponding position on the call stack is not the preset safe breakpoint.

[0026] Furthermore, the snapshot data conversion between the old and new versions of WASM instances is performed, including:

[0027] S2.1: Entering the critical section: When entering the update critical section, the set synchronization barrier flag is triggered, and the task scheduling of the game main thread is paused according to the triggering state of the synchronization barrier flag. At the same time, the control flow of the game main thread is switched from the game business loop to the entry function corresponding to the hot update trigger signal.

[0028] S2.2: Parallel instantiation: By obtaining the module binary code and imported objects, the corresponding instantiation parameter package is set, and the instantiation parameter package is uploaded through the API interface. The encoding and linking completed in the new version of WASM instance are then constructed to obtain the corresponding new version of WASM instance.

[0029] S2.3: State Transition: Traverse the entire linear memory space and resource handle table of the old version WASM instance, identify the corresponding module metadata and external resource references, obtain the stack frame information corresponding to the call stack through the stack unrolling interface of the WASM runtime, and determine the state snapshot of the old version WASM instance based on the module metadata, external resource references and stack frame information. At the same time, determine the mapping relationship of data structures between the old and new version WASM instances through the set data migration protocol description file, and map the state snapshot to the new version WASM instance according to the mapping relationship to obtain the final new version WASM instance.

[0030] Furthermore, based on the required initial memory page count and maximum memory page count corresponding to the update task, the required initial linear memory size and maximum capacity of the new version WASM instance are set. Through the memory creation interface of the underlying WASM runtime, the virtual address space range corresponding to the new version WASM instance is set, and there is no overlap between the virtual address space range of the new version WASM instance and the linear memory address range of the old version WASM instance.

[0031] Furthermore, updating the global context handle through atomic operations includes:

[0032] S3.1: Fingerprint Comparison: Based on the target region and expected memory initialization image corresponding to the final new version WASM instance, determine the corresponding cyclic redundancy hash value and fixed-length hash value, compare the cyclic redundancy hash value and fixed-length hash value, and determine the corresponding fingerprint comparison result based on the comparison result, specifically:

[0033] When the cyclic redundancy check code and the fixed-length hash value are consistent, the final new version WASM instance passes the fingerprint comparison and the next step S3.2 boundary verification is executed; otherwise, the final new version WASM instance fails the fingerprint comparison and a rollback operation is triggered.

[0034] S3.2: Boundary Verification: Using the data mapping described in the data migration protocol description file, the target starting address and write data length corresponding to each memory write operation are obtained. These two values ​​are then combined to determine the corresponding write memory size. Simultaneously, the total linear memory size corresponding to the final new version of the WASM instance is compared with the write memory size. Based on the comparison result, the corresponding boundary verification result is determined. Specifically:

[0035] If the written memory size does not exceed the total linear memory size, the final new version WASM instance passes the boundary check, and the next step S3.3 atomic switch is executed based on the final new version WASM instance; otherwise, the final new version WASM instance fails the boundary check, and a rollback operation is triggered.

[0036] S3.3: Atomic Switching: Create an array of function pointers in the virtual machine hardening layer, and set the actual function pointers in the array to the memory address of the WASM function entry point corresponding to the final new version of the WASM instance.

[0037] Compared with the prior art, the beneficial effects of the present invention are:

[0038] Firstly, by identifying interruptible safety points, this invention ensures that hot update operations are only triggered when the game's main thread is in a safe and idle state, thereby avoiding problems such as race conditions, memory layout misalignment, and inconsistent data semantics caused by forced updates, and preventing game logic errors, abnormal reward calculations, or corrupted save files.

[0039] Secondly, by pausing the main thread task scheduling within the set update critical section and utilizing a preset data migration protocol, the present invention can completely and accurately snapshot and migrate the running state of the old version WASM instance to the new version WASM instance, thereby ensuring the continuity and consistency of the game state before and after the update.

[0040] Thirdly, before the final switch, this invention performs fingerprint comparison and boundary verification on the new version of WASM instance, and performs atomic operations after the verification is passed to update the global context handle, thereby preventing damaged or malicious update packages from disrupting game operation, and safely rolling back when verification fails, thus enhancing the robustness of the system.

[0041] Fourthly, this invention uses an asynchronous thread to prepare for the verification, temporary storage, and instantiation of hot update patches, and performs pause and switching operations at a safe interruptible point confirmed by the main thread, thereby minimizing the blocking time of the main thread and helping to maintain the smoothness and timely response of the game screen. Attached Figure Description

[0042] Figure 1 This is a flowchart illustrating the WASM hot update method for mini-games in this invention.

[0043] Figure 2 This is a flowchart illustrating the safety point detection suspension method of the present invention;

[0044] Figure 3 This is a flowchart illustrating the critical section construction method in this invention;

[0045] Figure 4 This is a flowchart illustrating the verified atom switching method in this invention. Detailed Implementation

[0046] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0047] refer to Figure 1 This embodiment provides a method for hot-updating mini-games using WASM based on virtual machine hardening. The specific steps of this method are as follows:

[0048] Step S1: Safepoint Detection Suspension. This involves asynchronously receiving the hot update patch for the target WASM module via network download or local events, verifying the integrity of the acquired hot update patch, and temporarily storing the verified patch in an asynchronous thread within the game's main thread. Simultaneously, a designated safepoint detection module listens to and judges the event loop of the game's main thread to determine the corresponding interruptible safepoint. At this interruptible safepoint, the update critical section is entered based on the verified hot update patch. It is important to note that if no corresponding interruptible safepoint exists in the game's main thread, the temporarily stored hot update patch will be suspended and delayed.

[0049] Step S2: Update Critical Section Construction. When the verified hot update patch enters the critical section, a synchronization barrier flag is set to pause task scheduling on the game's main thread, ensuring the hot update patch runs correctly. Simultaneously, a new version of the WASM instance is built according to the WASM runtime's instantiation interface, and snapshot data from the old version of the WASM instance is transferred to the new version using a preset data migration protocol.

[0050] Step S3: Atomic Switching After Verification. Based on the snapshot data transformation performed in Step S2, memory layout and semantic consistency are verified. After successful verification, the global context handle is updated atomically and points to the function index table of the new WASM instance, thus achieving an atomic switch between the old and new WASM instances.

[0051] In this embodiment, by listening to and judging the event loop of the game's main thread, the corresponding interruptible safe points are determined. In the game's main thread where there are no interruptible safe points, the verified and temporarily stored hot update patch is suspended and delayed. (Reference) Figure 2 This embodiment provides a method for suspending safety point detection, which specifically includes the following steps:

[0052] Step S1.1: Construct a request queue. This involves designing and deploying a hot update event listener and a request buffer in the client system. Specifically, the hot update event listener is independently set up in the background service module of the game's main thread. It receives hot update trigger signals from network interfaces (such as HTTP requests or WebSocket pushes) or local file systems (such as local cache checks) and performs integrity verification on the received hot update trigger signals. This includes, but is not limited to, verifying MD5 / SHA-256 hash values ​​and verifying digital signatures to obtain the corresponding hot update trigger signal after successful verification. It is worth noting that the integrity verification methods in this embodiment are all conventional techniques, so they are not specifically described in this embodiment.

[0053] Furthermore, the request buffer is used to temporarily store the hot update trigger signal after successful verification, in order to construct a priority hot update request queue. Specifically, the request buffer is set as a thread-safe and globally shared data buffer, and each unit of the request queue in the data buffer has a corresponding hot update request structure. The hot update request structure includes, but is not limited to, a task identifier (i.e., a unique ID), a task payload (i.e., a reference to the "hot update data package"), a target module (i.e., the name of the WASM module to be updated), and task metadata (such as priority, creation timestamp, and number of retries).

[0054] Step S1.2: Safety Point Determination. This involves using state probes to determine the corresponding frame period, atomic transaction state, and commit state. A call stack monitoring hook is used to monitor changes in the depth of the game's main thread call stack, and based on the monitoring results, corresponding preset safety breakpoints are determined. Simultaneously, the set safety point detection module is combined with the determined frame period, atomic transaction state, and commit state to perform safety point determination, thereby verifying the determined preset safety breakpoints and identifying the corresponding interruptible safety points. Details are as follows:

[0055] Step S1.2.1: State Determination. This involves embedding corresponding state probes into the game engine or application framework using the set frame cycle probes, atomic transaction probes, and state commit probes. Specifically, a corresponding frame start probe is set at the beginning of each game logic frame processing loop (e.g., after "processing input" and before "logic update" in the engine's main loop), and a corresponding frame end probe is set at the end of each game logic frame (e.g., after "logic update," "animation / physics simulation," and "rendering commit" are all completed, before entering the next frame loop or waiting for vertical synchronization). By using the set frame start and frame end probes, the corresponding frame cycle probe is constructed, thereby marking the beginning and end positions of each game logic frame to determine the boundaries of the identified frames.

[0056] Furthermore, by analyzing the game's business processes (such as battle settlement, data saving, and transaction submission), corresponding atomic transactions (i.e., logically indivisible and uninterrupted business process units, such as a complete battle damage calculation and settlement process, an archive write operation involving multiple data tables, or a network request sending and confirmation callback processing) are identified. Simultaneously, a corresponding transaction entry probe is set at the entry point of each atomic transaction processing function to set the corresponding flag at the entry point. Corresponding transaction exit probes are set on all exit paths of each atomic transaction processing function (i.e., including normal returns and abnormal exits) to clear the corresponding flags at the entry points. In other words, by setting transaction entry and exit probes, corresponding atomic transaction probes are constructed, thereby marking the entry and exit points of the game's business processes to determine the progress status of the game's business processes, including active and inactive states.

[0057] Furthermore, based on the operation call points that persist or externally affect the game's runtime state (i.e., variables in memory) (such as SavToDisk() to save the game, CommitTransaction() to commit a database transaction, Network.Send() to send the final state to the server, or writing the final score to the player data object), a corresponding state entry probe is set before each operation call point. This allows the setting of a flag bit preceding the operation call point. A corresponding state exit probe is set after each operation call point. This allows the setting of a flag bit preceding the corresponding operation call point to be cleared. In other words, by setting state entry and exit probes, a corresponding state submission probe is constructed. This allows setting flag bits at the operation call points where intermediate calculation results are written to permanent states (such as player attributes or inventory data) to distinguish the corresponding state, including the state in progress and the submitted state.

[0058] Step S1.2.2: Determine the preset breakpoint. This involves identifying the entry point executed by the game's main thread each frame with a call stack depth less than a preset depth (which can be set according to actual needs, so it is not specifically described in this embodiment). The corresponding marker function (e.g., the game's main loop entry function (e.g., MainLoop) or the engine-provided idle callback function (e.g., Unity's LateUpdate (after all Updates)) is then determined. Corresponding monitoring code (e.g., a "stub function") is set at the beginning of the marker function to monitor the current execution context. In other words, the monitoring code uniformly acquires all functions existing in the current execution context and compares them with the marker function. Based on the comparison result, the corresponding call stack state is determined, specifically:

[0059] If a plotted function exists among all the retrieved functions, the corresponding call stack is idle, and the location on the call stack is the preset safe breakpoint. Conversely, if no plotted function exists among all the retrieved functions, the corresponding call stack is busy, and the location on the call stack is not the preset safe breakpoint.

[0060] Step S1.2.3: Breakpoint Determination. This involves using the frame period probe set in Step S1.2.1 to determine the corresponding game logic frame boundary, and setting a basic safety window between two adjacent game logic frame boundaries (i.e., when the current game logic frame has ended and the next game logic frame has not yet started). Simultaneously, within the basic safety window, the atomic transaction status and the state of the operation call point are determined using the atomic transaction probe and status commit probe set in Step S1.2.1.

[0061] Furthermore, based on the preset safety breakpoints determined in step S1.2.2, the corresponding atomic transaction state and the state of the operation invocation point within the corresponding basic safety window are obtained. That is, when the atomic transaction state is inactive and the operation invocation point is in a committed state, the corresponding preset safety breakpoint is an interruptible safety point.

[0062] Step S1.3: Suspend Scheduling. Based on the hot update request queue obtained in Step S1.1 and the interruptible safety point determined in Step S1.2.3, the call stack position corresponding to the verified hot update trigger signal in the hot update request queue is determined. In other words, if a verified hot update trigger signal exists in the hot update request queue and the corresponding call stack position is not an interruptible safety point, the main thread's control flow continues (i.e., entering the rendering stage or starting the next frame), and the verified hot update trigger signal is set to a suspended state in the hot update request queue. Conversely, if a verified hot update trigger signal exists in the hot update request queue and the corresponding call stack position is an interruptible safety point, the highest priority hot update trigger signal is determined based on its priority and removed from the hot update request queue. Simultaneously, based on the update task corresponding to the highest priority hot update trigger signal, the task object of the update task (including patch data, target module information, etc.) is used as a parameter to call or trigger the next stage execution module, thus entering the update critical section. It is worth noting that during the process of entering the update critical section, the game's main thread task scheduling is paused.

[0063] In this embodiment, by setting a synchronization barrier flag and using a new version of the WASM instance, task scheduling of the game's main thread is paused, and snapshot data from the old version of the WASM instance is transferred to the new version of the WASM instance. (See reference...) Figure 3 This embodiment provides a method for constructing an updated critical section, which specifically includes the following steps:

[0064] Step S2.1: Entering the Critical Section. During system initialization, a globally visible boolean variable supporting atomic operations is used to set the corresponding synchronization barrier flag, which is then set in the game engine's main loop or task scheduler. Specifically, the update task corresponding to the highest-priority hot update trigger signal in step S1.3 enters the update critical section and triggers the synchronization barrier flag. Simultaneously, based on the triggered synchronization barrier flag, the task scheduling of the game's main thread is paused. It's worth noting that when pausing the game's main thread's task scheduling, its scheduling priority is set to the highest priority, and a compact loop that does not contain blocking calls and only checks the completion flag is executed to suspend the game's main thread. At the same time, the game's main thread executes the update task corresponding to the highest-priority hot update trigger signal in step S1.3. In other words, within the update critical section, the control flow of the game's main thread switches from the game's business logic loop to the entry function corresponding to the hot update trigger signal.

[0065] Step S2.2: Parallel Instantiation. Based on the required initial and maximum memory page counts for the update task in Step S1.3, the required initial linear memory size and maximum capacity for the new version of the WASM instance are set. Simultaneously, through the memory creation interface of the underlying WASM runtime (e.g., the WebAssembly object in the browser, or a standalone runtime such as Wasmtime / V8), the virtual address space range for the new version of the WASM instance is set, ensuring that the virtual address space range of the new version of the WASM instance does not overlap with the linear memory address range of the old version of the WASM instance.

[0066] Furthermore, the corresponding new version of the .wasm file data is obtained through network download or local caching to determine the corresponding module binary code. Based on the JavaScript object (i.e., in the web environment) or the corresponding host binding (i.e., in the native environment), the corresponding functions, global variables, and memory objects are set to determine the corresponding import object. In other words, the corresponding instantiation parameter package is set using the determined module binary code and import object. Simultaneously, the set instantiation parameter package is uploaded through the WASM runtime API interface (such as WebAssembly.instantiate or new WebAssembly.Instance), and the corresponding encoding and linking are completed in the new version of the WASM instance. The function table, default values ​​of global variables, and memory management structure of the new version of the WASM instance are also initialized to construct the corresponding new version of the WASM instance. It is worth noting that the encoding, linking, and initialization processes performed here are all conventional techniques, and therefore are not specifically described in this embodiment.

[0067] Step S2.3: State Transition. This involves traversing the entire linear memory space of the old WASM instance using the WASM runtime's debug or reflection interface to identify the corresponding module metadata, including data segments (i.e., the starting address and size of global data initialized at compile time in memory) and global variables (i.e., the type and memory address (or index) of each exported or internal global variable). Simultaneously, the stack unwinding interface of the WASM runtime is used to obtain the stack frame information corresponding to the call stack, including control flow information (i.e., return address and function identifier), local state information (i.e., local variables and computed state registers), frame pointers, and stack pointers. The resource handle table of the old WASM instance is also traversed to obtain corresponding external resource references, such as the timer ID returned by `setTimeout`, the network request object initiated by `fetch`, and open file descriptors. Based on the obtained external resource references, the corresponding resource binding list is set. In other words, by obtaining the module metadata, stack frame information, and resource binding list, a state snapshot corresponding to the old WASM instance is determined.

[0068] Furthermore, based on the update task in step S1.3, a corresponding data migration protocol description file is set up to determine the mapping relationship of the data structure between the new version WASM instance and the old version WASM instance. Simultaneously, based on the determined mapping relationship, the determined state snapshot of the old version WASM instance is mapped to the new version WASM instance to obtain the corresponding final new version WASM instance.

[0069] In this embodiment, based on the consistency check of the snapshot data, the global context handle is updated through atomic operations and points to the function index table of the new version of the WASM instance. (See reference...) Figure 4 This embodiment provides a method for switching atoms after verification, which specifically includes the following steps:

[0070] Step S3.1: Fingerprint Comparison. Based on the target region corresponding to the final new version WASM instance obtained in Step S2.3 (which can be specifically set according to the data migration protocol description file, so it is not specifically described in this embodiment), the corresponding cyclic redundancy check (CR) hash value is determined. Simultaneously, based on the expected memory initialization image corresponding to the final new version WASM instance (including the initial value of the module data segment corresponding to the new version WASM instance and the binary content of the target region corresponding to the final new version WASM instance), a preset anti-collision algorithm (such as SHA-256) is used to determine the corresponding fixed-length hash value. Specifically, the determined CR is compared with the fixed-length hash value, and the corresponding fingerprint comparison result is determined based on the comparison result. Specifically:

[0071] When the Cyclic Redundancy Check (CRC) code matches the fixed-length hash value, the final new version of WASM instance passes the fingerprint comparison and proceeds to the next step, S3.2, boundary verification. Conversely, when the CRC code does not match the fixed-length hash value, the final new version of WASM instance fails the fingerprint comparison. In this case, a rollback operation is triggered, which restores the global context handle to point to the old version of WASM instance and deletes the loaded final new version of WASM instance.

[0072] Step S3.2: Boundary Verification. This involves using the data mapping described in the data migration protocol file in Step S2.3 to obtain the target starting address and write data length for each memory write operation. These two values ​​are then combined to determine the corresponding write memory size. Simultaneously, based on the total linear memory size of the final new version of the WASM instance, the determined write memory size is compared with the total linear memory size. The boundary verification result is then determined based on the comparison result. Specifically:

[0073] If the written memory size does not exceed the total linear memory size, the final new version WASM instance passes the boundary check. At this point, the next step, S3.3 atomic switch, is performed based on the final new version WASM instance. Conversely, if the written memory size exceeds the total linear memory size, the final new version WASM instance fails the boundary check. In this case, a rollback operation is triggered, which restores the global context handle to point to the old version WASM instance and deletes the loaded final new version WASM instance.

[0074] Step S3.3: Atomic Switching. This involves creating a function pointer array in the virtual machine hardening layer (the thin layer between the game's main program and the WASM instance). Each entry in the function pointer array is configured with a WASM function that can be called externally (i.e., by the game's main program or other modules). Each entry in the function pointer array also includes a proxy jump instruction and an actual function pointer. The proxy jump instruction is fixed-length machine code used to jump based on the entry memory address in the corresponding actual function pointer. The actual function pointer is a variable used to store the entry memory address of the WASM function corresponding to the final new version of the WASM instance after boundary verification.

[0075] To elaborate further, a critical write operation is performed during the actual switchover. That is, based on the WASM function entry memory address corresponding to the final new version of the WASM instance, the entry memory address within the actual function pointer in the function pointer array is updated, and this is completed within a single memory write cycle.

[0076] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended embodiments and their equivalents.

Claims

1. A method for hot-updating mini-games using WASM based on virtual machine hardening, characterized in that, Including: S1: Safety Point Detection Suspension: Perform integrity verification on the obtained hot update patch, and temporarily store the verified hot update patch in the asynchronous thread of the game's main thread. At the same time, determine the corresponding interruptible safety point from the game's main thread, and at the interruptible safety point, enter the update critical section according to the verified hot update patch. S2: Update Critical Section Construction: In the update critical section, a synchronization barrier flag is set, the task scheduling of the game's main thread is paused, a new version of WASM instance is constructed, and the snapshot data of the old and new versions of WASM instance is converted through a preset data migration protocol; S3: Verified Atomic Switching: Verify the new version of the WASM instance after the snapshot data conversion, and update the global context handle through atomic operations based on the new version of the WASM instance after successful verification.

2. The method for hot-updating mini-games using WASM based on virtual machine hardening as described in claim 1, characterized in that, Entering the update critical section includes: S1.1: Constructing a request queue: By setting a hot update event listener, the corresponding hot update trigger signal is received and obtained, and the integrity of the hot update trigger signal is verified. The verified hot update trigger signal is obtained, and the verified hot update trigger signal is temporarily stored in the set request buffer area to construct the corresponding hot update request queue. S1.2: Safety Point Determination: By setting the state probe, the corresponding frame period, atomic transaction state and commit state are determined. By using the call stack monitoring hook, the preset safety breakpoint is determined in the game's main thread call stack. Based on the frame period, atomic transaction and commit state, the preset safety breakpoint is determined to identify the corresponding interruptible safety point. S1.3: Suspend scheduling: When there is a verified hot update trigger signal in the hot update request queue and the corresponding call stack position is not an interruptible safe point, the control flow of the main thread continues to run, and the corresponding state of the verified hot update trigger signal is set to the suspended state. When there is a verified hot update trigger signal in the hot update request queue, and the corresponding call stack position is an interruptible safe point, the hot update trigger signal with the highest priority is determined according to the priority in the hot update request queue, and the update critical section is entered according to the hot update trigger signal with the highest priority.

3. The method for hot-updating mini-games using WASM based on virtual machine hardening as described in claim 2, characterized in that, The corresponding interruptible safety points are identified, including: S1.2.1: State determination: By setting the frame period probe, atomic transaction probe and state commit probe, state probes are implanted in the game engine or application framework to obtain the corresponding frame period, atomic transaction state and commit state. S1.2.2: Determine the preset breakpoint: By monitoring the current execution context through the monitoring code set at the beginning of the plotting function, obtain all functions existing in the current execution context, and determine the state of the call stack and the preset safe breakpoint by comparing the obtained functions with the plotting function; S1.2.3: Breakpoint Judgment: Based on the frame period, a basic security window is set, and within the basic security window, when the atomic transaction state is in an inactive state and the operation call point is in a committed state, the corresponding preset security breakpoint is an interruptible security point.

4. The method for hot-updating mini-games using WASM based on virtual machine hardening as described in claim 3, characterized in that, At the beginning and end of the game logic frame processing loop, corresponding frame start probes and frame end probes are set respectively to construct frame period probes and determine the boundaries of the identified frames. Based on the game's business process, corresponding atomic transactions are written, and corresponding transaction entry probes and transaction exit probes are set at the entry point and exit path of the atomic transaction processing function, respectively, to construct atomic transaction probes and determine the progress status of the game's business process. A state entry probe and a state exit probe are set up before and after the operation call point, respectively, to construct a state submission probe and determine the state of the operation call point.

5. The method for hot-updating mini-games using WASM based on virtual machine hardening as described in claim 3, characterized in that, All acquired functions and plotted functions are compared, and based on the comparison results, the corresponding call stack state and preset safe breakpoints are determined, specifically as follows: If a plotted function exists among all the retrieved functions, the corresponding call stack is in an idle state, and the corresponding position on the call stack is the preset safe breakpoint; otherwise, the corresponding call stack is in a busy state, and the corresponding position on the call stack is not the preset safe breakpoint.

6. The method for hot-updating mini-games using WASM based on virtual machine hardening as described in claim 1, characterized in that, Perform snapshot data conversion between old and new versions of WASM instances, including: S2.1: Entering the critical section: When entering the update critical section, the set synchronization barrier flag is triggered, and the task scheduling of the game main thread is paused according to the triggering state of the synchronization barrier flag. At the same time, the control flow of the game main thread is switched from the game business loop to the entry function corresponding to the hot update trigger signal. S2.2: Parallel instantiation: By obtaining the module binary code and imported objects, the corresponding instantiation parameter package is set, and the instantiation parameter package is uploaded through the API interface. The encoding and linking completed in the new version of WASM instance are then constructed to obtain the corresponding new version of WASM instance. S2.3: State Transition: Traverse the entire linear memory space and resource handle table of the old version WASM instance, identify the corresponding module metadata and external resource references, obtain the stack frame information corresponding to the call stack through the stack unrolling interface of the WASM runtime, and determine the state snapshot of the old version WASM instance based on the module metadata, external resource references and stack frame information. At the same time, determine the mapping relationship of data structures between the old and new version WASM instances through the set data migration protocol description file, and map the state snapshot to the new version WASM instance according to the mapping relationship to obtain the final new version WASM instance.

7. A method for hot-updating mini-games based on virtual machine hardening according to claim 6, characterized in that, Based on the required initial and maximum number of memory pages corresponding to the update task, the required initial linear memory size and maximum capacity of the new version WASM instance are set. Through the memory creation interface of the underlying WASM runtime, the virtual address space range of the new version WASM instance is set, and there is no overlap between the virtual address space range of the new version WASM instance and the linear memory address range of the old version WASM instance.

8. The method for hot-updating mini-games using WASM based on virtual machine hardening as described in claim 1, characterized in that, Updating the global context handle through atomic operations includes: S3.1: Fingerprint Comparison: Based on the target region and expected memory initialization image corresponding to the final new version WASM instance, determine the corresponding cyclic redundancy hash value and fixed-length hash value, compare the cyclic redundancy hash value and fixed-length hash value, and determine the corresponding fingerprint comparison result based on the comparison result, specifically: When the cyclic redundancy check code and the fixed-length hash value are consistent, the final new version WASM instance performs fingerprint comparison and executes the next step S3.2 boundary verification. Conversely, if the final new version of WASM instance fails fingerprint comparison, a rollback operation will be triggered. S3.2: Boundary Verification: Using the data mapping described in the data migration protocol description file, the target starting address and write data length corresponding to each memory write operation are obtained. These two values ​​are then combined to determine the corresponding write memory size. Simultaneously, the total linear memory size corresponding to the final new version of the WASM instance is compared with the write memory size. Based on the comparison result, the corresponding boundary verification result is determined. Specifically: If the written memory size does not exceed the total linear memory size, the final new version WASM instance passes the boundary check, and the next step S3.3 atomic switch is executed based on the final new version WASM instance; otherwise, the final new version WASM instance fails the boundary check, and a rollback operation is triggered. S3.3: Atomic Switching: Create an array of function pointers in the virtual machine hardening layer, and set the actual function pointers in the array to the memory address of the WASM function entry point corresponding to the final new version of the WASM instance.

Images