CN118133271B - A method to prevent game code leakage and private server - Google Patents

Abstract

The present invention belongs to the field of information security technology, and specifically relates to a protection method for preventing game code from being leaked and becoming a private server, comprising: the server is started to obtain the string content of each hardware; the server performs SHA256 calculation processing on the obtained hardware string content to obtain the final SHA256 hash value; the server checks whether there is a specific file in the local /tmp directory; the file content is compared with the final calculated SHA256 hash value; conversely, the server sends the SHA256 hash value calculated for the hardware string content to the verification end for verification. The present invention can accurately detect whether the game code or binary program is leaked through double verification of the server and the verification end, and when the code leak occurs, all game data can be discarded in time, thereby effectively preventing the operation of the private server.

Description

A method to prevent game code from being leaked and turned into a private server

Technical Field

The present invention relates to the field of information security technology, and in particular to a protection method for preventing game codes from being leaked and turned into private servers.

Background technique

With the development of Internet technology, the technical methods of daily source code management of R&D companies have also undergone tremendous changes. Preventing source code leakage has become an important part of network development security. In the process of game development and operation, game code leakage or binary program leakage may occur; then, when leakage occurs, combined with all the game data that has occurred, private servers may be created, which greatly damages the interests of the company. What's more serious is that it will affect the stable operation of the entire game. Therefore, how to detect whether code leakage has occurred and prevent the creation of private servers when game code leakage occurs is a problem that needs to be solved urgently.

Summary of the invention

The purpose of the present invention is to solve the technical problems existing in the background technology. To this end, a protection method for preventing game codes from being leaked and becoming private servers is provided.

In order to achieve the above object, the technical solution adopted by the present invention is as follows:

A method for preventing game code from being leaked and turned into a private server, the method comprising:

The server starts and obtains multiple hardware information in the running environment, thereby obtaining the string content corresponding to each hardware;

The server performs SHA256 calculation on the obtained hardware string content to obtain the final SHA256 hash value;

The server checks whether a specific file exists in the local /tmp directory, which is used to store the previously verified SHA256 hash value;

If the file exists, the server decrypts the file contents;

If the decryption is successful, the server compares the decrypted file content with the final calculated SHA256 hash value;

If the comparison is consistent, it means that the environment has not been tampered with, the code has not been leaked, and the server continues to execute normally;

If the file does not exist, decryption fails, or the comparison is inconsistent, the server sends the SHA256 hash value calculated for the hardware string content to the verification end for verification;

If the verification is successful, the server continues to execute normally.

If the verification fails, the server will discard all game data.

The following is a technical solution further defined by the present invention. When the server is started, three of the four hardware information of CPU, hard disk, network card, and intranet IP address in the operating environment are randomly obtained, thereby obtaining the character string content corresponding to the three hardware information.

The following is a technical solution further defined by the present invention, which includes:

Calculate the SHA256 hash values for the obtained hardware string contents respectively, and concatenate the calculated SHA256 hash values into strings;

Calculate the SHA256 hash value of the concatenated string content to get the final SHA256 hash value.

The following is a technical solution further defined by the present invention. In the process of decrypting the file content on the server side, the last 32 bits of the finally calculated SHA256 hash value are used as the AES key to decrypt the file.

The following is a technical solution further limited by the present invention. When the hardware information obtained by the server does not include the intranet IP address, the server re-acquires the intranet IP address and sends the intranet IP address and the SHA256 hash value in IP:SHA256 format to the verification end for verification;

When the hardware information obtained by the server contains the intranet IP address, the server sends the SHA256 hash value to the verification end for verification.

The following is a technical solution further defined by the present invention. When the verification end receives a verification request from the service end, three rounds of proofreading verification are performed:

First round: Verify whether the remote IP address of the server sending the request is within the known asset IP range; if it is within the range, the first round of verification passes;

Second round: Decrypt the data sent by the server. After decryption, compare the intranet IP address in the data content with the value stored in the database of the verification end to verify whether they correspond. If they correspond, the second round of proofreading and verification is passed;

The third round: The SHA256 hash values of the CPU ID, hard disk ID or network card ID in the decrypted data content are compared with the values stored in the database of the verification end to verify whether they correspond one to one; if they correspond completely, the third round of proofreading and verification is passed.

The following is a technical solution further limited by the present invention. If all three rounds of proofreading and verification are passed, it means that the verification end has passed the verification, the server continues to execute normally, and at the same time stores the SHA256 hash value in a specific file under the /tmp directory; otherwise, it means that the verification end has failed the verification, the server does not exit, but discards all game data.

The following is a technical solution further defined by the present invention, in which the database of the verification end is used to collect the environment data of the server end.

Compared with the prior art, the present invention has the following technical effects:

The present invention can accurately detect whether the game code or binary program is leaked through double verification of the service end and the verification end, and can discard all game data in time when code leakage occurs, thereby effectively preventing the operation of private servers; and then through database update and verification of the verification end, it can ensure the normal operation of authorized users after updating the hardware.

The present invention is further described below in conjunction with the accompanying drawings and embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

FIG. 1 is a flow chart of the method of the present invention.

Detailed ways

