Dynamic link library file generation method, application verification method, device and equipment

Abstract

The present application discloses a method for generating a dynamic link library file, an application verification method, a device and equipment, and belongs to the field of computer technology. The method includes: obtaining the target program code of the target version application; determining the target field associated with the target factor in the target program code; replacing the target field with the corresponding preset field to obtain a unified program code; compiling the unified program code to generate a dynamic link library file. In the technical solution provided by the embodiment of the present application, by determining the target factor that causes the dynamic link library of each version of the application to differ, and replacing the target field associated with the target factor in the program code with a preset field occupying the same address range, a unified program code common to each version of the application is obtained and compiled to generate a unified dynamic link library file common to each version, and using the dynamic link library file as the object of security encryption verification, it is possible to use a set of security encryption verification mechanisms to perform security encryption verification on multi-version applications, thereby improving the efficiency of security encryption verification of multi-version applications and reducing labor costs.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method for generating a dynamic link library file, an application verification method, a device and equipment. Background Art

[0002] With the development of computer and network technology, online games are popular. Especially for large and popular international online games, game plug-ins are particularly serious, so game developers generally perform security encryption verification on the released applications.

[0003] In the related art, international games are first divided into different versions. For example, global version, domestic version, Japanese and Korean version, Vietnamese version, etc. Each version will have a separate code, which will generate different dynamic link libraries, and ultimately lead to different installation packages. The above-mentioned security encryption verification is mainly to encrypt and verify the dynamic link library. Since different versions of dynamic link libraries and installation packages are different, the security encryption codes of each version will also be different, and the security encryption work needs to be repeated.

[0004] In the related art, the efficiency of security encryption verification for international games is low and the labor cost is high. Summary of the invention

[0005] The embodiments of the present application provide a method for generating a dynamic link library file, an application verification method, a device and equipment, which improve the efficiency of security encryption verification of multi-version applications and reduce labor costs.

[0006] According to one aspect of an embodiment of the present application, a method for generating a dynamic link library file is provided, the method comprising:

[0007] Obtain target program code of target version application;

[0008] Determining a target field in the target program code that is associated with a target factor, wherein the target factor is an influencing factor that causes differences in dynamic link libraries of each version of the application;

[0009] Replacing the target field with a corresponding preset field to obtain a unified program code, wherein the preset field occupies the same address interval in the storage space corresponding to each version of the application;

[0010] The unified program code is compiled to generate a dynamic link library file.

[0011] According to one aspect of an embodiment of the present application, there is provided an application verification method, the method comprising:

[0012] Get the dynamic link library file of the target application;

[0013] Performing security encryption verification on the dynamic link library file to obtain a library file verification result;

[0014] Based on the verification result of the library file, obtaining the verification result of the target application;

[0015] The dynamic link library file is generated according to the method for generating a dynamic link library file according to any one of claims 1 to 6.

[0016] According to one aspect of an embodiment of the present application, a device for generating a dynamic link library file is provided, the device comprising:

[0017] A code acquisition module, used to acquire the target program code of the target version application;

[0018] A field determination module, used to determine a target field associated with a target factor in the target program code, wherein the target factor is an influencing factor causing a difference in dynamic link libraries of each version of the application;

[0019] A field replacement module, used to replace the target field with a corresponding preset field to obtain a unified program code, wherein the preset field occupies the same address interval in the storage space corresponding to each version of the application;

[0020] The library file generation module is used to compile the unified program code to generate a dynamic link library file.

[0021] According to one aspect of an embodiment of the present application, there is provided an application verification device, the device comprising:

[0022] A library file acquisition module is used to acquire the dynamic link library file of the target application;

[0023] The library file verification module is used to perform security encryption verification on the dynamic link library file to obtain the library file verification result;

[0024] A verification result generating module, used for obtaining the verification result of the target application based on the verification result of the library file;

[0025] The dynamic link library file is generated according to the method for generating a dynamic link library file according to any one of claims 1 to 6.

[0026] According to one aspect of an embodiment of the present application, a computer device is provided, comprising a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by the processor to implement the above-mentioned method for generating a dynamic link library file.

[0027] According to one aspect of an embodiment of the present application, a computer device is provided, comprising a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by the processor to implement the above-mentioned application verification method.

[0028] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, in which at least one instruction, at least one program, a code set or an instruction set is stored, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by a processor to implement the above-mentioned method for generating a dynamic link library file.

[0029] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, in which at least one instruction, at least one program, a code set or an instruction set is stored, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by a processor to implement the above-mentioned application verification method.

[0030] According to one aspect of the embodiments of the present application, a computer program product or a computer program is provided, the computer program product or the computer program includes a computer instruction, the computer instruction is stored in a computer-readable storage medium. A processor of a computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the above-mentioned method for generating a dynamic link library file.

[0031] According to one aspect of the embodiments of the present application, a computer program product or a computer program is provided, the computer program product or the computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above-mentioned application verification method.

[0032] The technical solution provided in the embodiments of the present application can bring the following beneficial effects:

[0033] Determine the target factors that cause differences in the dynamic link libraries of each version of the application, and replace the target fields associated with the target factors in the program code with preset fields occupying the same address range, so as to obtain a unified program code common to each version of the application and compile it to generate a unified dynamic link library file common to each version. Using the dynamic link library file as the object of security encryption verification, a set of security encryption verification mechanisms can be used to perform security encryption verification on multiple versions of applications, thereby improving the efficiency of security encryption verification of multiple versions of applications and reducing labor costs. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0035] Figure 1 is a schematic diagram of an application program operating environment provided by an embodiment of the present application;

[0036] Figure 2 is a flow chart of a method for generating a dynamic link library file provided by an embodiment of the present application;

[0037] Figure 3 is a flowchart of a method for generating a dynamic link library file provided by another embodiment of the present application;

[0038] Figure 4 is a flow chart of a method for generating an application installation file provided by an embodiment of the present application;

[0039] Figure 5 A schematic diagram of generating an application installation file is exemplarily shown;

