Method for realizing computer software protection based on network communication

Abstract

The invention discloses a method for realizing computer software protection based on network communication, which relates to the technical field of software protection, and comprises the following steps that: client software modifies codes of the client software according to a modification rule and generates an analytic state client; starting an analysis state client, triggering a symbol analysis request through a built-in communication handle, and sending the symbol analysis request to a server; the server receives the symbol analysis request and verifies the symbol analysis request, after verification is passed, a symbol analysis response is generated in combination with the verification dynamic factor, and the symbol analysis response is returned to the analysis state client; the analysis state client receives and verifies the symbol analysis response, and after verification is passed, symbol analysis is completed according to the symbol analysis response. According to the method, the defense capability on dynamic analysis, simulation execution and environment clone attacks is remarkably improved by operating a parameterized code transformation mechanism driven by environment fingerprints.

Description

Technical Field

[0001] This invention relates to the field of software protection technology, and in particular to a method for protecting computer software based on network communication. Background Technology

[0002] In modern software distribution and runtime environments, software protection has become a crucial element in safeguarding developers' rights and maintaining business sustainability. With the widespread adoption of network communication technologies and the advancement of computing terminal capabilities, software protection mechanisms based on remote verification and dynamic reconfiguration have gradually become a research hotspot. These mechanisms typically rely on interaction between the client and server, employing methods such as runtime code transformation, encryption and obfuscation, or remote authorization control to enhance the concealment of software logic and suppress unauthorized copying. Especially in networked deployment scenarios, ensuring the integrity of software functionality while effectively preventing reverse engineering, static analysis, and unauthorized secondary distribution is a core challenge in the design of current software protection systems.

[0003] Existing software protection solutions based on network communication mostly rely on static authorization verification or one-time code obfuscation strategies. They lack the ability to continuously evolve the client code state during operation, making them vulnerable to continuous monitoring and behavior extraction by advanced dynamic analysis tools. Furthermore, while some solutions introduce remote symbol resolution mechanisms, their resolution logic is highly coupled with the client code structure, making them easily predictable or simulated, thus weakening the protection strength. Periodic heartbeat verification or code packing with fixed rules is often used to mitigate these problems, but such methods remain insufficient against targeted attacks and struggle to achieve fine-grained runtime adaptive protection. 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 protecting computer software based on network communication to solve the problem of difficulty in achieving fine-grained runtime adaptive protection.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, the present invention provides a method for protecting computer software based on network communication, comprising, The server generates modification rules based on the unique identifier of the client software and sends the modification rules to the client software. The client software modifies its own code according to the modification rules and generates a parsed client. Start the parsing client, trigger a symbol resolution request through the built-in communication handle, and send the symbol resolution request to the server; The server receives and verifies the symbol resolution request. Once the verification is successful, it generates a symbol resolution response by combining the verification dynamic factor and returns the symbol resolution response to the client in the resolution state. The parsing client receives and verifies the symbol resolution response. After successful verification, it completes symbol resolution based on the response and retrieves the evolution rule package from the server before the end of the current run. It then transforms its own code again to generate a new parsing client for the next run.

[0007] As a preferred embodiment of the method for protecting computer software based on network communication according to the present invention, wherein: the generation of the parsing state client specifically refers to... The server obtains the unique identifier and runtime environment fingerprint sent by the client software; Select the basic transformation rule group corresponding to the unique identifier from the pre-stored transformation template library, and perform parameterized adjustment of the basic transformation rule group by runtime environment fingerprint to generate modification rules; Using the AES symmetric encryption algorithm and a shared key, the modified rules are encrypted and HMAC integrity signed to generate an encrypted modified rule package, which is then sent to the client software. After receiving the encrypted modification rule packet, the client software uses the AES symmetric encryption algorithm and the shared key to decrypt the encrypted modification rule packet and verify the HMAC integrity signature. After verifying the HMAC integrity signature, the client software's own code is rearranged and opaque predicates are inserted to generate a parsed client.

[0008] As a preferred embodiment of the method for protecting computer software based on network communication described in this invention, the step of reordering code blocks and inserting opaque predicates into the client software's own code to generate a parsed client specifically involves: The client software's own code is divided into multiple independent code blocks; Based on the code block rearrangement instructions in the modification rules, multiple independent code blocks are sequentially reorganized; Based on the opaque predicate insertion instructions in the modification rules, conditional branch predicates that are always true are inserted at the connection points of multiple independent code blocks after reorganization, generating a parsed client.

[0009] As a preferred embodiment of the method for protecting computer software based on network communication as described in this invention, the modification rules include code block rearrangement instructions and opaque predicate insertion instructions.

[0010] As a preferred embodiment of the method for protecting computer software based on network communication according to the present invention, wherein: sending the symbol resolution request to the server specifically involves, Initialize the parsed client and call the built-in communication handle to collect dynamic runtime environment fingerprints and unresolved symbols; Get local random numbers from the random number generator; Perform HMAC operations on the dynamic runtime environment fingerprint, unresolved symbols, and local random numbers to generate the real signature value; The dynamic runtime environment fingerprint, unresolved symbols, local random numbers, and real signature values ​​are combined to generate a symbol resolution request and send it to the server.

[0011] As a preferred embodiment of the method for protecting computer software based on network communication according to the present invention, wherein: the generation of symbol resolution response specifically includes, The shared key is used to re-perform HMAC operations on the dynamic runtime environment fingerprint, unresolved symbol, and local random number in the symbol resolution request, and then compared and verified with the real signature value in the symbol resolution request. After successful verification, a verification dynamic factor is generated. The verification dynamic factor is used as the decryption key to decrypt the encrypted symbol address library, thus obtaining the decrypted symbol address library; Using unresolved symbols, extract the corresponding address mapping values ​​from the decrypted symbol address database to generate an address mapping table; The address mapping table and verification dynamic factor are encrypted to generate a symbol resolution response.

