Software protection method based on virtual machine encryption mode and storage medium

Abstract

The invention discloses a software protection method based on a virtual machine encryption mode and a storage medium, and the method comprises the steps: encrypting to-be-protected data through a key to obtain encrypted data, the to-be-protected data comprising an executable code, a configuration file and a resource file of to-be-protected software; constructing a virtual machine execution environment in the equipment memory, wherein the virtual machine execution environment comprises a virtual processor, a virtual memory space and a virtual register; loading the encrypted data to a virtual memory space, and configuring a virtual processor; after the protected software is started, performing anti-debugging monitoring, and if a debugging behavior is monitored, executing an anti-debugging operation; during the running period of the to-be-protected software, the MAC address of the equipment is obtained regularly, and the legality of the equipment is verified; and when a preset self-destruction triggering condition is met, executing a self-destruction operation. According to the method, various security threats can be effectively resisted, and software code and data security is protected.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of software security, in particular to a software protection method based on a virtual machine encryption mode and a storage medium. BACKGROUND

[0002] Under the current digital wave, software is facing unprecedented security challenges. From frequent attacks by malicious software to the threat of reverse engineering, data leakage risks are everywhere. Traditional encryption schemes are gradually unable to cope with complex attack methods, and a more powerful and intelligent encryption solution is urgently needed. SUMMARY

[0003] The technical problem to be solved by the application is to provide a software protection method based on a virtual machine encryption mode and a storage medium, which can effectively resist various security threats and protect software code and data security.

[0004] In order to solve the above technical problems, the technical scheme adopted by the application is as follows: a software protection method based on a virtual machine encryption mode, comprising: Obtaining a key and encrypting to-be-protected data through the key to obtain encrypted data, wherein the to-be-protected data includes executable code, configuration files and resource files of to-be-protected software; Building a virtual machine execution environment in the device memory, wherein the virtual machine execution environment includes a virtual processor, a virtual memory space and a virtual register; Loading the encrypted data to the virtual memory space and configuring the virtual processor; After the to-be-protected software is started, anti-debugging monitoring is performed, if a debugging behavior is monitored, an anti-debugging mechanism is triggered, and an anti-debugging operation is performed; During the running of the to-be-protected software, the MAC address of the device is obtained regularly, and the legality of the device is verified according to the MAC address of the device; When a preset self-destruction trigger condition is met, a self-destruction mechanism is triggered, and a self-destruction operation is performed.

[0005] The application further provides a computer readable storage medium, which stores a computer program, and the program is executed by a processor to realize the method.

[0006] The application has the beneficial effects that: by loading the software to be protected into a VM (virtual machine) execution environment after encryption, the software is ensured to run in a safe environment; by monitoring anti-debugging, the software process is prevented from being tracked or intervened by a debugger; by verifying the legality of the device periodically, the software is effectively prevented from running on an unauthorized device; by performing a self-destruction operation when the self-destruction trigger condition is met, the software can be self-destructed instantly when facing a security crisis, and the data security is maximally protected. The application can effectively resist various security threats and protect the software code and data security by constructing a safe VM execution environment, real-time effective anti-debugging measures, and precise remote binding control, combined with a powerful instant self-destruction function. BRIEF DESCRIPTION OF DRAWINGS

[0007] Figure 1 A flowchart of a software protection method based on a virtual machine encryption mode of the application; Figure 2 A method flowchart of the first embodiment of the application. DETAILED DESCRIPTION

[0008] To explain the technical content, purposes and effects of the application in detail, the following will be explained in combination with the embodiments and the drawings.

[0009] Please refer to Figure 1 A software protection method based on a virtual machine encryption mode, comprising: obtaining a key and encrypting the data to be protected by the key to obtain encrypted data, wherein the data to be protected includes the executable code, configuration file and resource file of the software to be protected; constructing a virtual machine execution environment in the device memory, wherein the virtual machine execution environment includes a virtual processor, a virtual memory space and a virtual register; loading the encrypted data into the virtual memory space and configuring the virtual processor; after the software to be protected is started, monitoring anti-debugging, and if a debugging behavior is monitored, triggering an anti-debugging mechanism to perform an anti-debugging operation; during the running of the software to be protected, obtaining the MAC address of the device periodically, and verifying the legality of the device according to the MAC address of the device; when the preset self-destruction trigger condition is met, triggering a self-destruction mechanism to perform a self-destruction operation.

[0010] As can be seen from the above description, the application has the beneficial effects that: by constructing a safe VM execution environment, real-time effective anti-debugging measures and precise remote binding control, combined with a powerful instant self-destruction function, various security threats can be effectively resisted, and the software code and data security are protected.