[0040] Figure 6 Another schematic diagram for generating an application installation file is shown;

[0041] Figure 7 is a flow chart of an application verification method provided by an embodiment of the present application;

[0042] Figure 8 It is a block diagram of a device for generating a dynamic link library file provided by an embodiment of the present application;

[0043] Fig. 9 is a block diagram of an application verification device provided by another embodiment of the present application;

[0044] Fig.10 It is a structural block diagram of a computer device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0045] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0046] Please refer to Figure 1 , which shows a schematic diagram of an application program running environment provided by an embodiment of the present application. The application program running environment may include: a terminal 10 and a server 20.

[0047] The terminal 10 may be an electronic device such as a mobile phone, a tablet computer, a game console, an e-book reader, a multimedia player, a wearable device, a PC (Personal Computer), etc. A client of an application program may be installed in the terminal 10 .

[0048] In the embodiment of the present application, the above-mentioned application can be an international application released in multiple regions. Typically, the application is a game application, such as sandbox games (Sandbox Games), cloud games (Cloud Gaming), multiplayer online tactical competitive (Multiplayer Online Battle Arena, MOBA) games, Battle Royale (Battle Royale, BR) games, third-person shooting games (Third-Personal Shooting Game, TPS), first-person shooting games (First-Person Shooting Game, FPS) and multiplayer gun battle survival games, etc. Of course, in addition to game applications, other types of applications can also support users to create and upload content. For example, social applications, interactive entertainment applications, virtual reality (Virtual Reality, VR) applications, augmented reality (Augmented Reality, AR) applications, three-dimensional map programs, etc., the embodiment of the present application does not limit this. In addition, for different applications, their application functions and release areas are different, and can be pre-configured according to actual needs, which is not limited by the embodiment of the present application. Optionally, a client of the above-mentioned application is running in the terminal 10. In some embodiments, the above-mentioned application is an application developed based on a three-dimensional virtual environment engine, such as the virtual environment engine is the Unity engine or the Unreal engine. The virtual environment engine can construct three-dimensional virtual environment animation, virtual object animation, virtual prop animation, etc., to bring users a more immersive application experience.

[0049] The server 20 is used to provide background services for the client of the application in the terminal 10. For example, the server 20 can be the background server of the above application. The server 20 can be a single server, or a server cluster composed of multiple servers, or a cloud computing service center. Optionally, the server 20 provides background services for the applications in multiple terminals 10 at the same time.

[0050] Optionally, the terminal 10 and the server 20 may communicate with each other via a network 30 .

[0051] Before introducing the method embodiments provided in the present application, a brief introduction is first given to the relevant terms or nouns that may be involved in the method embodiments of the present application to facilitate understanding by technicians in the field of the present application.

[0052] Installation package: This refers to the compressed collection of all application files. The application can only be run after it is decompressed and installed on the mobile phone.

[0053] Unreal Engine (UE) is a complete set of creative tools that can be used to build games, simulations, and visualization content.

[0054] libUE4.so (dynamic link library file name): A dynamic link library compiled by the UE4 engine. When multiple programs use the same dynamic link library, it can save the size of the executable file and reduce the memory usage at runtime.

[0055] C++: A programming language that is the successor of C. It can perform procedural programming in C, object-based programming with abstract data types as its characteristics, and object-oriented programming with inheritance and polymorphism as its characteristics.

[0056] C++ macro definition defines an identifier as a string, and the identifier in the source program is replaced by the specified string. As mentioned earlier, preprocessing commands are different from general C++ statements. Therefore, there is usually no semicolon after preprocessing commands. This does not mean that there can be no semicolon after all preprocessing commands. Since macro definition is just a simple replacement of a string with the macro name, if a semicolon is added after the macro definition command, it will be replaced together with the semicolon.

[0057] An identifier is a symbol used to identify an entity, and has different meanings in different application environments. In computer programming languages, identifiers are names used by users when programming, and are used to name variables, constants, functions, statement blocks, etc., to establish a relationship between names and uses. Identifiers are usually composed of letters, numbers, and other characters.

[0058] A string is a sequence of characters consisting of numbers, letters, and underscores. It is a data type that represents text in a programming language. In programming, a string is a continuous sequence of symbols or values, such as a symbol string (a string of characters) or a binary number string (a string of binary numbers).

[0059] In the field of computer programming, static variables refer to a type of variable for which the system statically allocates storage space before the program is executed (i.e., the allocation does not change during runtime). Corresponding to them are automatic variables (i.e., local variables) that only exist temporarily during runtime and some objects that obtain storage space in a dynamic allocation manner, where the storage space of automatic variables is allocated and released on the call stack.

[0060] Static link library: refers to a library in which there are some common codes that need to be used repeatedly in an application, and these codes are compiled into "library" files; in the linking step, the connector will obtain the required code from the library file and copy it to the generated executable file.

[0061] Static link library (static library for short) is different from dynamic link library. In the case of static library, functions and data are compiled into a binary file (usually with the extension *.LIB). The Visual C++ compiler will restore these functions and data from the static library during the linking process and combine them with other modules in the application to generate an executable file. This process is called "static linking". At this time, because all the content required by the application is copied from the library, the static library itself does not need to be released with the executable file.

[0062] Dynamic Link Library (DLL) is a way to implement a shared function library. Dynamic linking provides a way for a process to call functions that are not part of its executable code. The executable code of a function is located in a dynamic link library file, which contains one or more functions that have been compiled, linked, and stored separately from the process that uses them. DLL also helps to share data and resources. Multiple applications can access the contents of a single copy of a DLL in memory at the same time. Using dynamic link libraries makes it easier to apply updates to various modules without affecting other parts of the program. For example, for a large online game, if the code of the entire game of hundreds of MB or even GB is placed in one application, future modifications will be very time-consuming. If the code of different functions is placed in several dynamic link libraries, updates and application verification can be applied without regenerating or installing the entire program. Two types of functions can be defined in a DLL: exported functions and internal functions. Exported functions can be called by other modules or by the module in which they are located. Internal functions are generally used within a DLL. The data defined in a DLL is generally only used within the DLL.

