# Stealth Process Launcher This kernel module allows you to run processes that are completely hidden from the system, including from root users. The processes will not be visible in: - Process listings (ps, top, htop) - /proc filesystem - Command history and logs ## Disclaimer **THIS CAN LEADS TO KERNEL HANG AND KEREL PANIC** ## How It Works The module: 1. Hooks the Linux kernel's `/proc` directory listing operations 2. Intercepts directory listing requests 3. Filters out entries for processes we want to hide 4. Can hide entire process chains (including parent processes) 5. Optionally suppresses dmesg log entries related to the hidden process 6. Auto-cleanup when target process completes (optional) 7. Works for all users, including root ## Usage Instructions ### Building the Module ```bash make ``` ### Using the Helper Script (Recommended) ```bash # Make script executable chmod +x run_stealth.sh # Run a command in stealth mode with auto-cleanup (default) sudo ./run_stealth.sh -c "sleep 120" -p "sleep" # Run a command in stealth mode without auto-cleanup sudo ./run_stealth.sh -c "sleep 120" -p "sleep" -a 0 ``` The `-p` parameter is optional and will hide all processes matching the pattern. The `-a` parameter controls auto-cleanup: - `-a 1` (default): Module automatically unloads when the target process completes - `-a 0`: Module stays loaded until manually removed with `rmmod` ### Manual Loading ```bash # Load the module with a command to run and auto-cleanup sudo insmod stealth_launcher.ko target_cmd="sleep 120" hide_pattern="sleep" auto_cleanup=1 # To manually unload the module (if auto_cleanup=0) sudo rmmod stealth_launcher ``` ### Force-Unloading the Module If the module becomes stuck and cannot be unloaded with regular `rmmod`, use the force unload feature: ```bash # Method 1: Use the helper script (recommended) sudo ./force_unload.sh # Method 2: Manual force unload echo 1 > /sys/module/stealth_launcher/parameters/force_unload sleep 1 sudo rmmod stealth_launcher ``` ## Parameters - `target_cmd`: The command to run in stealth mode - `hide_pattern`: String pattern to match in process names to hide - `disable_dmesg`: Whether to prevent logging to dmesg (default: 1, enabled) - `hide_loader`: Hide the module loader and parent processes (default: 1, enabled) - `auto_cleanup`: Automatically unload module when target process completes (default: 1, enabled) - `force_unload`: Set to 1 to force release resources and allow module unload (for recovery) ## Notes - The hidden process continues running even after the module is unloaded - Up to 50 processes can be hidden at once (configurable in the code) - The process will be hidden from all users, including root users - The entire process chain is hidden (including the shell that launched it) - No logging to dmesg is performed for the hidden process - With auto-cleanup enabled, the module will be automatically removed when the target process finishes - If the module gets stuck, use the force unload feature as a last resort ## Advanced Usage ### Hiding an Existing Process You can load the module to hide processes matching a specific pattern: ```bash sudo insmod stealth_launcher.ko hide_pattern="firefox" auto_cleanup=0 ``` This will hide all processes with "firefox" in their name. ### Hiding a Process Without Launching a Command If you just want to hide processes without launching a new command: ```bash sudo insmod stealth_launcher.ko hide_pattern="pattern_to_hide" auto_cleanup=0 ``` ## Troubleshooting ### Module Cannot Be Unloaded If you see "Device or resource busy" errors when trying to unload the module: 1. Try the force unload script: `sudo ./force_unload.sh` 2. If that fails, try setting the force_unload parameter manually: ``` echo 1 > /sys/module/stealth_launcher/parameters/force_unload sleep 1 sudo rmmod stealth_launcher ``` 3. As a last resort: `sudo rmmod -f stealth_launcher` ## Technical Details The module uses: - Kernel-level hooking of `/proc` directory operations - Process management and launching via `call_usermodehelper` - Control register modification to enable writing to read-only kernel structures - Process hierarchy traversal to hide parent processes - Kernel timers and workqueues for auto-cleanup - Parameter callbacks for force unload functionality ## Limitations - Some advanced forensic tools might still detect the process - Process communication can potentially reveal its existence - Module footprint is visible in `lsmod` output (until auto-cleanup) - Only hides process from standard listing tools, not from direct ptrace/memory analysis