Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi,
I'm writing a piece of code that's supposed to discover keyloggers in one's system. A keylogger is a spy that logs all user keystrokes to a file. So I'm interested in writing a program that discovers the existence of a keylogger in the system.
Any ideas how to implement it? (over redhat based on kernel 2.4.x)
thanks
There are many ways to implement a keylogger, so it's not easy... The most obvious is with shared library redirection that lets you hijack functions such as read(), gets(), et cetera... To detect this one you would have to create a mini shared library that deletes the LD_PRELOAD environment variable or stuff in /etc/ld.so.preload See ld.so(8)
The other ways involve kernel modules... One of them hijacks system calls: read() (different from the libc wrapper with the same name) which would let you sniff keystrokes from statically compiled programs as well as suid binaries. (Remember: shared vs static... the method mentioned above would sniff keystrokes from non-suid dynamically linked binaries. LD_PRELOAD is ignored for suid/sgid programs)
Still exists another that uses some obscure feature or extension of the X protocol. It must be in the web
Thanks for the explanation, it was informative, but I was asking mainly on ANTI-keylogger implementation. My keylogger involves kernel modules as you suggested, but I'm interested in discovering it...
Are you interested in recovering *any* kind of keylogger ?
Discovering LKM-based malware is difficult. There are many ways to hide something in the kernel and different Linux versions handle stuff such as the system call table differently and it appears that these days there isn't such a table at all. See the "Linux Kernel Module Programming Guide" for directions. The old ways of hijacking system calls were dropped for more stealthy ones. For these ones see Phrack
I've been thinking of 3 possible implementations, but I still can't see it all the way to the end. Maybe you can help me out with this:
1st idea is keeping a copy to the original system calls, and then, whenever the user runs the anti-keylooger, compare the original copy of the functions and the copy currently used. In case of a difference between the copies, it might be that there is a keylogger in the system. My problems with these options are: 1. assuming I'm keeping my original copy as a module, how do I let the antikeylogger use it? 2. how to compare between the 2 copies?
2nd idea: measuring the time it takes to perform a write operation, assuming when a keylogger is in the system it will take more clock cycles to write. problems: how can I keep the "usual" number of clock cycles?
3rd idea: maybe I can use interrupts to trace keyloggers planted in my system. I don't like this idea....
Can you help me with those ideas?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.