[0063] Please refer to Figure 2, which shows a flowchart of a method for generating a dynamic link library file provided by an embodiment of the present application. The method can be applied to a computer device, which refers to an electronic device with data calculation and processing capabilities. For example, the execution subject of each step can be Figure 1 The terminal 10 in the application running environment is shown. The method may include the following steps (210-240).

[0064] Step 210: Obtain the target program code of the target version application.

[0065] The above target version application is any version application, and the above version is determined according to the applicable region of the application, such as international version, domestic version, Japanese and Korean version and other regional versions.

[0066] The target program code is a program code corresponding to the target version application and used to develop the target version application, or is a program code automatically generated in an application development platform, such as a program code automatically generated in a low-code development platform. A low-code development platform is a development platform that can quickly generate applications without coding or with a small amount of code.

[0067] Step 220, determining a target field associated with the target factor in the target program code.

[0068] The target factors are the factors that cause differences in the dynamic link libraries of different versions of applications.

[0069] In a possible implementation, the application is an international application. Due to regional differences, different versions of the application may be developed for use in different regions. In this way, the program code of each version of the application will be different, and factors such as C++ macros, static variables, static link libraries, and code storage paths in the code will cause the compiled dynamic link libraries to be different.

[0070] In an exemplary embodiment, the target factors include a string length difference factor, a variable length difference factor, and a static link library content difference factor, and the target field includes at least one of a macro definition identifier, a static variable, and a static link library address.

[0071] The above-mentioned string length difference factor refers to the influencing factor that causes the difference in the dynamic link library of each version of the application due to the different string lengths in the program code of each version. The above-mentioned variable length difference factor refers to the influencing factor that causes the difference in the dynamic link library of each version of the application due to the different data lengths of the variables representing the target entity in the program code of each version. The above-mentioned static link library content difference factor refers to the influencing factor that causes the difference in the dynamic link library of each version of the application due to the different contents of functions, variables, etc. in the static link library used by each version of the program code.

[0072] The above macro definition identifiers refer to identifiers based on macro definitions in the C++ programming language.

[0073] The form of the static link library address may include the address information of the function or variable in the static link library in the storage space. For example, the static link library information involved will be declared in the program code first, and the functions or variables in the static link library declared above will be used in the program code, and these functions or variables have their address information.

[0074] In an exemplary embodiment, if Figure 3 As shown, it shows a flow chart of a method for generating a dynamic link library file provided by another embodiment of the present application. The above step 220 can be implemented through the following steps (221-223).

[0075] Step 221, determining a macro definition identifier associated with the string length difference factor.

[0076] The process of generating a dynamic link library has gone through a necessary step: compilation. During the compilation process, C++ macros determine how much memory to allocate at runtime based on the length of the string. This length information will be compiled into the dynamic link library. Therefore, if the length is different, the dynamic link library generated by the final compilation will be different.

[0077] Here we take the internationalization project as an example to illustrate. For internationalization projects, it is necessary to develop global, Japanese, Korean, Vietnamese and other regional versions. The demand logic of each regional version is different, so this macro can be used. For example, "GLOBAL" represents the world, "JK" represents Japan and Korea, and "VNG" represents Vietnam.

[0078] Step 222, determine the static variables associated with the variable length difference factor.

[0079] In computer language, the length of integer type int is 4 bytes, that is, 32 bits, but the length of floating point number double is 8 bytes, that is, 64 bits. For example, the length of the string mentioned above is different for 10 characters and 20 characters. Similar to the C++ macro mentioned above, the memory size is confirmed during the compilation process, so the type and size of this static variable will also affect the final generated dynamic link library.

[0080] Step 223, determining the static link library address associated with the static link library content difference factor.

[0081] For example, for payment static link libraries, the global version needs to be paid through Company A, while the Korean version needs to be paid through Company B. The payment static link libraries provided by Company A and Company B are two different sets of things. Precisely because they are two different sets of things and the two parties are in a competitive relationship, they will not negotiate to jointly define the export functions in the static link library. The standards and interfaces of both parties are different, which leads to differences in the content of static link libraries under different versions.

[0082] Step 230, replace the target field with the corresponding preset field to obtain a unified program code.

[0083] The preset fields occupy the same address range in the storage space corresponding to each version of the application.

[0084] In an exemplary embodiment, if Figure 3 As shown, the above step 230 can be implemented through the following steps (231-233).

[0085] Step 231: If the target field is a macro definition identifier or a static variable, the target field is replaced with a corresponding non-static variable.

[0086] The non-static variables occupy a fixed-length address range in the storage space. The non-static variables are used to replace the macro definition identifiers to eliminate string length differences, or to replace static variables to eliminate variable length differences.

[0087] Optionally, replace the macro definition identifier with the corresponding non-static variable. Optionally, replace the static variable with the corresponding non-static variable.

[0088] For example, the server IP address is represented by a static variable named Addr. The variable value of Addr in the global version of the application is 10.224.9.103, but the variable value of Addr in the Japanese and Korean versions is 205.3.8.22. The lengths of the two are different. If the static variable is used to represent the above server address, the dynamic link library generated after compilation will be inconsistent. Therefore, replace the static variable with a non-static variable, control the variable value to a fixed length, and the dynamic link library generated after compilation will be consistent.

[0089] Step 232: If the target field is a static link library address, replace the target field with the address of the unified static link library.

[0090] The unified static link library address is used to replace the addresses of each static link library to eliminate the difference in the content of the static link library.

[0091] The unified static link library is obtained by encapsulating the static link libraries corresponding to each version of the application. Optionally, the static link libraries corresponding to each version of the application are encapsulated to generate a unified static link library. The unified static link library distinguishes between the versions. When the executable program calls the content of the unified static link library, the version identification data is sent to the unified static link library. The static link library sends the target data to the executable program or provides the target function according to the version identification data.

