Eli Fulkerson .com
HomeProjectsDecloak
 
 


Decloak - A pID exhaustion scanner

Important! You probably shouldn't use this utility. You should use unhide instead. After tracking down the difference in output between it and my utility, I have discovered the error... on my side. This utility (among other issues) is not properly identifying used PGID's... which consume the same numberspace as the PID's, but do not show for the /proc/ or function checks I was using to verify things. Thusly, decloak is hereby retired other than as a curiosity.

Description:

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.

Platform:

  • Linux. In theory it should work on any Unix that assigned pid's sequentially (I think all of them?)
  • Language:

  • C++
  • License:

  • GPL
  • Usage:

    $ ./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.
    
    

    Download:

  • decloak.cpp.txt - source
  • decloak-patch.txt - apparently decloak didn't compile properly except on my machine. This patch was offered by a third party