A method for reverse engineering of anti-soft encryption software

Abstract

This invention discloses a method for reverse engineering anti-software encryption software, relating to the field of anti-software encryption technology. The method includes: constructing a two-layer payload and anti-software encryption encapsulation for a non-complete release version; generating a serial number binding table through a bootstrap program and an encryption function payload index; upon first use of the software, generating a unique code from the client hardware through the bootstrap program, and generating a device-bound activation proof request package along with the serial number binding relationship; the server verifies the activation proof request package, checking the consistency between the unique code and the serial number, and the validity of remote proof materials, generating a payload decapsulation instruction package valid only for the current session, and sending it back to the client. This invention triggers a revocation list and revocation instruction when the evidence package points to a copied installation or abnormal execution trajectory, and cleans up the local authorization code and related installation files, achieving abnormal revocation and traceability, enhancing the suppression effect on reverse engineering of shared software and cross-machine theft.

Description

Technical Field

[0001] This invention relates to the field of anti-software encryption technology, and in particular to a method for reverse engineering anti-software encryption software. Background Technology

[0002] With the development of software distribution and network service, anti-software encryption and software protection have gradually shifted from single static hardening to a chain-based solution of "release-registration-network verification-authorization execution". Common practices include packing, registration codes, network verification and local storage of authorization codes, and are supplemented by anti-reverse engineering methods such as obfuscation encoding and debugger detection to provide a certain degree of protection and access control for critical code and critical data during the runtime phase.

[0003] Existing link-based solutions are still prone to issues when combating shared installations and reverse engineering, such as reusable authorization elements, weak binding between authorization status and device status, and difficulty in fine-grained constraints on session-level authorization. For example, once the authorization code is stored on the client machine, it may be copied and migrated; if network verification lacks stable constraints from device-side hardware identifiers, cross-device reuse is difficult to effectively identify; if the full functional payload or critical code is exposed for too long during operation, reverse engineers can still obtain a relatively complete execution view in the debugging window, thereby reducing the ease with which the security strength of software cracking can be improved. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a method for reverse engineering anti-software encryption software to solve the problem that it is difficult to improve the security strength of software encryption software in scenarios of shared installation and reverse analysis.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] This invention provides a method for reverse engineering anti-software encryption software, comprising:

[0008] Construct a two-layer payload and anti-soft encryption encapsulation for an incomplete release version, and generate a serial number binding table by indexing the boot shell program and the encryption function payload;

[0009] When the software is used for the first time, a unique code is generated from the client hardware by starting the shell program, and an activation certificate request package for device binding is generated together with the serial number binding relationship.

[0010] The server verifies the activation certificate request packet, checks the consistency between the unique code and the serial number, and verifies the validity of the remote proof materials. It then generates a payload decapsulation instruction packet that is only valid for the current session and sends it back to the client.

[0011] Based on the authorization information of the decapsulation instruction packet, the client decrypts, loads, and executes the segmented payloads in the encrypted payload packet, generating a loaded execution-state payload instance and session authorization information;

[0012] During operation, the client implements delayed decryption and short-term resident loading protection for critical functions based on the loaded execution-state payload instance and session authorization records, and triggers copy installation identification and authorization revocation processing.

[0013] As a preferred embodiment of the anti-software encryption software reverse engineering method described in this invention, the specific steps for constructing the dual-layer payload and anti-software encryption encapsulation of the incomplete release version are as follows:

[0014] The functional payload is split into functional segments based on code logic and resource dependencies, and segment identifiers are assigned accordingly.

[0015] Each functional segment is individually encrypted and then combined to form an encrypted payload packet;

[0016] Generate index entries for each encryption function segment and summarize them to form an encryption function payload index;

[0017] A boot shell program containing program loading logic, registration interface logic, and upgrade detection logic is constructed, and the encryption function payload index is written into the boot shell program to form a two-layer payload structure.

[0018] In a preferred embodiment of the anti-software encryption software reverse engineering method described in this invention, the specific steps for generating the serial number binding table are as follows:

[0019] The launcher receives user information and sends a registration request to the server.

[0020] After the server verifies the user information and confirms payment, it generates a unique serial number.

[0021] Extract all segment identifiers from the cryptographic payload index and bind them to unique serial numbers to generate a serial number binding table.

[0022] As a preferred embodiment of the anti-software encryption software reverse engineering method of the present invention, the specific steps for generating a unique code from the client hardware by starting a shell program are as follows:

[0023] The boot shell program calls the operating environment interface to read the CPU serial number, motherboard serial number, and hard disk serial number of the client hardware. After standardization processing, the serial numbers are concatenated in a predetermined order to generate the original hardware information string.

[0024] Apply the SHA-256 hash algorithm to the original hardware information string to generate a fixed-length unique code.

[0025] As a preferred embodiment of the anti-soft encryption software reverse engineering method described in this invention, the specific steps for generating the payload decapsulation instruction packet, which is only valid for the current session, are as follows:

