A GDB command intelligent recognition method based on machine learning composite model

Abstract

The present invention discloses a GDB command intelligent recognition method based on a machine learning composite model. The method comprises the following steps: constructing a first program set and a first GDB command set, using commands in the first GDB command set to traverse and debug typical programs in the first program set, and obtaining an instruction debugging information set; using the constructed GDB command feature extraction model to process the instruction debugging information set to obtain instruction debugging features, forming a training sample set from the instruction debugging features and GDB command encoding, and using the training sample set to complete the training of a GDB command prediction model. When in use, the user's GDB command instruction debugging information is input into the GDB command prediction model to obtain the corresponding standard GDB command, and the GDB command recognition is completed, thereby avoiding errors in the debugging process and improving the efficiency and accuracy of user GDB command recognition.

Description

Technical Field

[0001] The present invention belongs to the technical field of computer software development, and in particular relates to a GDB command intelligent recognition method based on a machine learning composite model. Background Art

[0002] With the development of code debugging technology, many open source code debugging tools have emerged, such as the open source debugging visualization tool VS Code Debug Visualizer developed by VS Code, the error tracking and debugging tool Sentry, the Python integrated development environment PyCharm, etc. Open source code debugging tools play an important role in software development, helping developers to efficiently discover, diagnose and fix errors in the code. These tools have their own characteristics and are suitable for different programming languages ​​​​and debugging needs. At the same time, the debugger GDB in the GNU project has also appeared in many specially modified GDB versions. However, some GDB commands in these modified GDBs may have different names or functions from standard GDB commands, which may cause users to be unable to debug or debug errors when using GDB to debug code. Summary of the invention

[0003] In view of this, the present invention provides a GDB command intelligent recognition method based on a machine learning composite model, which realizes accurate recognition of user GDB commands based on a combination of a relationship extraction model and a machine learning model.

[0004] The present invention provides a GDB command intelligent recognition method based on a machine learning composite model, which specifically includes the following steps:

[0005] Step 1, constructing a first program set including typical programs, constructing a first GDB command set including known GDB commands, and establishing GDB command codes for the GDB commands in the first GDB command set; using GDB commands to traverse and debug typical programs in the first program set, obtaining instruction debugging information to form an instruction change information set, a signal information set, a system call information set, a GDB output information set, and a command input information set;

[0006] Step 2: annotate the features of the before and after change information in the instruction change information set to form an instruction change annotation file set as the first sample set; construct a GDB command feature extraction model, and use the first sample set to complete the training and verification of the GDB command feature extraction model; input the instruction change information set into the trained GDB command feature extraction model to obtain the instruction change features;

[0007] Step 3: The instruction change characteristics, signal information, system call information, GDB output information and command input information of the same GDB command constitute the GDB command characteristics of the GDB command, and the GDB command characteristics are cleaned and labeled to obtain the GDB command characteristic code, and the GDB command characteristic code is used as the data feature and the GDB command code is used as the label to form a sample, and a second sample set is constructed;

[0008] Step 4: construct a GDB command prediction model, score the prediction results of the GDB command prediction model, and use the second sample set to complete the training and verification of the GDB command prediction model;

[0009] Step 5. During actual use, a standard test program is constructed, and the user GDB command to be predicted is used to debug the standard test program, and information before and during debugging is obtained to form user instruction change information, user signal information, user system call information, user GDB output information, and user command input information; the user instruction change information, user signal information, user system call information, user GDB output information, and user command input information are input into the trained GDB command prediction model to obtain the standard GDB command corresponding to the user GDB command.

[0010] Furthermore, the GDB command feature extraction model in step 2 is a relationship extraction model, an entity extraction model or a triple extraction model.

[0011] Furthermore, the GDB command prediction model is a logistic regression model, a decision tree model, a support vector machine model or a naive Bayes model.

[0012] Furthermore, the F1 score is used to score the prediction results of the GDB command prediction model.

[0013] Furthermore, a prediction result debugging standard test program is used to obtain information during the debugging process to form verification instruction change information, verification signal information, verification system call information, verification GDB output information and verification command input information; the verification instruction change information, verification signal information, verification system call information, verification GDB output information and verification command input information are compared with the user instruction change information, user signal information, user system call information, user GDB output information and user command input information. If they are the same, it means that the prediction result is accurate; otherwise, it means that the prediction result is wrong and step 5 is executed again.

