CN110673837B

CN110673837B - Code repairing method and device, electronic equipment and computer readable storage medium

Info

Publication number: CN110673837B
Application number: CN201910809755.9A
Authority: CN
Inventors: 车雄生
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-08-29
Filing date: 2019-08-29
Publication date: 2020-11-17
Anticipated expiration: 2039-08-29
Also published as: CN110673837A

Abstract

The present disclosure provides a code repair method, a code repair apparatus, an electronic device, a computer-readable storage medium; relates to the technical field of software engineering. The code repairing method comprises the following steps: acquiring an initial dynamic library generated after compiling an original code; performing code injection processing on the initial dynamic library to generate a modified dynamic library; determining a function with a patch label from the modified dynamic library as a patch function, and generating execution information of the patch function; and responding to the code execution instruction, and calling a patch function according to the execution information so as to repair the original code. The method and the device can directly modify the code in the code engineering where the original code is located, are convenient for achieving the effect of code repair on the original code by loading the patch file package at the client, and have the advantages of being simple in operation, low in repair cost and the like.

Description

Code repairing method and device, electronic equipment and computer readable storage medium

Technical Field

The present disclosure relates to the field of software engineering technologies, and in particular, to a code recovery method, a code recovery apparatus, an electronic device, and a computer-readable storage medium.

Background

In the software development process, multiple iterations and updates are usually performed on the code, and a new function module is added to the code project or a problem (bug) occurring in the code project is repaired, so that the corresponding application program is more suitable for the use requirement of a user.

In the code repair technology in the prior art, a developer can adopt a code logic written by a scripting language to replace a code logic in an original code, and when too much logic is involved in bug in a service code, the workload of the developer in the code repair process is large; in addition, the code modification involves a large amount of code, which may cause the problem of new bug reappearing in new code logic, and reduce the development efficiency of developers. Meanwhile, when the codes in the original code engineering are modified by adopting the script language, developers need to learn a new script language, so that a certain learning burden is caused to the developers.

It is to be noted that the information disclosed in the above background section is only for enhancement of understanding of the background of the present disclosure, and thus may include information that does not constitute prior art known to those of ordinary skill in the art.

Disclosure of Invention

An object of the present disclosure is to provide a code repair method, a code repair apparatus, an electronic device, and a computer-readable storage medium, which overcome, to some extent, the problem of repair cost due to too much logic involved in a bug in a service code, which is caused by the limitations and disadvantages of the related art.

According to a first aspect of the present disclosure, there is provided a code repair method, including: acquiring an initial dynamic library generated after compiling an original code; performing code injection processing on the initial dynamic library to generate a modified dynamic library; determining a function with a patch label from the modified dynamic library as a patch function, and generating execution information of the patch function; and responding to a code execution instruction, and calling the patch function according to the execution information so as to repair the original code.

According to a second aspect of the present disclosure, there is provided a code repair apparatus including: the initial dynamic library acquisition module is used for acquiring an initial dynamic library generated after the original code is compiled; the modified dynamic library generating module is used for performing code injection processing on the initial dynamic library to generate a modified dynamic library; the execution information generation module is used for determining a function with a patch label from the modification dynamic library as a patch function and generating execution information of the patch function; and the function calling module is used for responding to the code execution instruction and calling the patch function according to the execution information so as to repair the original code.

In an exemplary embodiment of the disclosure, the modifying dynamic library generation module includes: a module to be injected determining unit, configured to determine one or more code modules as modules to be injected based on the initial dynamic library; the configuration file generating unit is used for generating a configuration file according to the module to be injected; and the modified dynamic library generating unit is used for performing code injection processing on the initial dynamic library according to the configuration file so as to generate the modified dynamic library.

In an exemplary embodiment of the present disclosure, the modifying dynamic library generating unit includes: a function library acquisition unit for acquiring a target function library; a code injection unit, configured to add a modification code segment to the initial dynamic library according to the configuration file and the objective function library, so as to complete the code injection process; wherein the modification code segment comprises code execution redirection information of the module to be injected.

In an exemplary embodiment of the present disclosure, the code injection unit is configured to: determining an adapter based on the library of objective functions; wherein the adapter comprises a function adapter and an interface adapter; generating the modification code segment according to the function adapter and the interface adapter; determining an intermediate instruction corresponding to the initial dynamic library; adding the modifying code segment to the intermediate instruction according to the configuration file to complete the code injection process.

In an exemplary embodiment of the present disclosure, the code recovery apparatus further includes: an injected function determining module, configured to determine, from the modified dynamic library, a function subjected to code injection processing as an injected function; the identification format determining module is used for determining the identification format of the function mapping identification; a mapping identifier adding module, configured to add a corresponding target function mapping identifier to the injected function according to the identifier format; wherein the target function mapping identifier is used for determining a mapping relationship between the function information of the injected function and a function index; and the patch function generating module is used for determining a patch label format and adding a corresponding patch label to the injected function according to the patch label format to form a patch function.

In an exemplary embodiment of the present disclosure, the mapping identifier adding module includes a mapping identifier adding unit, configured to obtain a name space name, a class name, and a function name corresponding to the injected function; determining a key of the target function mapping identifier through the name space name, the class name and the function name based on the identifier format; and taking the index value corresponding to the injected function as the value of the target function mapping identifier.

In an exemplary embodiment of the present disclosure, the mapping identifier adding unit includes an identifier value adding unit, configured to determine a reload function corresponding to the injected function, and determine a corresponding number identifier for the reload function; and combining the name space name, the class name, the function name and the serial number identifier based on the identifier format to generate a key of the target function mapping identifier.

In an exemplary embodiment of the present disclosure, the execution information generation module includes a first information generation unit, configured to obtain a predefined instruction format, and determine a function instruction of the patch function according to the instruction format; determining a signature identifier of a native function corresponding to the patch function according to the function instruction; wherein the signature identification is used for locating and calling the native function; adding the signature identification to the execution information.

In an exemplary embodiment of the present disclosure, the execution information generation module includes a second information generation unit, configured to determine whether the patch function includes a closure and an iterator; if the patch function comprises the closure and the iterator, initializing the closure and the iterator corresponding to the patch function; and adding the closure subjected to the initialization processing and an iterator to the execution information.

In an exemplary embodiment of the present disclosure, the execution information generation module includes a third information generation unit, configured to determine signature information of a jump code segment in the patch function according to the code execution redirection information; generating jump execution information of the jump code segment according to the signature information; adding the jump execution information to the execution information.