[0026] The server uses its private key to decrypt the activation certificate request packet, extracts the device binding identifier pair, remote proof materials, and timestamp, and checks the difference between the timestamp and the current time to confirm that the request is within the valid time window.

[0027] Parse the serial number and unique code from the device binding identifier pair to obtain the registered user information and authorized segment list corresponding to the serial number;

[0028] Retrieve the unique code historically bound to the serial number, verify whether the current unique code is consistent with the historical unique code, and generate a consistency verification result;

[0029] Verify the digital signature of the remote proof material, check whether the metric value matches the trusted execution environment benchmark value, and generate the remote proof validity verification result;

[0030] If both the consistency check result and the remote proof validity check result pass the verification, a random session key is generated; otherwise, the request is rejected.

[0031] The authorized segment list is encrypted and decrypted using the session key to form a payload decapsulation instruction packet.

[0032] As a preferred embodiment of the anti-software encryption software reverse engineering method of the present invention, the specific steps for generating the loaded execution-state payload instance and session authorization information are as follows:

[0033] After receiving the decapsulation instruction packet, the client uses the locally stored session key to decrypt the instruction packet and obtain the decryption authorization list;

[0034] Based on the segment identifier and temporary decryption token in the decryption authorization list, locate the corresponding encrypted function segment from the encrypted payload packet, use the temporary decryption token to decrypt each encrypted function segment, and restore the original function segment code;

[0035] The decrypted functional code segments are loaded into the protected area of ​​memory and arranged in the order of loading in the decryption authorization list to form a continuous executable memory image.

[0036] The client jumps to the entry address of the memory image, executes the functional segment code, generates the loaded execution-state payload instance, and records the session authorization information.

[0037] As a preferred embodiment of the anti-software encryption software reverse engineering method of the present invention, the key functions include the core algorithm logic of the software, license verification routine, data encryption and decryption logic, and user identity authentication interface.

[0038] As a preferred embodiment of the anti-software encryption software reverse engineering method of the present invention, the delayed decryption specifically includes the following steps.

[0039] During runtime, the client monitors calls to critical functions and retrieves the authorization status of these functions from the session authorization information.

[0040] If the critical function has been authorized but not decrypted, the client uses the decryption parameter seed in the session authorization information to generate a temporary decryption key;

[0041] If the critical functions have been authorized and decrypted, then the decrypted critical function code will be executed directly.

[0042] If critical functions are not authorized, execution will terminate and an error message will be returned;

[0043] A temporary execution buffer is allocated for critical functions. A temporary decryption key is used to decrypt the encrypted function segments corresponding to the critical functions from the encrypted payload packet to generate the decrypted critical code.

[0044] The decrypted critical code is loaded into a temporary execution buffer in memory, and the buffer is set to read-only permission. The critical code is executed, and the code data in the temporary execution buffer is cleared immediately after the critical code is executed, generating execution trace clearing results.

[0045] As a preferred embodiment of the anti-software encryption software reverse engineering method of the present invention, the operation steps of the short-term resident load protection are as follows:

[0046] The client allocates a dedicated protected memory region for critical functions and sets the access permissions of the protected memory region to read-only and execute.

[0047] Based on the already loaded execution-state payload instance, once the critical functions are loaded into the protected memory area via delayed decryption, the client locks the protected memory area to prevent external access.

[0048] The client monitors the execution process of key functional code and records the code execution trajectory;

[0049] After the critical function code is executed, the code data in the protected memory area is immediately overwritten, a random byte sequence is filled in, the lock on the protected memory area is released based on the execution trace cleanup result, the session authorization information is updated, and a runtime evidence package is generated.

[0050] As a preferred embodiment of the anti-software encryption software reverse engineering method of the present invention, the specific steps for triggering copy installation identification and authorization revocation are as follows:

[0051] The server receives the execution evidence packet and parses the session authorization information and code execution trace in the execution evidence packet;

[0052] Verify the consistency between the serial number and the device binding relationship based on the session authorization information, and check whether the code execution trajectory is abnormal;

[0053] When the server detects a change in the key and device binding relationship caused by installation on another machine, it refuses to continue issuing decapsulation instructions, adds the corresponding serial number to the revocation list, and sends a revocation instruction to the client.

[0054] The client deletes the local license key and related installation files according to the revocation command, and cleans up the cached encrypted payload index.

[0055] The beneficial effects of this invention are as follows: By delivering a non-complete release version with a dual-layer payload and encrypted data encapsulation, only the boot shell program and the encrypted functional payload index are delivered, and registration payment and serial number binding are completed. This ensures that the complete functional payload does not appear in a recoverable plaintext form during the release stage, reducing static unpacking and offline reverse engineering exposure from the source. Upon first use, the boot shell program generates a unique code based on the client hardware and forms a device binding identifier pair with the unique serial number. Combined with remote proof materials, it forms an activation proof request package, making the authorization subject to the credibility constraints of the serial number, device status, and execution environment, increasing the difficulty of cross-machine reuse and debugging / tampering. During the execution stage, the server only generates a payload decapsulation instruction package valid for the current session and encapsulates the authorization segment list, making the decryption authorization one-time and time-sensitive. The client decrypts and loads in segments, and with delayed decryption and short-term resident loading, the plaintext dwell time is compressed, reducing the availability of memory dumps and dynamic tracking. When the running evidence package points to a copied installation or abnormal execution trajectory, the revocation list and revocation instruction are triggered, and the local authorization code and related installation files are cleaned up, achieving abnormal revocation and traceability, enhancing the suppression effect on reverse engineering and cross-machine theft of shared software. Attached Figure Description