[0012] As a preferred embodiment of the method for protecting computer software based on network communication described in this invention, the encrypted symbol address library is a pre-installed, encrypted database on the server side, which stores the mapping relationship between the core symbols that need to be dynamically parsed in the software and their corresponding real address mapping values.

[0013] As a preferred embodiment of the method for protecting computer software based on network communication described in this invention, the step of obtaining the evolution rule package from the server before the end of the current operation specifically involves: Extract the hidden verification value locally from the parsing client; The dynamic factor, local random number, and dynamic runtime environment fingerprint are concatenated in a predetermined order to generate concatenated data; Perform cryptographic hashing on the concatenated data to obtain the session verification value, and compare it with the hidden verification value; When the session checksum and the hidden checksum match, the unresolved symbols in the memory of the parsed client are replaced with the address mapping values ​​in the address mapping table, restoring the parsed client to a fully functional executable software and running it. At the end of the runtime, collect the current code summary, obtain the client's unique identifier from the client software, and generate new local random numbers using a random number generator; The client's unique identifier, the current code digest, and a new local random number are combined to generate an evolution rule request, which is then sent to the server. The server authenticates and matches evolution rule requests with policies, and generates evolution rule packages.

[0014] As a preferred embodiment of the method for protecting computer software based on network communication described in this invention, the step of generating a new parsing-state client for the next run specifically involves: Perform integrity verification on the evolution rule package to obtain the verified evolution rule package; Based on the verified evolution rule package, code block rearrangement, opaque predicate insertion, and control flow randomization refactoring operations are performed on the complete code in the executable software memory. Integrity verification anchors are inserted at the positions specified in the evolution rule package, and the jump metadata and verification routines in the evolution rule package are written into the memory code. The written memory code image is serialized to a disk file, generating a new parsed-state client for the next run.

[0015] As a preferred embodiment of the method for protecting computer software based on network communication described in this invention, the control flow randomization reconstruction operation refers to, based on the flow randomization instructions in the evolution rule package, randomly changing the jump and connection relationships between code blocks while keeping the original program logic unchanged, thereby generating a control flow graph with a unique structure and difficult to predict.

[0016] The beneficial effects of this invention are as follows: Through a parameterized code transformation mechanism driven by runtime environment fingerprints, fine-grained runtime adaptive protection is achieved. The server decomposes the runtime environment fingerprint reported by the client into independent feature components such as processor type, memory configuration, and operating system version, and maps them to the rearrangement order offset of code block rearrangement instructions, the insertion density position of opaque predicate insertion instructions, and the expression complexity position of conditional branch predicates, respectively, dynamically generating modification rules that precisely match the current execution context. Based on this, the client performs structural-level refactoring of its own code, ensuring that the control flow graph, basic block layout, and obfuscation strength are adjusted in real time according to the environment characteristics for each run. This mechanism achieves code morphology evolution at the device level or even the session level without relying on external intervention, significantly improving the defense capabilities against dynamic analysis, simulated execution, and environment cloning attacks. Attached Figure Description

[0017] 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.

[0018] Figure 1 A flowchart illustrating a method for protecting computer software based on network communication.

[0019] Figure 2 The flowchart for the symbol resolution request.

[0020] Figure 3 A flowchart for generating symbol resolution responses.

[0021] Figure 4 A flowchart for verifying the symbol resolution response. Detailed Implementation

[0022] 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.

[0023] 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.

[0024] 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.

[0025] Reference Figures 1-4 This is one embodiment of the present invention, which provides a method for protecting computer software based on network communication, including the following steps: S1. The server generates modification rules based on the unique identifier of the client software and sends the modification rules to the client software. The client software modifies its own code according to the modification rules and generates a parsed client.

[0026] The server obtains the unique identifier and runtime environment fingerprint sent by the client software; specifically, the server receives the unique identifier and runtime environment fingerprint actively sent by the client software through network communication when the client software starts.

[0027] Select a basic transformation rule group corresponding to the unique identifier from the pre-stored transformation template library, and perform parameterized adjustment on the basic transformation rule group using the runtime environment fingerprint to generate modification rules; the modification rules include code block rearrangement instructions and opaque predicate insertion instructions.

[0028] Specifically, the server uses a unique identifier as an index key value, searches for and selects a basic transformation rule group that perfectly matches the index key value in a pre-stored transformation template library. The basic transformation rule group contains a variety of predefined sets of code block rearrangement instructions and sets of opaque predicate insertion instructions.

[0029] The runtime environment fingerprint is decomposed into multiple independent feature components. Each feature component corresponds to a specific parameter position in the basic transformation rule group. The specific parameter position refers to the reserved parameter field position of each code block reordering instruction and opaque predicate insertion instruction in the basic transformation rule group, including the reordering offset position of the code block reordering instruction, the insertion density position of the opaque predicate insertion instruction, and the expression complexity position of the conditional branch predicate.

[0030] Iterate through each instruction in the basic transformation rule group and directly map the corresponding feature components of the runtime environment fingerprint to the parameter field of the instruction. For example, map the processor type feature component in the runtime environment fingerprint to the rearrangement order offset position of the code block rearrangement instruction, map the memory configuration feature component in the runtime environment fingerprint to the insertion density position of the opaque predicate insertion instruction, and map the operation version feature component in the runtime environment fingerprint to the expression complexity position of the conditional branch predicate.

[0031] After replacing all parameter fields, the adjusted code block rearrangement instruction set and the opaque predicate insertion instruction set are combined to form a complete modification rule.

[0032] Using the AES (Advanced Encryption Standard) symmetric encryption algorithm and a shared key, the modification rules are encrypted and HMAC (Hash Authentication Code) integrity signature is performed to generate an encrypted modification rule package, which is then sent to the client software.