In an exemplary embodiment of the present disclosure, the code repairing apparatus further includes a patch file storage module, configured to generate a patch file corresponding to the patch function according to the patch function and the execution information; acquiring a predefined patch file name format; adding a corresponding patch file name for the patch file according to the patch file name format; and storing the patch file name in a file path of the modified dynamic library so as to call the patch function through the patch file name.

In an exemplary embodiment of the present disclosure, the function calling module includes a function calling unit for initializing a virtual machine; calling the patch function through the virtual machine according to the execution information; determining a native function contained in the patch function through a reflection mechanism according to the positioning information; and executing the code section of the patch function and the code section of the native function to complete the calling of the patch function.

According to a third aspect of the present disclosure, there is provided an electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the method of any one of the above via execution of the executable instructions.

According to a fourth aspect of the present disclosure, there is provided a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method of any one of the above.

Exemplary embodiments of the present disclosure may have some or all of the following benefits:

in the code repairing method provided in an exemplary embodiment of the present disclosure, code injection processing is performed in an initial dynamic library generated after a target code segment is compiled to obtain a modified dynamic library, execution information of a patch function and the patch function in the modified dynamic library is obtained, and the patch function is called according to the execution information to repair the target code segment. On one hand, in the code repairing process, the modified code is injected into the initial dynamic library corresponding to the original code instead of the code being injected into the original code corresponding to the service code, so that the situation that the original code is changed in the code repairing process can be avoided. On the other hand, after code injection processing, the code repair of the client can be realized by calling the patch function, so that the error probability in the code repair process can be reduced, and the development efficiency is improved. On the other hand, the bug in the original code can be modified by directly injecting the code into the original code project corresponding to the original code without the need of developers to learn other programming languages, so that the learning cost of the developers is reduced, and the effect of efficiently repairing the code of the client is achieved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure. It is to be understood that the drawings in the following description are merely exemplary of the disclosure, and that other drawings may be derived from those drawings by one of ordinary skill in the art without the exercise of inventive faculty.

FIG. 1 is a diagram illustrating an exemplary system architecture to which a code repair method and apparatus of embodiments of the present disclosure may be applied;

FIG. 2 illustrates a schematic structural diagram of a computer system suitable for use with the electronic device used to implement embodiments of the present disclosure;

FIG. 3 schematically illustrates a flow diagram of a code repair method according to one embodiment of the present disclosure;

FIG. 4 schematically illustrates a flow diagram of a process for code injection into an initial dynamic library in accordance with one embodiment of the present disclosure;

FIG. 5 schematically illustrates a flow diagram of a process for code injection according to a configuration file and an objective function library in one embodiment according to the present disclosure;

FIG. 6 schematically illustrates an intermediate instruction screenshot corresponding to code before an initial dynamic library code injection process is performed according to an embodiment of the present disclosure;

FIG. 7 schematically illustrates an intermediate instruction screenshot corresponding to code after an initial dynamic library has been performed for code injection processing, according to an embodiment of the present disclosure;

FIG. 8 schematically illustrates a flow diagram for adding an objective function mapping identification to an injected function in accordance with an embodiment of the present disclosure;

FIG. 9 schematically illustrates a flow diagram for adding an objective function mapping identification to an injected function in accordance with an embodiment of the present disclosure;

FIG. 10 is a schematic diagram that illustrates parameter stacking when an instruction is called in one embodiment of the present disclosure;

FIG. 11 is a schematic diagram that illustrates a call relationship between a native program and a virtual machine in accordance with one embodiment of the present disclosure;

FIG. 12 schematically illustrates a block diagram of a code repair apparatus according to one embodiment of the present disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the subject matter of the present disclosure can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and the like. In other instances, well-known technical solutions have not been shown or described in detail to avoid obscuring aspects of the present disclosure.

Furthermore, the drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repetitive description will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

Fig. 1 is a schematic diagram illustrating a system architecture of an exemplary application environment to which a code repair method and apparatus according to an embodiment of the present disclosure may be applied.

As shown in fig. 1, the system architecture 100 may include one or more of

terminal devices

101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the

terminal devices

101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few. The

terminal devices

101, 102, 103 may be various electronic devices having a display screen, including but not limited to desktop computers, portable computers, smart phones, tablet computers, and the like. It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation. For example, server 105 may be a server cluster comprised of multiple servers, or the like.

The code recovery method provided by the embodiment of the present disclosure is generally executed by the server 105, and accordingly, the code recovery apparatus is generally disposed in the server 105. However, it is easily understood by those skilled in the art that the code recovery method provided in the embodiment of the present disclosure may also be executed by the

terminal devices

101, 102, and 103, and accordingly, the code recovery apparatus may also be disposed in the

terminal devices

101, 102, and 103, which is not particularly limited in this exemplary embodiment. For example, in an exemplary embodiment, a user may send a code repair instruction to the server 105 through the

terminal devices

101, 102, and 103, and the server performs code repair processing on an original code by using the code repair method provided by the embodiment of the present disclosure to obtain a code repair result, and transmits the code repair result to the

terminal devices

101, 102, and 103, and the like.

FIG. 2 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present disclosure.

It should be noted that the computer system 200 of the electronic device shown in fig. 2 is only an example, and should not bring any limitation to the functions and the scope of the application of the embodiments of the present disclosure.

As shown in fig. 2, the computer system 200 includes a Central Processing Unit (CPU)201 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)202 or a program loaded from a storage section 208 into a Random Access Memory (RAM) 203. In the RAM 203, various programs and data necessary for system operation are also stored. The CPU 201, ROM 202, and RAM 203 are connected to each other via a bus 204. An input/output (I/O) interface 205 is also connected to bus 204.

The following components are connected to the I/O interface 205: an input portion 206 including a keyboard, a mouse, and the like; an output section 207 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 208 including a hard disk and the like; and a communication section 209 including a network interface card such as a LAN card, a modem, or the like. The communication section 209 performs communication processing via a network such as the internet. A drive 210 is also connected to the I/O interface 205 as needed. A removable medium 211 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 210 as necessary, so that a computer program read out therefrom is mounted into the storage section 208 as necessary.

In particular, the processes described below with reference to the flowcharts may be implemented as computer software programs, according to embodiments of the present disclosure. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 209 and/or installed from the removable medium 211. The computer program, when executed by a Central Processing Unit (CPU)201, performs various functions defined in the methods and apparatus of the present application.

It should be noted that the computer readable media shown in the present disclosure may be computer readable signal media or computer readable storage media or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In contrast, in the present disclosure, a computer-readable signal medium may include a propagated data signal with computer-readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present disclosure may be implemented by software, or may be implemented by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.