[0014] Furthermore, the GDB commands corresponding to the GDB command code include breakpoint commands, single-step debugging commands, start debugging commands, exit debugging commands and query register commands.

[0015] Furthermore, the Strace tool is used to monitor the GDB process to obtain system call information related to the GDB command.

[0016] Furthermore, the signal information set in step 1 includes a SIGTRAP signal, a SIGINT signal, a SIGSEGV signal, and a SIGFPE signal. Beneficial Effects

[0017] The present invention constructs a first program set and a first GDB command set, uses commands in the first GDB command set to traverse and debug typical programs in the first program set, and obtains an instruction debugging information set; uses the constructed GDB command feature extraction model to process the instruction debugging information set to obtain instruction debugging features, and forms a training sample set from the instruction debugging features and GDB command encoding. The training sample set is used to complete the training of the GDB command prediction model. When in use, the user's GDB command instruction debugging information is input into the GDB command prediction model to obtain its corresponding standard GDB command, complete the recognition of the GDB command, avoid errors in the debugging process, and improve the efficiency and accuracy of user GDB command recognition. DETAILED DESCRIPTION

[0018] The present invention is described in detail with reference to the following embodiments.

[0019] The present invention provides a GDB command intelligent recognition method based on a machine learning composite model, the core idea of ​​which is: constructing a first program set and a first GDB command set, using commands in the first GDB command set to traverse and debug typical programs in the first program set to obtain an instruction debugging information set; using the constructed GDB command feature extraction model to process the instruction debugging information set to obtain instruction debugging features, forming a training sample set from the instruction debugging features and GDB command encoding, using the training sample set to complete the training of a GDB command prediction model, and when in use, inputting user GDB command instruction debugging information into the GDB command prediction model to obtain its corresponding standard GDB command, thereby completing the recognition of the GDB command.

[0020] The present invention provides a GDB command intelligent recognition method based on a machine learning composite model, which specifically includes the following steps:

[0021] Step 1, construct a first program set including multiple typical programs, construct a first GDB command set including multiple known GDB commands, encode the GDB commands in the first GDB command set to form GDB command codes; select GDB commands from the first GDB command set, traverse the typical programs in the first program set, use GDB commands to debug the typical programs, and obtain instruction debugging information including instruction change information, signal information, system call information, GDB output information and command input information during the debugging process, and form an instruction change information set, a signal information set, a system call information set, a GDB output information set and a command input information set respectively.

[0022] Among them, instruction change information refers to the memory address space change information of a typical program during debugging, signal information refers to the system debugging signal called by the GDB command, system call information refers to the Ptrace system call used by the GDB command, GDB output information refers to the information output after the GDB command is executed, and command input information refers to the information input when using the GDB command, and the command input information includes the name and / or parameters of the command. System debugging signals are signals sent by the operating system to the process during debugging, including SIGTRAP signals, SIGINT signals, SIGSEGV signals, SIGFPE signals, etc.

[0023] Step 2: Annotate the features of the before and after change information in the instruction change information set to form an instruction change annotation file set as the first sample set; construct a GDB command feature extraction model, and use the first sample set to complete the training and verification of the GDB command feature extraction model; input the instruction change information set into the trained GDB command feature extraction model to obtain the instruction change features output by the GDB command feature extraction model.

[0024] Among them, the GDB command feature extraction model can adopt a relationship extraction model, an entity extraction model, a triple extraction model, etc.

[0025] Step 3: The instruction change characteristics, signal information, system call information, GDB output information and command input information of the same GDB command constitute the GDB command characteristics of the GDB command. Data cleaning and label encoding are performed on each type of GDB command characteristics to obtain the GDB command feature code. The GDB command feature code is used as the data feature and the GDB command code is used as the label to form a sample to construct the second sample set.

[0026] Step 4: Build a GDB command prediction model based on the logistic regression model, use the F1 score to score the prediction results of the GDB command prediction model, and use the second sample set to complete the training and verification of the GDB command prediction model.

[0027] The GDB command prediction model may also adopt a decision tree model, a support vector machine (SVM) model, or a naive Bayes model.