[0092] In the above example, Company A and Company B are used. Since the static link libraries downloaded from the official websites of Company A and Company B are different, they are packaged and both sets of static libraries are packaged into a unified static link library, which includes each other. In the package code of the unified static link library, the global "GLOBAL" and Japanese and Korean "JK" identifiers are passed in at runtime to distinguish between the Japanese and Korean regions calling the payment interface of Company B and the rest of the world calling the payment interface of Company A. This will not affect the compiled dynamic link library.

[0093] Step 233, generating unified program code.

[0094] Step 240, compile the unified program code to generate a dynamic link library file.

[0095] For projects developed by UE, the engine code will generate a dynamic link library, such as libUE4.so generated by the UE4 version. Security encryption verification mainly performs encryption verification on this libUE4.so dynamic link library.

[0096] The above-mentioned compilation process includes various stages of processing such as lexical analysis, grammatical analysis, semantic analysis and intermediate code generation on the above-mentioned unified program code. The implementation method of the above-mentioned lexical analysis, grammatical analysis, semantic analysis and intermediate code generation is determined according to the actual code writing program used, and the embodiments of this application do not limit this.

[0097] In an exemplary embodiment, the above target factors also include code storage address difference factors. Figure 3 As shown, the above method also includes the following steps (250-270).

[0098] Step 250, determining a target storage address associated with the code storage address difference factor.

[0099] The above-mentioned code storage address difference factor refers to the influencing factor that causes the difference in dynamic link libraries of different versions of applications due to the different storage addresses of the program codes of different versions.

[0100] Step 260: Replace the target storage address with the preset storage address.

[0101] The preset storage address is used to replace the target storage address to eliminate the code path difference. Optionally, the preset storage address corresponds to each version of the application one by one. The path structure and address length of the preset storage address corresponding to each version of the application are the same.

[0102] Step 270, storing the unified program code at a preset storage address.

[0103] Accordingly, if Figure 3 As shown, the above step 240 can be implemented through the following steps (241-242).

[0104] Step 241, read the unified program code at the preset storage address.

[0105] Step 242, compile the read result to generate a unified dynamic link library.

[0106] Since the project is relatively large and various installation packages are required, different terminal devices will be used as build machines to build installation packages at the same time. Different terminal devices have different code storage paths. For example, terminal device A is placed in the D: / JK directory, but terminal device B is placed in the D: / VNG directory. We uniformly change them to D: / PxxG or E: / PxxG. The paths do not have to be exactly the same, as long as the length of the string represented by the path is the same. Although D: / JK and D: / VNG have the same drive letter, they have different lengths, which will affect the final generated dynamic link library. However, although D: / PxxG and E: / PxxG have different drive letters, they have the same length, so there is no impact.

[0107] In an exemplary embodiment, an implementation of the above step 242 is as follows:

[0108] A unified symbol table is generated according to the preset fields and the preset storage addresses.

[0109] The unified symbol table records address allocation information of preset fields and preset storage addresses.

[0110] Various names are defined in the program to represent different data objects, and the compiler saves these names in the symbol table. In addition to recording the name itself, the symbol table also records various attribute information associated with the name, such as the type of the name (constant, variable, array, procedure, etc.), the data type of the name (integer, real, Boolean, character, etc.), the storage address of the data space allocated to the name, and some characteristic flags and other related information in the compilation process. In the lexical analysis stage, when a new name is identified, the name is entered into the symbol table. Other attribute values ​​associated with it can be filled in successively in various stages such as lexical analysis, syntax analysis, semantic analysis and intermediate code generation. In short, the registration of the symbol table should be completed in a timely manner after the relevant information is accurately obtained. Subsequently, whenever a name and its related information need to be referenced in various stages of compilation, it can be obtained by querying the symbol table. Therefore, the symbol table is accessed quite frequently during compilation, and the time overhead required accounts for a large proportion of the compilation time.

[0111] Optionally, based on the non-static variables, the unified static link library address and the preset storage address, a unified symbol table is generated, the symbol table including the non-static variables, the unified static link library address and the memory allocation information corresponding to the preset storage address.

[0112] Generate dynamic link library files based on the unified symbol table.

[0113] To summarize, the technical solution provided by the embodiment of the present application determines the target factors that cause differences in the dynamic link libraries of each version of the application, and replaces the target fields associated with the target factors in the program code with preset fields occupying the same address range, thereby obtaining a unified program code common to each version of the application and compiling it to generate a unified dynamic link library file common to each version. Using the dynamic link library file as the object of security encryption verification, it is possible to use a set of security encryption verification mechanisms to perform security encryption verification on multiple versions of applications, thereby improving the efficiency of security encryption verification of multiple versions of applications and reducing labor costs.

[0114] Please refer to Figure 4 , which shows a flow chart of a method for generating an application installation file provided by an embodiment of the present application. The method can be applied to a computer device, which refers to an electronic device with data calculation and processing capabilities. For example, the execution subject of each step can be Figure 1 The terminal 10 in the application running environment is shown. The method may include the following steps (410-470).

[0115] Step 410, obtaining the target program code of the target version application.

[0116] Step 420, determining a target field in the target program code that is associated with the target factor.

[0117] Step 430, replace the target field with the corresponding preset field to obtain a unified program code.

[0118] Step 440, compile the unified program code to generate a dynamic link library file.

[0119] Optionally, the dynamic link library file is securely encrypted to obtain an encrypted dynamic link library file.

[0120] Step 450 , obtaining a target field associated with the target factor in the program code of each version of the application.

[0121] Optionally, data information corresponding to a target field associated with a target factor in a program code of each version of the application is obtained, for example, data content corresponding to the target field.

[0122] Optionally, determine the string corresponding to the macro definition identifier. Optionally, determine the variable value corresponding to the static variable. Optionally, determine the function or variable located in the static link library corresponding to the static link library address. Optionally, determine the target storage address.

[0123] Step 460 : Generate configuration files for each version of the application based on the target fields associated with the target factors in the program codes of each version of the application.

