Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding hooks for other system calls #6

Open
fkelbert opened this issue May 28, 2013 · 8 comments
Open

Adding hooks for other system calls #6

fkelbert opened this issue May 28, 2013 · 8 comments
Labels

Comments

@fkelbert
Copy link

I just spent some time trying to figure out how to also hook the write system call. I did not manage to do it. Do you plan to provide some generic functions/macros to hook any kind of system call? I could keep trying implementing this, but maybe you are already up to it..

@alexandernst
Copy link
Owner

Thank you for reading the code :)
Yes, I'm planing to make an exact copy of Procmon for Windows (that means adding all common sys_calls).
The problem right now is that I'm still writing the UI and thinking about how exactly to bring the data from the kernel module to userland.

Anyways, if you want to play with it, adding sys_call hook for write won't be difficult at all. Just have a look at https://github.com/alexandernst/procmon/blob/master/procmon/lkm/hookfns.c, lines 26-32 and 39-45. Just replace "read" with "write".

Anyways, as I already said, there are some massive changes going on and I haven't pushed them yet; maybe I'll have some time this weekend and I'll push some of them.

@fkelbert
Copy link
Author

In fact, I tried to do that before and I now tried to do it again. The problem was in fact the if-statement in the hooking function, which prevented most system calls from being reported.

Also, I run into a problem of recursion: The monitor monitored itself. I solved this issue by changing the corresponding hooking function as follows:

  • only monitor user id 1000; in particular not root

  • unhook calls while performing additional actions, as these additional actions may in turn issue system calls

    if(current->cred->uid == 1000) {
    unhook_calls();
    printk(KERN_INFO "%s wrote '%s'\n", current->comm, buf);
    hook_calls();
    }
    return real_sys_write(fd, buf, count);

@alexandernst
Copy link
Owner

Nice catch, I'll have that in mind ;)

Are you just playing with the project or you're willing to push changes? If the second, maybe I could try to push all my changes so you can have a look at them.

@fkelbert
Copy link
Author

Yes, I'm willing to push as far as it makes sense, of course. Yesterday I have been trying for some hours to intercept fork(), vfork() and clone(). It seemed that sys_fork() and sys_vfork() were not used internally at all, as the hook function got never executed. However, when I tried to hook clone(), the system kept crashing, even if I just passed the parameters to the original hook function :-( Probably I did not use the correct signature of the function. Any ideas?

asmlinkage long hooked_sys_clone(unsigned long clone_flags, unsigned long newsp, int __user *parent_tid, void *newtls, int __user *child_tid) {
return real_sys_clone(clone_flags,newsp,parent_tid,newtls,child_tid);
}

@fkelbert
Copy link
Author

btw, man 2 clone says "The raw system call interface on x86 and many other architectures is roughly [...]", which does not help too much. Any ideas where to get the exact signature from?

@alexandernst
Copy link
Owner

Ok, I'll try to pull as much as I can this weekend. The main problem right now is that my PC died so I have to work with my secondary one (which is not anywhere near as good as my main one) :(

The best way to see that is having a look at syscalls.h in your kernel headers. This is for 3.9.4: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/linux/syscalls.h?id=refs/tags/v3.9.4

@milabs
Copy link
Contributor

milabs commented Sep 2, 2013

Note that we need to handle stubs separately. For example, hooking execve through the sys_call_table doesn't correct as __NR_execve points to the stub_execve not the sys_execve. IIRC there are about 5-10 stubs for x86_64 and several ones for x86_32.

@alexandernst
Copy link
Owner

@milabs You completely lost me on this one. I haven't even thought about this one, but thanks for the tip! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants