Understanding Magisk and the Shamiko Module: Unpacking Claims of Bypassing Digital.ai’s Android Security

Android apps are a common target for threat actors to modify the behavior of applications, and tools like Magisk have gained popularity due to their extendability and ability to remain considerably hidden. A module called Shamiko has emerged as a popular choice for further hiding Magisk, highlighting the importance of security solutions that can detect these sophisticated hiding techniques.

In this post, we’ll dive into what Magisk is, explore Magisk modules in general—what they are, an overview of how they’re built, and their integration into the Android system—and later discuss Shamiko. We will also address the claims around circumventing security measures, how application hardening solutions provide comprehensive protection against evolving threats, and the broader impact of such tools on Android app security.

What is Magisk? 

Overview of Magisk 

Magisk is a popular tool that allows Android users to gain root access without altering the core system files. By modifying the boot image rather than the system image, Magisk remains “systemless,” meaning it hides modifications from typical system integrity checks. This capability allows users to root their devices while still running apps that typically block rooted devices, making Magisk particularly powerful for both customization and maintaining app compatibility. Magisk modifies key partitions like boot.img and replaces the init executable with magiskinit, which loads its custom configurations during the boot process without directly tampering with Android’s core system files¹.

Magisk Installation

When Magisk is installed, it ensures persistence across reboots by replacing the init executable with its own magiskinit. The init executable is a native Linux binary that is the first executable to run during the boot process. By intercepting this stage, Magisk can modify system behavior from the very start.

Additionally, Magisk modifies the init.rc file, which is a text-based configuration file Android uses to define commands to be executed at different stages of the boot process. The syntax of init.rc allows it to issue commands during boot, and Magisk patches it to introduce custom boot actions, ensuring its own operations integrate seamlessly.

What is Zygisk? 

Zygisk, part of the Magisk framework, allows developers to inject custom code into the Zygote process after it forks new app or system_server processes. This injection happens after the specialization stage, ensuring any modifications occur inside the newly forked processes rather than within the Zygote daemon itself.

Zygisk’s lifecycle is driven by several PLT (Procedure Linkage Table) function hooks laid out in key libraries:  

• libandroid_runtime
• libart
• libnative_bridge 

These hooks are strategically placed to give Zygisk fine-grained control over the process and its lifecycle, particularly during key phases like process initialization.

The Procedure Linkage Table (PLT) is a mechanism the dynamic linker uses to resolve function addresses at runtime, enabling libraries to share code dynamically. By placing hooks in the PLT, Zygisk can intercept calls made to important functions within the Android runtime, allowing it to inject custom behavior at various points in the lifecycle of an app or system process. This enables precise control over each initialization phase, allowing developers to modify behaviors during critical stages of process execution.

For example, hooks in libandroid_runtime allow Zygisk to intervene in the Android runtime environment, while hooks in libart provide control over the Android Runtime (ART), which is responsible for running app code. Meanwhile, libnative_bridge handles native libraries, allowing Zygisk to manage interactions between the Android runtime and native code. 

In the following diagram, you will see an illustration of the order of execution of these hooks and how they interact with the process lifecycle. 

What is Specialization?

Once Zygote forks a new process for an app or service, it performs specialization. Specialization applies security sandboxing measures that restrict the behavior and privileges of the new app process. This ensures that each app runs in a controlled, isolated environment and cannot interfere with the system or other apps. During this process, the system enforces policies, such as setting user permissions, security contexts, and other app-level restrictions. Specialization is crucial to maintaining Android’s secure multi-user environment.

Additionally, Zygote forks a special process called system_server, which hosts a wide array of system services that are responsible for managing key Android operations. These services control how apps interact with the Android operating system and govern critical components like permissions, device policies, and app lifecycle management. With Zygisk, developers can hook into both system_server and app processes to alter their behavior or introduce custom functionality. This capability is particularly powerful because it allows developers to influence how apps and services operate in real-time, providing a high degree of control over system-level behavior. However, the custom code runs within the constraints of Android’s security sandbox, meaning it must adhere to the permissions and limitations that apply to the app or system process.

Common Use Cases for Magisk 

• Rooting Devices: Many users turn to Magisk to gain root access to Android, allowing for a high level of customization and control over their devices.
• Installing Modules: Beyond rooting, Magisk also supports modules that extend or modify the functionality of the Android system or existing apps. 

In the next section, we will explore how Zygisk works together with Magisk modules to further extend the capabilities of the Android system.

What Are Magisk Modules? 

Magisk modules are extensions that allow users to add functionality, modify system components, or tweak app behavior in a modular way. These modules are one of the critical reasons for Magisk’s popularity, as they provide a way to easily customize the Android experience without modifying the core system files directly. 

How Are Magisk Modules Built? 

Developers typically build Magisk modules using scripts and configuration files that specify their modifications. They are developed in a modular format that allows them to be easily added or removed from the system using the Magisk Manager app. Modules can range from simple scripts to more complex changes, depending on what they aim to accomplish. 

Examples of Magisk Modules

