Introduction: Beyond Basic Magisk Modules

Magisk has revolutionized Android rooting, offering a systemless approach that preserves device integrity while providing extensive modification capabilities. While many Magisk modules focus on simple file overlays or app installations, its true power lies in its dynamic scripting hooks. For developers and security researchers aiming for deeper system control or advanced exploitation techniques, understanding boot_scripts and post-fs-data.d is paramount. These execution points provide unparalleled control over the Android boot process, enabling complex, dynamic system manipulations and potent root exploits.

Understanding Magisk Module Execution Stages

A typical Magisk module leverages customize.sh for initial installation and file placement. However, for runtime modifications and persistent hooks, Magisk provides dedicated directories:

• post-fs-data.d: The Early Bird
  Scripts in this directory are executed very early in the boot process, right after the /data partition is mounted but before Zygote (the process responsible for launching all Android applications) starts. At this stage, /system, /vendor, and /product partitions are typically mounted read-only, but /data is fully writable. This makes post-fs-data.d ideal for:
  • Modifying files within the /data partition before applications can access them.
  • Setting up critical bind mounts that affect the entire system or specific applications.
  • Preparing environment variables or setting up logging early on.
• boot_scripts: The Late Bloomer
  Scripts in this directory execute later, after post-fs-data.d scripts have finished, and after virtually all system partitions (including /system, /vendor, /product) are mounted and potentially remounted read-write by Magisk itself. This stage is perfect for:
  • System-wide environment variable injection (e.g., LD_PRELOAD for hooking native libraries).
  • Modifying system properties (setprop).
  • Launching background services or daemons that require a more fully initialized system.
  • Performing actions that rely on other modules having already initialized.

Crafting a Module with Dynamic Hooks

Let’s walk through creating a basic module structure incorporating these hooks.

Module Structure

my_advanced_module/├── customize.sh├── module.prop├── post-fs-data.d/│   └── 00-early_setup.sh└── boot_scripts/    └── 01-late_action.sh

Ensure your scripts inside post-fs-data.d and boot_scripts are executable (chmod +x).

Example 1: post-fs-data.d for Early Data Manipulation and Stealth

Imagine a scenario where you want to create a hidden directory or inject a file into an application’s data directory *before* it has a chance to sanitize or detect it. We can use post-fs-data.d for this.

Scenario: Create a hidden directory /data/local/tmp/.hidden_payload and place a sensitive file inside it, then bind-mount a dummy file over a legitimate app’s configuration file.

my_advanced_module/post-fs-data.d/00-early_setup.sh:

#!/system/bin/shMODDIR="${0%/*}/.." # Get the module's root directory# Create a hidden directory in /data/local/tmpmkdir -p /data/local/tmp/.hidden_payloadecho "This is a hidden exploit payload." > /data/local/tmp/.hidden_payload/secret_file.txtchmod 600 /data/local/tmp/.hidden_payload/secret_file.txtchown root:root /data/local/tmp/.hidden_payload/secret_file.txt# Example: Bind-mount a dummy file over an app's config# This requires knowing the target app's data path, e.g., com.example.vulnerableappTARGET_APP_CONFIG="/data/data/com.example.vulnerableapp/shared_prefs/app_config.xml"DUMMY_CONFIG="$MODDIR/system/etc/dummy_config.xml" # A file within your module# Ensure the target path exists (Magisk ensures /data is mounted)if [ -f "$TARGET_APP_CONFIG" ]; then    # Create the dummy file in the module's system overlay    mkdir -p "$MODDIR/system/etc"    echo '<prefs><setting name="is_premium" value="false"/></prefs>' > "$DUMMY_CONFIG"    # Bind mount the dummy config    mount -o bind "$DUMMY_CONFIG" "$TARGET_APP_CONFIG"    log_print "INFO: Bind-mounted $DUMMY_CONFIG over $TARGET_APP_CONFIG"else    log_print "WARNING: Target app config not found: $TARGET_APP_CONFIG"filog_print "00-early_setup.sh completed."

In this script, we perform actions directly on the /data partition. The log_print function (provided by Magisk’s environment) is crucial for debugging during early boot.

Example 2: boot_scripts for System-wide Environment Injection (LD_PRELOAD)

One of the most powerful uses of boot_scripts is injecting shared libraries via LD_PRELOAD. This allows you to hook into native functions of virtually any process on the system, including system servers and critical applications, without modifying their binaries directly.