As another aspect, the present application also provides a computer-readable medium, which may be contained in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by an electronic device, cause the electronic device to implement the method as described in the embodiments below. For example, the electronic device may implement the steps shown in fig. 3 to 11, and the like.

The technical solution of the embodiment of the present disclosure is explained in detail below:

in the software life cycle, the steps of demand analysis, product design, development, testing and the like can be generally included. For software development, the completion of the development of a piece of software can generally represent the beginning of its lifecycle, and the continuous maintenance and updating of software is of great importance for a vital piece of software. Therefore, after one software is released and on-line, the project codes can be iterated and updated for multiple times, so that the software runs more stably.

In one scheme provided by the inventor, after the software is released online, a developer can perform software repair or update iteration on the software according to the running condition of the software. During the code repair process, a developer can modify the operation logic in the original code so as to achieve the code repair effect. Taking a process of program development by adopting a programming language C # (C Sharp) as an example, when codes in an open source item Xlua are repaired, Xlua can support a scripting language Lua to repair the C # codes, wherein the Xlua can increase the Lua scripting programming capability for various C # environments, and the principle of the method is that static code instrumentation is adopted to realize a realization process that functions can be redirected to the Lua.

Specifically, in the process of repairing the C # code by using XLua, the code repair is mainly completed by the following steps, including: firstly, the service codes are configured, and which codes in the service codes need to be statically injected. Second, the XLua injector can inject code into the C # compiled Dynamic Link Library file (DLL) according to configuration. In this step, decompilated code that is instrumented by an Intermediate Language (IL) may be determined. The step is mainly carried out by generating bridging codes first and then inserting piles at the instruction level to carry out code injection. Again, if a bug is found in the business code, it may be through an Application Programming Interface (API) provided by XLua: holtfix "replaces" a C # function with the content written by the Lua script to complete the code modification.

However, when a similar code repair technique is used for code repair, if too many bugs are involved in the service code, a huge repair cost is generated. For example, assuming there is a one thousand lines of C # functions, there is a problem with a line of code in the middle. First, in the case of XLua, the thousand lines of code can be rewritten using Lua script. While the XIL, even though the redirected ILRuntime is a DLL file generated by parsing C #, since the new class written by the new logic cannot directly access the private member of the repaired class, and needs to access through a special API, the XIL basically corresponds to rewriting the code since there are many codes involved in accessing the private member.

In addition, when the code repair is performed by adopting the technology, the adopted carrier is generally Lua script or C # standard program set, and is not ideal in the aspect of safety.

Based on one or more of the problems described above, the present example embodiment provides a code repair method. The code recovery method may be applied to the server 105, and may also be applied to one or more of the

terminal devices

101, 102, and 103, which is not particularly limited in this exemplary embodiment. Referring to fig. 3, the code repair method may include the following steps S310 to S340:

and S310, acquiring an initial dynamic library generated after the original code is compiled.

And S320, performing code injection processing on the initial dynamic library to generate a modified dynamic library.

And S330, determining a function with a patch label from the modified dynamic library as a patch function, and generating execution information of the patch function.

Step S340, responding to the code execution instruction, and calling a patch function according to the execution information so as to repair the original code.

In the code repairing method provided in this exemplary embodiment, code injection processing is performed in an initial dynamic library generated after a target code segment is compiled to obtain a modified dynamic library, execution information of a patch function and a patch function in the modified dynamic library is obtained, and the patch function is called according to the execution information to repair the target code segment. On one hand, in the code repairing process, the modified code is injected into the initial dynamic library corresponding to the original code instead of the code being injected into the original code corresponding to the service code, so that the situation that the original code is changed in the code repairing process can be avoided. On the other hand, after code injection processing, the code repair of the client can be realized by calling the patch function, so that the error probability in the code repair process can be reduced, and the development efficiency is improved. On the other hand, the bug in the original code can be modified by directly injecting the code into the original code project corresponding to the original code without the need of developers to learn other programming languages, so that the learning cost of the developers is reduced, and the effect of efficiently repairing the code of the client is achieved.

The above steps of the present exemplary embodiment will be described in more detail below.

In step S310, an initial dynamic library generated by compiling the original code is acquired.

In this example embodiment, the original code may be code that needs to be subjected to code repair processing. For example, the original code may be project code that has been published online. The item code may be various types of application code, and may be, for example, a game item code, a website item code, a shopping platform item code, and so forth. The original code may be project code written in a variety of programming languages. For example, the original code may be a project code written in C #/C + + programming language, a project code written in Java programming language, a project code written in Python programming language, a project code written in PHP programming language, or a project code written in JavaScript programming language. It should be noted that the present disclosure does not make any special limitation on the type of programming language used by the original code. The initial dynamic library may be an initial dynamic link library file generated after the original code is compiled. The compiling process may be a process in which a developer automatically processes an original code and generates a corresponding dynamic link library when the developer compiles the code in a software development tool. After the original code is compiled by a developer, the development tool corresponding to the original code can automatically compile the original code to form an initial dynamic library. Before the code repair is carried out, the compiled code file can be preprocessed, so that a developer can obtain the compiled C # project code file through a development tool.

In the present example embodiment, code repair may be performed on code written in various programming languages. The following will describe in detail the code repair method in the present exemplary embodiment, taking project code developed in C # language as an example. For example, when program development is performed in C # language, the program development may be performed in a plurality of development environments supporting C # language, for example: development of C # programs based on the NET platform, development of programs based on the Unity 3D game engine, and the like, the C # development environment in the present exemplary embodiment is not particularly limited.

In step S320, a code injection process is performed on the initial dynamic library to generate a modified dynamic library.

In this example embodiment, the code injection process may be a process of preprocessing an initial dynamic library corresponding to the original code. That is, a process of adding code to a class, a function (also referred to as a method), an interface, and the like, which need to be code-injected in the initial dynamic library, may perform the code injection process in various ways. The modified dynamic library may be a new dynamic link library file generated after code injection processing is performed on the initial dynamic library. The code injection process for the initial dynamic library may be a process of adding a code segment corresponding to a new code execution logic to the initial dynamic library. The developer can carry out code injection processing on a specific code module in the initial dynamic library according to development requirement configuration so as to generate a modified dynamic library based on the initial dynamic library subjected to the code injection processing.

The present exemplary embodiment may perform code injection processing on the initial dynamic library in multiple scenarios, and the following procedure of performing code injection processing through the following three scenarios is specifically described as an example.