[0124] The data content corresponding to the target field is stored in the configuration file. Optionally, the string corresponding to the above macro definition identifier is stored in the configuration file as the variable value of the non-static variable that replaces the macro definition identifier, and the executable program is waited to obtain it from the configuration file to assign the non-static variable. Optionally, the variable value corresponding to the above static variable is stored in the configuration file as the variable value of the non-static variable that replaces the static variable, and the executable program is waited to obtain it from the configuration file to assign the non-static variable.

[0125] For example, strings representing regions such as "GLOBAL", "JK", "VNG", and "TW" can be put into a configuration without having to hit the dynamic link library during compilation, which will not affect the final generated dynamic link library.

[0126] In some application scenarios, some strings can be defined through simple fixed code fields based on C++ macros. These fixed code fields are less flexible, and different fixed code fields will lead to inconsistency in the final generated dynamic link library. In order not to affect the consistency of the final generated dynamic link library, the pre-stored strings in the configuration file can be read and assigned to the variables in the code to eliminate the impact of the string length on the dynamic link library.

[0127] Step 470: Generate installation files for each version of the application based on the dynamic link library file and the configuration files for each version of the application.

[0128] The installation file may be an installation package of each version of the application. For any version of the application, the installation package of the version of the application includes the same dynamic link library file as other versions and a configuration file corresponding to the version of the application, so that the version of the application can retrieve and use the proprietary data of the version when running.

[0129] Optionally, the installation files of each version of the application are generated based on the encrypted dynamic link library file and the configuration files of each version of the application.

[0130] In one example, if Figure 5 As shown, it exemplifies a schematic diagram of generating an application installation file. By clarifying the entire process of application security encryption verification, the specific operations of security encryption verification are abstracted, and a set of security encryption verification algorithms suitable for different versions are designed. Since the main task of security encryption is to securely encrypt the dynamic link library files generated by the engine code. Therefore, whether the engine code is consistent directly affects whether the dynamic link library files are consistent. Through analysis, it can be determined that factors such as C++ macros, static variables, static libraries, code paths, etc. in the code will affect the generation of dynamic link library files. Then, a reasonable mechanism for building and publishing online game installation packages is designed, and through technical means, the above factors that affect the inconsistency of dynamic link library files are solved one by one, and the problem of inconsistency of dynamic link library files is solved from the process. Therefore, in Figure 5 In the process shown, first prepare to start building the application installation file and enter the application installation file generation process; secondly, compile the unified program code to generate a dynamic link library file; then perform security encryption on the dynamic link library file; then, generate the encrypted application installation file; and finally publish the application installation file.

[0131] In one example, if Figure 6 As shown, it exemplarily shows a schematic diagram of generating a game application installation file. First, the game code of the internationalized game is obtained. The main purpose of the solution is to use one game code to develop and maintain different versions. Then, the inconsistency problem of the dynamic link library files generated after compiling different versions of the game code is solved to generate a unified game code. For example, all factors in the game code that affect the inconsistency of the dynamic link library files of each version of the game (macro definition identifier, static variable, static link library, code storage address) are solved one by one.

[0132] For macro-defined identifiers in game code: C++ macros define an identifier as a string, and the identifier in the source program is replaced by the specified string. Different lengths of the string will lead to different compiled symbol tables, which in turn will lead to inconsistent dynamic link library files.

[0133] Solution: Replace all logic implemented by macro definition identifiers in the code with variables. When the program starts, read different configurations and assign the configuration version identifier to the version variable.

[0134] For static variables in the game code: the static variable refers to the variable declared and defined before compilation. The length of the static variable will also lead to inconsistency in the dynamic link library files compiled from different versions of the game code.

[0135] Solution: Replace all the logic implemented by static variables in the code with non-static variables, and store the variable values ​​of static variables in the configuration file. When the program starts, it reads different configuration files and dynamically assigns the values ​​in the configuration files to the non-static variables corresponding to the values.

[0136] For static link libraries in game code: static link libraries refer to a collection of external functions and variables. Inconsistencies in header files and export functions of static link libraries will also lead to inconsistencies in dynamic link library files compiled from different versions of game code.

[0137] Solution: Change the static link library address to the unified static link library address. The game version information is passed in through the interface of the unified static link library. The unified static link library distinguishes and implements corresponding operations based on the game version information, thereby ensuring that the exported static link library is completely consistent.

[0138] For the code storage address in the game code: The code storage address refers to the storage address of the game code when compiling the C++ program, for example: C:\Project\MyUE4. The length of the storage address will also lead to inconsistency in the dynamic link library files compiled from different versions of the game code.

[0139] Solution: Put each version of the game code into the same directory structure and ensure that the path lengths are consistent.

[0140] Since the above factors that lead to inconsistency of dynamic link libraries have been resolved, a unified game code can be generated. The above unified game code is a common game code for all versions of the game. Then compile the unified game code corresponding to different versions of the game to generate the same dynamic link library for each version of the game. By compiling the above unified game code, it can be ensured that the dynamic link libraries generated in each version of the game are completely consistent, so that different versions of installation packages can be built with the same dynamic link library. Finally, the installation packages of each version of the game are released. The versions of the above game installation packages include global version, domestic version, Japanese and Korean version, and Vietnamese version.

[0141] All versions of the above game applications can use the same set of security encryption verification mechanisms to perform security encryption verification on the same dynamic link library files. This ensures that the dynamic link libraries in each version of the game are consistent, greatly reducing the time and manpower for security encryption verification, improving the efficiency of security encryption verification for international games, and ensuring the consistency and accuracy of security encryption verification.

[0142] In summary, the technical solution provided by the embodiment of the present application determines the target factors that cause the dynamic link libraries of each version of the application to differ, and replaces the target field associated with the target factor in the program code with a preset field occupying the same address range, thereby obtaining a unified program code common to each version of the application and compiling it to generate a unified dynamic link library file common to each version, and also stores the data information of the target field in the configuration file to ensure the data integrity of each version of the application, and finally generates the installation package of each version of the application based on the same dynamic link library file and the configuration file of each version of the application, thereby improving the generation efficiency of the installation file of the multi-version application, as well as the maintenance efficiency of the multi-version application, and reducing the application development and operation costs and labor costs. Using the dynamic link library file as the object of security encryption verification, it is also possible to use a set of security encryption verification mechanisms to perform security encryption verification on the multi-version application, thereby improving the security encryption verification efficiency of the multi-version application and reducing labor costs.