Scenario: Force all applications to load a custom shared library (mylib.so) that intercepts open() calls.

First, you would need to compile mylib.so for your target architecture (ARM, ARM64). Place it in your module, e.g., my_advanced_module/system/lib64/mylib.so.

my_advanced_module/boot_scripts/01-late_action.sh:

#!/system/bin/shMODDIR="${0%/*}/.." # Get the module's root directoryLIB_PATH="$MODDIR/system/lib64/mylib.so" # Path to your compiled library# Check if the library existsif [ -f "$LIB_PATH" ]; then    # Set LD_PRELOAD globally for all processes    export LD_PRELOAD="$LD_PRELOAD:$LIB_PATH"    log_print "INFO: LD_PRELOAD set to include $LIB_PATH"    # Alternatively, for specific processes, you might use:    # (This requires more advanced PIDs monitoring, usually done by a daemon)    # echo "$LIB_PATH" > /data/local/tmp/ldpreload_target.txt    # for PID in $(pgrep -f "com.android.systemui"); do    #   echo "$LIB_PATH" > /proc/$PID/attr/current    # done    # Note: Directly manipulating /proc/$PID/attr/current is complex and often fails without proper capabilities/context.    # The 'export LD_PRELOAD' is generally more reliable for system-wide effects or for processes spawned by shell scripts.else    log_print "ERROR: LD_PRELOAD library not found: $LIB_PATH"fi# Example: Modify a system propertysetprop persist.sys.my_custom_feature truelog_print "INFO: Set persist.sys.my_custom_feature to true"log_print "01-late_action.sh completed."

Note on LD_PRELOAD effectiveness: While export LD_PRELOAD affects processes launched from the shell environment, Zygote and subsequently all Android apps are carefully sandboxed. Global LD_PRELOAD injection for *all* apps typically requires modifying Zygote’s environment directly, which Magisk often handles via its core patching or by providing an API for modules (e.g., through its native bridge). For system services or shell-spawned processes, export LD_PRELOAD is effective. For comprehensive app-level hooking, explore Magisk’s Zygote injection capabilities or techniques like ptrace via a daemon launched in boot_scripts.

Combining Strategies for Advanced Exploits

The real power emerges when these hooks are used in conjunction. Consider an exploit chain:

1. post-fs-data.d prepares the ground:
   • Creates a hidden directory for an exploit payload (e.g., a modified APK or a custom shared library).
   • Modifies a critical configuration file in an app’s private data to trigger a specific vulnerable code path upon launch.
   • Sets a unique flag or identifier in /data/local/tmp that boot_scripts can later detect.
2. boot_scripts activates the payload:
   • Detects the flag set by post-fs-data.d.
   • Launches a background daemon that monitors application launches (e.g., via logcat or inotify on specific directories).
   • Upon detection of a target app, uses am start with specific intent extras, or attempts to inject the preloaded library to hook specific functions.
   • Potentially uses resetprop or setprop to alter system behavior or bypass security checks based on early boot conditions.

This layered approach allows for complex, multi-stage exploits that are difficult to detect or revert, as they blend seamlessly into the system’s legitimate boot process.

Security Considerations and Best Practices

Developing advanced Magisk modules requires careful attention to stability and security:

• Error Handling: Always include checks (e.g., if [ -f "$FILE" ]; then) and use log_print for debugging. Errors during early boot can lead to boot loops.
• Minimality: Keep your scripts as concise and focused as possible to reduce potential failure points.
• Persistence: Be mindful of how your modifications persist across reboots and Magisk updates. Avoid hardcoding paths that might change.
• Stealth: For security research or offensive operations, minimize traces. Avoid verbose logging, and clean up temporary files created by your scripts. Use hidden directories and obscure file names.
• Testing: Test on multiple devices and Android versions if possible. Use a virtual device or a non-critical physical device for initial development.
• Resource Management: Scripts in post-fs-data.d and boot_scripts run during a critical phase. Avoid heavy computations or long-running processes that could delay boot or consume excessive resources. If a long-running process is needed, spawn it as a background service.

Conclusion

Magisk’s boot_scripts and post-fs-data.d directories offer a powerful toolkit for developers seeking to achieve deeper system integration, dynamic modifications, and sophisticated root exploits on Android. By understanding their distinct execution timings and capabilities, you can craft modules that interact with the system at critical junctures, enabling advanced security research, custom ROM features, and robust system-level automations. Mastering these hooks is a crucial step towards becoming an expert in Android system modification and exploitation.