[0033] Specifically, the modification rules are serialized into a binary data stream.

[0034] The server derives the encryption key required for the AES symmetric encryption algorithm and the signature key required for HMAC integrity signature from the shared key, directly providing the necessary key materials for subsequent encryption and integrity signature.

[0035] The server generates a 128-bit initialization vector using a cryptographically secure random number generator. The 128-bit length is chosen because the block size of the AES symmetric encryption algorithm is fixed at 128 bits, and the 128-bit initialization vector length must exactly match the block size.

[0036] Using the AES symmetric encryption algorithm in CBC (Cryptographic Block Chaining) mode, the binary data stream is encrypted with a derived encryption key and a randomly generated 128-bit initialization vector to generate encrypted ciphertext. Specifically, the binary data stream is divided into multiple 128-bit blocks using the AES symmetric encryption algorithm in CBC mode. Starting from the first block, the current block is XORed with the encrypted ciphertext of the previous block and then encrypted. The first block is XORed with the randomly generated 128-bit initialization vector and then encrypted. This process is repeated block by block until the entire binary data stream is completed, generating encrypted ciphertext.

[0037] The encrypted ciphertext is concatenated with a 128-bit initialization vector to form encrypted data.

[0038] The HMAC integrity signature algorithm is used to perform an integrity signature on encrypted data using a derived signature key, generating a signature value. Specifically, the encrypted data is taken as the message, the derived signature key is taken as the key, and the HMAC-SHA256 algorithm is used for processing (i.e., the key is bound to the message according to cryptographic security requirements), resulting in a 256-bit binary digest, which is the signature value. The cryptographic security requirements are well-known technologies in the field of cryptography, such as the HMAC construction method specified in RFC2104 (HMAC Algorithm Specification) and the SHA-256 hash algorithm specified in FIPS180-4 (Secure Hash Standard).

[0039] It should be noted that the HMAC-SHA256 algorithm is an authentication code algorithm that combines a key with a message and uses the SHA256 hash function to generate a fixed-length digest. It is used to verify data integrity and authenticity of its source and is a publicly available cryptographic technique.

[0040] The encrypted data and the signature value are combined (that is, the encrypted data and the signature value are concatenated byte by byte) to form a complete encrypted modification rule package, and the encrypted modification rule package is sent to the client software through network communication.

[0041] After receiving the encrypted modification rule packet, the client software uses the AES symmetric encryption algorithm and the shared key to decrypt the encrypted modification rule packet and verify the HMAC integrity signature.

[0042] Specifically, the encrypted data and signature value are separated from the encrypted modification rule package. The separation method is that the first part is the encrypted data and the second part is the signature value.

[0043] The client software derives the encryption key required for the AES symmetric encryption algorithm and the signature key required for the HMAC integrity signature from the shared key. The derivation method is exactly the same as that of the server. It uses the HKDF extension function, takes the shared key as the input key material, takes the fixed string "AES-Encryption" as the salt value of the encryption key, and takes the fixed string "HMAC-Signature" as the salt value of the signature key, and generates an encryption key with an output length matching the length of the AES symmetric encryption algorithm key and a signature key with an output length matching the length of the HMAC integrity signature key, respectively.

[0044] It should be noted that the HKDF extension function is a key derivation function based on HMAC. Its operating principle is to generate a pseudo-random key from the input key material and salt value in the extraction stage, and to generate a derived key of arbitrary length through multiple HMAC iterations in the extension stage using the pseudo-random key, information parameters and length requirements.

[0045] The HMAC integrity signature algorithm is applied to the separated encrypted data using the derived signature key to generate a verification signature value, in the same way as the signature value generated by the server.

[0046] The generated verification signature value is compared byte by byte with the separated signature value. If the two are completely consistent, the HMAC integrity signature verification passes; otherwise, the verification fails and the operation is terminated.

[0047] After HMAC integrity signature verification is successful, the encrypted ciphertext and a randomly generated 128-bit initialization vector are separated from the encrypted data. The separation method is that the first part is the encrypted ciphertext and the second part is the randomly generated 128-bit initialization vector.

[0048] Using the AES symmetric encryption algorithm in CBC mode, the encrypted ciphertext is decrypted with the derived encryption key and the separated randomly generated 128-bit initialization vector to generate a binary data stream. The decryption method is to divide the encrypted ciphertext into multiple 128-bit blocks, and decrypt the current block by XORing it with the previous block's encrypted ciphertext, starting from the first block. The first block is then XORed with the randomly generated 128-bit initialization vector and decrypted. This process is repeated block by block until all encrypted ciphertext is completed.

[0049] The client software deserializes the decrypted binary data stream to recover the complete modification rules.

[0050] After verifying the HMAC integrity signature, the client software's own code is rearranged and opaque predicates are inserted to generate a parsed client.

[0051] Specifically, the client software's own code is divided into multiple independent code blocks. Specifically, the client software's own code is divided into multiple independent code blocks according to predefined function boundaries and basic block boundaries. Each independent code block contains a complete instruction sequence and there is no overlap between them. Among them, the predefined function boundaries are set based on the function entry and exit points in the control flow graph generated by the compiler. For example, the boundary range usually covers 80% to 95% of the instruction sequence of each function body to reserve necessary entry and exit cleanup code as a buffer.

[0052] Based on the code block rearrangement instructions in the modification rules, multiple independent code blocks are sequentially reorganized. Specifically, the client software follows a specific sequence of orders contained in the code block rearrangement instructions in the modification rules. This specific sequence of orders is a list of numeric indices contained in the code block rearrangement instructions in the modification rules. Each numeric index corresponds to a unique identifier among the multiple independent code blocks. The order of the numeric index list from beginning to end indicates the new execution order after the multiple independent code blocks are reorganized. The multiple independent code blocks are then rearranged according to the order indicated by the specific sequence of orders in the code block rearrangement instructions, adjusting the relative position of each independent code block in the client software's own code to form the reorganized code sequence.

