Kernel debugging and system call hijacking

How to modify a system call without recompiling the kernel without rmmod the kernel module

In order to solve this problem, two kinds of solutions are finally implemented:

1.Linux system call hijacking

2.Kprobes Kernel debug Technology (not really modified)

The following are respectively:

Linux system call Hijacking:

In fact, is to modify the kernel symbol table, to achieve a hijacking role. Because the system call actually triggers a soft interrupt for a 0x80 , it then goes to the entry System_call ()of the system call handler. system_call () checks the system call number to see what kind of service is being invoked and then jumps to the entry address of the kernel function that is required to call based on the kernel symbol table, so if we modify the kernel symbol table at this time, So that it jumps to our own function, we can complete the hijacking.

However , after 2.6, the kernel symbol table is no longer exported, so we need to find its location in memory. The exact way to find is to find the location of the 0x80 Interrupt Service function in the interrupt vector table , and then find the instruction to jump from the kernel symbol table in this interrupt service function code, and the location of the kernel symbol table can be analyzed from the instruction.

The following is a simple hijack mkdir system call test, by loading the hook.ko kernel module, hijacking the mkdir system call, and then using mkdir command to create a directory to test whether the truncation was successful. If successful, it will output "PID xxx called sys mkdir !" by Qiankun". The results were tested successfully. Here's the pass.

Kprobes kernel Debugging technology

First declare two points:

1. This is not a modification, but a dynamic insertion of the probe in the running kernel, which can execute a user-defined callback function after the kernel has run to the probe point. Returns to the normal execution process after execution is complete. So he's actually not really modifying the original system call. But you can achieve something similar to the modified effect, for the moment it counts as a "pseudo-modification".

2. I used the jprobe detection method in kprobes in the test , in fact, other kernel debugging techniques such as Systemtap and so should be able to achieve this function, but I do not realize it all.

Kprobes is a lightweight kernel debugging tool that uses the Kprobes technology to perform a user-defined operation at the probe point by dynamically inserting probing points in the kernel that can be run again.

Kprobes use can be divided into three main parts:

1. register the probe point section.

2. debug the Processing section.

3. Unregister the probe point section.

The following is the use of kprobes in the jprobe detection method, the sys_open and sys_write To add a probe point. This can affect the final result of Sys_open and sys_write To some extent , and achieve the purpose of similar modification. The following is the test process, you can see that every time the kernel calls sys_write and sys_open , we will call our probe function first.

The code is as follows:

From for notes (Wiz)

List of attachments

Kernel debugging and system call hijacking