[0011] Furthermore, after the software to be protected is started, anti-debugging monitoring is performed. If debugging behavior is detected, the anti-debugging mechanism is triggered, and anti-debugging operations are performed, including: After the protection software starts, it obtains process status information, including the debugger process ID (TracerPid). If the debugger process ID is not 0, it is determined that the anti-debugging mechanism needs to be triggered and the anti-debugging operation is performed. A high-precision timer is used to record timestamps before and after the execution of preset critical code, thereby obtaining the start and end timestamps of the critical code, and the execution time of the critical code is calculated based on the start and end timestamps. If the execution time exceeds a preset time threshold, the software to be protected is determined to be in a debugging state, and an anti-debugging operation is performed. The anti-debugging operations include terminating the process, jumping to an invalid code region, and logging exceptions.

[0012] As described above, when the value of the TracerPid field is not 0, it indicates that the current process is being tracked by a debugger. By triggering anti-debugging mechanisms, measures such as terminating the process or jumping to invalid code regions are taken to prevent the debugger from working properly. Furthermore, if the software is being debugged, the debugger's intervention increases the overhead of instruction execution, significantly extending code execution time. Therefore, by recording the timestamps before and after the execution of critical code, the execution time of critical code is calculated. If the execution time exceeds a preset threshold, the software is considered to be in a debugged state. Anti-debugging operations are then initiated, such as modifying the code execution flow, to prevent the debugger from accurately setting breakpoints.

[0013] Furthermore, the key code includes core operation functions for the virtual machine environment, core encryption and decryption functions, and authorization verification functions. The core operation functions for the virtual machine environment include a virtual processor initialization function and a virtual machine encrypted code loading function. The core encryption and decryption functions include a key generation function and a sensitive data decryption function. The authorization verification functions include a MAC address upload function and an authorization result verification function.

[0014] As described above, VM environment construction is the foundation of encrypted software. If a debugger wants to crack the VM instruction set, it will inevitably set breakpoints here, leading to increased execution time. Encryption logic is the core target of cracking; debugger breakpoints significantly increase encryption and decryption time. Illegal debugging often attempts to bypass authorization; breakpoints can cause abnormal execution times in network interactions or verification logic. Therefore, by calculating the execution time of the core operation functions, encryption / decryption core functions, and authorization verification functions of the virtual machine environment, we can determine whether the software is in a debug state, ensuring coverage of core security logic.

[0015] Furthermore, before obtaining the start and end timestamps of the key code by recording timestamps before and after the execution of the preset key code using a high-precision timer, the process further includes: Verify the integrity of the high-precision timer interface.

[0016] As described above, since the debugger may return a false timestamp by hooking the high-precision timer interface, it is necessary to verify the integrity of the timer interface before recording the timestamp. For example, calculate the CRC value of the interface function and compare it with the preset value. If the CRC value does not match, it is determined to be a debugger.

[0017] Furthermore, during the operation of the software to be protected, the MAC address of the device is periodically obtained, and the legitimacy of the device is verified based on the MAC address, including: The device's MAC address is periodically obtained and sent to the server via an encrypted channel; The server verifies the MAC address based on a preset whitelist; If the verification is successful, the server returns the authorization license for the software to be protected and binds the software to the MAC address. If the verification fails, the functionality of the software to be protected will be restricted or the software to be protected will be terminated.

[0018] As described above, verifying the device's MAC address effectively prevents software from running on unauthorized devices.

[0019] Furthermore, it also includes: The system monitors network status in real time. If the network connection is interrupted, the current MAC address is sent to the server for verification after the network is successfully reconnected. If the server detects a change in the MAC address of the device, it updates the corresponding binding record.

[0020] As can be seen from the above description, the validity of the bound records can be guaranteed, ensuring the continued normal use of the software.

[0021] Furthermore, the preset self-destruct triggering conditions include at least one of the following: detecting preset abnormal behavior, receiving a self-destruct command sent by the server, and detecting that the device hardware has been physically disassembled or damaged. The abnormal behaviors include exceeding a preset threshold for the number of incorrect password inputs, the software process being illegally injected with external code, and the target IP address of the device's network connection being on a preset blacklist; among them, the determination of whether the software process has been injected with external code is made by monitoring abnormal read and write operations in the memory area and the integrity of the executable code of the software to be protected; The self-destruct operation includes erasing the data stored in the software to be protected, destroying the virtual machine execution environment, and clearing the relevant identification information of the device and the software to be protected. The relevant identification information of the device and the software to be protected includes the binding record of the MAC address of the software and the device and the installation identifier of the software to be protected on the device.

[0022] As described above, by monitoring the software's operating status and device environment in real time, a self-destruct operation is performed when the self-destruct conditions are met, ensuring that keys, data, VM environments, etc. are completely destroyed, thus guaranteeing the security of software and data.

[0023] Furthermore, before encrypting the data to be protected using the key to obtain encrypted data, the process further includes: Obfuscate and transform the executable code of the software to be protected.

