Introduction: Unlocking Android’s Core with Magisk Modules

Magisk has revolutionized Android rooting, offering a systemless approach that preserves SafetyNet integrity while granting powerful root access. Its true potential, however, lies in its module framework. Magisk modules allow developers to modify, enhance, or even exploit system-level functionalities without touching the `system` partition directly. This article delves into the advanced techniques of Magisk module development, moving beyond simple file replacements to explore sophisticated system-level exploitation and persistent modifications.

Understanding the Magisk Module Template is crucial. It provides the boilerplate for creating powerful modifications that integrate seamlessly with the Android OS. We’ll explore how to leverage its core components to achieve persistent, systemless changes, implement custom daemons, and even interact with the underlying Android system at a low level.

The Core Components of a Magisk Module

Every Magisk module adheres to a fundamental structure, defined by several key files. Mastering these files is the first step towards advanced module development.

module.prop: The Module’s Identity

This file defines your module’s metadata. While seemingly simple, proper configuration ensures compatibility and user experience. Beyond basic fields like `id`, `name`, `version`, and `author`, you can specify `min_magisk_version` and `min_api`, which are critical for targeting specific Android versions or Magisk builds.

id=my_advanced_module
name=Advanced System Tweaker
version=v1.0.0
versionCode=1000
author=TechHacker
description=Advanced system tweaks and custom daemon injection.
min_magisk_version=23000
min_api=29

customize.sh: The Installation Maestro

This script executes during the module’s installation. It’s your primary entry point for modifying the system. Unlike simple file copying, `customize.sh` can perform complex operations:

• Conditional installations based on device properties (`getprop`), Android version, or Magisk version.
• Prompting the user for input during installation to allow custom configurations.
• Patching existing system files or binaries.
• Setting up initial permissions and SELinux contexts for injected files.

The `MODPATH` variable points to your module’s installation directory in `/data/adb/modules/`. Files placed here will be magically bind-mounted to their respective `/system` or `/vendor` locations during boot.

post-fs-data.sh: Early Boot System Modifications

Executed shortly after the file system is mounted (but before `zygote` starts), `post-fs-data.sh` is ideal for early system-level tweaks. This includes:

• Mounting custom file systems.
• Applying SELinux policy rules (`magiskpolicy`).
• Modifying files that need to be in place before many system services begin.
• Setting up initial environment variables for system processes.