[0056] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0057] Figure 1 This is a flowchart illustrating the method for reverse engineering anti-software encryption software.

[0058] Figure 2 A flowchart for constructing a two-layer load and generating a sequence number binding table.

[0059] Figure 3 A flowchart for server verification and generation of decapsulation instruction packets.

[0060] Figure 4 A flowchart for delayed decryption and short-term residency protection. Detailed Implementation

[0061] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0062] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0063] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0064] Reference Figures 1-4 As one embodiment of the present invention, this embodiment provides a method for reverse engineering anti-software encryption software, comprising the following steps:

[0065] S1. Construct a two-layer payload and anti-soft encryption encapsulation for an incomplete release version, and generate a serial number binding table by using the boot shell program and the encryption function payload index.

[0066] S1.1. Perform code logic parsing and resource dependency parsing on the functional payload, read the executable file format information of the functional payload and parse the function entry, function call relationship and basic block jump relationship, determine the start and end address range of each functional unit based on the function entry and basic block jump relationship, and form a functional unit boundary set; determine the start and end address ranges that are independent of each other and can be loaded and executed separately in the functional unit boundary set as the code logic boundary.

[0067] The import, export, relocation, and resource tables of the functional payload are read, and symbolic and resource reference relationships are resolved. Starting from the functional unit corresponding to the segment identifier, the symbolic and resource reference relationships are recursively expanded until no new referenced symbols or resources exist. The union of the set of referenced symbols and the set of referenced resources corresponding to the segment identifier is obtained and determined as the resource dependency closure. The functional payload is split into multiple functional segments according to the code logic boundary and the resource dependency closure. A segment identifier is written for each functional segment, and the segments are summarized to form a functional segment list.

[0068] Based on the functional segmentation list, generate a corresponding symmetric encryption key for each segment identifier, establish a one-to-one correspondence between the functional segmentation list, segment identifiers and symmetric encryption keys, and output a segment key mapping table.

[0069] Based on the segment key mapping table, symmetric encryption is performed on the functional segment corresponding to each segment identifier, and a set of encrypted functional segments is output. The set of encrypted functional segments is then combined and encapsulated to form an encrypted payload packet.

[0070] To further explain, the symmetric encryption process is performed as follows:

[0071] ;

[0072] in, This indicates the sequence number corresponding to the segment identifier; Indicates the first Each function segment plaintext (encrypted input plaintext), is derived from the function segment list and... The corresponding functional segments are obtained from the functional segment list. The corresponding functional segments are obtained; Indicates the first A symmetric encryption key, derived from a segmented key mapping table and... The corresponding symmetric encryption key is obtained; This represents a symmetric encryption operation; Indicates the first Each encryption function segments the ciphertext.

[0073] S1.2. Based on the encapsulation order of the encryption function segment set in the encryption payload packet, generate an index entry for each encryption function segment corresponding to each segment identifier. The index entry records the segment identifier, starting offset, length and encryption algorithm identifier, and summarizes all index entries to form an encryption function payload index.

[0074] Construct a bootstrap shell program that includes program loading logic, registration interface logic, and upgrade detection logic. Set a main entry routine in the bootstrap shell program. The main entry routine is used to read the encryption function payload index and parse the index entries to form the function segment location result, and to extract and prepare the encryption function segments based on the function segment location result. Set a registration entry routine in the bootstrap shell program. The registration entry routine is used to collect user information, encapsulate it into registration request data and send it to the server. At the same time, it receives the serial number returned by the server and writes it to the local authorized storage area of ​​the bootstrap shell program.

[0075] An upgrade detection routine is set up in the boot shell program. The upgrade detection routine is used to submit the serial number to the server and request the return of upgrade status data and parse the upgrade status data to determine whether to allow entry into the full version loading process. The encryption function payload index is written into the data segment of the boot shell program and an index offset pointer is established so that the main entry routine can locate and read the encryption function payload index through the index offset pointer, forming a two-layer payload structure.

[0076] The registration interface logic of the startup shell program receives user information and sends a registration request to the server. The server verifies the user information and generates a unique serial number after confirming payment. The server also verifies the user information, including field integrity and field format. Field integrity verification determines whether the user information contains required fields and generates a field integrity verification result. Field format verification determines whether required fields meet the corresponding format rules and generates a field format verification result. The server then summarizes the field integrity and field format verification results into a user information verification result.