[0143] Please refer to Figure 7 , which shows a flow chart of an application verification method provided by an embodiment of the present application. The method can be applied to Figure 1 In the application running environment shown in the figure, the method may include the following steps (710-730).

[0144] Step 710, obtaining the dynamic link library file of the target application.

[0145] Optionally, an encrypted dynamic link library file of the target application is obtained.

[0146] Step 720, perform security encryption verification on the dynamic link library file to obtain the library file verification result.

[0147] In a possible implementation, although the code of the application development engine is open source, each team will rewrite the engine code, so the rewritten engine code needs to be encrypted and protected, that is, the generated dynamic link library file needs to be encrypted.

[0148] Optionally, a security encryption verification is performed on the encrypted dynamic link library file to obtain a library file verification result.

[0149] In an exemplary embodiment, the above step 720 may be performed in the following manner.

[0150] Obtain the standard file corresponding to the dynamic link library file; if the contents of the standard file and the dynamic link library file are the same, the library file verification result indicates that the library file is normal; if the contents of the standard file and the dynamic link library file are different, the library file verification result indicates that the library file is abnormal.

[0151] The process of security encryption verification involves verifying the internal information of the dynamic link library. There will be a separate set of security encryption verification codes outside. The general principle of the security encryption verification process is to use a set of external encryption verification codes to analyze the content in the dynamic link library (such as code, incoming data, etc.) and perform verification. Based on the characteristics that it is impossible for the application itself to modify this code and data, if it is found that the code or data in the dynamic link library has been tampered with, it means that the verification fails and it is considered to be a plug-in behavior.

[0152] The premise of the above security encryption verification is to eliminate all factors that may cause inconsistency in the dynamic link library and confirm the initial content of the dynamic link library file. Therefore, a standard file is set as a reference, and then the dynamic link library file is subjected to security encryption verification. Otherwise, it is impossible to distinguish whether the code is modified by a plug-in or the application itself.

[0153] Step 730, based on the library file verification result, obtain the verification result of the target application.

[0154] If the library file verification result indicates that the library file is normal, it is determined that the verification result of the target application is passed;

[0155] If the library file verification result indicates that the library file is abnormal, it is determined that the verification result of the target application is verification failure.

[0156] The dynamic link library file is generated according to the above-mentioned method for generating the dynamic link library file.

[0157] To summarize, the technical solution provided in the embodiment of the present application uses a set of security encryption verification mechanisms to perform security encryption verification on multi-version applications to determine the security of the applications, thereby improving the efficiency of security encryption verification of multi-version applications and reducing labor costs.

[0158] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0159] Please refer to Figure 8 , which shows a block diagram of a device for generating a dynamic link library file provided by an embodiment of the present application. The device has the function of implementing the above-mentioned method for generating a dynamic link library file, and the function can be implemented by hardware, or by hardware executing corresponding software. The device can be a computer device, or can be set in a computer device. The device 800 can include: a code acquisition module 810, a factor determination module 820, a code replacement module 830 and a library file generation module 840.

[0160] The code acquisition module 810 is used to acquire the target program code of the target version application.

[0161] The field determination module 820 is used to determine a target field in the target program code that is associated with a target factor, where the target factor is an influencing factor that causes differences in dynamic link libraries of different versions of applications.

[0162] The field replacement module 830 is used to replace the target field with a corresponding preset field to obtain a unified program code, wherein the preset field occupies the same address interval in the storage space corresponding to each version of the application.

[0163] The library file generation module 840 is used to compile the unified program code to generate a dynamic link library file.

[0164] In an exemplary embodiment, the target factors include a string length difference factor, a variable length difference factor, and a static link library content difference factor, and the target field includes at least one of a macro definition identifier, a static variable, and a static link library address. The field determination module 820 includes:

[0165] The macro definition identifier determining unit is used to determine the macro definition identifier associated with the character string length difference factor.

[0166] The static variable determination unit is used to determine the static variable associated with the variable length difference factor.

[0167] The static link library address determination unit is used to determine the static link library address associated with the static link library content difference factor.

[0168] In an exemplary embodiment, the field replacement module 830 is used to:

[0169] If the target field is the macro definition identifier or the static variable, the target field is replaced with a corresponding non-static variable, and the non-static variable occupies an address interval of a fixed length in the storage space;

[0170] If the target field is the static link library address, the target field is replaced with the address of a unified static link library, where the unified static link library is obtained by encapsulating the static link libraries corresponding to the various versions of the application;

[0171] The unified program code is generated.

[0172] In an exemplary embodiment, the target factor further includes a code storage address difference factor, and the device 800 further includes:

[0173] The storage address determination module is used to determine a target storage address associated with the code storage address difference factor.

[0174] The storage address replacement module is used to replace the target storage address with a preset storage address.

[0175] The code storage module is used to store the unified program code at the preset storage address.

[0176] The library file generation module 840 includes:

[0177] The code reading unit is used to read the unified program code under the preset storage address.

[0178] The code compiling unit is used to perform the compiling process on the reading result to generate the unified dynamic link library.

[0179] In an exemplary embodiment, the code compiling unit is further configured to:

[0180] Generate a unified symbol table according to the preset field and the preset storage address, wherein the unified symbol table records address allocation information of the preset field and the preset storage address;

[0181] Based on the unified symbol table, the dynamic link library file is generated.

[0182] In an exemplary embodiment, the apparatus 800 further includes:

[0183] A field acquisition module, used for acquiring a target field associated with the target factor in the program code of each version of the application;

[0184] A configuration file generating module, configured to generate configuration files of the respective versions of the applications based on target fields associated with the target factors in the program codes of the respective versions of the applications;

