A method for repairing module callback function parameter mismatch and related equipment

Abstract

The present invention provides a repair method for module callback function parameter mismatch and related equipment, comprising: obtaining newly created parameters contained in the callback function type in the repair program and original parameters contained in the upper-layer callback function of the source program; comparing the newly created parameters with the original parameters, and taking the parameters in the newly created parameters that are different from the original parameters as newly added parameter information; searching for callback pointers of the original parameter callback functions in all source programs, and using the virtual function interface corresponding to the callback pointer of the callback class to notify the upper layer to allow the basic code to call the extended code corresponding to the newly added parameter information for repair, and then ignore the newly added parameter information, so as to decouple the processing logic of the received data from the underlying data, and notify the upper layer to allow the basic code to call the extended code corresponding to the newly added parameter information for repair, and then ignore the newly added parameter information, so as to solve the problem of program execution crash caused by parameter mismatch.

Description

Technical Field

[0001] The present invention relates to the technical field of computer program software, and in particular to a method for repairing module callback function parameter mismatch and related equipment. Background Art

[0002] In program development, in order to decouple the code, a callback function pointer is usually used to decouple the underlying function from the upper-level caller. The execution of the callback function pointer can notify the caller after the underlying function is executed.

[0003] However, the existing problem is that program developers often develop programs in modules. If some modules upgrade the code functions, such as adding an extra parameter to a callback function that notifies the outside, and another module does not modify all the places where the callback is used to add parameters, the program will crash when it is executed. At the same time, the callback function pointer cannot check the number of its parameters. Therefore, if the underlying module increases the number of function parameters, but the corresponding callback function does not increase the number of parameters, the program does not know that it does not match. Only when the program is executed and the callback function is executed, will the program crash. That is, during the normal operation of the computer system, it crashes for some reason, or the host or program stops working.

[0004] If the program code has not been released, it is easy to fix the function by modifying the program code. However, if the program has been released, a method is needed to fix such parameter mismatch. Summary of the invention

[0005] The present invention provides a method for repairing module callback function parameter mismatch, by searching for callback pointers of original parameter callback functions in all source programs and calling a virtual function interface corresponding to the callback pointer of the callback class, based on the hook repair technology, ignoring the newly added parameter information, so as to solve the problem of program execution crash caused by parameter mismatch.

[0006] A method for repairing module callback function parameter mismatch, including:

[0007] Get the newly created parameters contained in the callback function type in the repair program and the original parameters contained in the upper callback function of the source program;

[0008] Comparing the newly created parameters with the original parameters to obtain newly added parameters; wherein the newly added parameters are parameters that are different between the newly created parameters and the original parameters;

[0009] Find the callback pointers of the original parameter callback functions in all source programs;

[0010] The virtual function interface corresponding to the callback pointer is called, and program repair is implemented based on the hook technology.

[0011] Preferably, the information of the newly added parameters includes the number of parameters, parameter names and parameter types.

[0012] Preferably, the search process of the virtual function interface includes the following steps:

[0013] Write a new class with a nested class, in which a virtual function interface is defined to inherit the class in the source program and implement the processing logic of reading data and generating callbacks;

[0014] Find and record all classes in the source program that are inherited from the source program, and record the creation addresses of the classes that are inherited from the source program;

[0015] And find the address of calling the virtual function interface of the class inherited from the source program;

[0016] Wherein, the process of searching for the address of calling the virtual function interface is implemented through assembly code.

[0017] Preferably, the process of searching for the virtual function interface address includes:

[0018] Parsing the transplanted executable file in the module and parsing out the read-only field; wherein the read-only field stores the name of each class and the corresponding continuation table;

[0019] Traverse the read-only fields, search for all inherited classes by name retrieval, and then create the target class;

[0020] Traversing the classes in the continuation table, and taking the first virtual function corresponding to the target class as the destructor, and calling the position of the destructor corresponding to the continuation table as the matching function;

[0021] Record all target class names that meet the search conditions and the starting address and offset address of the corresponding class relative to the module, and then obtain the actual loading memory address of the module.

[0022] Preferably, the method further comprises establishing a search linked list, which comprises:

[0023] The starting address and offset address of the target class are stored in a search linked list;

[0024] And by comparing the size of the created instantiated object and the address of the storage continuation table, it corresponds to the created target class.