[0077] The server performs verification on the payment completion status, including verification of the validity of the payment order number and verification of the consistency of the payment status. The verification of the validity of the payment order number is used to determine whether the payment order number exists and has not been cancelled, and generates an order number verification result. The verification of the consistency of the payment status is used to determine whether the payment status is "paid", and generates a payment status verification result. The server summarizes the order number verification result and the payment status verification result into a payment verification result.

[0078] When both user information verification and payment verification are successful, the server generates a unique serial number, outputs a registration successful response, and sends the unique serial number back to the launcher. When either user information verification or payment verification fails, the server outputs a registration failed response and sends back a failure identifier and a description of the failure reason. After receiving the registration failed response, the launcher stops writing the serial number and retains the running state of the incomplete release version.

[0079] Extract all segment identifiers from the cryptographic payload index to form a functional segment list. Bind the functional segment list to unique serial numbers to generate a serial number binding table.

[0080] S2. When the software is used for the first time, a unique code is generated from the client hardware through the startup shell program, and together with the serial number binding relationship, a device binding activation certificate request package is generated.

[0081] S2.1. Under the premise that the software must be activated online for the first use, read the unique serial number in the serial number binding table to form a serial number record; the boot shell program calls the operating environment interface to read the CPU serial number, motherboard serial number and hard disk serial number of the client hardware; the boot shell program performs standardization processing on the CPU serial number, motherboard serial number and hard disk serial number, the standardization processing includes removing spaces and separators, converting all letters to uppercase, unifying the hexadecimal representation to a fixed character set representation without prefix, padding the end of hardware identifiers that are less than the predetermined length with placeholder characters, and truncating hardware identifiers that exceed the predetermined length to the predetermined length, to obtain the standardized CPU serial number, standardized motherboard serial number and standardized hard disk serial number.

[0082] To further explain, the predetermined length is determined by the hardware identifier normalization rules written by the boot shell program when it is released. This is used to unify the CPU serial number, motherboard serial number and hard disk serial number to the same character length to ensure the consistency of the generated unique code. Each hardware identifier is normalized to a fixed length of 16 to 64 characters, preferably 32 characters. If the length is insufficient, placeholders are added; if it exceeds the limit, it is truncated to ensure the stability of the unique code.

[0083] The boot shell program concatenates the standardized CPU serial number, standardized motherboard serial number, and standardized hard disk serial number in a predetermined order to generate a string of original hardware information. The predetermined order is: standardized CPU serial number first, standardized motherboard serial number in the middle, and standardized hard disk serial number last. The predetermined order is written into the boot shell program's preset concatenation rules and is fixed when the boot shell program is released to ensure that the concatenation order is consistent in different client environments and outputs the original hardware information string.

[0084] The bootloader applies the SHA-256 hash algorithm to the original hardware information string to generate a fixed-length unique code. This includes converting the original hardware information string into a byte sequence using UTF-8 encoding and generating message data; iteratively compressing the message data using SHA-256 message digest operation to obtain a 256-bit digest value; and outputting the 256-bit digest value as a fixed-length unique code in hexadecimal string format. Finally, it performs a joint organization between the serial number record and the unique code to generate a device binding identifier pair and outputs the device binding identifier pair.

[0085] S2.2. After the device binding identifier pair is generated, the hardware root trust is triggered to output remote proof materials, including the boot shell program calling the remote proof interface provided by the trusted execution environment and submitting proof request data. The proof request data includes at least the device binding identifier pair and the measurement request identifier of the boot shell program. The trusted execution environment collects the code measurement value and runtime status measurement value of the boot shell program to form a measurement report, and uses the proof key held by the hardware root trust to perform digital signature on the measurement report to generate a signature report. The signature report and the measurement report together constitute the remote proof materials. The remote proof materials are used to prove that the boot shell program is in an execution environment that has not been debugged or tampered with.

[0086] The device binding identifier and remote proof materials are encapsulated to generate a verifiable proof package. This includes writing field type identifiers and field length identifiers to the device binding identifier and remote proof materials and concatenating them in a fixed field order to generate a structured proof payload, which is then output as a verifiable proof package. Based on the network activation session, a non-reusable session parameter package is generated. This includes starting a shell program to generate a session identifier and a random number. The random number is generated by a cryptographically secure random number generator and recorded as a session random number. At the same time, the shell program obtains the timestamp of this network activation session and records it as a session timestamp. The session identifier, session random number, and session timestamp are encapsulated in a fixed field order to generate a non-reusable session parameter package.

[0087] To further explain, the fixed field order is defined by the structured encapsulation format and is fixed in the bootstrap program. The fixed field order is used to concatenate the device binding identifier and remote proof materials in a uniform field arrangement order to generate a structured proof payload.

[0088] The verifiable proof packet and the non-reusable session parameter packet are encapsulated with anti-soft encryption to generate an activation proof request packet. The verifiable proof packet and the non-reusable session parameter packet are combined in a fixed order to form a request plaintext payload. The request plaintext payload is symmetrically encrypted to obtain an encrypted payload. The encrypted payload is then used to calculate a message authentication code to obtain an integrity check value. The encrypted payload and the integrity check value are then encapsulated together to form the activation proof request packet.