[0028] Step 5. During actual use, a standard test program is constructed, and the user GDB command to be predicted is used to debug the standard test program, and information before and during debugging is obtained to form user instruction change information, user signal information, user system call information, user GDB output information, and user command input information; the user instruction change information, user signal information, user system call information, user GDB output information, and user command input information are input into the trained GDB command prediction model to obtain a prediction result of the user GDB command, which is a standard GDB command with the same function as the user GDB command.

[0029] In order to further improve the accuracy of the user GDB command prediction results, the present invention debugs the standard test program by using the prediction results, i.e., the standard GDB command, obtains information during the debugging process, and forms verification instruction change information, verification signal information, verification system call information, verification GDB output information and verification command input information; the verification instruction change information, verification signal information, verification system call information, verification GDB output information and verification command input information are compared with the user instruction change information, user signal information, user system call information, user GDB output information and user command input information. If they are the same, it means that the prediction result is accurate; otherwise, it means that the prediction result is wrong and step 5 is executed again for prediction. Example

[0030] In this embodiment, a GDB command intelligent recognition method based on a machine learning composite model provided by the present invention is adopted to realize the recognition of standard GDB command types such as breakpoint command breakpoint, single-step debugging command next, start debugging command run, exit debugging command quit, and register query command info reg, including the following steps:

[0031] S1. Build a model training database. Build a comparison information database, which contains the following attributes: instruction change information, signal information, system call information, GDB output information, and command input information. The specific construction process is as follows:

[0032] S1.1. Obtain instruction change information.

[0033] Through the child_process module in Node.js, create the current GDB terminal process, and use methods such as GDBProcess.stdout.on and GDBProcess.stderr.on to obtain GDB output data in real time, and then use the GDBProcess.stdin.write method to pass the GDB command to the GDB debugger.

[0034] Use this terminal process to debug the target executable program. The debugged executable program is attached to the current terminal process in the mode of a child process, and the PID information of the current terminal process and the child process is saved. Use the saved PID information to retrieve the memory area information of the debugged process through the VirtualQuery function in the Windows API. The sample code is as follows:

[0035] #include<windows.h>

[0036] #include<stdio.h>

[0037] int main()

[0038] {

[0039] MEMORY BASIC INFORMATION mbi, SIZE T bytesReturned;

[0040] LPVOID address = NULL; / / Start from the lowest end of the address space

[0041] while(bytesReturned = VirtualQuery(address, &mbi, sizeof(mbi)),bytesReturned){

[0042] printf("Base Address:%p\n",(void*)mbi.BaseAddress);

[0043] printf("Region size:%lx\n",mbi.Regionsize);

[0044] printf("state:%lu\n",mbi.state);

[0045] printf("Protect:%lu\n",mbi.Protect);

[0046] printf("Type:%lu\n",mbi.Type);

[0047] / / ...You can print other fields as needed

[0048] / / Move to the next memory area

[0049] address =(LPBYTE)mbi.BaseAddress + mbi.RegionSize;

[0050] }

[0051] if (bytesReturned == 0) {

[0052] / / Handle VirtualQuery failure

[0053] printf("VirtualQuery failed with error:%lu\n",GetLastError()),

[0054] }

[0055] return 0;

[0056] }

[0057] In the above code, starting from the lowest end of the address space (NULL), VirtualQuery is called iteratively until there are no more memory areas to query, that is, bytesReturned is 0. Each iteration prints out the information of the current memory area and moves the address to the starting position of the next memory area. Through this method, the memory start address and end address of the debugged process are obtained, and the memory address and other information of the debugged process are read in real time; then the memory of the debugged process is read through the ReadProcessMemory function in the Windows API.

[0058] In this embodiment, a script is used to implement the above process. First, the stored PID process is used to obtain the handle of the target process using the OpenProcess function, as shown in the following code:

[0059] HANDLE hProcess = OpenProcess(PROCESS VM READ, FALSE,targetProcessId);

[0060] if(hProcess == NULL){

[0061] / / Handle errors, such as printing error messages or exiting the program

[0062] }

[0063] The memory address and size to be read are calculated by using the saved start address and end address, and then stored as lpBaseAddress and nSizeToRead, as shown in the following code:

[0064] SIZE T bytesRead;

[0065] LPCVOID lpBaseAddress=(LPCVOID)targetMemoryAddress; / / target memory address

[0066] SIZET nSizeToRead=sizeof(YOUR DATA TYPE); / / Number of bytes to read

