I'd like to prevent would-be hackers from attaching to my binary on Linux systems. I see that ptrace DENY_ATTACH can be used on OSX. Is there such option that can be used on linux? How about on Windows?
Thanks for any info!
Such a system call requires kernel support. Even if it existed in Linux, it would be fairly easy to disable by compiling your own kernel.
In linux, ptrace returns -1 if the process is being ptraced.
So, one solution would be, inside your program, try to attach to your process, and if you get a -1, you will know that the program is being ptraced.
Related
I have a process waiting on a futex:
# strace -p 5538
Process 5538 attached - interrupt to quit
futex(0x7f86c9ed6a0c, FUTEX_WAIT, 20, NULL
How can I best debug such a situation? Can I identify who holds the futex? Are there any tools similar to ipcs and ipcrm but for futexes?
Try using gdb -p *PID* and then run where or bt to see a backtrace.
It won't be spectacularly useful with binaries and libraries that have had their debugging symbols stripped, but you may be able to deduce a fair bit from the context. It might be able to indicate to you which part of a complex process is hanging, and then you could examine the right part of the sources to search for the lock.
I have the same problem with a piece of c++ code. Running ubuntu 12.10 64bit. It looks to like a similar problem in 2007, where the libc was buggy (and maybe still is?).
I start a pthread which runs a traceroute in a system call. Printf before and after the system indicate, that the operating system hangs on the system call, WITHOUT executing the traceroute.
I am not sure if my linux is broken once again because of the ubuntu update, or if it's a libc related bug. Since a lot of applications seem to have "similar" problems, I assume it's stuck somewhere in the userspace.
My c++ code runs perfectly on 32bit systems and even 64bit osx, so i assume that ubuntu 12.10 + 64bit libc combination is broken.
I am working on a kernel module and a user-space application to test that module.
The problem is that during testing my system hangs/freeze.
I have placed lots of debug prints in the code.
The last message that is printed is just before linux select call in my user-space application. Does select somehow freeze the system?
So, How can i debug that where is problem? whether the problem is on user-space application or kernel module?
As n.m mentioned, your userspace program can't freeze Linux, so its an error in your kernel module. The best way to debug this is to use a kernel debugger, and figure out what your module is doing wrong.
Common errors are uninitialized pointers that your module passes to the kernel or locking issues, so take a close look at those.
A userspace program cannot, by definition, freeze Linux. There's a bug in the kernel.
The question is how to execute aout-format binary (I mean old format which for example used on FreeBSD before it has migrated to ELF) on Linux system. Is there a possibility to do so without extra coding (is there some existing solution)? Probably it should be in form of kernel module or patch for the Linux kernel. Another solution could be user-space launcher (may be even run-time linker). I have searched for something similar but was unable to found something. I have not yet checked difference in system calls interfaces, if you have some comments about that, you are welcome to provide them.
P.S. I know that writing user-space launcher for aout static binary is quite trivial but the question is about some existing solution.
Check for CONFIG_BINFMT_AOUT in your kernel config.
If your kernel has /proc/config.gz:
zgrep CONFIG_BINFMT_AOUT /proc/config.gz
On Ubuntu and the like:
grep CONFIG_BINFMT_AOUT /boot/config-$(uname -r)
Kernel option was CONFIG_BINFMT_AOUT, not sure if it's still around or necessary.
I'm trying to build a debugger-like program
under Linux (Ubuntu) and I've run into some problems.
From what I've heard, the /proc vfs provides mechanisms to
create watchpoints, but I can't seem to find out how.
Some man pages pointed me to “control file”s, supposedly located
at /proc/<pid>/ctl, but I can't find this file anywhere.
(Perhaps this file is only for Solaris? Or maybe it's Ubuntu's fault?)
Under Linux, as far as I know, a debugger will have to call ptrace to attach to the process being debugged, and possibly to influence its behavior.
Looking at the source of GDB is likely to be helpful.
There is information in /proc/<pid> that is of interest to debuggers. For example, you can read the process's memory via /proc/<pid>/mem. You can also use ptrace for this, and you need to use ptrace to write.
So a OS multi-tasks and runs one process at a given moment (assuming it's a single core machine). Is there a way I can track/poll and find which process was running at what time and at what time it was put in the queue and retrieved back. Are there any system calls for this ?. Is there a way to achieve this without modifying the linux kernel's source.
I think you need lttng, it definitely give a you a elaborate view of the system's task switch thing(and much more than that) with the lttng viewer. Lttng's kernel part has been merged to current Linux kernel, and you can use it if your kernel has enabled this feature. Here is some screen shots for lttng.
I don't think you can do this natively. AFAIK linux does not a keep a history track of this information.
That's an illogical question. If you are querying the OS from a script/process then the active program is ... YOURS.
Though I guess if you want the history you could watch the /proc directory or the output from ps