[0089] To further explain, the fixed order is defined by the activation proof request packet encapsulation format and solidified in the startup shell program. It is used to first combine the verifiable proof packet and then combine the non-reusable session parameter packet to form the request plaintext payload.

[0090] S3. The server verifies the activation proof request packet, checks the consistency between the unique code and the serial number, and the validity of the remote proof materials. It then generates a payload decapsulation instruction packet that is only valid for the current session and sends it back to the client.

[0091] S3.1. The server receives the activation certificate request packet and completes the data decryption, encapsulation and parsing. It uses the private key to decrypt the activation certificate request packet to obtain the request plaintext payload, and extracts the device binding identifier pair, remote proof materials and timestamp from the request plaintext payload.

[0092] The server reads the current time and calculates the difference with the timestamp to generate a time difference. The server compares the time difference with the effective time window execution interval to generate a time window verification result. The effective time window execution interval is determined by the server's preset network activation session validity rules and is fixed when the server publishes the service. The effective time window execution interval represents the range of time differences that allow activation certificate request packets to be accepted. When the time difference falls within the effective time window execution interval, a passing time window verification result is generated. When the time difference does not fall within the effective time window execution interval, a failing time window verification result is generated.

[0093] If the time window verification result is successful, the serial number and unique code are parsed from the device binding identifier. Based on the serial number, the registered user information and authorized segment list are queried, and the serial number, unique code, registered user information, and authorized segment list are output. Based on the serial number, the unique code that was previously bound to the serial number is retrieved, and a matching comparison is performed between the previously bound unique code and the unique code to generate a consistency verification result. If the previously bound unique code and the unique code are completely consistent, a successful consistency verification result is generated. If the previously bound unique code and the unique code are inconsistent, a failed consistency verification result is generated.

[0094] S3.2. Extract the measurement report and signature report from the remote proof materials. The measurement report is generated by the trusted execution environment after the remote proof interface accepts the proof request data. The measurement report contains the code measurement value and runtime status measurement value of the bootstrap program. The code measurement value is calculated from the code page digest of the bootstrap program, and the runtime status measurement value is obtained by summing the debug status flag and integrity status flag of the bootstrap program.

[0095] The server uses the Trusted Execution Environment (TEE) baseline value to perform a matching check on the measurement report and generates a measurement check result. The TEE baseline value is determined by the server's pre-configured trusted version registration information of the bootstrap program. The trusted version registration information of the bootstrap program includes at least the baseline code measurement value and the baseline runtime status measurement value of the bootstrap program. When the code measurement value in the measurement report matches the baseline code measurement value and the runtime status measurement value in the measurement report matches the baseline runtime status measurement value, a passing measurement check result is generated. When the code measurement value or the runtime status measurement value does not match, a failing measurement check result is generated.

[0096] The server uses the digital signature verification rules of remote proof materials to verify the signature report and generate a signature verification result. The digital signature verification rules are determined by the hardware root trust public key preset by the server. The server uses the hardware root trust public key to verify the digital signature value of the signature report. If the verification is successful, a successful signature verification result is generated; if the verification fails, a failed signature verification result is generated. The server summarizes the measurement verification result and the signature verification result to generate a remote proof validity verification result. If both the measurement verification result and the signature verification result are successful, a successful remote proof validity verification result is generated. If either the measurement verification result or the signature verification result is unsuccessful, an unsuccessful remote proof validity verification result is generated.

[0097] S3.3. The server performs a joint determination on the time window verification result, the consistency verification result, and the remote proof validity verification result to generate a session authorization determination result. If the time window verification result, the consistency verification result, and the remote proof validity verification result are all passed, a passed session authorization determination result is generated. If the time window verification result, the consistency verification result, or the remote proof validity verification result is all failed, a failed session authorization determination result is generated. The server generates a random session key when the session authorization determination result is passed, and outputs a rejection response and terminates the payload decapsulation instruction packet generation process when the session authorization determination result is failed.

[0098] The server uses a random session key to encrypt the list of authorized segments, generating an encrypted list of authorized segments, and then encapsulates the encrypted list of authorized segments to form a payload decapsulation instruction packet.

[0099] S4. Based on the authorization information of the decapsulation instruction packet, the client decrypts, loads, and executes the segmented payloads in the encrypted payload packet, generating a loaded execution-state payload instance and session authorization information.

[0100] S4.1. The client receives the payload decapsulation instruction packet and reads the encrypted authorization segment list from it. The client uses the random session key generated when the session authorization determination result is passed to perform symmetric decryption on the encrypted authorization segment list to obtain the decryption authorization list. The decryption authorization list contains segment identifiers, temporary decryption tokens and loading order identifiers.

[0101] To further explain, the decryption process of the decryption authorization list satisfies the following relationship, specifically:

[0102] ;

