Magisk for Mobile Pentesting: Rooting Android Devices and Building Custom Modules (Part II)

TL;DR: In the first part of this post we covered how to root an Android device and all the steps involved in the process from unlocking the bootloader to patching the boot.img and flashing it into the device. In this part of the post we will focus on how to create custom Magisk modules, including an example module that automates the deployment and management of Frida Server for security assessments.

TL;DR #2: Based on our research about Magisk Modules creation we found that there is not much detailed information about creating a module and many of the articles suggest to start from templates that often have a lot of unnecessary commands and information that are confusing for enthusiasts that pretend to start developing their own modules.

TL;DR #3: Magisk for Mobile Pentesting: Rooting Android Devices and Building Custom Modules (Part I).

In this post, we will cover the following topics:

1. How Magisk Modules Work

2. Classic Structure of Magisk Modules

3. Breaking Down the Components

4. Creating our Frida Automatic Server Deploy Module!!

5. Packing the Magisk Module

6. Installing the Magisk Module

7. Useful Magisk Configuration

8. Recommended Magisk Modules

9. Conclusion

Magisk Modules

One of the best features of Magisk is the possibility of installing modules. Modules are very useful to bypass root detections, bypass SSL Pinning, and improve compatibility with Play Integrity services (as we previously mentioned).

In this second part, we will show you how to create a custom Magisk module by using an example that we developed as a practical use for the Frida server. This module automatically downloads, updates, and runs Frida Server on every boot (ensuring that Frida is always running and updated without user intervention). If you need to know what Frida is and how to use it, please check this publication from our blog :)

To achieve this, we will include:

• BusyBox, which provides some UNIX utilities that are not available by default in Android like wget and xz.

• Multiple architecture support (ARM, ARM64, x86, and x86_64).

• Automatic updates, ensuring that Frida Server is always up-to-date with the latest release.

• Dynamic execution, which ensures Frida starts automatically after each reboot.

You can find the source code for this module on our GitHub repository: GitHub — Frida Server Automatic Deployment Module

1. How Magisk Modules Work

A Magisk module is basically a collection of Bash scripts and system modifications packaged into a ZIP file. Magisk dynamically loads these modifications without altering the system partition, making it a great tool for security testing.

Why Use a Magisk Module?

Magisk keeps changes after reboot and supports automation for system modifications without user interaction. It allows updates without altering the system partition and maintaining OTA compatibility. Users can easily manage modules containing binaries, scripts, and configurations.

2. Classic Structure of Magisk Modules

Normally, a Magisk module follows this specific directory structure:

ModuleStructure/
│── META-INF/ (optional)
│   └── com/ (optional)
│       └── google/ (optional)
│           └── android/ (optional)
│               ├── update-binary (optional)
│               ├── updater-script (optional)
│── system/
│   └── bin/
│       ├── additional-binary-1 (optional)
│       ├── additional-binary-2 (optional)
│       ├── additional-binary-3 (optional)
│── module.prop
│── post-fs-data.sh
│── service.sh
│── customize.sh
│── uninstall.sh

Each component serves a specific role in defining how the module installs, runs, and interacts with the system.

3. Breaking Down the Components

We are going to describe these components:

1. module.prop (Module Metadata)

The module.prop file is a mandatory component of any Magisk module. It contains the information that defines how the module is identified within the Magisk Manager app. This file does not execute any commands but provides information such as the module’s name, author, version, and description.

2. customize.sh (Installation Script)

The customize.sh script is executed during the installation of a Magisk module. Its main role is to prepare the module for execution by extracting necessary files, setting up the proper permissions, and ensuring that everything is ready for the next boot. Basically, this script defines what gets installed and how.

3. Additional Binaries in system/bin/

Magisk modules can include additional binaries inside the system/bin/ directory to extend their functionality. These binaries are useful for performing operations that are not natively available in Android, like handling network requests, extracting compressed files, or executing system commands. Since Android does not include utilities like wget or tar by default, adding precompiled binaries allows modules to execute tasks without requiring additional dependencies.

Magisk dynamically mounts this directory at boot, making the binaries accessible as if they were part of the system itself, ensuring that scripts can rely on them without requiring manual installation.

4. post-fs-data.sh (Executed Early in Boot)

The post-fs-data.sh script is executed early in the boot process, before most system services are fully initialized. Mainly used for setting up modifications that must persist before the system fully loads. Magisk modules commonly use post-fs-data.sh to apply system changes, configure necessary binaries, ensure compatibility before the device finishes booting, and save files or configurations dynamically.