[0024] As described above, by deeply obfuscating and transforming the software code, the originally clear code logic is broken into multiple fragments, the order is randomly shuffled, and a large amount of redundant code and fake branches are inserted. At the same time, variable names and function names are encrypted or randomized, making it difficult for reverse engineers to understand the true intent of the code when analyzing it, thus interfering with reverse analysis.

[0025] Further, the step of encrypting the data to be protected using the key to obtain encrypted data includes: The data to be protected is divided according to the preset data block size, and each of the divided data blocks is encrypted using the key and different initialization vectors.

[0026] As described above, by segmenting the data and encrypting it with different IVs (Initialization Vectors) and encryption keys, the difficulty of cracking is increased.

[0027] Furthermore, it also includes: During the process of loading the encrypted data into the virtual memory space, the device performs a heartbeat verification. If the heartbeat verification fails, the loading operation is terminated.

[0028] As described above, by verifying the VM client, it is ensured that the VM execution environment has not been tampered with.

[0029] The present invention also proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0030] Example 1 Please refer to Figure 2 The first embodiment of the present invention is a software protection method based on VM encryption mode, which can be applied to financial industry applications (trading terminals), mobile office applications, etc.

[0031] VM encryption mode, or virtual machine encryption mode, constructs a virtual execution space within the software runtime environment, loading software code and data into this space for execution. In this virtual space, the instruction set, memory management, registers, etc., are all built and managed by the virtual machine, isolated from the real hardware environment. This makes it difficult for reverse engineering tools to directly obtain the software's actual code logic, as they are dealing with complex instruction flows and memory layouts after virtualization. For example, traditional disassemblers, when analyzing VM-encrypted software, obtain chaotic and disordered instruction sequences, unable to reconstruct the original code structure, greatly increasing the difficulty of cracking.

[0032] This method is based on a software protection architecture, which includes a VM management module, an encryption core module, an anti-debugging monitoring module, a remote binding module, and a self-destruct control module.

[0033] The VM management module is used to build, maintain, and manage the VM execution environment, including functions such as virtual processor instruction scheduling, virtual memory allocation and reclamation, and virtual device simulation. It monitors the VM environment's running status in real time to ensure the software runs in a secure and stable environment. For example, when abnormal virtual memory access is detected, it promptly isolates or terminates the relevant processes to prevent malicious attacks.

[0034] The encryption core module is used to implement data encryption in memory. When the program loads, the data in memory needs to be encrypted, and it is decrypted when needed. After use, the decrypted data is destroyed, thus ensuring that all data in memory is in encrypted form.

[0035] The anti-debugging monitoring module continuously monitors debugging behavior during software operation. It employs various anti-debugging techniques (such as process status monitoring, time-based detection, heartbeat packets, code obfuscation, and polymorphism) to immediately take countermeasures upon detecting debugging behavior, protecting the software code from reverse engineering. Simultaneously, it records anti-debugging events and uploads them to a remote server for security analysis.

[0036] The remote binding module is responsible for communicating with the remote server to obtain, upload, verify, and manage user MAC addresses and binding relationships. It periodically synchronizes MAC address information with the server to ensure binding validity. Upon receiving a self-destruct command or other security instructions from the server, it promptly notifies the software to perform the appropriate action.

[0037] The self-destruct control module monitors the software's running status and device environment in real time based on predefined self-destruct trigger conditions. When these conditions are met, it coordinates various modules to execute self-destruct operations, ensuring the complete destruction of keys, data, and the VM environment, thus guaranteeing software and data security. Simultaneously, the self-destruct log records each step of the self-destruct process in real time (including timestamps and operation details, such as "202X-XX-XX 10:00 Key overwrite completed 3 times") and uploads it to a remote server via an encrypted channel for post-incident security auditing.

[0038] The aforementioned modules collaborate closely, interacting through message passing and function calls. The encryption core module provides encrypted data to the VM management module, which is responsible for running the software in a secure VM environment and feeding back its running status to the anti-debugging monitoring module and the self-destruct control module. Upon detecting abnormal debugging behavior, the anti-debugging monitoring module immediately triggers its anti-debugging mechanism, executing anti-debugging operations such as terminating the process or jumping to an invalid code region. The remote binding module communicates with the remote server to obtain authorization information and instructions, and transmits the results to other modules. For example, upon receiving a self-destruct instruction, it notifies the self-destruct control module to initiate self-destruction. During self-destruction, the self-destruct control module coordinates with the encryption core module to destroy the key and with the VM management module to destroy the VM environment, ensuring the orderly execution of the entire self-destruction process.

[0039] like Figure 2 As shown, this method includes the following steps: S1: Obtain the key.

[0040] When the software starts, it obtains the key through the encryption card (key).