(1) And (5) carrying out packaging injection by the development tool. Taking the Unity editor as an example, the "InjectFix" menu in the Unity editor already implements the Unity packing operation Hook, specifically, Hook (Hook) is a platform of Windows message handling mechanism on which an application can set up a subroutine to monitor certain messages for a specified window. When the build button of Unity is clicked, the injection operation may be automatically added.

(2) Automated package script injection. The developer can add calls to specified command lines in the self-developed automation packaging script to complete code injection. For example, a developer may add a call to an ifix.

(3) The code injection process is performed through a menu provided by a code editor. Taking the Unity editor as an example, the menu provided by the Unity editor is used for code injection processing. The Unity editor is a code editor, and after a developer writes or modifies code in the editor, the developer can directly see the modification effect through click operation. In the Unity editor, clicking on the "project" option under the "project fix" menu, code injection can be done through the Unity editor.

For example, referring to fig. 4, the code injection process may be performed on the initial dynamic library through steps S410 to S430 described below. Wherein:

in step S410, one or more code modules are determined as modules to be injected based on the initial dynamic library. The module to be injected can be a code segment corresponding to the code injection processing determined by a developer according to the development requirement. Since the initial dynamic library includes many code modules (i.e., code segments), it is possible to determine which code modules need to be subjected to the code injection process from the initial dynamic library before the code injection is performed. The module that needs to be subjected to code injection processing may be a new type developed by a developer, a code module that frequently changes, a code module with an uncertain operating state, or the like. The developer can determine which code modules are used as modules to be injected according to development requirements. For example, when the software is executed online for the first time, all the code modules may be configured as modules to be injected, and as the version is updated, some classes running stably will not perform the code injection process any more. And determining a code module needing code injection processing as a module to be injected based on the initial dynamic library so as to perform the code injection processing subsequently.

In step S420, in response to the configuration operation, a configuration file is generated according to the module to be injected. The configuration operation may be an operation performed by a developer through a code development tool for writing a class requiring a code injection process into a configuration file. The configuration file may be a file generated after the configuration operation is performed on the module to be injected. When the code injection processing is performed, a developer can configure which classes need to be injected in a configuration file, and in response to the configuration operation of the developer, a development tool can generate a corresponding configuration file according to a module to be injected so as to perform the code injection processing on code segments in the configuration file. For example, a developer may perform configuration operations of performing code injection processing on the "Helloworld" class, the "ifix. Exemplary contents of the configuration file are as follows:

in step S430, a code injection process is performed on the initial dynamic library according to the configuration file to generate a modified dynamic library. After the specific module to be injected is configured in the configuration file, code injection processing can be performed on the initial dynamic library according to the configuration file to generate a corresponding modified dynamic library.

In the present exemplary embodiment, the code injection process for the initial dynamic library according to the configuration file may be completed by the following steps: acquiring a target function library; adding a modification code segment to the initial dynamic library according to the configuration file and the target function library to complete the code injection processing; wherein the modification code segment comprises code execution redirection information of the module to be injected.

The objective function library may be a function library used when performing a code injection process. The library of the objective function may include, but is not limited to, nrefactor library, mono. The following describes the procedure of the code injection process, taking the objective function library as mono. Mono. After the target function library is obtained, a modification code segment can be added to the initial dynamic library according to the configuration file and the target function library. The code execution redirection information may be information that modifies code execution logic contained in the code segment for redirecting the module to be injected. The following code segments schematically show a decompilation result after a module to be injected is subjected to code injection processing at a code level; wherein, the redirection logic of the Add function in the code module in the execution process is defined in the if statement.

Specifically, the execution logic of the code segment may be: in the Add function, an if statement is adopted to judge whether an execution logic of a patch function exists, if the return value judged by the if condition is true, the logic in the statements of WrapperManagerImp1. GetPatch (0) __ Gen _ Wrap _0(this, a, b) is executed, and if the return value judged by the if condition is false, the execution logic 'a b' in the original code is continuously executed; wherein, IsPatched () may mean to determine whether a patch function exists.

In the present exemplary embodiment, referring to fig. 5, the code injection process according to the configuration file and the objective function library may be completed through the following steps S510 to S540.

In step S510, an adapter is determined based on the objective function library; the adapter comprises a function adapter and an interface adapter. The adapter may be a function or interface used to push parameters of a function or interface call onto the virtual machine stack during subsequent code execution. The function adapter may be responsible for pushing the parameters of the function call into the virtual machine stack. Because the execution logic of the adapter is defined in the target function library, if a certain adapter needs to be called, the corresponding adapter can be determined in the target function library so as to generate the execution logic required by code execution in the following process. For example, in the decompiled example code after the Add function is subjected to code injection processing, __ Gen _ Wrap _0 called by the redirection logic of the if statement is a function adapter. Example code that decompiled the function adapter __ Gen _ Wrap _0 is as follows:

wherein the function adapter __ Gen _ Wrap _0 shows: PushObject (P0) can be adopted to push a P0 parameter with the type of Object into a virtual machine stack; the integer parameters P1 and P2 can be pushed into the virtual machine stack by "call. Executing a process of calling and executing related instructions on the virtual machine through a statement of "this. Specifically, this. methodid may represent a procedure identifier; (this is. anonobj | ═ null)? 4:3 may represent the number of parameters. In the end part of the function adapter, an integer variable is returned from the virtual machine stack using a "call. getint32 (0)" statement.

In addition, the interface adapter may be responsible for pushing the parameters of the interface call into the virtual machine stack. Since the interface adapter has similar functions to the function adapter, the interface adapter has a plurality of steps for transferring one interface object compared to the function adapter, which is not described in detail in this exemplary embodiment.

In step S520, a modification code segment is generated according to the function adapter and the interface adapter. Since the function adapter and the interface adapter may be used in modifying the code segment to implement parameter stack or other functions. Thus, when a modification code segment is generated, the corresponding function adapter and interface adapter may be called to write the modification code segment. And generating a corresponding modification code segment through a function adapter and an interface adapter in the target function library so as to inject the modification code segment into the initial dynamic library.

In step S530, an intermediate instruction corresponding to the initial dynamic library is determined. The Intermediate instruction may include an Intermediate Language (IL) generated after the original code is compiled, and since the code injection process is mainly performed based on the Intermediate instruction, the Intermediate instruction corresponding to the initial dynamic library may be determined first. Before the code injection processing is performed, a developer may predefine an instruction system in a private bytecode format, acquire the predefined instruction system when the code injection processing is performed, and generate an intermediate instruction corresponding to the initial dynamic library based on the acquired instruction system. Compared with the code repairing carrier such as the Lua or C # standard program set which is commonly used when the C # program is developed in the prior art, the code repairing process is carried out by adopting the customized private bytecode format, and the code repairing carrier has higher safety.