5. service.sh (Post-Boot Execution Script)

The service.sh script is executed once the device has fully booted and system services are operational. This script is useful for running persistent background tasks, starting services, or ensuring that specific processes remain active. Unlike post-fs-data.sh, which runs early in the boot process, service.sh is intended for executing tasks that require a fully initialized system.

6. uninstall.sh (Module Cleanup Script)

The uninstall.sh script is executed when the Magisk module is removed. Its purpose is to clean up any files or modifications introduced by the module, ensuring that the system is returned to its original state. While Magisk handles most removals automatically, this script allows us to manually delete additional files that might persist after uninstallation.

7. META-INF Directory (Optional)

The META-INF directory is commonly found in ZIP packages used for flashing modifications via custom recoveries. It typically contains installation scripts like update-binary and updater-script, which guide the recovery through the installation process. However, Magisk does not require this directory to recognize and install a module.

Magisk handles module installations differently, relying on the module.prop file and the module’s folder structure. Since Magisk dynamically mounts modifications rather than flashing system partitions, the META-INF directory is entirely optional for Magisk modules. Removing it does not affect functionality, and the module will still be installed and operate correctly.

4. Creating our Frida Automatic Server Deploy Module!!

In this section we will explain how our Frida Automatic Server Deployment module works and what every script, binary and configuration file does to make it work correctly. You can access every file’s code by clicking in the index!

1. module.prop (click on it to see the Just Mobile Security implementation)

In our case, module.prop defines our Frida Server Automatic Deployment module name and ID. The description states that the module downloads, updates, and runs Frida Server automatically, and also mentions the inclusion of BusyBox for compatibility with different Android architectures.

Module.prop example

id=frida_auto_deploy
name=Frida Server Automatic Deployment
version=1.0
versionCode=100
author=Juan Martinez Blanco (IT Security Consultant - Just Mobile Security)
description=Automatically downloads, updates, and runs Frida Server on boot. Includes multi-architecture BusyBox.

2. customize.sh (click on it to see the Just Mobile Security implementation)

In our Frida Server Automatic Deployment module, customize.sh ensures that all files are properly extracted by performing the following steps:

• Detecting the device architecture to ensure compatibility before installation.

• Extracting essential files, such as scripts for execution (post-fs-data.sh, service.sh, uninstall.sh), the module descriptor (module.prop), and the required binaries inside system/bin/.

• Setting executable permissions to ensure that scripts run correctly after reboot.

• Providing user feedback through ui_print, making it easier to troubleshoot installation issues.

• Prompting a reboot message to finalize the installation and apply all changes.

3. Additional Binaries in /system/bin/

In our Frida Server Automatic Deployment module, we include BusyBox, a lightweight collection of UNIX utilities. Since different devices use different CPU architectures, we provide multiple versions of BusyBox.

4. post-fs-data.sh

In our Frida Server Automatic Deployment module, post-fs-data.sh ensures that the correct BusyBox binary is selected based on the device architecture.

The script performs the following steps:

• Detecting the device's CPU architecture using getprop ro.product.cpu.abi.

• Selecting the correct BusyBox binary for the architecture.

• Removing unnecessary BusyBox versions to free up space and prevent conflicts.

• Making the BusyBox binary executable so that it can be used by other scripts in the module.

5. service.sh

In our Frida Server Automatic Deployment module, service.sh is responsible for:

• Checking the latest Frida Server version from the GitHub API and comparing it with the installed version.

• Downloading and updating Frida Server if a newer version is available.

• Ensuring that Frida is always running by starting it automatically after every reboot.

• Using nohup to detach the process from the terminal, allowing Frida to run in the background persistently.

• Logging updates and executions in a frida.log file for debugging purposes.

6. uninstall.sh

In our Frida Server Automatic Deployment module, uninstall.sh is responsible for:

• Removing Frida Server and all related files from the module directory.

• Cleaning up logs and temporary files created during execution.

• Ensuring that no leftover binaries (such as BusyBox) remain after uninstallation.

7. META-INF Directory

We did not include META-INF directories and files because they were not necessary to this particular module, it should be noted that in some particular cases like supporting old versions of Magisk it may be necessary to include them within the module.

5. Packing the Magisk Module

Once all scripts are finished, binaries are placed in the correct directory structure, and the module.prop file is configured, the last step is to package the module into a ZIP file for installation.