[0025] Preferably, the process of implementing program repair based on hook technology includes:

[0026] Establishing multiple stacks, and pushing register values ​​into the stacks respectively, wherein the number of the stacks is the same as the number of newly created parameters;

[0027] Get the object's virtual table pointer from the instantiation pointer;

[0028] Create a new object pointer register and assign the object pointer to the object pointer register;

[0029] The second function of the virtual table is called, and the calling instruction of the second function is modified into a jump instruction, and redundant parameters are ignored and popped.

[0030] Preferably, the lookup linked table is defined in a 34-bit system or a 64-bit system.

[0031] A repair device for module callback function parameter mismatch, comprising:

[0032] An acquisition module is used to acquire the newly created parameters contained in the callback function type in the repair program and the original parameters contained in the upper layer callback function of the source program;

[0033] A comparison module, used for comparing the newly created parameters with the original parameters to obtain the newly added parameters;

[0034] A search module is used to search for callback pointers of original parameter callback functions in all source programs;

[0035] The repair module is used to use the virtual function interface corresponding to the callback pointer to notify the upper layer to allow the basic code to call the extended code corresponding to the newly added parameter information for repair, and then ignore the information of the newly added parameters, thereby decoupling the processing logic of the received data from the underlying data to achieve program repair.

[0036] A repair server for module callback function parameter mismatch, the server comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the repair method for module callback function parameter mismatch when executing the program.

[0037] A computer readable medium stores a computer program, which, when executed by a processor, implements the steps of a repair method for module callback function parameter mismatch.

[0038] Beneficial Effects

[0039] The present invention provides a method for repairing module callback function parameter mismatch, by searching for callback pointers of original parameter callback functions in all source programs, and using the virtual function interface corresponding to the callback pointer of the callback class, notifying the upper layer to allow basic code to call the extended code corresponding to the newly added parameter information for repair, and then ignoring the newly added parameter information, so as to solve the problem of program execution crash caused by parameter mismatch.

[0040] The present invention solves the problem of difficulty in finding virtual interfaces in assembler programs by writing a class to inherit the previously written class and realizing the virtual interface therein, thereby ensuring that all function calling points are repaired to ensure stable operation of the program. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 The present invention is a flowchart of a method for repairing module callback function parameter mismatch.

[0042] Figure 2 Flowchart of the method for searching for callback pointers of original parameter callback functions in all source programs according to the present invention

[0043] Figure 3 The present invention is a flowchart of the process of searching for the address of a class inherited from a source program and calling a virtual function interface.

[0044] Figure 4 It is a schematic diagram of the structure of the repair device for module callback function parameter mismatch described in the present invention. DETAILED DESCRIPTION

[0045] The following is a description of the implementation of the present invention by specific embodiments. People familiar with the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0046] It should be noted that in the description of the present invention, the terms "middle", "upper", "lower", "lateral", "inner", etc. indicating directions or positional relationships are based on the directions or positional relationships shown in the drawings, which are only for the convenience of description, and do not indicate or imply that the device or element must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0047] In addition, it should be noted that in the description of the present invention, unless otherwise clearly specified and limited, the terms "set", "install", "connect", and "connect" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two elements. For those skilled in the art, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0048] like Figure 1 As shown, based on the technical problem raised by the background technology, the present invention provides a method for repairing module callback function parameter mismatch, comprising:

[0049] Step S110, obtaining the newly created parameters contained in the callback function type in the repair program and the original parameters contained in the upper layer callback function of the source program;

[0050] Specifically, in the case of C language programming language: the source program upper callback function is defined as: void (*Recv_Notify) (void*buff, int recv_length)

[0051] The function pointer type is Recv_Notify, and the callback function contains two original parameters, namely buff and length.

[0052] The callback function in the fix is ​​defined as:

[0053] void(*Recv_Notify)(void*buff,int recv_length,int already_length);

[0054] The function pointer type is a callback function, which contains three new parameters, namely buff, length and intalready_length. Usually, the parameters in the source program and the repair program are obtained by searching.

[0055] Step S120, compare the newly created parameters with the original parameters to obtain the newly added parameters; wherein the newly added parameter information is the different parameters between the newly created parameters and the original parameters, that is, the newly added parameters are the parameters that are added or reduced in the original parameters compared with the newly created parameters; it can be seen that the newly created parameters have an additional parameter int already_length compared with the original parameters, and a new parameter int already_length is added.