[0067] Allocate a buffer for the read data and call the ReadProcessMemory function, as shown in the following code:

[0068] / / Read memory

[0069] BOOL success = ReadProcessMemory(hProcess, targetAddress, buffer.data(), buffersize, &bytesRead);

[0070] if(!success){

[0071] std::cerr <<"Failed to read memory, error code: "< <GetLastError()<< std::endl;

[0072] CloseHandle(hProcess);

[0073] return 1;

[0074] }

[0075] / / Process the read data (here just simply print it out)

[0076] std::cout<<"Read data:";

[0077] for(SIZE_T i=0; i< bytesRead; ++i){

[0078] printf("%02x", buffer[i]);

[0079] }

[0080] std::cout<< std::endl;

[0081] / / Close the process handle

[0082] CloseHandle(hProcess);

[0083] The information in all the acquired addresses is stored. After each GDB command is executed, the changes in the corresponding memory addresses before and after the debugged program are compared, and the instruction change information is saved.

[0084] For example, the principle of setting breakpoints is mainly based on special instructions of the CPU and the debugging mechanism of the operating system. INT 3 is a trap instruction, also known as the call instruction of the debug exception handling routine. Its instruction code is 0xCC, which is a single-byte opcode. When the CPU executes the INT 3 instruction, it will fall into the kernel and execute the INT 3 exception handling code. When comparing the before and after execution of the GDB command, it is found that the instruction data of a certain address is replaced with INT 3, then it can be inferred that the function of this instruction is to add a breakpoint at this address.

[0085] S1.2. Get system call information.

[0086] The GDB debugger implements debugging functions based on the Ptrace system call. The mechanism provided by the Ptrace system call enables the tracer program, i.e. the GDB debugger, to observe and control the execution of another traced program (i.e. the debugged program), while checking and changing the memory and registers of the traced program. This is essential for implementing debugging functions such as breakpoint debugging, single-step execution, and tracing system calls. The system calls used by GDB mainly include:

[0087] PTRACE_TRACEME: Put the current process into the traced state.

[0088] PTRACE_ATTACH: Attach to another process and start tracing it.

[0089] PTRACE_DETACH: Stop tracing a process.

[0090] PTRACE_CONT: Continue running a stopped process.

[0091] PTRACE_GETREGS: Get the register values ​​of the traced process.

[0092] PTRACE_SETREGS: Set the register values ​​of the traced process.

[0093] PTRACE_PEEKUSER: Read the user area data of the traced process.

[0094] PTRACE_POKEUSER: Write data to the user area of ​​the traced process.

[0095] Use the Strace tool to intercept and record system calls issued by the process and signals received. Use Strace to monitor the GDB process to see if it calls Ptrace.

[0096] Start the Strace process through the spawn method in the child_process module in NodeJS, and use the Strace tool to monitor the system call information of the current GDB process. For example, through the strace -v -o strace.log -p 1234 command, the system call information of process 1234 is output to the strace.log file. By continuously reading the content of strace.log, the system call information can be obtained.

[0097] S1.3. Obtain signal information.

[0098] When GDB starts debugging command execution, it usually sends a series of system debugging signals to interact and control the debugged process. The specific types and functions of these system debugging signals may vary depending on the operating system and GDB version. The following are some common signals and their functions during debugging:

[0099] SIGTRAP:

[0100] When the GDB debugger pauses a program at a breakpoint, it usually sends a SIGTRAP signal to the debugged process. The SIGTRAP signal is a trap signal used to indicate that the program has reached a preset breakpoint or other situations that require debugger intervention have occurred.

[0101] SIGCONT:

[0102] After pausing the debugged process, if the developer wants to continue executing the program, the GDB debugger will send a SIGCONT signal to resume the execution of the process. The SIGCONT signal is used to continue the execution of the previously stopped process.

[0103] Other signals:

[0104] GDB may also send other types of signals to the debugged process as needed, such as interrupt signal SIGINT, termination signal SIGTERM, etc. These signals are usually used to control the execution flow of the program during debugging, such as interrupting the current execution, requesting program termination, etc.

[0105] Ptrace is one of the basic and core mechanisms for GDB to implement debugging functions, supporting GDB to effectively track and control the execution of the debugged program. GDB can capture the signals received by the debugged program, such as the interrupt signal SIGINT, the termination signal SIGTERM, etc.