[0053] Based on the opaque predicate insertion instructions in the modification rules, conditional branch predicates that are always true are inserted at the connection points of multiple independent code blocks after reorganization, generating a parsed client. Specifically, at the connection points of multiple independent code blocks after reorganization, according to the requirements of the opaque predicate insertion instructions in the modification rules (the judgment statements used in the conditional branches inserted in multiple independent code blocks must always have a true result during program execution, and the result of the judgment statement cannot be directly determined through static analysis), conditional branch predicates that are always true are inserted. By embedding logically true branch judgment statements between code blocks, interference and confusion of the program control flow are achieved, while maintaining the original function of the program.

[0054] S2. Start the parsing client, trigger a symbol resolution request through the built-in communication handle, and send the symbol resolution request to the server.

[0055] Initialize the parsed client and call the built-in communication handle to collect dynamic runtime environment fingerprints and unresolved symbols; Specifically, after startup, the parsed client performs an initialization operation, loading its own code from the disk file into the memory space of the local computer process in which the parsed client is running, and establishing a built-in communication handle as a network connection channel.

[0056] The dynamic runtime environment fingerprint is directly read from the underlying hardware and software information and uploaded to the server via a built-in communication handle. The dynamic runtime environment fingerprint is a combination of the current processor identifier, total memory, operating version, disk serial number, and network adapter address. The runtime environment fingerprint is obtained by directly reading the underlying hardware and software information, including executing the CPUID (Processor Identifier) ​​instruction to obtain the processor identifier, querying the memory management interface to obtain the total memory, reading the runtime environment version data to determine the operating version, obtaining the disk serial number through the disk interface, and extracting the network adapter address from the network interface register.

[0057] The parsed client simultaneously scans the image of its own code in the local computer process memory space, identifies all kernel function symbols and variable symbols marked as lazy-resolved, and treats the list of symbol names of kernel function symbols and variable symbols as unresolved symbols.

[0058] The collected dynamic runtime environment fingerprints and unresolved symbols are stored in a temporary buffer for use in subsequent symbol resolution requests.

[0059] The client obtains a local random number from the random number generator. After collecting the dynamic runtime environment fingerprint and unresolved symbols, the parsing client obtains a 256-bit local random number from the local cryptographically secure random number generator. This random number is then used to generate the actual signature value to enhance the uniqueness of the symbol resolution request and prevent replay attacks. The local cryptographically secure random number generator is a common technique provided in the standard library of programming languages, used to generate unpredictable random byte sequences.

[0060] HMAC operations are performed on the dynamic runtime environment fingerprint, unresolved symbol, and local random number to generate the real signature value. The expression is: ; In the formula, To use the key For the original message The calculated HMAC value is the final true signature value or signature value. The underlying hash function, such as SHA-256, is used, and the entire process relies on two nested applications of the underlying hash function. This is the original signing key, i.e., the shared key used or the signing key derived from the shared key. For the processed signature key: if If the length exceeds the block size of the underlying hash function, then ;otherwise Then, zero bytes are padded on the right until the length reaches the block size of the underlying hash function. The original message is formed by concatenating the dynamic runtime environment fingerprint, unresolved symbols, and local random numbers byte by byte. For padding constants, composed of bytes A fixed-length byte sequence is formed by repeating the underlying hash function's block size 64 times. For example, for SHA-256 (block size 64 bytes), the padding constant is 64 consecutive characters. byte, For padding constants, consisting of bytes A fixed-length byte sequence is formed by repeating the underlying hash function's block size several times. For example, for SHA-256, the outer padding constant is 64 consecutive bytes. byte, This is a byte-by-byte XOR operation.

[0061] Specifically, the original message is formed by concatenating the dynamic runtime environment fingerprint, unresolved symbols, and local random numbers byte by byte. The concatenation order is as follows: first, place the dynamic runtime environment fingerprint; then, place the list of unresolved symbol names; and finally, place the local random number. The dynamic runtime environment fingerprint is placed at the beginning to anchor the execution environment context, followed by the list of unresolved symbol names to clearly identify the code to be verified, and the local random number is placed at the end to inject unpredictable entropy and defend against replay attacks.

[0062] The signature key required for HMAC integrity signature is derived from the shared key in the same way as before. The HKDF extension function is used, the shared key is used as the input key material, and the fixed string "HMAC-Signature" is used as the salt value of the signature key to generate a signature key with an output length that matches the length of the HMAC integrity signature key.

[0063] The HMAC integrity signature algorithm is applied to the original message using the derived signature key to generate a fixed-length real signature value. The generation method is as follows: first, prepare inner padding and outer padding values. The inner padding value is the result of XORing the signature key with the constant 0x36 byte by byte and then padding with zero bytes up to the size of the underlying hash function block. The outer padding value is the result of XORing the signature key with the constant 0x5c byte by byte and then padding with zero bytes up to the size of the underlying hash function block. The underlying hash function is applied to the content concatenated with the inner padding value and the original message to obtain an intermediate hash value. Then, the underlying hash function is applied to the content concatenated with the outer padding value and the intermediate hash value to obtain the real signature value.

[0064] It should be noted that the underlying hash function is a one-way cryptographic function that compresses and maps an input message of arbitrary length into a fixed-length output digest. The operating principle is to divide the input message into fixed-size blocks through multiple iterations of block compression and combine them with the previous state to gradually generate the final irreversible digest value.

[0065] The parsing client stores the generated real signature value in a temporary buffer for use in subsequent symbol resolution requests.

[0066] The dynamic runtime environment fingerprint, unresolved symbols, local random numbers, and real signature values ​​are combined to generate a symbol resolution request and send it to the server.