[0041] S2: Encrypt the data to be protected using the key to obtain encrypted data, wherein the data to be protected includes the executable code, configuration files and resource files of the software to be protected.

[0042] Specifically, all data requiring protection, including the software's executable code, configuration files, and resource files, is divided into blocks of specific sizes. For example, a 1MB executable file is divided into several 1KB blocks, each encrypted using a key and a different Initialization Vector (IV) to increase the difficulty of cracking. The encrypted data is then stored in a custom field within the VM shell's PE (Portable Executable Format, found in EXE and DLL files).

[0043] Furthermore, during the VM encryption process, the software code undergoes deep obfuscation and transformation. The originally clear code logic is broken down into multiple fragments, randomly shuffled, and a large amount of redundant code and spurious branches are inserted. Simultaneously, variable names and function names are encrypted or randomized, making it difficult for reverse engineers to understand the true intent of the code during analysis. For example, a simple addition function can be transformed through code obfuscation techniques into a code block containing multiple complex mathematical operations and conditional judgments, which have no practical meaning in the normal execution path and are purely used to interfere with reverse analysis.

[0044] S3: Build a virtual machine execution environment in the device's memory.

[0045] Specifically, a VM execution environment is built in the device memory, including the initialization of components such as virtual processors, virtual memory space, and virtual registers.

[0046] S4: Load the encrypted data into the virtual memory space and configure the virtual processor so that the virtual processor can recognize and execute virtual machine encryption instructions.

[0047] Specifically, the encrypted code and data are loaded into the virtual memory space, and the virtual processor is configured to recognize and execute instruction sets encrypted by the VM, thus giving the virtual processor in the VM environment the exclusive ability to "recognize, parse, and execute VM encrypted instructions".

[0048] Furthermore, during the code loading process, a heartbeat verification is performed on the VM client to ensure that the VM environment has not been tampered with during data execution. For example, if a data packet delay exceeds a threshold (e.g., 5 seconds) while calculating encrypted data, the loading process is terminated, and a command to the server regarding the data packet reception delay is sent.

[0049] S5: After the protection software starts, it performs anti-debugging monitoring. If debugging behavior is detected, the anti-debugging mechanism is triggered and anti-debugging operations are performed.

[0050] Specifically, during the initial startup phase, the software continuously monitors its own process status. In this embodiment, it reads process status information provided by the system kernel, such as / proc / [pid] / status (Linux system) or obtains process-related information through the Windows API, and checks the TracerPid field (debugger process ID). If the value of the TracerPid field is not 0, it indicates that the current process is being tracked by the debugger, and the software will immediately trigger anti-debugging mechanisms to perform anti-debugging operations, such as terminating the process or jumping to invalid code regions, making the debugger unable to function properly.

[0051] The TracerPid field is one of the process status information maintained by the Linux system kernel. Its core function is to identify whether the current process is being tracked by other processes (usually debuggers). It is a key detection indicator for software anti-debugging. The TracerPid field exists in the Linux system's process status file, located at / proc / [pid] / status.

[0052] Furthermore, when the software is running normally, the code execution time is within a reasonable range. However, if the software is being debugged, the intervention of the debugger will increase the overhead of instruction execution, resulting in a significant increase in code execution time. Therefore, in this embodiment, a high-precision timer is used to record the timestamps before and after the execution of critical code. When the execution time exceeds a preset threshold, it is determined that the software is in a debugging state, and anti-debugging operations are initiated, such as modifying the code execution flow to prevent the debugger from accurately setting breakpoints.

[0053] Specifically, the first step is to select a high-precision timer to ensure accurate time measurement. In practical applications, the underlying timer interface needs to be selected based on the operating system. For example, for Linux, clock_gettime(CLOCK_MONOTONIC, ×pec) is used for nanosecond (ns) timekeeping. Selecting the CLOCK_MONOTONIC clock (which monotonically increases from system startup and is unaffected by system time rollback) avoids timestamp backtracking due to time synchronization issues and ensures accurate difference calculation.

[0054] Step 2: Implement event tracking before and after critical code segments in the software. Event tracking involves inserting timestamps before and after the execution of core, sensitive code segments. In this embodiment, event tracking is implemented on the following code segments to ensure coverage of core security logic.

[0055] 1. Core operations of the VM environment: The VM environment is the foundation of encrypted software. If the debugger wants to crack the VM instruction set, it will inevitably set a breakpoint here, which will prolong the execution time.

[0056] Specific tracking points include the "function entry point" and "after initialization" of virtual processor initialization functions (such as VM_Init()), and the "loading start" and "before returning after successful loading" of VM encrypted code loading functions (such as VM_LoadEncryptedCode()).

[0057] 2. Encryption / Decryption Core Logic: The encryption logic is the core target of cracking. Debugger breakpoints will significantly increase the encryption and decryption time (e.g., normal decryption takes 1ms, but during debugging it may take more than 100ms).