In step S540, a modify code segment is added to the intermediate instruction according to the configuration file to complete the code injection process. The configuration file records which classes or functions can be subjected to code injection processing, and the modified code segments can be added into intermediate instructions corresponding to the initial dynamic library according to the configuration file so as to complete the code injection processing. Referring to fig. 6 and 7, fig. 6 and 7 schematically show a variation of the intermediate instruction before and after the code injection process is performed.

It should be noted that the code injection operation may be an operation performed before each release of the software version, and if the version update is not performed, the code injection operation may not be performed.

In this exemplary embodiment, after the code injection process is completed, the code repair method further includes: adding the target function mapping identifier to the injected function can be completed through steps S810 to S840.

In step S810, a function subjected to code injection processing is determined from the modified dynamic library as an injected function. The injected function may be a function that modifies the code injection process in the dynamic library. For example, there may be a corresponding modification identifier for the function subjected to the code injection process, and the modification identifier may determine to modify the injected function in the dynamic library. After the code injection process is completed, the injected function can be determined from the modified dynamic library so as to add the corresponding target function mapping identifier to the injected function.

In step S820, the identification format of the function mapping identification is determined. The function mapping identification may be an identification capable of reflecting a mapping between the function information to the function index. The identification format for determining the function mapping identification can be an identification format predefined by a developer according to development requirements. The identification format of the function mapping identification can correspond to various types of formats, and the identification format which meets the specific development requirement can be determined according to the actual application. For example, in this example embodiment, an enumeration type may be adopted to add function mapping identifiers to injected functions, and each injected function corresponds to one function mapping identifier. The identification format may be a predefined format of the function mapping identification, for example, the identification format of the function mapping identification may be a two-part content including a key and a value. Specifically, the identifier format of the function mapping identifier may be: the key (key) of the function mapping identifier may be composed of a name space name, a class name and a function name corresponding to the function, and the value (value) of the function mapping identifier may be composed of an index assigned to the function by the injector.

The function mapping identifier may be an identifier including mapping information of function information to function indexes, and each injected function corresponds to a corresponding function mapping identifier. The identification format of the function mapping identifier may adopt an enumeration format, and specifically, the function mapping identifier may include a key and a value. In the present example embodiment, the key (key) identified by the function map may be composed according to the name space name, class name and function name corresponding to the injected function, and the format of the key may be "name space name _ class name _ function name". The value (value) of the function map identification may be the index assigned by the injector to the function.

In step S830, adding a corresponding target function mapping identifier to the injected function according to the identifier format; wherein the objective function mapping identifier is used for determining a mapping relationship between function information of the injected function and the function index. The target function mapping identity may be a function mapping identity that uniquely corresponds to the injected function. After the predefined identifier format is obtained, a corresponding target function mapping identifier may be added to the injected function according to the identifier format. The mapping relation between the function information of the injected function and the function index can be determined through the target function mapping identification, and in the subsequent process of calling the execution function, the function execution information can be determined according to the determined target function mapping identification. Referring to fig. 9, in the present exemplary embodiment, an operation of adding an objective function mapping identifier to an injected function may be performed through steps S910 to S930 described below. Wherein:

in step S910, a name space name, a class name, and a function name corresponding to the injected function are acquired. In this example embodiment, the identifier format identified according to the function mapping may result in: to define the target function mapping identifier, the name of the namespace, the class name, and the function name corresponding to the injected function may be determined first. And each injected function has a corresponding namespace, class and function, so that the namespace name, class name and function name corresponding to each injected function can be obtained first.

In step S920, the key of the target function mapping identifier is determined by the namespace name, the class name, and the function name based on the identifier format. The identifier format may define a format of a key of the function mapping identifier as "namespace name _ class name _ function name", and therefore, in the present exemplary embodiment, the key of the target function mapping identifier corresponding to the injected function may be determined according to the namespace name, the class name, and the function name corresponding to the function.

Further, if the injected function has a corresponding override function, the key identified by the objective function mapping may be added to the injected function by the steps comprising: determining a reloading function corresponding to the injected function, and determining a corresponding serial number identifier for the reloading function; and combining the name space name, the class name, the function name and the serial number identifier based on the identifier format to generate a key of the target function mapping identifier.

The override function may be a function that has the same function name as the injected function, but a different parameter type than the injected function. The number identification may be an identification used to distinguish a plurality of different reloading functions of the injected function when the injected function has a plurality of reloading functions. Next, a process of adding an objective function mapping flag to the following code segment will be described as an example. In particular, example code segments are shown below.

For "public int Add (int a, int b) in the above code segment; "function adds a reload function" public double Add (double a, double b); after "the following code segments are correspondingly generated:

if the injected function has a corresponding reload function, the reload function corresponding to the injected function can be determined first, and corresponding number identifiers are added to the reload function. For example, when there are heavy-load functions for the injected functions, a suffix number from 0 to N may be added to the heavy-load functions; in addition, if the injected function has a heavy-load function, a Tag mark is automatically added to the heavy-load function. The injected function has two Add functions and one Sub function, that is, the Add function has a reload function, the keys of the target function mapping identifications corresponding to the two Add functions can be "Fix-Test-Call-Add 0" and "IFix-Test-Call-Add 1", respectively, and the key of the target function mapping identification of the injected function Sub function can be "Fix-Test-Call-Sub 0". The enumerated type variable name identified by the target function mapping may be: IDMAP, the result of adding an enumerated type of target function mapping identification to the injected function is as follows:

in addition, in the C # code, the namespace corresponding to one injected function may be empty, and in this case, the namespace name of the injected function is empty. The injected function test and the injected function Start have corresponding key and value information, respectively, and the target function map of test is denoted by "Helloworld-test 0 ═ 5", and the target function map of Start is denoted by "Helloworld-Start 0 ═ 3".

And combining the name space name, the class name, the function name and the serial number identifier based on the identifier format to generate a key of the target function mapping identifier.

In step S930, the index value corresponding to the injected function is used as the value of the target function mapping identifier. The index value may be a corresponding index value assigned by the injector to the injected function, which may be the value identified by the objective function map. For example, the index value of "Helloworld-test 0" in the code segment is 5, and after the value of the target function mapping identifier is determined, the key and the value may be combined to form the target function mapping identifier, so that the patch function executes the corresponding code logic by calling the target function mapping identifier.