# post-fs-data.sh example: Injecting a custom hosts file
MODDIR=${0%/*}

# Ensure hosts file is writable and symlink is created
if [ -f /system/etc/hosts ]; then
  rm -f /system/etc/hosts
fi
ln -sf $MODDIR/system/etc/hosts /system/etc/hosts

# Or, if modifying existing files directly (use with caution, better to bind-mount)
# echo "127.0.0.1  localhost.localdomain customhost" >> /system/etc/hosts

log_print "Custom hosts file injected successfully."

service.sh: Persistent Background Operations

This script runs in the background after the boot process completes and system services are up. It’s perfect for:

• Running custom daemons or long-running scripts.
• Monitoring system events or logs.
• Implementing continuous system modifications or network proxies.
• Restarting services or applications after certain conditions are met.

# service.sh example: A simple background logger
MODDIR=${0%/*}
LOGFILE="$MODDIR/service_log.txt"

echo "Service started at $(date)" >> $LOGFILE

while true; do
  # Example: Monitor battery level and log it
  BATTERY_LEVEL=$(cat /sys/class/power_supply/battery/capacity)
  echo "Battery level: $BATTERY_LEVEL% at $(date)" >> $LOGFILE
  
  # Add your custom daemon logic here
  # Example: Run a custom binary
  # $MODDIR/bin/my_custom_daemon &

  sleep 60 # Run every minute
done

Advanced Techniques for System-Level Exploitation

1. Dynamic SELinux Policy Modification with `magiskpolicy`

Magisk provides `magiskpolicy`, a powerful tool to modify SELinux policies dynamically. This is crucial when your module’s injected services or binaries require permissions not typically granted to the context they run in. For instance, if your custom daemon needs to write to a protected directory, you might add a rule:

# In post-fs-data.sh or service.sh
# Grant 'my_custom_daemon_type' permission to write to 'app_data_file'
magiskpolicy --live "allow my_custom_daemon_type app_data_file:file { create write };"

Understanding SELinux contexts and rules is paramount here. Use `getenforce` to check the current mode and `audit2allow` to generate rules from audit logs if you encounter permission denied errors.

2. Injecting and Executing Custom Binaries/Libraries

For complex functionalities, you’ll often compile your own binaries or libraries. Place them in appropriate subdirectories within your module (e.g., `MODPATH/system/bin` for executables, `MODPATH/system/lib` or `MODPATH/system/lib64` for libraries). Magisk handles the bind-mounting, making them available in the system’s PATH or library paths.

Consider a scenario where you want to replace a system binary with your modified version, or add a new utility:

1. Place your compiled binary, e.g., `my_custom_tool`, into `MODPATH/system/bin/`.
2. In `customize.sh`, ensure it has executable permissions: `set_perm_recursive $MODPATH/system/bin 0 0 0755 0755`.
3. From `service.sh` or another script, you can then call `my_custom_tool`.

For library injection (e.g., `LD_PRELOAD` attacks or hooking), the process is more involved, often requiring modification of linker paths or specific application environments. Magisk can help by setting `LD_LIBRARY_PATH` for certain processes through `resetprop` or by modifying related system properties during early boot.

3. Manipulating System Properties with `resetprop`

`resetprop` is a Magisk utility that allows you to get, set, or delete system properties. This is incredibly useful for runtime configuration changes without modifying `build.prop` directly. Changes made via `resetprop` are typically volatile (they don’t survive reboots unless reapplied). However, within `post-fs-data.sh` or `service.sh`, you can make these changes persistent across a single boot cycle.

# In post-fs-data.sh or service.sh
# Example: Enable a debug flag system-wide
resetprop persist.sys.debug.enabled 1

# Example: Change a system setting normally inaccessible
resetprop ro.secure 0

Be cautious when modifying system properties, as incorrect values can lead to system instability or boot loops.

4. User Interaction During Installation

Leveraging `ui_print` and reading user input in `customize.sh` allows for dynamic module configuration. You can prompt users to choose between different options, specify paths, or enable/disable features.

# customize.sh example for user input
ui_print "- Select installation mode:"
ui_print "  [1] Basic features"
ui_print "  [2] Advanced features (might cause instability)"

read_prop() {
  local PROP_FILE=$1
  local PROP_NAME=$2
  grep "^$PROP_NAME=" "$PROP_FILE" | cut -d'=' -f2
}

OPTION=$(read_prop /tmp/magisk_install_options.prop "CHOICE")

case "$OPTION" in
  1)
    ui_print "- Installing basic features..."
    # Copy basic files
    ;; 
  2)
    ui_print "- Installing advanced features..."
    # Copy advanced files, perhaps with SELinux policies
    ;; 
  *)
    ui_print "! Invalid choice. Aborting."
    abort
    ;; 
esac

Note that user interaction during Magisk installation is typically done via the Magisk Manager UI, which passes choices through temporary files or environment variables that your `customize.sh` can read. The exact mechanism may vary with Magisk Manager versions.

Conclusion: The Power of Systemless Modifications

Magisk module development offers an unparalleled level of control over the Android operating system. By mastering `customize.sh`, `post-fs-data.sh`, and `service.sh`, alongside powerful tools like `magiskpolicy` and `resetprop`, developers can create sophisticated, systemless modifications ranging from custom daemons and runtime patches to dynamic configuration changes. This deep dive into advanced techniques empowers you to move beyond basic tweaks and truly explore the boundaries of Android system exploitation and enhancement, all while maintaining the integrity and security benefits of Magisk’s systemless design.