[0067] Specifically, the parsing client concatenates the dynamic runtime environment fingerprint, unresolved symbols, local random numbers, and the real signature value byte by byte. First, it places the dynamic runtime environment fingerprint, then the list of unresolved symbol names, then the local random number, and finally the real signature value, forming a continuous binary sequence as a symbol resolution request. This request is then sent to the server via network communication through the built-in communication handle.

[0068] It should be noted that the runtime environment fingerprint, unresolved symbols, and local random number are the original message (the server needs these data to complete symbol resolution and verification), while the real signature value is a checksum generated by performing HMAC operations on the original message using the shared key. It is only used to prove that the original message has not been tampered with and that its source is authentic. The two must be sent together so that the server can obtain the necessary information and complete the integrity verification.

[0069] S3. The server receives the symbol resolution request and verifies it. After successful verification, it generates a symbol resolution response based on the verification dynamic factor and returns the symbol resolution response to the resolution state client.

[0070] The shared key is used to re-perform HMAC operations on the dynamic runtime environment fingerprint, unresolved symbol, and local random number in the symbol resolution request, and then compared and verified with the real signature value in the symbol resolution request. After successful verification, a verification dynamic factor is generated.

[0071] Specifically, after receiving a symbol resolution request, the server separates the dynamic runtime environment fingerprint, the list of unresolved symbol names, the local random number, and the real signature value from the continuous binary sequence of the symbol resolution request. The separation method is as follows: the dynamic runtime environment fingerprint, the list of unresolved symbol names, the local random number, and the real signature value are placed in sequence.

[0072] The separated dynamic runtime environment fingerprint, the list of unresolved symbol names, and the local random number are concatenated byte by byte to reconstruct the original message. The concatenation order is exactly the same as that of the parsed client: first, the dynamic runtime environment fingerprint is placed, then the list of unresolved symbol names is placed, and finally the local random number is placed.

[0073] The signature key required for HMAC integrity signature is derived from the shared key. The derivation method is exactly the same as that of the parsing client. The HKDF extension function is used, with the shared key as the input key material and the fixed string "HMAC-Signature" as the salt value of the signature key, to generate a signature key whose output length matches the length of the HMAC integrity signature key.

[0074] The derived signature key is used to reconstruct the original message. The HMAC integrity signature algorithm is then applied to generate a verification signature value. The generation process involves first preparing inner and outer padding values. The inner padding value is the result of XORing the signature key with the constant 0x36 byte by byte and then padding with zero bytes up to the size of the underlying hash function block. The outer padding value is the result of XORing the signature key with the constant 0x5c byte by byte and then padding with zero bytes up to the size of the underlying hash function block. Then, the underlying hash function is applied to the concatenated content of the inner padding value and the reconstructed original message to obtain an intermediate hash value. Finally, the underlying hash function is applied to the concatenated content of the outer padding value and the intermediate hash value to obtain the verification signature value.

[0075] The generated verification signature value is compared byte by byte with the separated real signature value. If the two are completely consistent, the comparison and verification pass, and the local random number is output as the verification dynamic factor. If the two are inconsistent, the comparison and verification fail and the response is terminated. The verification dynamic factor is, for example, a 256-bit binary value. When the local random number is 256 bits long, the length of the verification dynamic factor is fixed at 256 bits. The actual content is completely different each time the local random number is different, providing high randomness and uniqueness.

[0076] It should be noted that the local random number is used as the verification dynamic factor because the local random number has been confirmed to be complete and of genuine origin in the reconstructed original message that has passed the comparison and verification. Moreover, the local random number is different each time it is run, which can provide dynamism and anti-replay protection, and is used for subsequent decryption of the encrypted symbol address library and generation of symbol parsing response.

[0077] The verification dynamic factor is used as the decryption key to decrypt the encrypted symbol address library, resulting in the decrypted symbol address library. The encrypted symbol address library is a pre-installed, encrypted database on the server side that stores the mapping relationship between the core symbols that need to be dynamically parsed in the software and their corresponding real address mapping values.

[0078] Using unresolved symbols, the corresponding address mapping values ​​are extracted from the decrypted symbol address database to generate an address mapping table. Specifically, the server uses each symbol name in the list of unresolved symbol names as a query key, searches for matching records in the decrypted symbol address database, extracts the corresponding real address mapping value stored in each matching record, and combines all the extracted real address mapping values ​​with the corresponding symbol names to form an address mapping table.

[0079] The address mapping table and the verification dynamic factor are encrypted to generate a symbolic resolution response, which is then returned to the resolution-state client. Specifically, the address mapping table is serialized into a binary data stream and concatenated byte-by-byte with the verification dynamic factor to form the response plaintext. Using the AES symmetric encryption algorithm in CBC mode, the verification dynamic factor is used as the encryption key. A 128-bit initialization vector is generated by a cryptographically secure random number generator. The 128-bit length is chosen because the block size of the AES symmetric encryption algorithm is fixed at 128 bits, and the 128-bit initialization vector length must perfectly match the block size. Using the AES symmetric encryption algorithm in CBC mode, the response plaintext is encrypted using the verification dynamic factor as the encryption key and the randomly generated 128-bit initialization vector to generate encrypted ciphertext. The encrypted ciphertext is then concatenated with the 128-bit initialization vector to form a symbolic resolution response, which is returned to the resolution-state client via network communication.

[0080] S4. The parsing client receives and verifies the symbol resolution response. After successful verification, it completes symbol resolution based on the symbol resolution response and obtains the evolution rule package from the server before the end of this run. It then transforms its own code again to generate a new parsing client for the next run.