[0058] Specific embedding locations include "after parameters are passed in" and "before key output" of key generation functions (such as Key_GenerateFromHardware()), and "after ciphertext input" and "before plaintext return" of sensitive data decryption functions (such as Data_Decrypt()).

[0059] 3. Remote authorization verification: Illegal debugging often attempts to bypass authorization, and breakpoints can cause abnormal execution times of network interactions or verification logic.

[0060] Specific data entry points include the MAC address upload function (such as MAC_UploadToServer()) before the network request is sent and after the server response is received, as well as the authorization result verification function (such as Auth_VerifyResult()) before verification starts and before verification result determination.

[0061] Step 3: Record and store timestamps to ensure that the data is not tampered with.

[0062] The timestamp recording must meet the requirements of real-time performance and tamper-proofing to prevent debuggers from bypassing detection by modifying the timestamp data. The specific implementation details are as follows: 1. Storage medium selection: Start_time and end_time are stored as local variables within the function, rather than global variables or memory heap (such as space allocated by malloc). This is because local variables are stored in the stack area, and their lifecycle is synchronized with the execution of critical code segments. If the debugger wants to modify the data in the stack area, it needs to accurately locate the stack address, which is much more difficult than modifying global variables.

[0063] 2. Timing control: Timestamp recording code should be placed immediately after critical code segments to avoid inserting irrelevant logic (such as log printing or memory cleanup). For example, record start_time (start timestamp) one line before the VM_Init() function call and end_time (end timestamp) immediately one line after the call to prevent irrelevant operations from taking up time and causing deviations in the difference calculation.

[0064] 3. Original data retention: The original counter value returned by the timer (such as a value of type LARGE_INTEGER) is stored directly, instead of being converted to milliseconds / microseconds in advance. This is because the original value has higher precision, and the conversion process may introduce floating-point errors, so the unit conversion needs to be unified during the difference calculation stage.

[0065] Step 4: Calculate the time difference to quantify the degree of delay.

[0066] Specifically, after the critical code is executed, the end timestamp is subtracted from the start timestamp to calculate the actual execution duration. In practical applications, unit conversion needs to be handled in conjunction with the timer type to ensure accurate results. For example, the tructtimespec structure contains seconds (tv_sec) and nanoseconds (tv_nsec), so the units need to be unified (e.g., nanoseconds) before calculating the difference, and finally converted to microseconds or milliseconds.

[0067] Step 5: Threshold determination and anti-debugging trigger, related to document security logic.

[0068] Specifically, if the execution time of critical code exceeds a preset time threshold, the software is determined to be in a debugging state, and anti-debugging operations are performed.

[0069] The preset time threshold is 1.5-3 times the normal execution time to avoid misjudgment due to differences in hardware performance (such as slower execution on low-end CPUs). For example, through extensive testing (executing critical code on target devices with different configurations), the maximum normal execution time is calculated to be T_max (e.g., normal VM initialization takes 500μs), then the time threshold is set to 3*T_max=1500μs.

[0070] Furthermore, the time threshold is stored in a custom field of the VM shell's PE, preventing the debugger from directly modifying the threshold data in memory.