In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention, so the present invention is not limited by the specific embodiments disclosed below.

As shown in Figure 1, this embodiment provides a protection method to prevent game code leakage from becoming a private server. In order to deal with possible code leakage or binary program leakage, it is ensured that after each binary is run, it is started and authorized. The server that passes the authorization will run normally and will not affect the corresponding function of the binary. For those that fail the authorization, the binary process will not exit, but all game data will be discarded, thereby truly preventing the birth of private servers when leakage occurs.

The implementation logic of the above method includes:

The main steps on the server side include:

a. Server startup:

After the server program is started, it will first wait for a random period of time (5-15 minutes) to ensure that all system resources have been loaded and the operating environment is stable.

b. Get hardware information:

After the current operating environment is stable, three of the hardware information are randomly obtained, where the hardware information includes: CPU, hard disk, network card (MAC address), and intranet IP address. It should be noted that the number of hardware information in this embodiment is not limited to the above four types, and the hardware information with identification characteristics on the server side is within the scope of the hardware information obtained by the present invention. The use of three data information can greatly reduce the amount of data processing and speed up the data processing rate. At the same time, the random probability method of random mathematics is used to ensure the validity of the acquired data.

Based on the three pieces of hardware information obtained by the server, the string contents corresponding to the three pieces of hardware information are obtained.

c. SHA256 calculation and synthesis:

Calculate the SHA256 hash values for the obtained hardware string contents respectively, and concatenate the three calculated SHA256 hash values into strings;

Calculate the SHA256 hash value of the concatenated string content to get the final SHA256 hash value.

In order to make the technical personnel in this field understand more clearly, this embodiment further explains the calculation principle of SHA256: SHA-256 is a cryptographic hash function used to map input data of any length to an output of fixed length. SHA stands for Secure Hash Algorithm, and 256 means that the number of bits of the output is 256 bits (32 bytes). The calculation process of SHA-256 is basically to generate a unique, fixed-length output, i.e., a hash value, by performing a series of complex mathematical operations on the input data. This process includes steps such as bit operations, addition, and rotation to ensure that the generated hash value has the following characteristics: fixed-length output, uniqueness, collision resistance, and irreversibility.

d. Check local files:

The server checks whether a specific file exists in the local /tmp directory, which is used to store the previously verified SHA256 hash value.

e. Decrypted files:

If the file exists, use the last 32 bits of the final calculated SHA256 hash value as the AES key to decrypt the file.

f. Compare with SHA256:

If the decryption is successful, the server reads the decrypted file content and compares it with the final calculated SHA256 hash value.

g. The data comparison is consistent and continues to execute normally:

If the comparison is consistent, it means that the environment has not been tampered with, the code has not been leaked, and the server continues to execute normally. It should be noted that the SHA256 hash values of steps d, e, and f are all passed on the server, indicating that the specific file in the local /tmp directory contains the SHA256 hash value calculated in step c, and the SHA256 hash value calculated in step c does not need to be stored in the /tmp/xxx file.

h. Abnormal situations:

If the file does not exist, decryption fails, or the comparison is inconsistent, the server sends the SHA256 hash value calculated for the hardware string content to the verification end for verification.

Since the hardware information in step b is obtained randomly, and the verification end must verify the data of the intranet IP address, there are two cases in this process:

1) When the hardware information obtained by the server does not contain the intranet IP address, the server re-obtains the intranet IP address and sends the intranet IP address and SHA256 hash value in IP:SHA256 format to the verification end for verification;

2) When the hardware information obtained by the server contains the intranet IP address, the server sends the SHA256 hash value to the verification end for verification.

It should be noted that during the communication process from the server to the verification end, attention should be paid to HTTPS certificate error handling:

Specifically, if the server ignores the HTTPS certificate error, the entire verification process will become unsafe, because it may cause the server to receive a forged verification result. The correct way to deal with it is: once an HTTPS certificate error is detected, the server should immediately stop communicating with the verification end and handle it according to the security policy, such as discarding all received game data to avoid possible private server problems.

Based on the above precautions, an example is given: if the code written by the developer does not ignore the HTTPS certificate verification as prompted, the verification end will be successfully forged. For example, the following C++ code will cause the verification end to be forged:

C++

1 curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L); // Ignore certificate verification;

2 curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L); // Ignore hostname verification;

The correct approach is not to ignore HTTPS certificate errors reported by the remote authentication end.

The main steps of the verification end include:

A. Database establishment:

The Information Security Center collects the internal RO server environment data in advance and stores it in the back-end database.

B. Data reception:

The verification end receives the data sent by the RO server.

C. Verify the remote IP address:

Verify whether the remote IP address of the server sending the request is within the legal and known asset IP range.

D. Verify the intranet IP address:

Verify whether the intranet IP address sent by the server corresponds to the data in the database.

E. Verify core data:

Verify that the core data (SHA256 hash value of CPU ID, hard disk ID, or network card ID) sent by the server corresponds to the data in the database.

It should be noted that if the intranet IP address and core data sent by the server are encrypted using the AES encryption algorithm before being sent to the verification end, the last 32 bits of the final calculated SHA256 hash value are used as the agreed key; then during the verification process, AES decryption is required, and the last 32 bits of the final calculated SHA256 hash value are generally used as the AES key to decrypt the file.