[0103] in, Indicates the first Each encryption authorization segment entry is taken from the encryption authorization segment list and... The corresponding entries; Indicates the first Each session identifier corresponds to a random session key; This represents a symmetric decryption operation; Indicates the first One authorized segment entry.

[0104] S4.2. The client locates the corresponding encrypted function segment in the encrypted payload packet based on the segment identifier in the decryption authorization list, and performs symmetric decryption on the located encrypted function segment based on the temporary decryption token in the decryption authorization list, generating the original function segment code and summarizing it to output the original function segment code set.

[0105] To further explain, the segmented decryption process of the encryption function satisfies:

[0106] ;

[0107] in, Indicates the first Each encryption function segments the ciphertext; Indicates the first A temporary decryption token, from the decryption authorization list and... The corresponding temporary decryption token is obtained; The output of the symmetric decryption operation is the first... Each original function is segmented into code segments (decrypted to output plaintext).

[0108] The client allocates a protected region of memory for the original functional segment code set, and writes the original functional segment code into the protected region sequentially according to the loading order identifier in the decryption authorization list, forming a continuous executable memory image.

[0109] The entry address is parsed from the continuously executable memory image and the client jumps to the entry address to execute the original functional segment code. After the original functional segment code completes execution in the protected area, it forms a loaded execution-state payload instance. At the same time, the client summarizes the decryption authorization list, segment identifier, temporary decryption token and loading order identifier to generate session authorization information.

[0110] S5. During operation, the client implements delayed decryption and short-term resident loading protection for critical functions based on the loaded execution-state payload instance and session authorization record, and triggers copy installation identification and authorization revocation processing.

[0111] S5.1. During operation, the client monitors the call requests of key functions and completes the authorization status retrieval. The client captures the call requests of key functions from the call entry point of the loaded execution payload instance. Key functions are limited to the core algorithm logic of the software, license verification routines, data encryption and decryption logic, and user authentication interface. The client retrieves the authorization status of key functions in the session authorization information based on the function identifier of the key functions and outputs the key function authorization status query results.

[0112] The client executes branch processing based on the key function authorization status query result. When the key function authorization status query result is authorized and decrypted, the client directly calls the decrypted key function code in the loaded execution-state payload instance and outputs the key function execution result. When the key function authorization status query result is unauthorized, the client terminates the key function call and returns an error message. The key function call record is written to the session authorization information and the unauthorized processing result is output. When the key function authorization status query result is authorized but not decrypted, the client enters the delayed decryption process and outputs the delayed decryption trigger flag.

[0113] S5.2. After the delayed decryption trigger flag is output, the client generates a temporary decryption key and completes the preparation of the temporary execution buffer. The client reads the decryption parameter seed corresponding to the key function from the session authorization information and generates a temporary decryption key by combining the session flag and session random number in the session authorization information. The client allocates a temporary execution buffer for the key function and sets the access permissions of the temporary execution buffer to read-only and execute. The client outputs the temporary decryption key and the temporary execution buffer flag.

[0114] It should be noted that the temporary decryption key is generated by a key derivation function from the decryption parameter seed, session identifier, and session random number.

[0115] Based on the temporary decryption key, the client performs segmented decryption, short-term loading, execution, and erasure of the encrypted function corresponding to the critical function. The client locates the corresponding encrypted function segment in the encrypted payload based on the function identifier of the critical function and outputs the location result. The client then performs symmetric decryption on the encrypted function segment corresponding to the critical function using the temporary decryption key to generate the decrypted critical code. The client loads the decrypted critical code into a temporary execution buffer and maintains the temporary execution buffer's read-only and execute access permissions. The client executes the decrypted critical code in the temporary execution buffer and outputs the critical function execution result. After the critical function execution is complete, the client immediately clears the code data in the temporary execution buffer and generates an execution trace clearing result, which is then written into the session authorization information.

[0116] S5.3. After the client writes the execution trace clearing result into the session authorization information, it performs short-term resident load protection and generates a runtime evidence package. It allocates a dedicated protected memory area for critical functions and sets the access permissions of the protected memory area to read-only and execute. In the protected memory area, it performs short-term resident load protection on the critical functions and locks the protected memory area to prevent external access. The client monitors the execution process of the critical function code and records the code execution trajectory. After the critical function code is executed, it immediately overwrites the code data in the protected memory area and fills it with a random byte sequence. Based on the execution trace clearing result, it unlocks and releases the protected memory area. At the same time, the client updates the session authorization information and generates a runtime evidence package. The runtime evidence package contains at least the session authorization information and the code execution trajectory.