[0071] In this embodiment, the anti-debugging operation includes: a. Jump to invalid code region: By forcibly modifying the program counter (Linux's RIP register), the code jumps to a random invalid address, causing debugger breakpoints to fail.

[0072] b. Terminate process: Call the system interface (Linux's exit()) to directly terminate the current software process, blocking the debugger from continuing analysis.

[0073] c. Record anomaly logs: Time-detected anomaly events (including timestamps, process IDs, and execution durations) are uploaded to a remote server via an encrypted channel (the communication logic with the remote binding module is reused) for administrators to trace attack behavior.

[0074] Furthermore, since debuggers may return false timestamps by hooking high-precision timer interfaces (such as QueryPerformanceCounter), it is necessary to verify the integrity of the timer interface before recording the timestamp. For example, calculate the CRC value of the interface function and compare it with the preset value. If the CRC value does not match, it is determined to be a debugger, thereby preventing the timer from being hooked and avoiding the detection logic from being bypassed.

[0075] Furthermore, if critical code is executed in multiple threads, the timestamp recording logic should be bound to the critical code in the same thread (using pthread_self() (Linux) to avoid time discrepancies caused by thread switching).

[0076] S6: During software operation, periodically obtain the device's MAC address and verify the device's legitimacy based on the MAC address. If the verification fails, restrict the functionality of the protected software or terminate its operation.

[0077] Specifically, upon initial runtime, the software obtains the device's MAC address through system network interface functions. In Windows systems, the GetAdaptersInfo function from the IPHelper API can be used to retrieve network adapter information and extract the MAC address. In Linux systems, the MAC address of the corresponding network interface is obtained by reading the / sys / class / net / [interface_name] / address file. This obtained MAC address is used as the device's unique identifier for subsequent binding operations.

[0078] The obtained MAC address is then sent to the remote server via an encrypted channel (such as TLS encryption protocol). The server pre-stores a list of legitimate user device MAC addresses (i.e., a whitelist). Upon receiving a MAC address, it compares it with the whitelist. If the received MAC address is in the legitimate list, the server returns an authorization, and the software can run normally. At the same time, the server generates a binding record between the software and that MAC address. If the MAC address does not match, the functionality is restricted or the software is terminated directly, effectively preventing the software from running on unauthorized devices.

[0079] Considering that users may change their network devices or network environment, leading to changes in MAC addresses, this embodiment includes a dynamic binding and update mechanism. Specifically, the software periodically (e.g., weekly) reacquires the device's MAC address and synchronizes it with the server. If a MAC address change is detected, and the changed MAC address is still in the valid list, the server updates the binding record to ensure the software continues to function normally. Simultaneously, the software monitors the network status in real time during operation. Once a network connection is interrupted and reconnected, a MAC address re-verification process is immediately triggered to ensure the validity of the binding.

[0080] S7: When the preset self-destruct trigger conditions are met, the self-destruct mechanism is triggered and the self-destruct operation is performed.

[0081] In this embodiment, the self-destruct triggering conditions include: 1. Abnormal behavior detected The software continuously monitors its own operating status and device environment. When the following abnormal behaviors are detected, a self-destruct mechanism is triggered: (1) Entering the wrong password multiple times. For example, specify a threshold of 5 consecutive incorrect attempts; exceeding this threshold will be considered an illegal cracking attempt.

[0082] (2) The software process has been illegally injected with external code. In this embodiment, this is determined by monitoring abnormal read and write operations in the memory region and the integrity of the code segment.

[0083] The detection of abnormal memory read / write operations relies on a combination of access control, behavior monitoring, and legality verification to identify memory access behaviors that exceed the normal operating range of the software. This core capability depends on the VM environment's dedicated management capabilities for virtual memory. 1) Capturing unauthorized access based on memory permissions: When building a VM environment, strict access permissions are set for virtual memory according to functional partitions (such as code segment, data segment, and key storage segment). The code segment (which stores VM encryption instructions) is set to read-only permission by default (configured through the Windows VirtualProtect / Linux mprotect system interface), prohibiting write operations; sensitive data segments (such as decrypted temporary keys and user data) are set to be readable and writable only by the software's own threads, restricting access by external processes / illegal threads.

[0084] When a write request to a read-only code segment or a read / write request to a sensitive data segment by an external process (such as a debugger or injection tool) is detected, an alarm is triggered through the system exception capture mechanism (Windows SEH structured exception handling, Linux SIGSEGV semaphore) to determine that it is an abnormal read / write.

[0085] 2) Real-time access logs and validity checks for critical memory regions Deploy memory access hooks (based on the VM's own memory management module, not system-level hooks, to prevent them from being cracked) for core memory areas within the VM environment (such as virtual registers and encrypted data loading areas): Record the three key elements of each memory access: access subject (process ID / thread ID, which must match the software's own valid ID), access type (read / write), and access address range. A pre-defined legal access rule base is established (such as "only thread A can read and write the key storage area" and "the data segment read and write address must be in the range of 0x12340000-0x1234FFFF"). If the access behavior exceeds the range of the rule base (such as unknown thread reading and writing the key area, address out of bounds), it is directly judged as abnormal.

[0086] 3) Identification of anomalies in memory access frequency and patterns During normal software operation, memory read and write operations follow a fixed pattern (e.g., the data segment read and write frequency is stable, and the code segment is only read once during VM initialization): If high-frequency random read / write (such as more than 100 writes to the same memory address in a short period of time) or cross-regional abnormal access (such as writing data directly from the data segment to the code segment) is detected, combined with the abnormal behavior detection logic, it is determined to be an abnormal read / write caused by illegal injection (the injected code needs to modify the memory structure through abnormal writing).

[0087] The core of determining incomplete code segments is to ensure that the encrypted code loaded by the VM has not been tampered with or is missing through a combination of preset checksum comparison, block verification, and structure detection. This relies on the technical design of encrypted code storage and data block segmentation. 1) Real-time comparison of preset integrity check values During the code encryption phase, a global checksum value (such as SHA-256 hash value, CRC32 checksum value) is generated synchronously and encrypted and stored in a trusted area of ​​the VM shell (such as an encrypted sub-segment of a custom field in the PE, or a remote server).