• Ad Blockers: Block ads across the system.
• App Functionality Extensions: Modify or extend the behavior of existing apps, such as enabling hidden features.
• Debloaters: Remove unwanted system apps for a leaner and more efficient device. 

Integration with the Android System: Zygisk 

One notable feature of Magisk is Zygisk, which integrates with Android’s Zygote process. Zygote is responsible for launching applications and initializing Dalvik/ART, serving as the parent process for apps. Zygisk lives within the app’s process, allowing it to modify apps from the inside and significantly control how apps operate. This integration enables Magisk to intercept key lifecycle events, such as during the preAppSpecialize and postAppSpecialize phases, and to apply hooks that alter the app’s behavior on the fly.

Introduction to Shamiko 

The Shamiko module further hides Magisk and prevents detection by security checks. It works alongside Magisk to help users maintain root access while concealing any modifications from apps that may have security policies against rooted devices. This highlights the need for advanced security solutions that can detect such sophisticated hiding techniques.

Claims of Bypassing Digital.ai (Arxan) Security

The developers of Shamiko have claimed that the module can bypass security measures implemented by Digital.ai’s (formerly Arxan) Android protections. However, despite its obfuscated code, a reverse engineering analysis of Shamiko has revealed the specific techniques it uses to obscure its presence.

The analysis shows that while Shamiko eliminates some of the artifacts left by Zygisk, it introduces new artifacts in the process—artifacts that are even easier to detect than those introduced by Magisk. 

Digital.ai’s Response to Shamiko and Similar Threats 

The developers of Shamiko created the module to bypass security measures implemented by Digital.ai and similar protections. Our analysis of Shamiko’s evasion techniques has shown that, as with many rooting tools, attempts to conceal certain artifacts often create new, detectable traces. This is a common paradox in process-manipulating tampering tools: the more they attempt to hide, the more artifacts they potentially introduce, which can aid in detection. 

Process-manipulating tools, like Magisk modules, operate directly within the application’s process. They modify detection methods, hook OS APIs, or alter the application’s code. Specifically, Magisk modules work during the pre-specialization and post-specialization phases of process creation. This timing means they inject code before and after the application process is fully initialized, allowing them to manipulate the app’s behavior within its own process space. While this grants significant control, it also leaves behind in-process artifacts that application hardening solutions can detect, as these modifications are accessible from within the sandbox. 

On the other hand, environment-manipulating tools modify the environment around the application, often at the system or kernel level. By altering system states or API responses, they create environmental artifacts that the app can detect, signaling potential tampering even if the tool itself tries to remain hidden. 

While tools like Shamiko may attempt to obscure their presence, these modifications often introduce additional artifacts our security solutions can detect. When choosing an application hardening solution, look for products that recognize both environmental and in-process anomalies, offering robust defense against tampering and unauthorized modifications.

Best Practices for Securing Android Applications Against Rooting Tools 

Rooting tools, or rootkits, are continually evolving, which presents significant challenges for application developers striving to protect their software from tampering and detection bypass techniques. Given the rapid introduction of new methodologies, it’s crucial for application vendors to implement specialized security solutions that can adapt to these changes. 

To effectively safeguard Android applications, security measures must address both process and environment manipulation techniques. Process-manipulating tools often leave in-process artifacts accessible within the app sandbox, while environment-manipulating tools can alter the system state, creating detectable anomalies. Recognizing these distinctive traces underscores the importance of layered detection capabilities within robust security solutions. 

Digital.ai offers a comprehensive suite of protections to defend against rooting tools and tampering attempts: 

• • Checksum Guard: Validates the integrity of the application’s code, ensuring that any unauthorized modifications are promptly detected.
  • Root Detection Guard: Identifies a wide range of rootkits across various versions, providing resilient root detection even as these tools evolve.

• App Aware: An application threat monitoring and analytics service that provides real-time visibility into attacks. App Aware logs guard triggers to a centralized server, enabling organizations to monitor application threats and react appropriately.  

By integrating these protections, application developers can establish robust security measures against a wide array of rooting tools, preserving the integrity of their applications and safeguarding sensitive data.

For insights on securing iOS applications against similar threats, refer to our previous blog post, “Understanding Jailbreaks,” which explores these challenges within the iOS ecosystem.

Conclusion: Addressing the Challenge of Rooting and Future-Proofing Security 

The rise of tools like Magisk, with its integration via Zygisk and modules such as Shamiko, represents an ongoing challenge for Android app security. However, with a proactive and adaptive approach, claims of the Shamiko hack notwithstanding, solutions like Digital.ai’s Android security suite provide robust defenses against these evolving threats. 

 

If you are a developer or an enterprise looking to protect your mobile apps against the latest threats, consider the comprehensive security solutions provided by Digital.ai, including App Aware. Stay ahead of attackers and ensure your apps are secure from tools like Magisk and Shamiko.

1. While we cannot comment as to whether using Magisk is illegal in whatever jurisdiction the reader finds themselves, we do know that using Magisk is a violation of the Android Terms of Service. Note: While not all people who use Magisk are threat actors, it is safe to say that all Android threat actors can and often do use Magisk.