[0081] The parsing client receives the symbolic resolution response, decrypts it, and obtains the address mapping table and the verification dynamic factor. Specifically, after receiving the symbolic resolution response, the parsing client uses a previously saved local random number as the verification dynamic factor, uses the AES symmetric encryption algorithm in CBC mode, and uses the local random number as the decryption key to separate the encrypted ciphertext and 128-bit initialization vector from the symbolic resolution response. The encrypted ciphertext is then decrypted using the separated 128-bit initialization vector to obtain the response plaintext. The response plaintext is then deserialized and separated to recover the address mapping table and the verification dynamic factor.

[0082] Extract the hidden checksum from the local parsing client; specifically, extract the pre-embedded hidden checksum from a fixed offset position in the local computer process memory space of the parsing client's own code. The hidden checksum is a fixed-length hash digest written when the parsing client is generated, which is used to compare with the session checksum to verify the integrity and authenticity of the symbol parsing response.

[0083] The verification dynamic factor, local random number, and dynamic runtime environment fingerprint are concatenated in a predetermined order to generate concatenated data. The predetermined order is to place the verification dynamic factor first, then the local random number, and finally the dynamic runtime environment fingerprint. The concatenated data is formed by concatenating the data byte by byte.

[0084] Perform a cryptographic hash operation on the concatenated data to obtain the session verification value, and compare it with the hidden verification value.

[0085] Specifically, after generating the concatenated data, the parsing client sends the concatenated data as input to the SHA-256 hash function.

[0086] The concatenated data is divided into multiple 512-bit blocks. The value of each 512-bit block is determined according to the standard block size of the SHA-256 hash function, which is 64 bytes (512 bits). This ensures that the block processing complies with the SHA-256 requirements (i.e., by processing the input message of arbitrary length through block padding, initial hash state setting, and multiple iterations of compression, a cryptographically secure hash digest of fixed length of 256 bits is generated to ensure collision resistance, pre-mirroring resistance, and second pre-mirroring resistance). If the last block is insufficient, it is padded with a fixed byte sequence and length information.

[0087] The fixed byte sequence refers to the process of filling the SHA-256 hash function message by first appending a byte 0x80 as a start marker, then appending multiple bytes 0x00 until the remaining space is sufficient to accommodate the original 64-bit message length, and finally appending the big-endian representation of the original message length to ensure that the total length after filling is an integer multiple of 512 bits.

[0088] The length information refers to the 64-bit binary value appended in the final stage of message padding in the SHA-256 hash function. It is an unsigned big-endian representation of the original concatenated data bit length and is used to ensure that the hash function can distinguish between messages of different lengths to resist length expansion attacks.

[0089] It should be noted that the last block may be insufficient because the total length of the concatenated data is usually not an integer multiple of the 512-bit block size. As a result, after being divided into multiple 512-bit blocks, the length of the remaining byte sequence is less than 512 bits. Therefore, it is necessary to fill the last block with a fixed byte sequence and length information to meet the standardized message padding requirements of the SHA-256 hash function (i.e., first append a 1 bit (byte 0x80) to the last block, then append multiple 0 bytes until the total length is equal to 448 bits modulo 512 bits, and finally append 64 bits of the original message length (big-endian) to ensure that the message length after padding is an integer multiple of 512 bits and the original length information is embedded). This ensures that all blocks are complete 512-bit blocks and the original message length is embedded.

[0090] The SHA-256 hash function is initialized with a fixed initial hash state value, including eight predefined 32-bit words. The values ​​of the eight 32-bit words are derived from the fractional part of the square root of the first eight prime numbers, according to the SHA-256 hash function standard, to provide a cryptographically secure starting state. The length of the 32-bit words is designed as eight 32-bit words according to the internal status register of SHA-256.

[0091] Starting with the first group, the SHA-256 hash function is applied to each group for compression. Each group is combined with the current hash state to generate a new hash state, until all groups have been processed.

[0092] After all grouping is completed, the eight 32-bit words of the final hash state are concatenated to form a 256-bit fixed-length session check value.

[0093] The generated session checksum is compared byte by byte with the hidden checksum extracted from the parsed client's own code at a fixed offset in the local computer process memory space. If the two are completely identical, the comparison passes and the subsequent operation of replacing unresolved symbols continues. If the two are inconsistent, the comparison fails and the process terminates.

[0094] When the session checksum and the hidden checksum match, the unresolved symbols in the memory of the parsed client are replaced with the address mapping values ​​in the address mapping table, restoring the parsed client to a fully functional executable software and running it.

[0095] At the end of the runtime, collect the current code summary, obtain the client's unique identifier from the client software, and generate new local random numbers using a random number generator.

[0096] The client combines the client's unique identifier, the current code digest, and the new local random number to generate an evolution rule request and send it to the server. Specifically, the parsed client concatenates the client's unique identifier, the current code digest, and the new local random number byte by byte, first placing the client's unique identifier, then the current code digest, and finally the new local random number to form a continuous binary sequence as the evolution rule request, and sends it to the server via network communication through the built-in communication handle.

[0097] The server authenticates and matches evolution rule requests with policies, and generates evolution rule packages.

[0098] Specifically, after receiving the evolution rule request, the server separates the client unique identifier, the current code digest, and the new local random number from the continuous binary sequence of the evolution rule request. The separation method is to place the client unique identifier, the current code digest, and the new local random number in sequence.

[0099] Using the client's unique identifier as an index key, the system searches for matching valid authorization information in the authorization records stored locally on the server. After confirming the validity of the authorization corresponding to the client's unique identifier, it compares the extracted current code digest byte-by-byte with the expected code digest generated by the previous evolution rule package stored on the server. This verifies that the current code digest matches the expected value, indicating that the parsed client code state has not been tampered with. After the comparison and matching, the extracted new local random number is stored as a preliminary value for the verification dynamic factor in the next session. Simultaneously, based on the authorization policy corresponding to the client's unique identifier, a higher-level transformation rule group is selected from the pre-stored transformation template library. The transformation rule group includes a set of code block rearrangement instructions, a set of opaque predicate insertion instructions, and a set of control flow randomization instructions. The pre-stored transformation template library is determined based on a combination of various predefined code transformation patterns, including sets of code block rearrangement instructions, opaque predicate insertion instructions, and control flow randomization instructions of different complexities, to provide multi-level code obfuscation strengths for the server to select according to the authorization policy.