[0088] After the VM environment loads the code segment, it immediately recalculates the checksum of the current code segment. The real-time calculated value is compared with the preset checksum. If they are inconsistent (e.g., checksums do not match, or a complete checksum cannot be calculated), it indicates that the code segment has been tampered with (e.g., external code is injected to overwrite the original code) or is missing (e.g., some code blocks are not loaded), and is therefore determined to be incomplete.

[0089] 2) Code segment block verification and heartbeat packet linkage verification The code segment is also divided into blocks of fixed size (e.g., 1KB / 4KB), and each block generates an independent checksum and stores it. In addition to the full checksum during loading, the software will combine the VM client heartbeat packet checksum during operation to periodically (e.g., every 30 seconds) re-check each block of the code segment; if the checksum of a certain block fails to be checked (e.g., checksum mismatch, block length abnormal), it means that the block has been tampered with or lost, and the code segment is directly determined to be incomplete.

[0090] 3) Code segment structure and instruction validity check The code segment encrypted by the VM has a fixed structure (such as a unified format of instruction header identifier + opcode + parameters).

[0091] The code segment boundary integrity is checked. The code segment is checked for the presence of a preset VM instruction header (such as 0xVM12) at the beginning and an end marker (such as 0xVMFF) at the end. If any of these are missing, the structure is determined to be incomplete.

[0092] The legality of instructions is checked. Before the virtual processor executes the code, it first verifies the encoding length and opcode range of each instruction (which must conform to the VM instruction set rules). If an illegal opcode or abnormal instruction length is found (e.g., a normal instruction is 4 bytes long, but only 2 bytes are detected), it means that the code segment has been tampered with, resulting in incomplete instructions, and is therefore judged as incomplete.

[0093] (3) The device network is connected to a blacklisted IP address. The software periodically compares the target IP address of the current network connection with the pre-set blacklist. If the target IP address belongs to the preset blacklist, the self-destruct mechanism is triggered.

[0094] 2. Remote command triggering The remote server can send a self-destruct command to the software based on security policies or administrator instructions. For example, when the company owning the software discovers that a device is missing or poses a significant security risk, the administrator can send a self-destruct command to the software running on that device through the server backend. Upon receiving the command, the software will immediately initiate the self-destruct process.