When creating the ZIP file, it’s crucial to ensure that the internal structure is immediately recognizable by Magisk. The ZIP file should directly contain the module’s structure rather than having an extra parent folder inside. A common mistake is compressing the entire module directory, which results in an extra folder inside the ZIP file. Because of this Magisk fails to recognize it as a valid module.

To properly zip the module, navigate to the module’s root directory and execute:

$ zip -r ../FridaServerAutomaticDeployment.zip *

This will ensure that the ZIP file contains the correct structure without unnecessary parent directories.

With the module correctly packaged, it is now ready for installation via Magisk, ensuring a seamless deployment of Frida Server with automatic updates and execution on boot.

6. Installing the Magisk Module

Once the module is properly packaged into a ZIP file, use Magisk Manager or ADB for a straightforward installation process.

Installing via Magisk Manager

1. Push the zip onto the device with

$ adb push FridaServerAutomaticDeployment.zip /sdcard/Download/

2. Open Magisk Manager on your device.

3. Navigate to Modules and tap on Install from Storage.

4. Select the FridaServerAutomaticDeployment.zip file.

5. Wait for the installation process to finish.

6. Reboot your device to apply the changes.

Installing via ADB

Alternatively, you can install the module directly from your computer using ADB:

$adb push FridaServerAutomaticDeployment.zip /sdcard/Download/
$ adb shell su -c "magisk - install-module /sdcard/Download/FridaServerAutomaticDeployment.zip"

Once the installation is complete, reboot the device to finalize the setup:

$ adb shell su -c "reboot"

After rebooting, Frida Server should be automatically installed, updated, and running in the background, ready for use in your security assessments. You can check if Frida is correctly installed and running using the following command.

$ adb shell su -c "ps -A | grep frida"

7. Useful Magisk Configuration

Before installing any module, its recommendable to configure Magisk to avoid root detection and ensure compatibility with some modules:

• Hide Magisk App - Renames the Magisk app to bypass basic detections.

• Enforce DenyList - Prevents other apps from asking for root access.

• Configure DenyList:

• Add Google Play Services

• Add any app that performs root checks, including the app you are going to test and those that perform Play Integrity checks.

8. Recommended Magisk Modules

There are many different Mogisk modules that could help us as security consultants to perform actions like bypassing Google Play Integrity Checks, Advanced Root Hiding, bypassing SSL Pinning, and in some cases even bypassing Strong Integrity Checks.

• PlayIntegrityFix helps us bypass Google’s Play Integrity and SafetyNet.

• TrickyStore prevents Google Play Store from detecting root access, avoiding compatibility issues with Play Protect certified apps.

• Zygisk Next is a standalone implementation of Zygisk. It provides Zygisk API support for KernelSU and is a replacement of Magisk’s built-in Zygisk.

• Shamiko helps hide root from applications that implement advanced detection mechanisms.

• Frida4Burp is a collection of scripts that facilitates the interception of HTTPS traffic on mobile applications. Very useful for Flutter apps too! ;)

• Kitsune Magisk is a modified version of Magisk that restores MagiskHide for a better root hiding and uses an alternative Zygisk loading method for better compatibility. It should be noted that some modules like Shamiko may not work properly with Kitsune, so this should be considered before switching to this version.

Note: when multiple modules are installed and activated they may interfere with each other. It is recommended that you try your own combinations to achieve the best results.

Conclusion

As we’ve seen in this post Magisk modules can be a great tool to incorporate into our security assessments giving us very handy functionalities like bypassing Google Play Integrity Checks, Advanced Root Hiding and bypassing SSL Pinning, making the tasks easier and giving us the possibility to rollback the changes applied by the modules by just uninstalling them.

We also covered the process of creating a new module and some common errors that often occur, additionally we shared with the community our Frida Server Auto Deployment module to keep your frida always running and updated and use it as an example for the module creation process, it should be noted that we have tested and analysed many modules and module templates that are publicly available and we found that they contain a lot of information that could be confusing if you are trying to create a new module from the scratch.

For more details about our module, please visit the our Github repository: Frida Server Automatic Deployment for Magisk — Just Mobile Security GitHub

Stay tuned to the following posts and don't forget to follow us!!

Just Mobile Security | LinkedIn

Just Mobile Security — Medium

Just Mobile Security Blog

Juan Urbano Stordeur (@juanurss) / Twitter