[0185] The installation file generation module is used to generate the installation files of the respective versions of the application based on the dynamic link library file and the configuration files of the respective versions of the application.

[0186] To summarize, the technical solution provided by the embodiment of the present application determines the target factors that cause differences in the dynamic link libraries of each version of the application, and replaces the target fields associated with the target factors in the program code with preset fields occupying the same address range, thereby obtaining a unified program code common to each version of the application and compiling it to generate a unified dynamic link library file common to each version. Using the dynamic link library file as the object of security encryption verification, it is possible to use a set of security encryption verification mechanisms to perform security encryption verification on multiple versions of applications, thereby improving the efficiency of security encryption verification of multiple versions of applications and reducing labor costs.

[0187] Please refer to Fig. 9 , which shows a block diagram of an application verification device provided by an embodiment of the present application. The device has the function of implementing the above-mentioned application verification method, and the function can be implemented by hardware, or by hardware executing corresponding software. The device can be a computer device, or it can be set in a computer device. The device 900 may include: a library file acquisition module 910, a library file verification module 920, and a verification result generation module 930.

[0188] The library file acquisition module 910 is used to acquire the dynamic link library file of the target application;

[0189] The library file verification module 920 is used to perform security encryption verification on the dynamic link library file to obtain a library file verification result;

[0190] A verification result generating module 930, configured to obtain a verification result of the target application based on the verification result of the library file;

[0191] The dynamic link library file is generated according to the method for generating a dynamic link library file according to any one of claims 1 to 6.

[0192] To summarize, the technical solution provided in the embodiment of the present application uses a set of security encryption verification mechanisms to perform security encryption verification on multi-version applications to determine the security of the applications, thereby improving the efficiency of security encryption verification of multi-version applications and reducing labor costs.

[0193] It should be noted that the device provided in the above embodiment, when implementing its functions, is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the device and method embodiments provided in the above embodiment belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0194] Please refer to Fig.10 , which shows a block diagram of a computer device provided in one embodiment of the present application. The computer device may be a terminal. The computer device is used to implement the method for generating a dynamic link library file provided in the above embodiment, or to implement the application verification method provided in the above embodiment, or to implement the method for generating an application installation file provided in the above embodiment. Specifically:

[0195] Typically, the computer device 1000 includes a processor 1001 and a memory 1002 .

[0196] The processor 1001 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 1001 may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), and PLA (Programmable Logic Array). The processor 1001 may also include a main processor and a coprocessor. The main processor is a processor for processing data in an awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in a standby state. In some embodiments, the processor 1001 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 1001 may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

[0197] The memory 1002 may include one or more computer-readable storage media, which may be non-transitory. The memory 1002 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 1002 is used to store at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is configured to be executed by one or more processors to implement the above-mentioned method for generating a dynamic link library file, or the above-mentioned application verification method, or the above-mentioned method for generating an application installation file.

[0198] In some embodiments, the computer device 1000 may also optionally include: a peripheral device interface 1003 and at least one peripheral device. The processor 1001, the memory 1002 and the peripheral device interface 1003 may be connected via a bus or a signal line. Each peripheral device may be connected to the peripheral device interface 1003 via a bus, a signal line or a circuit board. Specifically, the peripheral device includes: at least one of a radio frequency circuit 1004, a touch display screen 1005, a camera assembly 1006, an audio circuit 1007, a positioning assembly 1008 and a power supply 1009.

[0199] Those skilled in the art will understand that Fig.10 The structure shown in the figure does not constitute a limitation on the computer device 1000, and the computer device 1000 may include more or less components than those shown in the figure, or combine some components, or adopt a different component arrangement.

[0200] In an exemplary embodiment, a computer-readable storage medium is also provided, in which at least one instruction, at least one program, a code set or an instruction set is stored. When the at least one instruction, the at least one program, the code set or the instruction set is executed by a processor, the method for generating the dynamic link library file is implemented.

[0201] In an exemplary embodiment, a computer-readable storage medium is also provided, in which at least one instruction, at least one program, a code set or an instruction set is stored, and when the at least one instruction, the at least one program, the code set or the instruction set is executed by a processor, the above-mentioned application verification method is implemented.

[0202] Optionally, the computer readable storage medium may include: ROM (Read Only Memory), RAM (Random Access Memory), SSD (Solid State Drives) or optical disks, etc. Among them, the random access memory may include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).

[0203] In an exemplary embodiment, a computer program product or a computer program is also provided, the computer program product or the computer program includes a computer instruction, the computer instruction is stored in a computer-readable storage medium. A processor of a computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the above-mentioned method for generating a dynamic link library file.

[0204] In an exemplary embodiment, a computer program product or a computer program is also provided, the computer program product or the computer program comprising computer instructions, the computer instructions being stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above-mentioned application verification method.

[0205] It should be understood that the "multiple" mentioned in this article refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. In addition, the step numbers described in this article only illustrate a possible execution sequence between the steps. In some other embodiments, the above steps may not be executed in the order of the numbers, such as two steps with different numbers are executed at the same time, or two steps with different numbers are executed in the opposite order to the diagram. The embodiments of the present application are not limited to this.

[0206] The above description is only an exemplary embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A method for generating a dynamic link library file, characterized in that: The method comprises: Obtain target program code of target version application; Determine a target field associated with a target factor in the target program code, wherein the target factor is an influencing factor causing differences in dynamic link libraries of different versions of applications; the target factor includes a string length difference factor, a variable length difference factor, and a static link library content difference factor, and the target field includes at least one of a macro definition identifier associated with the string length difference factor, a static variable associated with the variable length difference factor, and a static link library address associated with the static link library content difference factor; Replacing the target field with a corresponding preset field to obtain a unified program code, wherein the preset field occupies the same address interval in the storage space corresponding to each version of the application; The unified program code is compiled to generate a dynamic link library file.