[0117] The server receives the execution evidence package and parses the session authorization information and code execution trajectory within it. Based on the session authorization information, the server verifies the consistency between the serial number and the device binding relationship and checks for anomalies in the code execution trajectory. This includes a critical function call sequence consistency check, a critical function call count consistency check, and a protected memory area erasure consistency check. The critical function call sequence consistency check determines whether the order of critical function calls recorded in the code execution trajectory matches the loading order identifier recorded in the session authorization information. The critical function call count consistency check determines whether the number of critical function calls recorded in the code execution trajectory exceeds the maximum number of session authorizations recorded in the session authorization information (set according to the critical function risk level, ranging from 1 to 10 times / session; core algorithm logic and license verification routines are preferably 1 to 3 times / session, and identity authentication interfaces are preferably 3 to 10 times / session; set based on reducing repeated triggering and dynamic dump availability within the debugging window). The protected memory area erasure consistency check determines whether there are protected memory area overwrite records in the code execution trajectory corresponding to the execution trace erasure results.

[0118] S5.4. When the critical function call sequence consistency check passes, the critical function call count consistency check passes, and the protected memory area erase consistency check passes, a passing code execution trajectory anomaly check result is generated. When the critical function call sequence consistency check fails, the critical function call count consistency check fails, or the protected memory area erase consistency check fails, a failing code execution trajectory anomaly check result is generated. Among them, the code execution trajectory corresponding to the passing code execution trajectory anomaly check result is normal, and the code execution trajectory corresponding to the failing code execution trajectory anomaly check result is abnormal.

[0119] When the serial number and device binding consistency verification passes and the code execution trajectory anomaly check result passes, the server maintains the payload decapsulation instruction packet issuance permission status and outputs the pass handling result; when the serial number and device binding consistency verification fails or the code execution trajectory anomaly check result fails, the server determines that there is a change in the key and device binding relationship caused by the installation on another machine and refuses to continue issuing payload decapsulation instruction packets. The server adds the corresponding serial number to the revocation list and sends a revocation instruction to the client. The revocation instruction includes the serial number and the revocation reason identifier.

[0120] After receiving the revocation command, the client deletes the local license code and related installation files, and clears the cached encryption payload index. The revocation command, the result of deleting the local license code, the result of deleting the related installation files, and the result of clearing the cached encryption payload index are summarized to form a revocation processing record.

[0121] This embodiment also provides a computer device applicable to the method of reverse engineering anti-software encryption software, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the method of reverse engineering anti-software encryption software as proposed in the above embodiment.

[0122] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0123] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements the method for reverse engineering anti-software encryption software as proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0124] In summary, this invention delivers a non-complete release version with a two-layer payload and encrypted data encapsulation. Only the boot shell program and the encrypted payload index are delivered, along with registration, payment, and serial number binding. This ensures that the complete payload does not appear in recoverable plaintext during the release phase, reducing static unpacking and offline reverse engineering exposure from the source. Upon first use, the boot shell program generates a unique code based on the client hardware and forms a device binding identifier pair with the unique serial number. Combined with remote verification materials, it forms an activation verification request package, ensuring that authorization is simultaneously constrained by the serial number, device status, and the credibility of the execution environment, increasing the difficulty of cross-machine reuse and debugging / tampering. During execution, the server only generates a payload decapsulation instruction package valid for the current session and encapsulates an authorization segment list, making decryption authorization one-time and time-sensitive. The client performs segmented decryption and loading, combined with delayed decryption and short-term resident loading to protect and compress plaintext dwell time, reducing the availability of memory dumps and dynamic tracking. When the running evidence package points to a copied installation or abnormal execution trajectory, it triggers a revocation list and revocation instruction, and cleans up the local authorization code and related installation files, achieving abnormal revocation and traceability, enhancing the suppression effect on reverse engineering and cross-machine theft of shared software.

[0125] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for reverse engineering anti-software encryption software, characterized in that: include, Construct a two-layer payload and anti-soft encryption encapsulation for an incomplete release version, and generate a serial number binding table by indexing the boot shell program and the encryption function payload; When the software is used for the first time, a unique code is generated from the client hardware by starting the shell program, and an activation certificate request package for device binding is generated together with the serial number binding relationship. The server verifies the activation certificate request packet, checking the consistency between the unique code and the serial number, as well as the validity of the remote proof materials. It then generates a payload decapsulation instruction packet that is only valid for the current session and sends it back to the client. Based on the authorization information of the decapsulation instruction packet, the client decrypts, loads, and executes the segmented payloads in the encrypted payload packet, generating a loaded execution-state payload instance and session authorization information; During operation, the client implements delayed decryption and short-term resident loading protection for critical functions based on the loaded execution-state payload instance and session authorization records, and triggers copy installation identification and authorization revocation processing.

2. The method for reverse engineering anti-software encryption software as described in claim 1, characterized in that: The specific steps for constructing the dual-layer payload and anti-soft encryption encapsulation of the incomplete release version are as follows. The functional payload is split into functional segments based on code logic and resource dependencies, and segment identifiers are assigned accordingly. Each functional segment is individually encrypted and then combined to form an encrypted payload packet; Generate index entries for each encryption function segment and summarize them to form an encryption function payload index; A boot shell program containing program loading logic, registration interface logic, and upgrade detection logic is constructed, and the encryption function payload index is written into the boot shell program to form a two-layer payload structure.