In step S840, a patch tag format is determined, and a corresponding patch tag is added to the injected function according to the patch tag format to form a patch function. The patch tag format may be a tag format predefined by a developer. The patch tag may be a tag identification for distinguishing whether a function is a patch function. In the code repairing process, a developer can add a corresponding patch tag for the injected function according to the development requirement and by combining the patch tag format. In modifying a dynamic library, the injected function with the patch tag added may be considered a patch function. For example, a corresponding "[ Patch ]" tag may be added to the Patch function in the code section described above.

In step S330, a function with a patch tag is determined from the modified dynamic library as a patch function, and execution information of the patch function is generated. The patch tag may be a tag for identifying a patch function. For example, "[ Patch ]" may be used as a Patch tag, and a Patch function may be a function that is subjected to a code injection process and is tagged with a Patch tag. In the injected functions, developers modify execution logic of some function codes according to development requirements, and patch tags can be attached to corresponding injected functions according to whether the execution logic of the injected functions is modified or not. In the code repairing process, the patch generator analyzes the modified dynamic library and determines a function with a patch tag from the modified dynamic library as a patch function so as to call the patch function according to the patch tag. By way of example, the following code segment shows the marking of two Add functions and one Sub function as a patch function. The result of the patch function after decompiling is as follows:

specifically, IDTag () may represent a Tag identifier added to a function having a reload function and a patch function corresponding to the function. Because the Add function has a corresponding reload function, Tag identifications are added to the two Add functions respectively. For example, the Tag identification of the function int Add (int a, int b) may be [ IDTag (0) ], and the Tag identification of the function double Add (double a, double b) may be [ IDTag (1) ]. With "public int Add (int a, int b); "function is an example, and the function execution logic is explained as follows: if the if decision condition returns to true, execute "return IFix. Wrappers ManagerImp1.GetPatch (0). __ Gen _ Wrap _0(this, a, b) in the if statement; "code logic; otherwise, the native code logic "return a b" in the original code is executed. The execution logic and "public int Add (int a, int b) of the other two functions in the above code segment; the functions are the same, and the description of this exemplary embodiment is omitted.

In addition, the decompilation result of the IsPatched function is as follows:

specifically, the execution logic of the IsPatched function is to return true when a parameter in the wrapperArray is not null, which indicates that the patch function executes the execution logic in the if statement.

The execution information of the patch function may be information required when the patch function call is made. Specifically, the generating of the execution information of the patch function may include:

(1) acquiring a predefined instruction format, and determining a function instruction of the patch function according to the instruction format; determining a signature identifier of a native function corresponding to the patch function according to the function instruction; wherein the signature identification is used for locating and calling the native function; adding the signature identification to the execution information.

The predefined instruction format may be a custom proprietary bytecode format employed by developers. Because the carriers generally adopted in the prior art for code repair are either Lua scripts or C # standard program sets, the code repair carriers are not ideal in terms of safety. Therefore, for security and ease of execution, the instruction system employed in the present example embodiment is different from the instruction format of the standard Microsoft Intermediate Language (MSIL). The function instruction may be a function instruction corresponding to a patch function determined according to a predefined instruction format. And determining a function instruction corresponding to the patch function in the modified dynamic library after the code injection processing according to a predefined instruction format.

The native function may be code logic contained in the patch function that already exists in the patch function before code injection is performed. The signature identification of the native function may be signature information corresponding to the native function. The signature identification may be used to locate the corresponding native function when executing the patch function. And adding the determined signature identification of the native function to the execution information of the patch function.

In the process of calling and executing the patch function, in many cases, the execution logic for executing the native function is called, so that the native function included in the patch function can be determined first. According to the function instruction of the patch function, the native function to be accessed by the patch function can be determined, and the signature of the native function is generated and used for locating the native function when the patch function is executed.

In addition, when the patch function executes, some types or fields may be called, and corresponding identification information for locating the types and fields is also added to the types and fields for subsequent calling of the patch function.

(2) Judging whether the patch function contains a closure and an iterator or not; if the patch function comprises the closure and the iterator, initializing the closure and the iterator corresponding to the patch function; and adding the closure subjected to the initialization processing and an iterator to the execution information. The closure may be a function that can read other internal variables of the function. Iterators, also known as cursors, can be programmatic interfaces that are visited on various containers (e.g., linked lists or arrays), and developers need not be concerned with the specific content in a container when using an iterator. If the closure and the iterator are used in the patch function, the patch function will include initialization information of these more saturated iterators, which may include the initialization logic of the closure, the initialization logic of the iterator, data definitions, and so on. And adding the closure corresponding to the obtained patch function and information such as initialization logic, data definition and the like of the iterator into the execution information.

(3) Determining signature information of a jump code segment in the patch function according to the code execution redirection information; generating jump execution information of the jump code segment according to the signature information; adding the jump execution information to the execution information. The jump code segment may be a code segment having a jump execution determined by the patch function according to the code execution redirection information. The signature information of the jumped code section may be information such as a signature mark for identifying the jumped code section. The jump execution information may be information indicating execution logic of the jump code section. After the signature information of the jump code segment in the patch function is determined according to the code execution redirection information, the jump execution information of the jump code segment can be generated according to the determined signature information, and the jump execution information is added to the execution information, so that the patch function can be called according to the execution information in the following.

After generating the execution information of the patch function, the code repairing method further includes: generating a patch file corresponding to the patch function according to the patch function and the execution information; acquiring a predefined patch file name format; adding a corresponding patch file name for the patch file according to the patch file name format; and storing the patch file name in a file path of the modified dynamic library so as to call the patch function through the patch file name. The patch file may be a file generated based on a patch function. After the patch function is determined, the patch function and the execution information of the generated patch function may be packaged to generate a patch file corresponding to the patch function, so that the corresponding patch file may be subsequently loaded to repair the error code.

The patch file name may be a file name uniquely corresponding to each patch file. The patch file name format may be a predefined name format for the patch file name. For example, in the present exemplary embodiment, the patch file name format may be defined as "dynamic link library name. After the name format of the patch file is obtained, the corresponding name of the patch file may be added to each patch file according to the name format of the patch file. After the corresponding patch file name is generated for the patch file, the patch file name may be stored in the project directory, so that the repair of the error code may be completed by subsequently loading the patch file. For example, a developer may complete the storage of the patch file by operating a menu under the Unity editor. By clicking on the "InjectFix/Fix" menu, the generated patch file is stored under the project directory in the named format of "DLL name. After the patch file is generated according to the patch function, the call of the patch file can be completed according to a simple loading instruction when the patch file is loaded subsequently, and then the code repair is completed.

