This is a linux utility that endeavors to find hidden processes via pid exhaustion. It exploits the linear manner in which pid's are assigned to new processes to reveal unseen processes.
In a nutshell... this utility forks. A lot. At least 65,000 times. Rather than actually performing any work, however, the child fork simply exits. The parent process, which had been given the pid of the new child, compares that to the previous child it spawned off during the previous cycle. If there is a gap between the current and previous child pid's, it is assumed that a process was found there. When a process is found, the script checks a few functions... getpriority, getsid, getpgid and the contents of /proc/(pid)/cmdline and reports them.
In theory, this sounds great. In practice, it isn't quite as useful as it would sound, I am seeing a lot of false positives in actual use. I *think*http://www.2kweb.net/html-tutorial/text-fmts/strikethrough/ what I'm seeing is an artifact of Linux's crumby threading support... zombie threads of missing processes that I can't find with 'ps', but I can't prove it. In particular, my mysql installation seems to always have a few phantom pid's associated with it... if I terminate mysql, they go away... if I start it again, they come back. Uninstalling/Reinstalling mysql has the same effect, so I don't think its a rootkitted mysqld or anything ironic like that. Edit: turns out this was just PGIDs. Nothing to see here. Move along.
However, if you can afford to bring the machine you are scanning largely down and shut down all the processess that you know about, the false positives disappear very quickly. When scanning a box with just the basic kernel, terminal and sshd stuff running I no longer get any false positives.
I think it would be safe to qualify this utility as experimental. If you find this utility interesting, you might also like hardscan, a utility which performs a similar exhaustion/handshake scan for tcp/ip ports.
$ ./decloak --help Usage: ./decloak Will brute force the PID space on the system via fork(). If consecutive fork()'s return non-consecutive PID's, it is assumed that a process has been discovered at that PID. At that point the PID in question will be queried for additional information. Output: PID - a 'discovered' process id PRI - the value returned by getpriority(PRIO_PROCESS, PID) SID - the value returned by getsid(PID) PGID - the value returned by getpgid(PID) COMMAND - the contents of /proc/PID/cmdline Caveats: - This script is occasionally unable to realize that it has already covered the pID space. and may repeat itself several times before it reaches its sanity check. Don't Panic. - The pID space check is imperfect, there is a chance that 1 out of every 4000 processes will slip through the cracks. My advice? Run it twice.