[0095] 3. Hardware malfunction The device monitors the hardware status. If it detects that the hardware device has been physically disassembled (by monitoring the status of hardware sensors, such as some devices with anti-tamper sensors, which are triggered when the sensor status changes) or that the storage medium is damaged (by dual determination through changes in the status of the device's anti-tamper sensors and abnormal SMART information of the storage device, such as when the anti-tamper sensor is triggered or SMART indicates that the disk is damaged), it will trigger the self-destruct function to prevent data from being damaged by hardware or illegally obtained.

[0096] The SMART (Storage Device Self-Monitoring, Analysis and Reporting Technology) information is generated by the storage device, uploaded to the system, and stored in a designated data area. The software needs to request the storage device's SMART information data from the system through tools provided by the system (such as the WMIC command in Windows or the smartctl tool in Linux) or API. If the requested data shows "abnormal disk damage-related indicators (such as excessive bad sectors)," then, combined with the tamper sensor status data, it is determined that the storage medium is damaged.

[0097] In this embodiment, the self-destruct operation includes: a. Data Erasure: Thoroughly erase the data stored in the software. Disk data is overwritten three times in the order of "0→1→random value"; memory data is forcibly zeroed using kernel-level functions such as the RtlZeroMemory function in Windows and the memset function in Linux.

[0098] b. VM Environment Destruction: The VM environment running the software is damaged, terminating the virtual processor, releasing and zeroing the virtual memory space, making it impossible for the software to resume operation in that environment. Simultaneously, the VM core parameter files are deleted, specifically including the virtual register configuration table and the VM instruction set mapping file, to prevent the VM environment from being restored through configuration.

[0099] c. Device Identifier Removal: Removes device and software-related identification information, such as remotely bound MAC address records and software installation identifiers on the device. Added feature: Removes local software license certificates and records linking device hardware fingerprints to the software. This prevents attackers from using this identification information to trace the software's origin or restore its functionality.

[0100] Steps S5-S7 can be executed simultaneously during software operation.

[0101] This embodiment, based on VM encryption mode, integrates anti-debugging and remote user MAC binding technologies with a software encryption and instant self-destruct implementation scheme, providing a comprehensive and multi-layered solution for software security protection. By constructing a secure VM execution environment, implementing effective anti-debugging measures, and precise remote binding control, combined with a powerful instant self-destruct function, it can effectively resist various security threats and protect the security of software code and data. It demonstrates significant advantages in multiple scenarios such as finance, core enterprise business, and mobile office, and has broad application prospects. In the future, with the continuous development of technology, this solution can further optimize encryption algorithms, improve the intelligence level of anti-debugging technology, and strengthen integration with emerging technologies (such as blockchain and artificial intelligence), continuously improving software security protection capabilities and adapting to the increasingly complex network security environment.

[0102] Example 2 This embodiment is a computer-readable storage medium corresponding to the above embodiments, on which a computer program is stored. When the program is executed by a processor, it implements the various steps of the software protection method based on virtual machine encryption mode as described in the above embodiments, and can achieve the same technical effect, which will not be repeated here.

[0103] In summary, the software protection method and storage medium based on virtual machine encryption mode provided by this invention can effectively resist various security threats and protect the security of software code and data by constructing a secure VM execution environment, implementing effective anti-debugging measures and precise remote binding control, combined with a powerful instant self-destruct function, thus providing a comprehensive and multi-layered solution for software security protection.

[0104] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A software protection method based on virtual machine encryption mode, characterized in that, include: Obtain a key and encrypt the data to be protected using the key to obtain encrypted data. The data to be protected includes the executable code, configuration files, and resource files of the software to be protected. A virtual machine execution environment is constructed in the device memory, the virtual machine execution environment including a virtual processor, a virtual memory space, and virtual registers; The encrypted data is loaded into the virtual memory space, and the virtual processor is configured. After the protection software starts, it performs anti-debugging monitoring. If debugging behavior is detected, the anti-debugging mechanism is triggered and anti-debugging operations are performed. During the operation of the protected software, the MAC address of the device is obtained periodically, and the legitimacy of the device is verified based on the MAC address. When the preset self-destruct trigger conditions are met, the self-destruct mechanism is triggered and the self-destruct operation is performed.

2. The software protection method according to claim 1, characterized in that, After the software to be protected is started, anti-debugging monitoring is performed. If debugging behavior is detected, the anti-debugging mechanism is triggered, and anti-debugging operations are performed, including: After the protection software starts, it acquires process status information, including the debugger process ID. If the debugger process ID is not 0, it is determined that the anti-debugging mechanism needs to be triggered and the anti-debugging operation is performed. A high-precision timer is used to record timestamps before and after the execution of preset critical code, thereby obtaining the start and end timestamps of the critical code, and the execution time of the critical code is calculated based on the start and end timestamps. If the execution time exceeds a preset time threshold, the software to be protected is determined to be in a debugging state, and an anti-debugging operation is performed. The anti-debugging operations include terminating the process, jumping to an invalid code region, and logging exceptions.

3. The software protection method according to claim 2, characterized in that, The key code includes core operation functions for the virtual machine environment, core encryption and decryption functions, and authorization verification functions. The core operation functions for the virtual machine environment include a virtual processor initialization function and a virtual machine encrypted code loading function. The core encryption and decryption functions include a key generation function and a sensitive data decryption function. The authorization verification functions include a MAC address upload function and an authorization result verification function.

4. The software protection method according to claim 2, characterized in that, Before obtaining the start and end timestamps of the key code by recording timestamps before and after the execution of the preset key code using a high-precision timer, the method further includes: Verify the integrity of the high-precision timer interface.

5. The software protection method according to claim 1, characterized in that, During the operation of the software to be protected, the MAC address of the device is periodically obtained, and the legitimacy of the device is verified based on the MAC address, including: The device's MAC address is periodically obtained and sent to the server via an encrypted channel; The server verifies the MAC address based on a preset whitelist; If the verification is successful, the server returns the authorization license for the software to be protected and binds the software to the MAC address. If the verification fails, the functionality of the software to be protected will be restricted or the software to be protected will be terminated.

6. The software protection method according to claim 5, characterized in that, Also includes: The system monitors network status in real time. If the network connection is interrupted, the current MAC address is sent to the server for verification after the network is successfully reconnected. If the server detects a change in the MAC address of the device, it updates the corresponding binding record.

7. The software protection method according to claim 1, characterized in that, The preset self-destruct triggering conditions include at least one of the following: detecting preset abnormal behavior, receiving a self-destruct command sent by the server, and detecting that the device hardware has been physically disassembled or damaged. The abnormal behaviors include exceeding a preset threshold for the number of incorrect password inputs, the software process being illegally injected with external code, and the target IP address of the device's network connection being on a preset blacklist; among them, the determination of whether the software process has been injected with external code is made by monitoring abnormal read and write operations in the memory area and the integrity of the executable code of the software to be protected; The self-destruct operation includes erasing the data stored in the software to be protected, destroying the virtual machine execution environment, and clearing the relevant identification information of the device and the software to be protected.

8. The software protection method according to claim 1, characterized in that, Before encrypting the data to be protected using the key to obtain the encrypted data, the process further includes: Obfuscate and transform the executable code of the software to be protected.

9. The software protection method according to claim 1, characterized in that, Also includes: During the process of loading the encrypted data into the virtual memory space, the device performs a heartbeat verification. If the heartbeat verification fails, the loading operation is terminated.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-9.

Images