In step S340, in response to the code execution instruction, the patch function is called according to the execution information to perform a repair process on the original code. The code execution instruction may be an instruction for calling execution of the code, and the code execution instruction may be generated by an operation of a user. For example, the application program corresponding to the original code is installed on the user side, and when the user performs the operation of updating the software through the user side, the code execution instruction may be generated correspondingly. The repair processing may be a process of repairing some parts of the original code where bugs exist by calling and executing a patch function, and some error logics in the original code may be changed or some parts with incomplete performance may be optimized through the repair processing. In response to the code execution instruction, the patch function may be called according to the execution information, and the called patch function generates a patch file, and the repair processing of the original code may be completed by loading the patch file. Load command may be called to load the patch file to complete the repair process on the original code, for example. By way of example, the following illustrates a code segment that loads a patch file from a file.

The patch path parameter may be a storage path of the patch file, and a corresponding parameter value may be assigned to the patch path parameter through an assignment operation. And in the execution logic of the if statement, judging whether the parameter value of the PatchPath parameter exists, if so, reading out the patch file from the file through a PatchManagerLoad command, loading and executing the patch file, and completing the repair operation of the original code.

Specifically, the patch function is called through the following steps: initializing a virtual machine; calling the patch function through the virtual machine according to the execution information; determining a native function contained in the patch function through a reflection mechanism according to the positioning information; and executing the code section of the patch function and the code section of the native function to complete the calling of the patch function.

The virtual machine may be a virtual machine used in the execution of the patch function. Before the patch function is called, initialization processing of the virtual machine may be performed. Initializing virtual machines may include, but is not limited to: reading the function instruction, reading the positioning information of the native function, reading the closure, the information of the iterator and the like. And reading required information when the patch function executes to initialize the virtual machine. The execution information includes function redirection execution information required when the patch function is executed. For example, a patch function may execute redirection logic in the modify code segment. The function redirection execution information contains signature information of a redirection function to be executed, when a patch function is loaded, the function can be located through the signature information of the redirection function, index information of the function is searched through a target function mapping identifier, and a stub pointed by the index is set. Here, the stub may be, specifically, an adapter, for example, a plurality of function adapters may be placed in one class; in addition, an stub may also be considered an instance of a class, i.e., an object, which may also be referred to as a stub.

After the initialization of these loaded patch functions is completed, the patch functions may be executed. The process of executing the patch function involves the implementation of a analytical virtual machine, which is generally a loop plus a conditional jump, as does the virtual machine in this example embodiment. The specific execution code is as follows:

where pc may be the start instruction and argmentBase may be the stack frame head address. The situation of the stack when entering the loop can be seen with reference to fig. 10. Execution of an instruction may be considered an operation on a stack, for example, "code. The Add instruction may represent a process of popping the two elements at the top of the stack and pushing the results onto the stack after adding the two elements to obtain the result of the operation. Ret "may represent the process of popping the computed result from the stack and returning the resulting value.

Specifically, the specific operation process of executing the corresponding stack by the instruction may be: the method adopts the adapter which comprises a function adapter and an interface adapter, and pushes parameters (attribute) used in the execution of the function into the stack in advance, the number of the parameters in the stack pushing operation can be known in advance before the parameter is pushed, and the position of a first local variable in the stack can be calculated through the number of the parameters. The local variable (localVar) is a variable corresponding to a parameter during execution of the patch function, and each parameter corresponds to one local variable. 1010 in FIG. 10 reflects the state in which the instruction runtime pushes parameters.

After the whole function is executed, the stack is cleared, and the result is placed at the stack frame head address, i.e. the state 1020 in fig. 10, and the stack 1020 stores the result of the return value (return val). Function logic inevitably accesses functions or fields of the current class or other classes, and positioning information of the functions or fields is stored in the patch file, and when the logic is executed, the C # reflection mechanism is used for accessing through the positioning information. Referring to fig. 11, fig. 11 shows the call relationship between the virtual machine 1120 and the native function 1110 when the patch function executes. In step S1110, when performing a hot update, a hot update function is called to perform an operation of adapting code, and in step S1120, it is shown that the operation of adapting code may include, but is not limited to, procedures of constructing a stack, pushing parameters, and calling a virtual machine to execute a method instruction. Specifically, in the process of constructing the stack, the parameters may be pushed according to the parameter list, and as the instruction is executed, a local variable corresponding to the parameter is generated, and the local variable is also stored in the stack 1122, and a method called in the process of executing the instruction is stored in the stack 1123. In the process of calling the execution instruction by the virtual machine, the corresponding executed patch function can be called according to the instruction content, and if the execution logic in the native function needs to be skipped and executed in the process of executing the patch function, the execution logic of the native function is called through a reflection mechanism, so that the calling of the patch function is completed.

Additionally, the storage unit 1124 in the virtual machine shows the contents of the patch file, which may include, but is not limited to, information about external functions, internal function lists, field lists, anonymous classes, external types, internal strings, exception handlers, etc.

It should be noted that a stack is understood as a data structure used to help analyze the instruction execution process, and the operation of the stack may reflect the change of data in the memory during the instruction execution process.

Further, the performance availability of the code repair method is analyzed from the following two dimensions:

(1) when a bug does not need to be changed, the negative impact of the injected code on the software performance is avoided.

According to the process of the code repairing method, under the condition of not redirecting, the Ispatched function call and the branch are added to the code file processed by the code injection compared with the original code. As can be seen from the implementation of the IsPatched function, the function is relatively simple and has a relatively small influence in some application programs that are relatively sensitive to performance, for example, in a Multiplayer Online Battle Arena (MOBA) game program or a racing game program, a frame drop is not found even when all classes are injected, and the performance influence can be considered to be relatively small.

(2) When a bug needs to be modified, the performance gap between the logic after redirection and the original logic is re-determined. The main gaps in this section are the performance loss of the reflection calls, the gap between the resolution execution and the native, etc. These factors add up to two orders of magnitude in the performance of the logic of the redirected logic and the native function, but the problem of bug irreparable due to this reason does not substantially occur in practical applications, because where the performance requirements are high, fewer bugs may occur instead.

Therefore, it is proved by practice that, from the viewpoint of performance requirements, the code repair method in the present exemplary embodiment can also meet the requirements. In addition, in some specific application scenarios, the code repairing method can only realize function modification operation, but is difficult to realize the effect of adding a program function, and instead, the whole code repairing process is more in line with software development rules.