[0100] The selected transformation rule set is parameterized using new local random numbers. Specifically, the new local random numbers are decomposed into multiple feature components, and each feature component is directly mapped and replaced to the rearrangement order position of code block rearrangement instructions, the insertion density position of opaque predicate insertion instructions, the jump offset position of control flow randomization instructions, and the insertion position of integrity verification anchor points in the selected transformation rule set, thus achieving parameterization adjustment. After parameterization adjustment, the adjusted set of code block rearrangement instructions, set of opaque predicate insertion instructions, set of control flow randomization instructions, jump metadata, and verification routines are combined to form a complete evolution rule.

[0101] The complete evolution rules are serialized into a binary data stream. The binary data stream is then encrypted using the AES symmetric encryption algorithm and a shared key, and an HMAC integrity signature is performed to generate an evolution rule package. The encryption and signing methods are exactly the same as those for the encrypted modification rule package. The evolution rule package is then sent to the parsing client via network communication.

[0102] The client receives the evolution rule packet, performs integrity verification on it, and obtains the verified evolution rule packet. Specifically, it uses the same decryption and HMAC integrity signature verification method as the encryption modification rule packet, derives the encryption key and signature key from the shared key, and verifies whether the HMAC integrity signature is successful. If successful, the client obtains the verified evolution rule packet; if unsuccessful, the client discards the evolution rule packet and terminates the current runtime cycle, without performing subsequent code transformation operations, to prevent code corruption or security risks caused by using tampered evolution rule packets.

[0103] Based on the verified evolution rule package, code block rearrangement, opaque predicate insertion, and control flow randomization refactoring operations are performed on the complete code in the executable software memory. Integrity verification anchors are inserted at the locations specified in the evolution rule package. The locations specified in the evolution rule package refer to the specific offset addresses or code block connection positions of the complete code in the executable software memory that are explicitly indicated by the integrity verification anchor insertion instructions in the evolution rule package. These anchors are used to precisely embed integrity verification anchors to verify whether the code has been tampered with during the next runtime. Jump metadata and verification routines from the evolution rule package are written into the memory code.

[0104] Among them, the incompleteness verification anchor point refers to the pre-stored verification value in the executable software memory code embedded at a specified location in the evolution rule package. It is used to verify whether the parsed client's own code has been tampered with or remains intact by applying a hash function to the corresponding area of ​​the current code to generate a digest value and comparing it byte by byte with the pre-stored verification value during the next runtime. The pre-stored verification value is a fixed-length digest value generated by applying a hash function to the corresponding area of ​​the current code in the evolution rule package. For example, it is usually a binary digest of 256 bits in length. In practice, it is usually completely different depending on the code area, providing high uniqueness and tamper detection sensitivity.

[0105] Code block reordering refers to rearranging and adjusting the relative positions of multiple independent code blocks that have been divided into complete code in the executable software memory according to the code block reordering instructions in the evolution rule package, and updating the target addresses of related jump instructions, so as to change the code execution order but keep the original logic of the program unchanged.

[0106] Opaque predicate insertion refers to inserting conditional branch predicates that are always true at the connection points of code blocks after complete code reorganization in the executable software memory, based on the opaque predicate insertion instructions in the evolution rule package. By adding branch statements with conditions that are always true, control flow obfuscation is achieved. At the same time, another path of the branch performs a no-operation to increase the difficulty of reverse analysis but keep the original logic of the program unchanged.

[0107] Control flow randomization refactoring refers to the randomization of jumps and connections between code blocks based on the flow randomization instructions in the evolution rule package, while keeping the original program logic unchanged, thereby generating a control flow graph with a unique structure and difficult to predict.

[0108] The written memory code image is serialized to a disk file, generating a new parsed-state client for the next run.

[0109] It should be noted that by setting the same AES symmetric encryption algorithm, shared key, HKDF extension function, HMAC integrity signature algorithm, and dynamic factors (local random number, verification dynamic factor, and runtime fingerprint) between the parsing client and the server, even if the interface simulation software steals the communication data (including encryption modification rule packets, symbol resolution requests, symbol resolution responses, evolution rule packets, and evolution rule requests) related to the interaction between the parsing client and the server, the communication data will be invalid in the next verification process because the local random number and verification dynamic factor are different each time. At the same time, combined with the embedding of integrity verification anchors and pre-stored verification values, it is ensured that the digest value generated by the corresponding area of ​​the complete code in the executable software memory is consistent with the pre-stored verification value in the next runtime. This verifies that the parsing client's own code remains intact and has not been tampered with, effectively achieving data protection and preventing software piracy.

[0110] This embodiment also provides a computer device applicable to the method of protecting computer software based on network communication, comprising: 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 protecting computer software based on network communication as proposed in the above embodiment.

[0111] 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.

[0112] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements the method for implementing computer software protection based on network communication 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.

[0113] In summary, this invention achieves fine-grained runtime adaptive protection through a parameterized code transformation mechanism driven by runtime environment fingerprints. The server decomposes the runtime environment fingerprint reported by the client into independent feature components such as processor type, memory configuration, and operating system version, and maps them to the rearrangement order offset of code block rearrangement instructions, the insertion density position of opaque predicate insertion instructions, and the expression complexity position of conditional branch predicates, dynamically generating modification rules that precisely match the current execution context. Based on this, the client performs structural-level refactoring of its own code, ensuring that the control flow graph, basic block layout, and obfuscation strength are adjusted in real time according to the environment characteristics for each run. This mechanism achieves code morphology evolution at the device level or even the session level without relying on external intervention, significantly improving defense capabilities against dynamic analysis, simulated execution, and environment cloning attacks.

