I have recently come across several posts on the Internet where guys keep asking for Linux analogs of Windows API. One of the most frequent one is something like "EnumProcessModules for Linux". As usual, most of the replies are looking like "why do you need that?" or "Linux is not Windows". Although, the last one is totally true, it is completely useless. As to "why do you need that?" - why do you care? Poor guy's asking a question here so let's assume he knows what he's doing.

This is the last part of the Hijack Linux System Calls series. By now, we have created a simple loadable kernel module which registers a miscellaneous character device. This means, that we have everything we need in order to patch the system call table. Almost everything, to be honest. We still have to fill the our_ioctl function and add a couple of declarations to our source file. By the end of this article we will be able to intercept any system call in our system should there be a need for that.

We all know what device drivers are - the hands of the operating system that make it possible for the kernel to handle hardware. We also know that there are two types of devices - character and block, depending on the way they handle data transmissions, but what does "miscellaneous" device mean? To put it simple - it means what it means. On one hand, this may be a driver that handles simple hardware, on the other hand, it is the way Linux allows us to create virtual devices, as one of the ways to communicate with kernel modules, which is exactly what we need in order to hijack Linux System Calls.

There are hundreds, if not thousands, of posts regarding this problem. Most of them are outdated, as they refer to older kernels (those, that still exported sys_call_table), others are about adding custom system call and recompiling the kernel. There are a few covering modern kernels, but those are brief and, mostly, only give you a general idea of how it works. I decided to make an in-depth description of the procedure and provide a working example.

Internet is full of information on Linux signals and usage thereof, starting with simple "signal(SIGSEGV, foo)" examples through more complicated tutorials. The purpose of this article is to show the way your applications interface with Linux kernel when it comes to signal handling.