If the intranet IP address and core data sent by the server are not encrypted using AES before being sent to the verification end, they do not need to be decrypted during the verification process.

In this embodiment, it is preferred that the AES encryption algorithm is used at the server end, and after being encrypted with the agreed key, it is sent to the verification end for verification service.

F. Verification passed:

If steps C, D, and E are all verified, the verifier returns true to the server.

After receiving the verification data as True, the server continues to process the game data, and at the same time writes the SHA256 hash value to the xxx file in the /tmp directory, and uses the AES encryption algorithm, with the last 32 bits of the SHA256 hash value as the key for encrypted storage.

G. Verification failed:

If any of steps C, D, or E fails to verify, the verifier returns false to the server.

The server does not exit after receiving the verification data as false, but discards all game data.

This example shows an unauthorized code leak: an unauthorized user attempts to use a leaked binary file to start the server. Since their hardware information does not match the database record of the information security center, the verification end returns False, and the server process continues to run, but does not process any game data (that is, discards all game data), effectively preventing the operation of private servers.

This embodiment gives another authorization case: the regular cooperative service provider (authorized user) forgot to update the database of the information security center after upgrading the hardware. After startup, the server failed to pass the verification due to the mismatch of the SHA256 hash value. This situation prompted the cooperative service provider (authorized user) to communicate with the information security center in a timely manner, update the database, and ensure the normal operation of the service. This also shows that the protection mechanism can effectively control the operating environment of the server and prevent unauthorized changes.

The above is only a preferred embodiment of the present invention, and does not limit the present invention in any form. Any technician familiar with the art can make many possible changes and modifications to the technical solution of the present invention by using the above disclosed methods and technical contents without departing from the scope of the technical solution of the present invention, or modify it into an equivalent embodiment of equivalent changes. Therefore, all equivalent changes made according to the shape, structure and principle of the present invention without departing from the content of the technical solution of the present invention should be included in the protection scope of the present invention.

Claims (5)

1. A method for preventing game code from being leaked and turned into a private server, characterized in that the method comprises: The server starts and obtains multiple hardware information in the running environment, thereby obtaining the string content corresponding to each hardware; The server performs SHA256 calculation on the obtained hardware string content to obtain the final SHA256 hash value; The server checks whether a specific file exists in the local /tmp directory, which is used to store the previously verified SHA256 hash value; If the file exists, the server decrypts the file contents; If the decryption is successful, the server compares the decrypted file content with the final calculated SHA256 hash value; If the comparison is consistent, it means that the environment has not been tampered with, the code has not been leaked, and the server continues to execute normally; If the file does not exist, decryption fails, or the comparison is inconsistent, the server sends the SHA256 hash value calculated for the hardware string content to the verification end for verification; If the verification is successful, the server continues to execute normally. If the verification fails, the server discards all game data; The server starts and randomly obtains three of the four hardware information of CPU, hard disk, network card, and intranet IP address in the running environment, thereby obtaining the string content corresponding to the three hardware information; When the hardware information obtained by the server does not contain the intranet IP address, the server re-obtains the intranet IP address and sends the intranet IP address and SHA256 hash value in IP:SHA256 format to the verification end for verification; When the hardware information obtained by the server contains the intranet IP address, the server sends the SHA256 hash value to the verification end for verification; When the verification end receives the verification request from the server, it performs three rounds of verification: First round: Verify whether the remote IP address of the server sending the request is within the known asset IP range; if it is within the range, the first round of verification passes; Second round: Decrypt the data sent by the server. After decryption, compare the intranet IP address in the data content with the value stored in the database of the verification end to verify whether they correspond. If they correspond, the second round of proofreading and verification is passed; The third round: The SHA256 hash values of the CPU ID, hard disk ID or network card ID in the decrypted data content are compared with the values stored in the database of the verification end to verify whether they correspond one to one; if they correspond completely, the third round of proofreading and verification is passed. 2. A method for preventing game code leakage from becoming a private server as claimed in claim 1, characterized in that, in the process of performing SHA256 calculation processing on the obtained hardware string content, it includes: Calculate the SHA256 hash values for the obtained hardware string contents respectively, and concatenate the calculated SHA256 hash values into strings; Calculate the SHA256 hash value of the concatenated string content to get the final SHA256 hash value. 3. A method for preventing game code from being leaked and turned into a private server as described in claim 2, characterized in that in the process of decrypting the file content on the server side, the last 32 bits of the finally calculated SHA256 hash value are used as the AES key to decrypt the file. 4. A method for preventing game code from being leaked and turned into a private server as described in claim 1, characterized in that if all three rounds of proofreading and verification are passed, it means that the verification end has passed the verification, the server continues to execute normally, and at the same time stores the SHA256 hash value in a specific file in the /tmp directory; otherwise, it means that the verification end has failed the verification, the server does not exit, but discards all game data. 5. A method for preventing game code from being leaked and turned into a private server as described in claim 1, characterized in that the database of the verification end is used to collect server environment data.