2. The method according to claim 1, characterized in that The step of replacing the target field with a corresponding preset field to obtain a unified program code includes: If the target field is the macro definition identifier or the static variable, the target field is replaced with a corresponding non-static variable, and the non-static variable occupies an address interval of a fixed length in the storage space; If the target field is the static link library address, the target field is replaced with the address of a unified static link library, where the unified static link library is obtained by encapsulating the static link libraries corresponding to the various versions of the application; The unified program code is generated.

3. The method according to any one of claims 1 to 2, characterized in that The target factor also includes a code storage address difference factor, and the method further includes: determining a target storage address associated with the code storage address difference factor; Replacing the target storage address with a preset storage address; Storing the unified program code at the preset storage address; The step of compiling the unified program code to generate a dynamic link library file includes: Reading the unified program code at the preset storage address; The read result is compiled to generate a unified dynamic link library.

4. The method according to claim 3, characterized in that The compiling process is performed on the reading result to generate the unified dynamic link library, including: Generate a unified symbol table according to the preset field and the preset storage address, wherein the unified symbol table records address allocation information of the preset field and the preset storage address; Based on the unified symbol table, the dynamic link library file is generated.

5. The method according to any one of claims 1 to 2, characterized in that: The method further comprises: Obtaining a target field associated with the target factor in the program code of each version of the application; generating configuration files of the respective versions of the applications based on target fields associated with the target factors in the program codes of the respective versions of the applications; Based on the dynamic link library file and the configuration files of the various versions of the application, the installation files of the various versions of the application are generated.

6. An application verification method, characterized in that: The method comprises: Get the dynamic link library file of the target application; Performing security encryption verification on the dynamic link library file to obtain a library file verification result; Based on the verification result of the library file, obtaining the verification result of the target application; The dynamic link library file is generated according to the method for generating a dynamic link library file according to any one of claims 1 to 5.

7. The method according to claim 6, characterized in that The performing of security encryption verification on the dynamic link library file to obtain the library file verification result comprises: Obtaining a standard file corresponding to the dynamic link library file; If the contents of the standard file are the same as those of the dynamic link library file, the library file verification result indicates that the library file is normal.

8. The method according to claim 7, characterized in that The method further comprises: If the contents of the standard file are different from those of the dynamic link library file, the library file verification result indicates that the library file is abnormal.

9. A device for generating a dynamic link library file, characterized in that: The device comprises: A code acquisition module, used to acquire the target program code of the target version application; A field determination module, used to determine a target field associated with a target factor in the target program code, wherein the target factor is an influencing factor causing differences in dynamic link libraries of various versions of applications; the target factor includes a string length difference factor, a variable length difference factor, and a static link library content difference factor, and the target field includes at least one of a macro definition identifier associated with the string length difference factor, a static variable associated with the variable length difference factor, and a static link library address associated with the static link library content difference factor; A field replacement module, used to replace the target field with a corresponding preset field to obtain a unified program code, wherein the preset field occupies the same address interval in the storage space corresponding to each version of the application; The library file generation module is used to compile the unified program code to generate a dynamic link library file.

10. The device according to claim 9, characterized in that The field replacement module is used to: If the target field is the macro definition identifier or the static variable, the target field is replaced with a corresponding non-static variable, and the non-static variable occupies an address interval of a fixed length in the storage space; If the target field is the static link library address, the target field is replaced with the address of a unified static link library, where the unified static link library is obtained by encapsulating the static link libraries corresponding to the various versions of the application; The unified program code is generated.

11. The device according to any one of claims 9 to 10, characterized in that The target factor also includes a code storage address difference factor, and the device also includes: A storage address determination module, used to determine a target storage address associated with the code storage address difference factor; A storage address replacement module, used to replace the target storage address with a preset storage address; A code storage module, used for storing the unified program code at the preset storage address; The library file generation module includes: A code reading unit, used for reading the unified program code at the preset storage address; The code compiling unit is used to perform the compiling process on the reading result to generate a unified dynamic link library.

12. The device according to claim 11, characterized in that The code compilation unit is also used for: Generate a unified symbol table according to the preset field and the preset storage address, wherein the unified symbol table records address allocation information of the preset field and the preset storage address; Based on the unified symbol table, the dynamic link library file is generated.

13. The device according to any one of claims 9 to 10, characterized in that The device also includes: A field acquisition module, used for acquiring a target field associated with the target factor in the program code of each version of the application; A configuration file generating module, configured to generate configuration files of the respective versions of the applications based on target fields associated with the target factors in the program codes of the respective versions of the applications; The installation file generation module is used to generate the installation files of the respective versions of the application based on the dynamic link library file and the configuration files of the respective versions of the application.

14. An application verification device, characterized in that: The device comprises: A library file acquisition module is used to acquire the dynamic link library file of the target application; The library file verification module is used to perform security encryption verification on the dynamic link library file to obtain the library file verification result; A verification result generating module, used for obtaining the verification result of the target application based on the verification result of the library file; The dynamic link library file is generated according to the method for generating a dynamic link library file according to any one of claims 1 to 5.

15. The device according to claim 14, characterized in that The library file verification module is specifically used for: Obtaining a standard file corresponding to the dynamic link library file; If the contents of the standard file are the same as those of the dynamic link library file, the library file verification result indicates that the library file is normal.

16. The device according to claim 15, characterized in that The library file verification module is also specifically used for: If the contents of the standard file are different from those of the dynamic link library file, the library file verification result indicates that the library file is abnormal.

17. A computer device, characterized in that: The computer device includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the method for generating a dynamic link library file as described in any one of claims 1 to 5, or the application verification method as described in any one of claims 6 to 8.

18. A computer-readable storage medium, characterized in that: The storage medium stores at least one instruction or at least one program, and when the at least one instruction or the at least one program is executed by the processor, it implements the method for generating a dynamic link library file as described in any one of claims 1 to 5, or the application verification method as described in any one of claims 6-8.

19. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method for generating a dynamic link library file as described in any one of claims 1 to 5, or the application verification method as described in any one of claims 6 to 8.

Images