how to access sys_call_table in linux 2.6

on October 17, 2005 - 6:57am

Linux kernel

I am trying to access sys_call_table in linux 2.6 kernel but I am getting the error :unresolved symbol sys_call_table if anyone has an idea reply this .I hv found that there is no possibility of exporting sys_call_table in RedHat linux 2.6.0

Add new comment

why?

strcmp

October 17, 2005 - 8:34am

Still living in the good old DOS days and used to hooking syscalls? Wanting to easily write viruses (hooking the execve() call), rootkits (hiding themselves by censoring certain returned values) and getting into load-unload-fifo problems?

Why do you want to do that? There are enough userland (e.g. ptrace) and kernel (custom file systems, lsm, kprobes, ...) APIs, why can't you use one of them?

Why would you want to do that

Edwardsjackiee (not verified)

October 17, 2005 - 9:00am

Why would you want to do that? Aren't you trying to solve a problem the wrong way? You can intercept systemcalls in userspace easily for all dynamically linked programs. In the kernel you can make a LSM module or something, or your own wrapper filesystem or whatever. But simply replacing existing systemcalls with your own at runtime isn't the way to go.

Huh?

Ano Nymous

October 17, 2005 - 9:48am

What a strange feeling, seeing my own text, erm, quoted by someone else. Original thread:

http://kerneltrap.org/node/5793

How to access sys_call_table in linux kernel 2.6

Anonymous (not verified)

October 20, 2005 - 2:31am

There is a need to intercept sys calls like open,exit,read and write. But I m not able to access the sys_call_table. I tried to change the ksyms.c file and export the symbol and recompile the kernel but while recompiling the kernel "make zImage" I got errors namely

/usr/src/linux-2.4.21-4.EL/include/acpi/actypes.h:184: syntax error before "INT64"
/usr/src/linux-2.4.21-4.EL/include/acpi/actypes.h:184: warning: type defaults to `int' in declaration of `INT64'
/usr/src/linux-2.4.21-4.EL/include/acpi/actypes.h:184: warning: data definition has no type or storage class
/usr/src/linux-2.4.21-4.EL/include/acpi/actypes.h:185: syntax error before "UINT64"
/usr/src/linux-2.4.21-4.EL/include/acpi/actypes.h:185: warning: type defaults to `int' in declaration of `UINT64'
/usr/src/linux-2.4.21-4.EL/include/acpi/actypes.h:185: warning: data definition has no type or storage class
In file included from sonypi.c:45:
/usr/src/linux-2.4.21-4.EL/include/linux/acpi.h:37:22: asm/acpi.h: No such file or directory
make[3]: *** [sonypi.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.21-4.EL/drivers/char'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.21-4.EL/drivers/char'
make[1]: *** [_subdir_char] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.21-4.EL/drivers'
make: *** [_dir_drivers] Error 2

So plz guide me in this aspect

There is no such need, see ab

Ano Nymous

October 20, 2005 - 12:38pm

There is no such need, see above.

Why is everyon trying to make a big ugly mess when it can be done so simple?

Thank for u r reply. But can

Anonymous (not verified)

October 21, 2005 - 5:49am

Thank for u r reply. But can u explain briefly about intercepting systemcalls in userspace for all dynamically linked programs or else some documents about it so that I can go on.

Make a small library

Ano Nymous

October 21, 2005 - 7:57am

Make a small library which implements all the wrapper functions you want and then add that library to /etc/ld.so.preload (see manpage of ld.so for more info) or to the LD_PRELOAD environment variable (best choice while testing).

Example lib which intercepts read():

#include <stdio.h>
#include <stdlib.h>
#define __USE_GNU
#include <dlfcn.h>


ssize_t (*readfn)(int, void*, size_t);

static void init(void) __attribute__((constructor));

static void init(void)
{
	fprintf(stderr, "Preloaded\n");
	readfn = dlsym(RTLD_NEXT, "read");
}

ssize_t read(int fd, void *buf, size_t nbytes)
{
	fprintf(stderr, "My read\n");
	return readfn(fd, buf, nbytes);
}

Intercepting open() is slightly trickier, as there's also open64() and it's defined as a variable function in glibc. Just read the headerfiles carefully.

It all depends on what your goal is of course, but if you want some sort of security wrappers then this isn't the most water tight method as programs can always call systemcalls directly, but the advantage is that it has low overhead. If you want to use it for security stuff then you'll probably better off with using ptrace, though that has a much higher overhead because it traces all systemcalls (or only exec and signals, but that's not useful enough here).

Static libs

Anonymous (not verified)

October 23, 2005 - 6:31am

Note that the method outlined above will not work for statically linked binaries. For them, you have to do much scarier things or resort to kernel-level hacks. In most cases, however, this really won't be a concern.

Out of interest, what're you trying to achive? In amongst everyone telling you to go use LSM, etc, I've seen nobody ask /why/ you're trying to do this. It's kind of important to know ;-)

I made it clear enough that i

Ano Nymous

October 23, 2005 - 7:58am

I made it clear enough that it's only for dynamically linked programs, and that it shouldn't be used for security things. He even asked how to do it for dynamically linked programs, so it should have been clear enough.

And people asked what they're trying to achieve, but they never bothered to answer that question. I think for most of them it's just a homework assignment, in general that's a save bet when people are blindly trying to do something useless what's done a million times before.

You method is good, but is th

Vadim (not verified)

November 15, 2005 - 11:40am

You method is good, but is there possibility to catch all system calls?
My goal is measuring all system calls, like
starttime();
old_syscall();
endtime();
I don't want to use ptrace as I'm going to measure multithreading software and don't know how to catch calls from threads.

Threads are made with the clo

Ano Nymous

November 15, 2005 - 12:18pm

Threads are made with the clone(2) call in Linux, so all you need to do is attach to the new thread, if that doesn't happen automatically already. Tried strace -T already? strace -c gives a nice output too.

With the preload trick you need to make wrappers for all systemcalls, which is more work if done by hand one by one. The advantage is that the overhead is much smaller than of trace.

Can I use the preload trick f

birkoff (not verified)

November 28, 2005 - 8:37am

Can I use the preload trick for "sys_stime" function ?

Question

Somnium (not verified)

March 9, 2006 - 11:04am

When I compile this example with:

gcc -shared -nostartfiles -o read_trap read_trap.c

And add it to my LD_PRELOAD and try to do a cat I get a symbol lookup error, undefined symbol: dlsym

This is al new for me so ofcourse I'm doing somthing stupid! But I'm having a little trouble finding a good source of info other then the man page's offcourse.

Any help would be great