[0106] Also use the Strace tool to continuously monitor the GDB process and obtain the signal information sent before and after the GDB command is executed.

[0107] S1.4. GDB output information.

[0108] The output information of the GDB debugger mainly provides debugging information such as the status of the program, the value of the variable, and the execution location. The GDB output information can be used to infer the possible commands to be executed. For example, when setting a breakpoint, the GDB debugger will display the location of the breakpoint, such as the file name and line number. By viewing this information, it can be inferred that a command may be used to set the breakpoint. For example, in the standard GDB environment, when a breakpoint command is entered, data information in the GDB output format of Breakpoint 1 at xxx can be monitored.

[0109] This embodiment uses the GDBProcess.stdout.on and GDBProcess.stderr.on methods to obtain the output information of the GDB debugger in real time.

[0110] S1.5. Command input information.

[0111] This embodiment uses the GDBProcess.stdin.on method to obtain the input data of the GDB process in real time.

[0112] S2. Acquisition of sample data.

[0113] In this embodiment, five common GDB commands, namely, breakpoint, single-step debugging next, start debugging run, quit debugging quit, and query register info reg, are debugged multiple times. Each debugging obtains instruction change information, signal information, system call information, GDB output information, and command input information. These feature information are collected and organized into a model training data table. The specific summary is as follows:

[0114] S2.1. Breakpoint.

[0115] The following information can be obtained by debugging related to breakpoints. This information is put into the model training data table, for example, row 1.

[0116] Instruction change characteristics: GDB inserts the INT 3 instruction at the breakpoint location.

[0117] Signal characteristics: When a breakpoint is hit, a SIGTRAP signal is triggered. When the program runs to a breakpoint, a SIGTRAP signal is triggered.

[0118] System call feature: PTRACE_POKETEXT is used to write a byte to the memory address of the debugged process. This is usually used to insert instructions (such as INT 3 instructions, used to set breakpoints) or modify data at a specific location in the debugged process.

[0119] GDB output information: Outputs feature information including "Breakpoint 1 at".

[0120] Command input: breakpoint 1.

[0121] S2.2. Single-step debugging next.

[0122] The following information can be obtained by single-step debugging. This information is put into the model training data table, such as row 2.

[0123] Instruction change characteristics: the previous line is restored and the next line is replaced by the INT 3 instruction.

[0124] Signal characteristics: Set the debugged process to single-step execution mode. In single-step execution mode, when the debugged process completes the execution of the current instruction, a single-step exception (such as SIGTRAP signal) will be triggered. When Ptrace is used to set the single-step execution mode, the child process will trigger a specific signal (such as SIGTRAP) after executing an instruction and wait for the parent process to handle it.

[0125] System call signature: PTRACE_SINGLESTEP is called.

[0126] GDB output information: None.

[0127] Actual command input: next.

[0128] S2.3. Start debugging run.

[0129] Start debugging. Related debugging can obtain the following information, which is put into the model training data table, such as row 4.

[0130] Instruction change characteristics: The corresponding addresses of all breakpoints in the code are replaced by INT 3.

[0131] Signal characteristics: None.

[0132] System call characteristics: When GDB starts the debugged program, the GDB process calls the system function fork() to create a child process. This child process will be used to execute the debugged program. After the child process is created, it calls the system function ptrace(PTRACE_TRACEME, ...) to set itself to the traced mode. The child process loads and executes the debugged executable file through the exec series of functions (such as execl, execp, etc.).

[0133] GDB output information: Output characteristic information including "Starting program:".

[0134] Actual command input: run.

[0135] S2.4. Exit debugging quit.

[0136] Exit debugging and related debugging to obtain the following information, which is put into the model training data table, such as row 5.

[0137] Instruction change characteristics: All locations in the code that were replaced with INT 3 instructions are replaced back to the original instructions.

[0138] Signal characteristics: usually implemented by sending an appropriate signal to the debugged program, such as SIGTERM (requesting program termination) or SIGKILL (forcibly terminating the program).

[0139] System call characteristics: The sending of these signals is done through system calls provided by the operating system, such as the kill function. GDB releases all resources allocated for the debugging session before exiting, including memory, file handles, etc. The release of these resources may involve system calls provided by the operating system, such as munmap (release memory mapping), close (close file handles), etc. Finally, GDB terminates its own process. This is usually achieved by calling the exit system call provided by the operating system, such as the exit or _exit function.

[0140] These functions notify the operating system of the termination of the GDB process and allow the operating system to reclaim resources allocated to the process.

[0141] GDB output information: None.

[0142] Actual command input: quit.

[0143] S2.4. Query register info reg.

[0144] The following information can be obtained by querying the register-related debugging, and this information is put into the model training data table, such as row 8.

[0145] Instruction change characteristics: No change.

[0146] Signal characteristics: None.

[0147] System call characteristics: unified type: write(1,"rax 0x0"...,37)=37.

[0148] GDB output information: The output information is characterized by the format of "key=value key2=value2".

[0149] Actual command input: info reg.

[0150] Through experimental data collection, the following table is compiled to provide data support for model training.

[0151] Table 1 Model training data table

[0152] User Commands GDB output information Signal characteristics System call characteristics Memory instruction change characteristics result b 1 Breakpoint1 at Triggering SIGTRAP signal PTRACE_POKETEXT is called 7714f8f0b803000000mov eax,37714f8f10300 addeax,dwordptr [eax]7714f8f0 ccint37714f8f10300 addeax,dwordptr [eax] breakpoint n none Trigger such as SIGTRAP signal PTRACE_SINGLESTEP is called 7714f8f0 ccint37714f8f10300 addeax,dwordptr [eax]7714f8f0b803000000mov eax,37714f8f5cc int 3 next ne none Trigger such as SIGTRAP signal PTRACE_SINGLESTEP is called 7714f8f0 ccint37714f8f10300 addeax,dwordptr [eax]7714f8f0b803000000mov eax,37714f8f5cc int 3 next r Breakpoint1 at none Call the system function fork() Call the system function ptrace(PTRACE_TRACEME,...) 7714f8f0b803000000mov eax,37714f8f10300 addeax,dwordptr [eax]7714f8f0 ccint37714f8f1cc int 3 run q none Triggering SIGTERM Call exit to call munmap 714f8f0 ccint37714f8f10300 addeax,dwordptr [eax]7714f8f0b803000000mov eax,37714f8f10300 addeax,dwordptr [eax] quit ntt none Trigger such as SIGTRAP signal PTRACE_SINGLESTEP is called 7714f8f0 ccint37714f8f10300 addeax,dwordptr [eax]7714f8f0b803000000mov eax,37714f8f5cc int 3 next QQ none Triggering SIGKILL Calling _exit 7714f8f0 ccint37714f8f10300 addeax,dwordptr [eax]7714f8f0b803000000mov eax,37714f8f10300 addeax,dwordptr [eax] quit i r Output information characteristics: "key=value key2=value2" none Unified type: write(1,"rax 0x0"...,37)=37 none info reg ap 4 Breakpoint3 at Triggering SIGTRAP signal PTRACE_POKETEXT is called 7714f8f5b91a000000mov ecx,1Ah7714f8facc int37714f8fe64ff15c0000000 calldword ptrfs:[0C0h]7714f8f5b91a000000mov ecx,1Ah7714f8fa8d542404lea edx,[esp+4]7714f8fe64ff15c0000000 calldword ptrfs:[0C0h] breakpoint bpp 1 Breakpoint1 at Triggering SIGTRAP signal PTRACE_POKETEXT is called 7714f8f0b803000000mov eax,37714f8f10300 addeax,dwordptr [eax]7714f8f0 ccint37714f8f10300 addeax,dwordptr [eax] breakpoint q none Triggering SIGTERM Calling munmap 7714f8f0 ccint37714f8f10300 addeax,dwordptr [eax]7714f8f0b803000000mov eax,37714f8f10300 addeax,dwordptr [eax] quit it Output information characteristics: "key=value key2=value2" none Unified type: write(1,"rax 0x0"...,37)=37 none info reg nxt none Trigger such as SIGTRAP signal PTRACE_SINGLESTEP is called 7714f8f0 ccint37714f8f10300 addeax,dwordptr [eax]7714f8f0b803000000mov eax,37714f8f5cc int 3 next

[0153] S3. Model training and reasoning.

[0154] S3.1. Entity recognition model training.

[0155] S3.1.1. Data annotation.