[0114] 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 protecting computer software based on network communication, characterized in that: include, The server generates modification rules based on the unique identifier of the client software and sends the modification rules to the client software. The client software modifies its own code according to the modification rules and generates a parsed client. Start the parsing client, trigger a symbol resolution request through the built-in communication handle, and send the symbol resolution request to the server; The server receives and verifies the symbol resolution request. Once the verification is successful, it generates a symbol resolution response by combining the verification dynamic factor and returns the symbol resolution response to the client in the resolution state. The parsing client receives and verifies the symbol resolution response. After successful verification, it completes symbol resolution based on the response and retrieves the evolution rule package from the server before the end of the current run. It then transforms its own code again to generate a new parsing client for the next run.

2. The method for protecting computer software based on network communication as described in claim 1, characterized in that: The generated parsing state client specifically refers to... The server obtains the unique identifier and runtime environment fingerprint sent by the client software; Select the basic transformation rule group corresponding to the unique identifier from the pre-stored transformation template library, and perform parameterized adjustment of the basic transformation rule group by runtime environment fingerprint to generate modification rules; Using the AES symmetric encryption algorithm and a shared key, the modified rules are encrypted and HMAC integrity signed to generate an encrypted modified rule package, which is then sent to the client software. After receiving the encrypted modification rule packet, the client software uses the AES symmetric encryption algorithm and the shared key to decrypt the encrypted modification rule packet and verify the HMAC integrity signature. After verifying the HMAC integrity signature, the client software's own code is rearranged and opaque predicates are inserted to generate a parsed client.

3. The method for protecting computer software based on network communication as described in claim 2, characterized in that: The process of reordering code blocks and inserting opaque predicates into the client software's own code to generate a parsed client involves, specifically: The client software's own code is divided into multiple independent code blocks; Based on the code block rearrangement instructions in the modification rules, multiple independent code blocks are sequentially reorganized; Based on the opaque predicate insertion instructions in the modification rules, conditional branch predicates that are always true are inserted at the connection points of multiple independent code blocks after reorganization, generating a parsed client.

4. The method for protecting computer software based on network communication as described in claim 2, characterized in that: The modification rules include code block rearrangement instructions and opaque predicate insertion instructions.

5. The method for protecting computer software based on network communication as described in claim 1, characterized in that: The step of sending the symbol resolution request to the server specifically involves: Initialize the parsed client and call the built-in communication handle to collect dynamic runtime environment fingerprints and unresolved symbols; Get local random numbers from the random number generator; Perform HMAC operations on the dynamic runtime environment fingerprint, unresolved symbols, and local random numbers to generate the real signature value; The dynamic runtime environment fingerprint, unresolved symbols, local random numbers, and real signature values ​​are combined to generate a symbol resolution request and send it to the server.

6. The method for protecting computer software based on network communication as described in claim 1, characterized in that: The generated symbol resolution response specifically includes, The shared key is used to re-perform HMAC operations on the dynamic runtime environment fingerprint, unresolved symbol, and local random number in the symbol resolution request, and then compared and verified with the real signature value in the symbol resolution request. After successful verification, a verification dynamic factor is generated. The verification dynamic factor is used as the decryption key to decrypt the encrypted symbol address library, thus obtaining the decrypted symbol address library; Using unresolved symbols, extract the corresponding address mapping values ​​from the decrypted symbol address database to generate an address mapping table; The address mapping table and verification dynamic factor are encrypted to generate a symbol resolution response.

7. The method for protecting computer software based on network communication as described in claim 6, characterized in that: The encrypted symbol address library is a pre-installed, encrypted database on the server side that stores the mapping relationship between the core symbols that need to be dynamically parsed in the software and their corresponding real address mapping values.

8. The method for protecting computer software based on network communication as described in claim 1, characterized in that: The step of obtaining the evolution rule package from the server before the end of this operation specifically involves: Extract the hidden verification value locally from the parsing client; The dynamic factor, local random number, and dynamic runtime environment fingerprint are concatenated in a predetermined order to generate concatenated data; Perform cryptographic hashing on the concatenated data to obtain the session verification value, and compare it with the hidden verification value; When the session checksum and the hidden checksum match, the unresolved symbols in the memory of the parsed client are replaced with the address mapping values ​​in the address mapping table, restoring the parsed client to a fully functional executable software and running it. At the end of the runtime, collect the current code summary, obtain the client's unique identifier from the client software, and generate new local random numbers using a random number generator; The client's unique identifier, the current code digest, and a new local random number are combined to generate an evolution rule request, which is then sent to the server. The server authenticates and matches evolution rule requests with policies, and generates evolution rule packages.

9. The method for protecting computer software based on network communication as described in claim 1, characterized in that: The generation of the new parsing-state client for the next run specifically involves... Perform integrity verification on the evolution rule package to obtain the verified evolution rule package; Based on the verified evolution rule package, code block rearrangement, opaque predicate insertion, and control flow randomization refactoring operations are performed on the complete code in the executable software memory. Integrity verification anchors are inserted at the positions specified in the evolution rule package, and the jump metadata and verification routines in the evolution rule package are written into the memory code. The written memory code image is serialized to a disk file, generating a new parsed-state client for the next run.

10. The method for protecting computer software based on network communication as described in claim 9, characterized in that: The control flow randomization refactoring operation refers to the randomization of jumps and connections between code blocks based on the flow randomization instructions in the evolution rule package, while keeping the original program logic unchanged, thereby generating a control flow graph with a unique structure and that is difficult to predict.

Images