3. The method for reverse engineering anti-software encryption software as described in claim 1, characterized in that: The specific steps for generating the serial number binding table are as follows. The launcher receives user information and sends a registration request to the server. After the server verifies the user information and confirms payment, it generates a unique serial number. Extract all segment identifiers from the cryptographic payload index and bind them to unique serial numbers to generate a serial number binding table.

4. The method for reverse engineering anti-software encryption software as described in claim 1, characterized in that: The specific steps for generating a unique code from the client hardware via the bootstrap program are as follows: The boot shell program calls the operating environment interface to read the CPU serial number, motherboard serial number, and hard disk serial number of the client hardware. After standardization processing, the serial numbers are concatenated in a predetermined order to generate the original hardware information string. Apply the SHA-256 hash algorithm to the original hardware information string to generate a fixed-length unique code.

5. The method for reverse engineering anti-software encryption software as described in claim 1, characterized in that: The specific steps for generating the payload decapsulation instruction packet, which is only valid for the current session, are as follows. The server uses its private key to decrypt the activation certificate request packet, extracts the device binding identifier pair, remote proof materials, and timestamp, and checks the difference between the timestamp and the current time to confirm that the request is within the valid time window. Parse the serial number and unique code from the device binding identifier pair to obtain the registered user information and authorized segment list corresponding to the serial number; Retrieve the unique code historically bound to the serial number, verify whether the current unique code is consistent with the historical unique code, and generate a consistency verification result; Verify the digital signature of the remote proof material, check whether the metric value matches the trusted execution environment benchmark value, and generate the remote proof validity verification result; If both the consistency check result and the remote proof validity check result pass the verification, a random session key is generated; otherwise, the request is rejected. The authorized segment list is encrypted and decrypted using the session key to form a payload decapsulation instruction packet.

6. The method for reverse engineering anti-software encryption software as described in claim 1, characterized in that: The specific steps for generating the loaded execution-state payload instance and session authorization information are as follows: After receiving the decapsulation instruction packet, the client uses the locally stored session key to decrypt the instruction packet and obtain the decryption authorization list; Based on the segment identifier and temporary decryption token in the decryption authorization list, locate the corresponding encrypted function segment from the encrypted payload packet, use the temporary decryption token to decrypt each encrypted function segment, and restore the original function segment code; The decrypted functional code segments are loaded into the protected area of ​​memory and arranged in the order of loading in the decryption authorization list to form a continuous executable memory image. The client jumps to the entry address of the memory image, executes the functional segment code, generates the loaded execution-state payload instance, and records the session authorization information.

7. The method for reverse engineering anti-software encryption software as described in claim 1, characterized in that: The key functions include the software's core algorithm logic, license verification routines, data encryption / decryption logic, and user authentication interface.

8. The method for reverse engineering anti-software encryption software as described in claim 1, characterized in that: The delayed decryption process involves the following steps. During runtime, the client monitors calls to critical functions and retrieves the authorization status of these functions from the session authorization information. If the critical function has been authorized but not decrypted, the client uses the decryption parameter seed in the session authorization information to generate a temporary decryption key; If the critical functions have been authorized and decrypted, then the decrypted critical function code will be executed directly. If critical functions are not authorized, execution will terminate and an error message will be returned; A temporary execution buffer is allocated for critical functions. A temporary decryption key is used to decrypt the encrypted function segments corresponding to the critical functions from the encrypted payload packet to generate the decrypted critical code. The decrypted critical code is loaded into a temporary execution buffer in memory, and the buffer is set to read-only permission. The critical code is executed, and the code data in the temporary execution buffer is cleared immediately after the critical code is executed, generating execution trace clearing results.

9. The method for reverse engineering anti-software encryption software as described in claim 1, characterized in that: The operation steps for the short-stay loading protection are as follows: The client allocates a dedicated protected memory region for critical functions and sets the access permissions of the protected memory region to read-only and execute. Based on the already loaded execution-state payload instance, once the critical functions are loaded into the protected memory area via delayed decryption, the client locks the protected memory area to prevent external access. The client monitors the execution process of key functional code and records the code execution trajectory; After the critical function code is executed, the code data in the protected memory area is immediately overwritten, a random byte sequence is filled in, the lock on the protected memory area is released based on the execution trace cleanup result, the session authorization information is updated, and a runtime evidence package is generated.

10. The method for reverse engineering anti-software encryption software as described in claim 1, characterized in that: The specific steps for triggering the identification and authorization revocation of copy installation are as follows. The server receives the execution evidence packet and parses the session authorization information and code execution trace in the execution evidence packet; Verify the consistency between the serial number and the device binding relationship based on the session authorization information, and check whether the code execution trajectory is abnormal; When the server detects a change in the key and device binding relationship caused by installation on another machine, it refuses to continue issuing decapsulation instructions, adds the corresponding serial number to the revocation list, and sends a revocation instruction to the client. The client deletes the local license key and related installation files according to the revocation command, and cleans up the cached encrypted payload index.

Images