[0156] This embodiment encodes five GDB commands, namely, next, info reg, quit, breakpoint, and run, as 0, 1, 2, 3, and 4, respectively. The data is saved in the form of Json, and the specific format is as follows.

[0157] {

[0158] "next":0,

[0159] "info reg":1,

[0160] "quit":2,

[0161] "breakpoint":3,

[0162] "run":4

[0163] }

[0164] The five command types are grouped together, and the data in the memory instruction change feature column is annotated. The information before the memory address changes is annotated, such as 7714f8f0 b803000000 mov eax,3. The information after the memory address changes is annotated, such as 7714f8f0 cc int 3, to form a Json format annotation file. The specific format is as follows:

[0165] {

[0166] "id": "1",

[0167] "text": "7714f8f0 cc int 3\n7714f8f1 0300 addeax,dword ptr [eax]\n7714f8f0 b803000000 mov eax,3\n7714f8f1 0300add eax,dword ptr [eax]\n",

[0168] "relation": [

[0169] {

[0170] "type": "Before change",

[0171] "offset": [

[0172] 9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25

[0173] ],

[0174] "text": "cc int 3"

[0175] },

[0176] {

[0177] "type": "After change",

[0178] "offset": [

[0179] 104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,...,139

[0180] ],

[0181] "text": "b803000000 mov eax,3"

[0182] }

[0183] ],

[0184] }

[0185] S3.1.2. Model training.

[0186] Train the relationship extraction model and save the trained model.

[0187] S3.1.3, Model reasoning and memory instruction change feature encoding.

[0188] Use the trained relation extraction model for reasoning, and use the data of the memory instruction change feature column as the input of the model, such as:

[0189] 7714f8f0 cc int 3

[0190] 7714f8f1 0300 add eax,dword ptr [eax]

[0191] 7714f8f0 b803000000 mov eax,3

[0192] 7714f8f5 cc int 3

[0193] The model output is in Json format, as follows:

[0194] {

[0195] "next": [

[0196] {

[0197] "type": "After change",

[0198] "end": 26,

[0199] "probability": 0.97,

[0200] "start": 9,

[0201] "text": "cc int 3"

[0202] },

[0203] {

[0204] "type": "Before change",

[0205] "end": 84,

[0206] "probability": 0.98,

[0207] "start": 65,

[0208] "text": "b803000000 mov eax,3"

[0209] }, 0.96 ]

[0212] }

[0213] The memory instruction change feature corresponding to the next command type is obtained through the relation extraction model, and then the memory instruction change feature is encoded according to the encoding value determined in S3.1.1.

[0214] S4. Cleaning and encoding of attribute column data in the model training database.

[0215] Encode the labels of each column. When there is "None" in the data, use the replacement method to change "None" to None. The encoding mapping relationship is as follows:

[0216] {"User input command":["b 1":0,"n":1,…],"GDB output information":["Breakpoint 1 at":0,"None":1,"key=value key2=value2":2,…],"Signal characteristics":["SIGTRAP":0,"SIGTERM":1,"None":3,…],"System call characteristics":["PTRACE_POKETEXT":0,"PTRACE_SINGLESTEP":1,"_exit":3,…],"Memory instruction change characteristics":[0,1,…],"Result":["breakpoint":0,"next":1,…]}

[0217] When new data enters the table or the model infers user data, the data is encoded according to this encoding rule.

[0218] S5. Machine learning model training and inference.

[0219] S5.1. Model training.

[0220] Use the encoded data as the input of the logistic regression model, sort X by rows, delete the first row of header data, exclude the result data columns, sort Y by rows, delete the first row of header data, exclude the first 5 feature data columns, and save the logistic regression model generated after training.

[0221] S5.2. Model reasoning.

[0222] When new data needs to be inferred, the data is first encoded according to the encoding rules in this embodiment, and then the saved logistic regression model is used for inference. The input is X containing 5 columns of feature data, and the model output Y is decoded according to the encoding rules. For example, if the output is 0, the "result" is found according to the rules: ["breakpoint":0,"next":1,...], that is, breakpoint. Finally, the prediction result is scored using the F1 score to generate a prediction value and score, such as breakpoint0.8.

[0223] S6. User use.

[0224] During user use, the loaded GDB and test program need to generate predicted standard GDB commands through model reasoning; then load the standardized test program and standard GDB debugger to compare the memory instruction change characteristics to determine the reliability of the model reasoning results.

