How do I detect in my program that it's being run under a debugger? I am aware that this seems to indicate that I try to do something I shouldn't, and that is too messy. I think it is an interesting question tho. Specifically, is there a way to do it in a POSIX environment? For example using sigaction (2) to detect that some handler is installed? Even a worse thought; is there some inline assembly code I could use on an x86 architecture?
As we discuss it -- would it eventually be possible to launch a debugger, such as gdb (1), and break at the place where you perform this possible hack. Thanks for any dirty one-liners or unlikely references to standards related to this.
Does this article (archive link) help?
It suggests, amongst other things:
file descriptors leaking from the parent process
environment variables ($_)
process state (getsid(), etc).
Note that most (if not all) of these rely on the debugger spawning the process that's being debugged. They're not so effective if the debugger is attached to a process that's already running.
There is no reliable way to detect that you are running under a debugger. That's because a debugger may use any number of methods to actually debug your code, some of which will almost certainly not be caught by your method.
My question is, why would you care? Unless you're trying to hide something :-)
Related
This question already has an answer here:
Should you free at the end of a C program [duplicate]
(1 answer)
Closed 3 years ago.
I am creating a console program, which will have some resources like some threads and some sockets.
When the user closes the console program, should I detect this closing event and free those resources, or can I just let the OS handle this?
And do well known console programs (for example: ls, cat, grep in Linux) free their resources when they exit?
My question is not about a single OS (my console program will run on Windows and Linux and macOS).
When the user closes the console program, should I detect this closing event and free those resources, or can I just let the OS handle this?
Good code is re-used. What today is "closes the console program", tomorrow could be "return from a function" called Christopher_console program().
Plan for re-use and close/free allocated resources.
Both other answers (so Luke's one and chux' one) make sense. It is a matter of perspective.
But cleaning up your mess makes debugging easier with valgrind.
If your program is serious enough to need a lot of debugging, you may want to facilitate that. If you choose to avoid cleanup for performance reasons (e.g. Luke's approach), you might however have some rare --cleanup-the-mess program option which forces it (and tries hard to keep valgrind happy) ...
But if you write things conceptually similar in high-view behavior to (Linux programs like:) cron, bash, guile, make, xslt, tidy, indent, convert, etc, so a shell program, or any kind of interactive interpreter which you would run (in most cases) for only a few minutes, you could reasonably decide to take Luke's approach. On the other hand, if you write a program which runs for a long time (some specialized server for example), you definitely want to avoid every memory leak (and you need to use valgrind).
Generally it is not required, and it's faster to let the OS take care of it. From a brief look at GNU coreutils source, many programs will simply call die() when encountering an error which will exit the process immediately.
In some systems there is a common c runtime, meaning that c programs share certain resources so a resource leak in one program can impact other applications. therefore it is essential that all applications release what is not in uses.
There is a good discussion on the CRT here What is the C runtime library?
My goal is to determine when executing a command, precisely which files it reads and writes. On Linux I can do this using ptrace (with work, akin to what strace does) and on FreeBSD and MacOS I can do this with the ktrace system command. What would you use to obtain this information on Windows?
My research so far suggests that I either use the debugger interface (similar to ptrace in many ways) or perhaps ETW. A third alternative is to interpose a DLL to intercept system calls as they are made. Unfortunately, I don't have the experience to guess as to how challenging each of these approaches will be.
Any suggestions?
Unfortunately it seems there is no easy way to intercept file level operations on Windows.
Here are some hints:
you could try to use FileMon from Sysinternals if it is enough for your needs, or try to look at the source of the tool
you could make use of commercial software like Detours - beware, I never used that myself and I'm not sure it really meets your needs
If you want a better understanding and are not frightened at doing it by hand, the Windows way of intercepting file I/O is using a File System Filter Driver. In fact, there is a FilterManager embedded in Windows system that can forward all file system calls to minifilters.
To build it, the interface with the system is provided by the FilterManager, and you have just (...) to code and install the minifilter that does the actual filtering - beware again never tested that ...
As you suggested, this is a fairly simple task to solve with API hooking with DLL injection.
This is a pretty good article about the application: API hooking revealed
I believe you can find more recent articles about the issue.
However, you probably need to use C++ to implement such a utility. By the way, programs can disable DLL injection. For example, I weren't able to use this approach on the trial version of Photoshop.
So, you may want to check if you can inject DLL files in the process you want with an existing solution before you start writing your own.
Please, take a look to the article CDirectoryChangeWatcher - ReadDirectoryChangesW all wrapped up.
It is a very old, but running, way to watch directory changes.
Microsoft owns a bunch of tools called Sysinternals. There is a program called Process Monitor that will show you all the file accesses for a particular process. This is very likely what you want.
Check this particular Stack Overflow question out for your question... This might help you:
Is there something like the Linux ptrace syscall in Windows?
Also, if you are running lower versions like Windows XP then you should check out Process Monitor.
Also, I would like you to check this out...
Monitoring certain system calls done by a process in Windows
I want to record synchronization operations, such as locks, sempahores, barriers of a multithreaded application, so that I can replay the recorded application later on, for the purpose of debugging.
On way is to supply your own lock, sempaphore, condition variables etc.. functions that also do logging, but I think that is an overkill, because down under they must be using some common synchronization operations.
So my question is which synchronization operations I should log so that I require minimum modifications to my program. In other words, which are the functions or macros in glibc and system calls over which all these synchronization operations are built? So that I only modify those for logging and replaying.
The best I can think of is debugging with gdb in 'record' mode:
Gdb process record/replay execution log
According to this page: GDB Process Record threading support is underway, but it might not be complete yet.
Less strictly answering your question, may I suggest
Helgrind
DRD
On other platforms, several other threading checkers exist, but I haven't got much experience with them.
In your case, an effective method of "logging" systems calls on Linux may be to use the LD_PRELOAD trick, and over-ride the actual system calls with your own versions of the calls that will log the use of the call and then forward to the actual system call.
A more extensive example is given here in Linux Journal.
As you can see at these links, the basic gist of the "trick" is that you can make the system load your own dynamic library before any other system libraries, such as pthreads, etc., and then mask the calls to those library functions by placing your own versions of those functions as the precendent. You can then, inside your over-riding function, log the use of the original function, as well as pass on the arguments to the actual call you're attempting to log.
The nice thing about this method is it will catch pretty much any call you can make, both a function that remains entirely in user-land, as well as a function that will make a kernel call.
So GDB record mode doesn't support multithreading, but the RR record/replay system absolutely does: https://rr-project.org/ .
For a commercial solution with fewer technical restrictions, there's also UDB: https://undo.io/solutions/ .
I've worked on debuggers for some years now and from what I've seen, the GDB record+replay stuff is really not ready for primetime, for this and other reasons (eg, slowdown & huge memory requirements).
If you can get it to work in your dev environment, record+replay/reversible debugging can be pretty gamechanging for your workflow; I hope you find a way to leverage it.
I'm writing a multithreaded server using Ptrheads and I want to trace the execution of individual threads.
What would be a good tracing library for this?
cTrace is an good option.
NPTL sounds exactly like what you need. I have tried unsuccessfully to install it, though, and it seems dated a bit but the features are great. If you succeed in installing it, drop me a line through here! There is also PAPI, but it's tough to handle, and there's finally Valgrind (particularly Cachegrind) for certain subset of debugging needs. Hope this helps.
While I am aware of the differences between debug and release builds, I am curious if attaching the debugger to a process (built release or debug) changes that processes behaviour?
For reference, I'm developing on HP 11.31 Itanium but still am curious for the general case.
http://en.wikipedia.org/wiki/Heisenbug#Heisenbug
Of course, attaching a debugger will change the timing (which can change e.g. thread race conditions), and also some system calls can detect if a debugger is attached.
It certainly can, depending on the platform and the method of debugging. For example, when debugging on Windows, there is actually the IsDebuggerPresent function. As noted that function can be circumvented, but then there are other means. So basically, it's complicated.
Yep, lots of things inside the Windows data structures change when a debugger is attached. It changes how memory is allocated/freed, it adds additional housekeeping code and "markers" on the stack (Ever noticed the F00D values in newly allocated memory) in fact many of the changes are used by anti-debuggers to detect if an application is being debugged.
In interpreted languages (Java, .NET) the runtime will often generate different machine instructions when running under a debugger to help it trap and display exceptions, show the original code, etc. It will usually generate unoptimized code as well when a debugger is attached.
Some of these changes affect the way the software behaves and can result complicate transient bugs that are caused by optimizations or extremely fine timinig dependencies.
Yes, I've often found that attaching a debugger to a process instantly makes bugs disappear, only to have them reappear when I compile my app in release mode. Unfortunately I usually can't really ask all my users to open a debugger just to run my app, so it can be quite frustrating.
Another thing to keep in mind is that for multithreaded apps attaching the debugger definitely can yield very different results. These are the kind of things referred to as "Heisenbugs."
Sure, in multithreaded apps, attaching a debugger can yield different result.
However, how about the codes which are not related to threads?
I have seen a release build, which has a debugger attached, doesn't have problems. But, when a debugger is not attached, it has problems.
If it is launched first and a debugger is attached to it, it also shows the same problems.