It should be noted that although the various steps of the methods of the present disclosure are depicted in the drawings in a particular order, this does not require or imply that these steps must be performed in this particular order, or that all of the depicted steps must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions, etc.

Further, in the present exemplary embodiment, a code recovery apparatus is also provided. The code repairing device can be applied to a server or terminal equipment. Referring to fig. 12, the code repair apparatus 1200 may include an initial dynamic library acquisition module 1210, a modified dynamic library generation module 1220, an execution information generation module 1230, and a function call module 1240. Wherein:

an initial dynamic library obtaining module 1210, configured to obtain an initial dynamic library generated after the original code is compiled; a modified dynamic library generating module 1220, configured to perform code injection processing on the initial dynamic library to generate a modified dynamic library; an execution information generating module 1230, configured to determine a function with a patch tag from the modified dynamic library as a patch function, and generate execution information of the patch function; and the function calling module 1240 is configured to, in response to the code execution instruction, call the patch function according to the execution information, so as to perform repair processing on the original code.

The specific details of each module or unit in the code recovery apparatus have been described in detail in the corresponding code recovery method, and therefore are not described herein again.

It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method for code recovery, comprising:

acquiring an initial dynamic library generated after compiling an original code;

performing code injection processing on the initial dynamic library to generate a modified dynamic library;

determining a function with a patch label from the modified dynamic library as a patch function, and generating execution information of the patch function; the execution information comprises a signature identification of a native function corresponding to the patch function;

responding to a code execution instruction, and calling the patch function according to the execution information so as to repair the original code; the patch function includes location information of a native function, and the calling the patch function according to the execution information includes: initializing a virtual machine; calling the patch function through the virtual machine according to the execution information; determining a native function contained in the patch function through a reflection mechanism according to the positioning information; and executing the code section of the patch function and the code section of the native function to complete the calling of the patch function.

2. The code repair method of claim 1, wherein the performing code injection processing on the initial dynamic library to generate a modified dynamic library comprises:

determining one or more code modules as modules to be injected based on the initial dynamic library;

generating a configuration file according to the module to be injected;

and performing code injection processing on the initial dynamic library according to the configuration file to generate the modified dynamic library.

3. The code repair method of claim 2, wherein the performing code injection processing on the initial dynamic library according to the configuration file comprises:

acquiring a target function library;

adding a modification code segment to the initial dynamic library according to the configuration file and the target function library to complete the code injection processing;

wherein the modification code segment comprises code execution redirection information of the module to be injected.

4. The method of claim 3, wherein adding a modification code segment to the initial dynamic library according to the configuration file and the objective function library to complete the code injection process comprises:

determining an adapter based on the library of objective functions; wherein the adapter comprises a function adapter and an interface adapter;

generating the modification code segment according to the function adapter and the interface adapter;

determining an intermediate instruction corresponding to the initial dynamic library;

adding the modifying code segment to the intermediate instruction according to the configuration file to complete the code injection process.

5. The code repair method of any of claims 3 or 4, wherein after the completion of the code injection process, the method further comprises:

determining a function subjected to code injection processing from the modified dynamic library as an injected function;

determining an identification format of the function mapping identification;

adding a corresponding target function mapping identifier to the injected function according to the identifier format; wherein the target function mapping identifier is used for determining a mapping relationship between the function information of the injected function and a function index;

determining a patch label format, and adding a corresponding patch label to the injected function according to the patch label format to form a patch function.

6. The code repair method of claim 5, wherein the objective function mapping identifier comprises a key and a value, and wherein adding the corresponding objective function mapping identifier to the injected function according to the identifier format comprises:

acquiring a name space name, a class name and a function name corresponding to the injected function;

determining a key of the target function mapping identifier through the name space name, the class name and the function name based on the identifier format;

and taking the index value corresponding to the injected function as the value of the target function mapping identifier.

7. The code repair method of claim 6, wherein determining the key of the target function mapping identifier by the namespace name, the class name, and the function name based on the identifier format comprises:

determining a reloading function corresponding to the injected function, and determining a corresponding serial number identifier for the reloading function;

8. The code repair method of claim 1, wherein the generating execution information of the patch function comprises:

acquiring a predefined instruction format, and determining a function instruction of the patch function according to the instruction format;

determining a signature identifier of a native function corresponding to the patch function according to the function instruction; wherein the signature identification is used for locating and calling the native function;

adding the signature identification to the execution information.

9. The code repair method of claim 1, wherein the generating execution information of the patch function further comprises:

judging whether the patch function contains a closure and an iterator or not;

if the patch function comprises the closure and the iterator, initializing the closure and the iterator corresponding to the patch function;

and adding the closure subjected to the initialization processing and an iterator to the execution information.

10. The code repairing method according to claim 1, wherein the execution information includes code execution redirection information corresponding to the patch function, and the generating the execution information of the patch function further includes:

determining signature information of a jump code segment in the patch function according to the code execution redirection information;

generating jump execution information of the jump code segment according to the signature information;

adding the jump execution information to the execution information.

11. The code repair method according to any one of claims 1 or 8 to 10, wherein after the generating of the execution information of the patch function, the method further comprises:

generating a patch file corresponding to the patch function according to the patch function and the execution information;

acquiring a predefined patch file name format;

adding a corresponding patch file name for the patch file according to the patch file name format;

and storing the patch file name in a file path of the modified dynamic library so as to call the patch function through the patch file name.

12. A code recovery apparatus, comprising:

the initial dynamic library acquisition module is used for acquiring an initial dynamic library generated after the original code is compiled;

the modified dynamic library generating module is used for performing code injection processing on the initial dynamic library to generate a modified dynamic library;

the execution information generation module is used for determining a function with a patch label from the modification dynamic library as a patch function and generating execution information of the patch function; the execution information comprises a signature identification of a native function corresponding to the patch function;

the function calling module is used for responding to a code execution instruction and calling the patch function according to the execution information so as to repair the original code; the patch function includes location information of a native function, and the calling the patch function according to the execution information includes: initializing a virtual machine; calling the patch function through the virtual machine according to the execution information; determining a native function contained in the patch function through a reflection mechanism according to the positioning information; and executing the code section of the patch function and the code section of the native function to complete the calling of the patch function.

13. An electronic device, comprising:

a processor; and

a memory having stored thereon computer readable instructions which, when executed by the processor, implement the code repair method of any of claims 1 to 11.

14. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out a code repair method according to any one of claims 1 to 11.