[0225] NodeJS loads the user's GDB debugger, enters the user's test program path, and loads the user's test program.

[0226] Monitor user input and obtain the instruction information corresponding to the test program, which is recorded as the T1 array, including command input information, GDB output information, signal information, system call information, and instruction change information.

[0227] The user enters a debugging command, such as sss, to obtain the data information required for model reasoning of the user's test program; the model result and accuracy after reasoning are obtained, such as breakpoint 0.8.

[0228] Re-use NodeJS to load the native GDB debugger, enter the standardized test code path, enter the breakpoint command corresponding to the debugging command sss, and generate the memory instruction change feature, denoted as M1.

[0229] Compare T1['instruction change information'] with M1. If they are completely consistent, the model inference is considered correct and the T1 array is stored in the database according to the rules of the model training data table. Otherwise, the user is prompted that the instruction is not within the recognition range and the next step cannot be performed.

[0230] Re-encode and train the newly stored data to generate a new model version, which replaces the original version for storage.

[0231] In summary, the above are only preferred embodiments of the present invention and are not intended to limit the protection scope of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A GDB command intelligent recognition method based on a machine learning composite model, characterized in that: The specific steps include: Step 1, constructing a first program set including typical programs, constructing a first GDB command set including known GDB commands, and establishing GDB command codes for the GDB commands in the first GDB command set; Using GDB commands to traverse and debug typical programs in the first program set, obtaining instruction debugging information to form an instruction change information set, a signal information set, a system call information set, a GDB output information set, and a command input information set; Step 2: annotate the features of the before and after change information in the instruction change information set to form an instruction change annotation file set as the first sample set; construct a GDB command feature extraction model, and use the first sample set to complete the training and verification of the GDB command feature extraction model; input the instruction change information set into the trained GDB command feature extraction model to obtain the instruction change features; Step 3: The instruction change characteristics, signal information, system call information, GDB output information and command input information of the same GDB command constitute the GDB command characteristics of the GDB command, and the GDB command characteristics are cleaned and labeled to obtain the GDB command characteristic code, and the GDB command characteristic code is used as the data feature and the GDB command code is used as the label to form a sample, and a second sample set is constructed; Step 4: construct a GDB command prediction model, score the prediction result of the GDB command prediction model, the score value represents the accuracy of the prediction result of the GDB command prediction model, and use the second sample set to complete the training and verification of the GDB command prediction model; Step 5: During actual use, a standard test program is constructed, and the user GDB command to be predicted is used to debug the standard test program, and information before and during debugging is obtained to form user command change information, user signal information, user system call information, user GDB output information, and user command input information; the user command change information, user signal information, user system call information, user GDB output information, and user command input information are input into the trained GDB command prediction model to obtain a standard GDB command corresponding to the user GDB command; Use F1 score to score the prediction results of the GDB command prediction model; Use the prediction result debugging standard test program to obtain information during the debugging process, and form verification instruction change information, verification signal information, verification system call information, verification GDB output information and verification command input information; compare the verification instruction change information, verification signal information, verification system call information, verification GDB output information and verification command input information with the user instruction change information, user signal information, user system call information, user GDB output information and user command input information. If they are the same, it means that the prediction result is accurate, otherwise it means that the prediction result is wrong and execute step 5 again.

2. The GDB command intelligent recognition method according to claim 1, characterized in that: The GDB command feature extraction model in step 2 is a relationship extraction model, an entity extraction model or a triple extraction model.

3. The GDB command intelligent recognition method according to claim 1, characterized in that: The GDB command prediction model is a logistic regression model, a decision tree model, a support vector machine model or a naive Bayes model.

4. The GDB command intelligent recognition method according to claim 1, characterized in that: The GDB commands corresponding to the GDB command code include breakpoint commands, single-step debugging commands, start debugging commands, exit debugging commands and query register commands.

5. The GDB command intelligent recognition method according to claim 1, characterized in that: Use the Strace tool to monitor the GDB process and obtain system call information related to GDB commands.

6. The GDB command intelligent recognition method according to claim 1, characterized in that: The signal information set in step 1 includes a SIGTRAP signal, a SIGINT signal, a SIGSEGV signal, and a SIGFPE signal.