[0056] In another embodiment, it also includes obtaining newly added parameter information, including the number of parameters, parameter names, parameter types, etc. Obtaining the parameter information can better determine the cause of the program crash based on the parameter type.

[0057] Step S130, searching for callback pointers of the original parameter callback function in all source programs; in this embodiment, two types of callback pointers in C language and C++ language programs are provided.

[0058] The function pointer of C language can be explained as follows: if a function is defined in a program, then the system will allocate a storage space for the function code during compilation. The first address of this storage space is called the address of this function. And the function name represents this address. Since it is an address, this embodiment can define a pointer variable to store it. This pointer variable is called a function pointer variable, or function pointer for short. The specific C language programming language is as follows:

[0059] typedefvoid(*Recv_Notify)(void*buff,intrecv_length);

[0060] Void Socket_Recv·(Recv_Notify fun_callback){

[0061] fun_callback(buff,length)}

[0062] Recv_Notify is a defined function pointer type, and the callback function contains two parameters, namely, buff and recv_length. Socket_Recv·(Recv_Notify fun_callback){

[0063] After the socket network communication receives the data from the server, it notifies the upper layer through the callback function set in the parameter, thereby decoupling the processing logic of the received data from the underlying socket data. fun_callback(buff,length) is the callback function set in this parameter after the socket network socket receives the data from the server, notifying the upper layer of the data processing layer.

[0064] C++ language class object member function pointer, a type of pointer data type in C++ language, used to store access information of a member function of a specified class with a given parameter list and return value type. Unlike ordinary functions, the call of a class member function has a special implicit parameter that is not written in the parameter list: the address of the class instance. Therefore, C++ class member function calls use the thiscall calling protocol. Class member functions are limited to the class to which they belong.

[0065] The situation of C++ language is as follows:

[0066] class File{

[0067] class Callback{

[0068] Public:

[0069] Virtual~Callback(){}

[0070] virtual voidread(uint8_t*buff,int length)=0;

[0071] };

[0072] Void setCallback(Callback*callback){

[0073] cb = callback;}

[0074] Void ReadFile()

[0075] {cb->read(buff,length)}

[0076] Among them, class File is defined as the File class, that is, the file reading and writing class, class Callback{Public:Virtual~Callback(){} is to establish a virtual destructor; virtual void read(uint8_t*buff, intlength)=0; a virtual function interface is defined.}; allback is a nested class, and contains an interface read, and 2 parameters buff and length; Callback*cb is a member variable, which is used to store the pointer of the callback class set in. VoidsetCallback(Callback*callback){ is an interface, which is used to receive an instance pointer of a class and save it to a member variable. Void ReadFile() is the function that actually reads the file content. After reading, it notifies the upper layer that the content reading is completed and can be processed. cb->read(buff,length) is to call the virtual function interface written before to notify the upper layer.

[0077] Step S140, calling the virtual function interface corresponding to the callback pointer, and implementing program repair based on the hook technology to ignore the newly added parameter information, thereby decoupling the processing logic of the received data from the underlying data to implement program repair.

[0078] This step introduces two situations, one is to use C language to set the callback interface, and the other is to use C++ pointer to set the callback interface. Therefore, this embodiment needs to adopt different solutions to perform repairs in the released program for the above two situations. The specific C++ language repair solution is as follows:

[0079] For C++ language, since an extra parameter is passed into the callback function, and the corresponding function of the callback function set in the upper layer does not add a parameter, a parameter is missing, resulting in a mismatch, which will cause the program to crash when executed. Therefore, a repair solution of this embodiment is to perform Hook code on all virtual function interfaces that call C++ to ignore the last parameter, so as to fix the program crash problem. Due to the characteristics of C++ language, this embodiment needs to find all calling places and perform Hook on all of them, and then ignore the newly added parameter information to solve the problem of program execution crash caused by parameter mismatch, and realize the overall search and replacement of callback functions in the source program.

[0080] like Figure 2 As shown, the overall search process of the callback function in the program is implemented by step 130, and the specific steps of searching for the callback pointer of the original parameter callback function in all source programs are as follows:

[0081] Step 131, write a new class with a nested class, define a virtual function interface in the nested class to inherit the class in the source program, and implement the processing logic of reading data and generating callbacks; in the C++ programming language, you need to write a class to inherit from the previously written class and implement the virtual interface therein. The specific programming language is as follows:

[0082] Class MyCallback:public Callback{

[0083] Virtual~MyCallback(){}

[0084] virtual void read(uint8_t*buff,int length){

[0085] Among them, MyCallback is a newly written class and inherits from the previously written class Callback. Read(uint8_t*buff, int length) is a virtual function interface that can implement the processing logic of generating a callback after reading data.

[0086] Step S132, search and record all classes in the source program that are inherited from the source program, and record the creation address of the class inherited from the source program. The specific implementation process is implemented through assembly code:

[0087] Push edx

[0088] Push ebx

[0089] mov eax,[esi]

[0090] Among them, Push edx is to push the value of register edx into the stack, where edx stores the pointer of parameter buff. Push ebx is to push the value of register ebx into the stack, where ebx stores the value of parameter length. mov eax, [esi], esi stores the pointer of the instantiated object of MyCallback, and this assembly code takes the virtual table pointer of the object from the pointer.

[0091] Step S133, searching for the address of the virtual function interface called by the class inherited from the source program; wherein the process of searching for the address of the virtual function interface called is implemented by assembly code;

[0092] mov ecx,esi

[0093] call dwordptr[eax+4];

[0094] Among them, mov ecx, esi means assigning the object pointer to the ecx register, and call dwordptr[eax+4], this assembly code, calls the second function in the continuation table, the first one is the destructor, corresponding to the read function of this embodiment. This step writes a class to inherit the previously written class and implements the virtual interface therein, so as to find all the calling points of the virtual function pointer in the program, solves the problem of difficulty in finding the virtual interface in the assembler, and then ensures that all the function calling points are repaired to ensure stable operation of the program.

[0095] like Figure 3 As shown, the detailed process of step S133 searching for the address of calling the virtual function interface of the class inherited from the source program is as follows:

[0096] Step S211, parsing the transplanted executable file in the module, and parsing out the read-only field; wherein the read-only field stores the name of each class and the continuation table of the class;

[0097] Specifically, in C++ language, when the compiler compiles it, it will create an RTTI implementation, in which RTTI records the name of each class and the continuation table of this class. The RTTI information is stored in the read-only data segment .rdata of this program, so this embodiment can parse the PE file of the program and parse the .rdata segment according to the PE file format, and then this embodiment traverses the .rdata segment to find all classes inherited from Callback.

[0098] First, find the Callback class from the .rdata segment. As a preferred method, you can find the Callback class based on the class name.

[0099] Step S212, traverse the read-only fields, search for all inherited classes by name search, and then create a target class, and search for all classes whose first virtual function in the continuation table is Callback.

[0100] Step S213, traverse the classes in the continuation table, and use the first virtual function corresponding to the target class as the destructor, and call the position of the destructor corresponding to the continuation table as the matching function;

[0101] If a class inherits from the Callback class, the first function in its corresponding virtual table is the destructor of the Callback class.

[0102] Step S214: record all target class names that meet the search conditions and the starting addresses and offset addresses of the corresponding classes relative to the module, and then obtain the real loading memory address of the module.

[0103] The first item value of MyCallback's virtual table is vftable_dd offset Callback____destructor

[0104] The second value is the second virtual function, corresponding to dd offsetconnectSuccess in this embodiment.

[0105] Based on the search scheme of this embodiment, all class names that meet the requirements and the offset addresses of the corresponding classes relative to the starting address of this module can be found. The search is when the program is not executed, and the program code is searched from the assembly code. The starting position of the program loaded into the memory changes each time the program is executed. Therefore, before loading, the offset address can only be recorded based on the assumed starting address of the memory it is loaded.

[0106] If the starting address of the module is assumed_Start, then the code offset address of the subclass found in the module is assumed_MyCallback_Offset.

[0107] In another embodiment, the process further includes establishing a search linked list, in which the start address and offset address of the target class are stored in the search linked list, and the continuation table address is matched with the target class for easy search.

[0108] Specifically, the size of the instantiated object created is compared with the address of the storage continuation table to correspond to the created target class, and the lookup list is defined in the 34-bit system or 64-bit system mode as follows:

[0109] If (system64) {

[0110] List<uint64_t> offsetlists;

[0111] }else{

[0112] List<uint32_t> offsetlists;

[0113] }

[0114] Offsetlists.push_back(suppose_MyCallback_Offset);

[0115] suppose_MyCallback_Offset.

[0116] Map <uint64_t,List<uint64_t> >class_info;

[0117] Map <uint32_t,List<uint32_t> >class_info;

[0118] class_info[suppose_Start]=offsetlists;

[0119] In addition, this embodiment designs a map separately

[0120] Map<string,uint64_t> class_size

[0121] class_size[MyCallback]=sizeof(MyCallback obj);

[0122] Among them, system64 is defined as a 64-bit system to store addresses, List<uint64_t> offsetlists;

[0123] }else{Otherwise the system is 32 bits, and this embodiment uses 32 bits of data to store addresses.

[0124] List<uint32_t> offsetlists;}

[0125] Offsetlists.

[0126] push_back(suppose_MyCallback_Offset);

[0127] In this embodiment, only suppose_MyCallback_Offset is stored, but the starting address of the module, suppose_Start, is not stored. A map is defined to store all the above data. The definition methods of 34 bits and 64 bits are as follows: Map <uint64_t,List<uint64_t> >class_info; 64-bit system definition method. Map <uint32_t,List<uint32_t> >class_info; 32-bit system definition method. The language program that associates the start address and all offset data in the module is:

[0128] class_info[suppose_Start]=offsetlists;

[0129] In addition, this embodiment designs a separate map to store the instantiation size of each class.<string,uint64_t> class_size The first one is also the name of the class, and the second one is the instantiation object size of the class. class_size[MyCallback]=sizeof(MyCallback obj); The size of the class can be obtained by creating an instance object MyCallback obj of a class and using the system function size_of(obj).

[0130] The offsets of all subclasses found are stored in a linked list, which is convenient for finding all instance objects of the linked list later. The specific way to create the linked list includes 34-bit system or 64-bit system.

[0131] After finding all subclasses that inherit from the Callback class, you then need to find out where specific instantiation objects are created in the code based on the subclasses.

[0132] In another embodiment, a specific embodiment of how to find the code of an object of a class is given, and the specific process is:

[0133] Set the size of the class instantiation object to 4; the size of the class instantiation object is related to the size of the instantiation object of the specific class. The size of the class can be obtained by creating an instance object MyCallback obj of the class and using the system function size_of(obj).

[0134] The call operator_new allocates memory space for instantiation of the class.

[0135] After the memory allocation space is completed with mov ecx,eax, the starting address of the allocated memory is stored in the eax register. For C++ programs, the object pointer of the class usually needs to be stored in the ecx register, that is, the eax register continues to be assigned.

[0136] mov dword ptr[eax], suppose_MyCallback_Offset is the virtual table corresponding to the storage class in the first address space.

[0137] According to the address suppose_MyCallback_Offset, we can find where the instantiation object of the class is created. The specific implementation process is as follows:

[0138] First, traverse the module map, the corresponding programming language is:

[0139] For(auto it=class_info.begin(); it!=class_info.end(); ++it)

[0140] Then we traverse each stored offset, and the corresponding programming language is:

[0141] {For(auto it2=it.second.begin();it2!=it.second.end();++it2){

[0142] Then the above features are used to search all the codes in the program, and by comparing the sizes of the instantiated objects created, the class_size created by the previous embodiment is used to facilitate the search for the class size, and the address of the virtual table is stored to correspond to the created class.

[0143] }

[0144] After finding the positions of all created codes of the class, the offset of the callback function to be found in the virtual table can be found, that is, the position in the virtual table. After finding the position, the call of the function can be matched in the present embodiment.

[0145] The calling function of this embodiment is the second position of the virtual table.

[0146] call dwordptr[eax+4],

[0147] Then the calculation formula for this virtual table position is as follows:

[0148] If the system is 64 bits, offset = eax + 8 * no; where no indicates the position in the virtual table.

[0149] If the system is 32 bits, offset = eax + 4 * no;

[0150] After finding these addresses, all the places where the callback function was set before calling this embodiment are found.

[0151] This embodiment needs to find all the call sites and hook them all, so as to ignore the newly added parameter information to solve the problem of program execution crash caused by parameter mismatch, and realize the overall search and replacement of callback functions in the source program.

[0152] Hook is a hook function that notifies the upper layer to allow the basic code to call the extended code corresponding to the newly added parameter information for repair. The hook repair process is:

[0153] After finding all the locations where objects are created and the corresponding functions are called, the original code is called as follows:

[0154] Push eax

[0155] Push edx

[0156] Push ebx

[0157] mov eax,[esi]

[0158] mov ecx,esi

[0159] call dwordptr[eax+4]

[0160] Among them, Push edx is to push the value of register edx into the stack, where edx stores the pointer of parameter buff, Push ebx is to push the value of register ebx into the stack, where ebx stores the value of parameter length, mov eax, [esi] esi stores the pointer of instantiated object of MyCallback, and this assembly code is to extract the virtual table pointer of the object from the pointer. mov ecx, esi This assembly code means to assign the object pointer to the ecx register. Call dwordptr [eax + 4] This assembly code is to call the second function of the virtual table.

[0161] The solution of this embodiment modifies the Hook repair process by modifying the call instruction to a jmp instruction, that is, modifying the call instruction to a switch instruction, then taking data from the stack to call call dwordptr[eax+4], and popping out an extra set received data length from the stack, so the called call function still only needs to pass in 2 parameters.

[0162] After modification, it is as follows:

[0163] Push eax

[0164] Push edx

[0165] Push ebx

[0166] mov eax,[esi]esi

[0167] mov ecx,esi

[0168] Jump newmemory / /

[0169] This time it needs to be modified into a jump instruction, and the destination address of the jump instruction is newmemory. Then newmemory is a newly allocated executable memory space in this embodiment. Implementation of Newmemory. In newmeory, this embodiment allocates an executable memory space through a system function. Newmeory VirtualAlloc(NULL,Size,MEM_COMMIT,PAGE_EXECUTE_READWRITE);

[0170] After the memory space is allocated, this embodiment needs to write the corresponding assembly code for execution. The specific process is:

[0171] Pop ebx

[0172] Pop edx

[0173] Pop ecx

[0174] Move ecx,esi

[0175] Push ebx

[0176] Push edx

[0177] call dwordptr[eax+4]

[0178] Among them, Pop ebx is the pop parameter, Pop edx is the pop parameter, Pop ecx pops an extra parameter, Move ecx, esi is to restore the pointer of ecx to the pointer of the object, Push ebx, Push edx call dwordptr[eax+4] only passes in two parameters when calling, thus ensuring that the parameters are matched. If there is another mismatch, that is, one parameter is missing. You can add a push operation in the above code to push one more parameter, that is, pass one more parameter in the register.

[0179] This embodiment uses the hook repair technology to modify the call instruction to a jmp instruction, then takes out data from the stack to call call dwordptr[eax+4], and pops out an extra set received data length from the stack. Only two parameters need to be passed in, making the repair process simpler, and both increasing and decreasing parameters can be taken into account, thereby ensuring the stability of program repair.

[0180] Design a repair solution for the C language. The specific implementation process is as follows:

[0181] The situation with C language is much simpler, wherein the following embodiment shows the assembly code for calling a function with C language.

[0182] push ebx

[0183] push ebx

[0184] push ffset Recv_Notify.

[0185] call read

[0186] Assuming the starting address of the module is suppose_Start, the code offset address of the found subclass in the module is suppose_Recv_Notify_Offset

[0187] The actual loaded memory offset algorithm is as follows:

[0188] Offset=suppose_Recv_Notify_Offset-suppose_Start+RealStart

[0189] Calculate the offset from the program based on the program's disassembled code and look for code features:

[0190] push ebx push parameter

[0191] push ebx push parameter

[0192] push Offset Here, this embodiment requires the corresponding callback function pointer to be passed in.

[0193] call read calls the specific corresponding function.

[0194] Only the above-mentioned assembly code features meet the needs of this embodiment to be searched, so as to repair all the found situations by supplementing parameters or reducing parameters. Among them, push ffset Recv_Notify is the function pointer of the callback function found, and Recv_Notify is the written function pointer. Using the search method of this embodiment, it is easy to find all the locations where the calling function is used, and all the calling points can be found. Based on the calling points, the parameter mismatch problem can be repaired in a C++ way.

[0195] The implementation adds a parameter to the existing callback function parameters, and takes the C++ language repair process as an example for further explanation:

[0196] For C++ language, the situation is as follows:

[0197] virtual void read(uint8_t*buff,int length,int already_length)=0;

[0198] A parameter int already_length is added to indicate how much data in the file has been read. For C++ language, since an extra parameter is passed into the callback function, and the corresponding function of the callback function set in the upper layer does not add a parameter, a parameter is missing, resulting in a mismatch, which will cause the program to crash when executed. Therefore, a repair solution of this embodiment is to hook the code for all virtual function interfaces that call C++ to ignore the last parameter, so as to fix the program crash problem. Due to the characteristics of C++ language, this embodiment needs to find all calling places and hook them all.

[0199] Step 1: Find all the calling points of the virtual function pointers. This embodiment needs to implement the corresponding callback function, so this embodiment needs to write a class to inherit from the previously written class and implement the virtual interface therein.

[0200] Class MyCallback:public Callback{

[0201] Virtual~MyCallback(){}

[0202] virtual void read(uint8_t*buff,int length){

[0203] }

[0204] Among them, MyCallback is a newly written class and inherits from the previously written class Callback. Read(uint8_t*buff, int length) is a virtual function interface that can implement the processing logic of generating a callback after reading data.

[0205] Step 2: Search for callback pointers of the original parameter callback functions in all source programs. The search ideas provided in this embodiment are as follows:

[0206] push 4;

[0207] MyCallback obj;

[0208] size_of(obj);

[0209] call operator_new;

[0210] mov ecx;

[0211] mov dwordptr[eax];

[0212] suppose_MyCallback_Offset;

[0213] Among them, push 4 is the size of the instantiation object of the class. The size of the class can be obtained by creating an instance object MyCallback obj of the class and using the system function size_of(obj). call operator_new is used to allocate memory space for the instantiation of the class. mov ecx,eax is used to allocate memory space. After the memory space is allocated, the allocated memory start address is stored in the eax register. The object pointer of the class is stored in the ecx register for assignment. mov dword ptr[eax],suppose_MyCallback_Offset is the virtual table corresponding to the storage class in the first address space. The address of the instantiation object of the created class can be found based on the address of suppose_MyCallback_Offset.

[0214] Step 3: Create class_size to find the size of the class and store the address of the virtual table to correspond to the created class. The specific implementation process is as follows:

[0215] call dwordptr[eax+4], callback the second function of the continuation table, if the system is 64 bits, offset = eax+8*no; if the system is 32 bits, offset = eax+4*no; among them, no is the position in the virtual table.

[0216] Step 4: After finding all the locations where objects are created and the corresponding functions are called, fix the problem of one more parameter by hooking. The original code call is as follows:

[0217] Pop ebx

[0218] Pop edx

[0219] Pop ecx

[0220] Move ecx,esi

[0221] Push ebx

[0222] Push edx

[0223] call dwordptr[eax+4]

[0224] Among them, Pop ebx is a pop-up parameter, Pop edx is a pop-up parameter, Pop ecx pops an extra parameter, Move ecx, esi is to restore the pointer of ecx to the pointer of the object, Push ebx, Push edx call dwordptr[eax+4], and only two parameters are passed in during the call, thereby ensuring that the parameters of this embodiment are matched. If there is another mismatch, a parameter is missing. A push operation can be added to the above code to push one more parameter, that is, one more parameter is passed in. The function pointer of the callback function set in this embodiment adopts the search method of nested class inheritance, which can find all the addresses of the callback function and obtain all the call points that should be obtained. Based on the call point, this method repairs the parameter mismatch problem in a C++ way, with good repair effect and stable operation.

[0225] like Figure 4 As shown, this embodiment also provides a repair device for module callback function parameter mismatch, including: an acquisition module 310, a comparison module 320, a search module 330 and a repair module 340.

[0226] Among them, the acquisition module 310 is used to obtain the newly created parameters contained in the callback function type in the repair program and the original parameters contained in the upper-level callback function of the source program; the comparison module 320 is used to compare the newly created parameters with the original parameters to obtain the newly added parameters; the search module 330 is used to find the callback pointer of the original parameter callback function in all source programs; the repair module 340 is used to use the virtual function interface corresponding to the callback pointer to notify the upper layer to allow the basic code to call the extended code corresponding to the newly added parameter information for repair, and then ignore the information of the newly added parameters, thereby decoupling the processing logic of the received data from the underlying data to achieve program repair.

[0227] The repair device stores a repair program with repair function, which enables the program to be developed in modules. The module upgrades the code function and can check the calling location of the callback function pointer. When the callback function is executed, the computer program can be guaranteed to run stably, effectively avoiding downtime caused by parameter mismatch, or host or program stopping working.

[0228] In another embodiment, the present invention also provides a repair server for module callback function parameter mismatch, the server includes a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executes the program as the steps of the above method, and the computer program stored in the repair server for module callback function parameter mismatch can stably run the repair code.

[0229] In another embodiment, the present invention further includes a computer-readable medium having a computer program stored thereon, wherein the program implements the steps of the above method when executed by a processor.

[0230] In another embodiment, the present invention further provides a repair system for block callback function parameter mismatch, including a repair server for module callback function parameter mismatch.

[0231] The present invention provides a method for repairing module callback function parameter mismatch, by searching for callback pointers of original parameter callback functions in all source programs, and using the virtual function interface corresponding to the callback pointer of the callback class to notify the upper layer to allow the basic code to call the extension code corresponding to the newly added parameter information for repair, thereby ignoring the newly added parameter information, so as to solve the problem of program execution crash caused by parameter mismatch. The present invention writes a class to inherit the previously written class, and implements the virtual interface therein, so as to find all the calling points of the virtual function pointer in the program, solves the problem of difficulty in finding the virtual interface in the assembler, and then ensures that all function calling points are repaired to ensure stable operation of the program.

[0232] So far, the technical solutions of the present invention have been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it is easy for those skilled in the art to understand that the protection scope of the present invention is obviously not limited to these specific embodiments. Without departing from the principle of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will fall within the protection scope of the present invention.

Claims

1. A method for repairing module callback function parameter mismatch, characterized in that: include: Get the newly created parameters contained in the callback function type in the repair program and the original parameters contained in the upper callback function of the source program; Comparing the newly created parameters with the original parameters to obtain newly added parameters; wherein the newly added parameters are parameters that are different from the original parameters; and information about the newly added parameters includes the number of parameters, parameter names, and parameter types; Find the callback pointers of the original parameter callback functions in all source programs; Call the virtual function interface corresponding to the callback pointer, and implement program repair based on hook technology; The virtual function interface search process includes the following steps: writing a new class with a nested class, wherein the virtual function interface is defined in the nested class to inherit the class in the source program and realize the processing logic of reading data and generating callback; searching and recording all classes in the source program that inherit from the source program, and recording the creation address of the class inherited from the source program; and searching for the address of calling the virtual function interface of the class inherited from the source program; wherein the process of searching for the address of calling the virtual function interface is realized by assembly code; The process of searching for the virtual function interface address includes: parsing the executable file transplanted in the module and parsing out the read-only field; wherein the read-only field stores the name of each class and the corresponding continuation table; traversing the read-only field, searching all inherited classes by name retrieval, and then creating a target class; traversing the classes in the continuation table, and taking the first virtual function corresponding to the target class as a destructor, and calling the position of the destructor corresponding to the continuation table as a matching function; recording all target class names that meet the search conditions and the corresponding class's starting address and offset address relative to the module, and then obtaining the real loading memory address of the module; The repair method further includes establishing a search linked list, which includes: storing both the starting address and the offset address of the target class in the search linked list; and corresponding to the created target class by comparing the size of the created instantiated object with the address of the storage continuation table; The process of implementing program repair based on hook technology includes: establishing multiple stacks and pushing register values ​​into the stacks respectively, wherein the number of the stacks is the same as the number of newly created parameters; taking out the virtual table pointer of the object from the instantiation pointer; creating a new object pointer register and assigning the object pointer to the object pointer register; calling the second function of the virtual table, and modifying the calling instruction of the second function to a jump instruction, ignoring and popping out redundant parameters.

2. The method for repairing module callback function parameter mismatch according to claim 1, characterized in that: The search linked table is defined in a 34-bit system or a 64-bit system.

3. An electronic device comprising a memory and a processor, characterized in that: The processor is used to implement the steps of the method for repairing module callback function parameter mismatch described in any one of claims 1-2 when implementing the computer management program stored in the memory.

4. A computer-readable medium having a computer program stored thereon, wherein when the program is executed by a processor, the steps of the method for repairing module callback function parameter mismatch described in any one of claims 1-2 are implemented.

Images