The goal of this post is to learn how to configure a physical mobile device to perform pentesting tests on Android applications. This method is a work alternative to the post about creating a virtualized environment in Android Studio that we saw previously. The main advantage of working with a physical device is that we will save a lot of space and resources on our computer by not having to download and work with emulated devices, in addition to the convenience of handling it with our own hands.
- Before starting
- What does rooting a device mean?
- What is Magisk?
- How to install Magisk on our Android device
- Enable Developer Options on our device
- USB Debugging
- OEM Unlocking
- Bootloader Unlocking and Custom Recovery installation
- Using the Custom Recovery and installing Magisk on the root system
- Bonus: Installing the Burp Suite certificate through Magisk
- Conclusion
- References
Before starting
You probably know or can imagine it, but it never hurts to make this kind of reminder. If you only have one Android mobile device and it’s your personal one, NEVER manipulate or modify its settings for actions like rooting or other options. Some disadvantages of these alterations are as follows:
- Device damage
- Loss of warranty
- Increased vulnerabilities
- Loss of automatic updates
- Inability to use multiple applications
Always use a device that you no longer use and that you don’t mind taking risks with to do this type of testing. Additionally, always inform yourself before installing applications or making any kind of changes.
What does rooting a device mean?
When we use an Android device, we always do so with the privileges of a normal user without any kind of privilege, so our actions on the device are always limited. By rooting it, superuser permissions are obtained, so any type of action can be performed on the operating system. In short, you can do whatever you want with it. The main problem is that this superuser is locked by default, so it’s the device manufacturer that controls what changes can be made to their devices, thus depending on the brand we have, there may be some variations in these limitations.
And why are mobile devices usually rooted? Well, the main action that is usually done on rooted devices is the installation of custom or more updated ROMs (Read Only Memory, the internal memory that stores the operating system) than what your device can access in a standard way. It is also used to remove applications or functionalities that come installed on the device by default and that cannot be removed as a normal user, as well as to install other applications or functionalities that are forbidden by default.
In our case, we will need to have superuser privileges on the device to be able to adequately perform all the necessary pentesting tests on the applications we want to audit.
However, there is a way to achieve maximum privileges on the Android device without the need to modify the operating system. This is possible thanks to Magisk.
What is Magisk?
Magisk is an open-source rooting tool for Android, which replaces the old rooting solutions that work by modifying the operating system. Since Magisk does not modify the system partition but instead installs as an additional layer superimposed on the operating system, it is a technique known as systemless root.
What is the advantage of this method? That by not having modified the system from its root, manufacturers are not able to detect that the phone has been modified, so the device can continue receiving updates and running sensitive applications while you have superuser access. Additionally, it allows passing the most demanding security and integrity tests, such as SafetyNet.
Next, we are going to explain how to become a superuser of our Android mobile using this tool and maintaining the integrity of the device.
How to install Magisk on our Android device
To begin with the process, I usually recommend (except for honorable exceptions) resetting the device to its factory state. I like to do this to ensure that the mobile in question is in a default state to make sure that there will be no configurations that could interfere with the processes that are going to be explained below. In my case, I’m going to be working with a Motorola Moto G5 (I know, it’s super old) with Android version 8.1. As additional information, I’ll tell you that this device was not going to be the one chosen to make this post, but rather it was going to be a Xiaomi Redmi 9 Pro. However, Xiaomi devices are a bit tricky and I’ll talk about it later in this post so you can keep it in mind in future situations.
Well, first of all, you need to know that when connecting a physical device with the default configuration to the computer, you will only be able to perform the basic options it offers, which are usually battery charging or file transfer. If we wanted to perform console operations using the platform-tools such as adb, we couldn’t. You can test this by plugging your device into the PC and executing the adb devices command. Nothing will appear. To be able to work from the console with the pertinent tools, we will have to enable developer options on our mobile device.
ATTENTION: From here on, we are going to need to use the tools mentioned in the platform-tools, specifically adb and fastboot. If you don’t have them yet, you can find them at the following links:
Enable Developer Options on our device
Developer options are advanced mobile device configuration options that are always hidden in the first instance so that people at the user level don’t have them too handy, since some require knowledge and responsible use to not cause some damage to the phone. The visualization of these options is practically the same on all mobiles of all brands, so it will be easy to enable them. In my specific case, the steps are as follows:
- Settings → System → About phone → Build number → Tap it 7 times
On other brands, it may vary a little, and instead of entering System, you may have to enter General, instead of About phone it may be Device information, but what is common in all will be finding the build number and you will have to tap it 7 times (as weird as it sounds). Messages will appear like Tap 3 more times to enable developer options, and finally something similar to Developer Options enabled.

Once this is done, these options will have appeared normally in the General or System tab. If you can’t find them, you can use the phone’s search engine to find them:

Within the Development Options, many tabs and advanced actions appear to enable or configure. However, we are only going to be interested in enabling two of them: USB Debugging and OEM Unlocking.
USB Debugging
USB debugging is what will enable cable communication between the mobile device and the computer, thus allowing interaction with the device’s applications and memory. In other words, when you enable this option, you will be able to visualize the device with adb and perform actions on it. However, a message will appear on your Android screen where you will have to trust the established connection:


At this point, it’s a good time to perform a check: we are going to install Magisk and we will see if the application grants us any type of privilege following a normal application installation process. To do this, and from our mobile device, we are going to go to the application’s GitHub repository to the Releases section and we are going to download the apk that is there at the following link:

Note: on some devices (Samsung Galaxy S9+ as far as we know) Magisk version v27.0 may give an error “recv_fd: msg_flags = 0, msg_controllen(0) !=24” when trying to use root permissions in applications. In this case, downloading the most recent version to date (v28.0) solves the problem.
Once obtained, we access downloads and install it. It will ask us to trust applications downloaded from our browser, so we will probably have to access the browser settings and select the Trust this source option. Once this is done, we open Magisk. The application itself doesn’t have much. What will interest us is to see that of the 4 tabs seen at the bottom, there will be 2 that it will not be possible to access, which are Superuser and Modules. Additionally, it will indicate that Zygisk (The execution of Magisk in the Zygote process, the first process of the operating system) is not installed. This indicates that we have not obtained privileges of any kind by magic:

To ensure that we don’t have any type of privilege, we can install any application of the so-called Root Checker that indicates when a device is rooted and when it is not. The one I usually use is the following (I leave you a link to apkpure to download on the mobile device because it’s not on GitHub):

Once we have installed the application and verified that simply by installing it we are not root, we are going to modify the extension of the Magisk download from apk to zip (without removing the application from the device) and we will store it in the downloads folder. We will need this later:

After finishing with the USB Debugging procedure, we return to the other developer option that we needed to enable.
OEM Unlocking
OEM unlocking (Original Equipment Manufacturer) involves unlocking the manufacturer’s protection on the mobile device. This opens up a range of possibilities, and one of the utilities that interests us is that the device’s bootloader has been unlocked. The bootloader or boot manager is the first tool that runs when starting a device and performs various checks before loading the operating system. When this option is disabled, only the manufacturer’s default partitions can be started, so by enabling this unlock, the possibility of making modifications at the software level opens up.
Additionally, with this option, the installation of a Custom Recovery has been enabled. The Recovery mode is basically an Android partition similar to Windows BIOS, which is independent so it has individual boot properties. As usual, this mode by default allows system recoveries or official installations. However, when using a Custom Recovery, the possibilities expand, and one of them is the installation of applications with the zip extension, which will install the application directly on the root system. For this reason, we previously saved the Magisk application in this format.

Don’t let this image serve as a guide, since I took it after having performed actions that we are going to explain below, and that’s why it appears with that gray tone. I mention this because simply enabling this unlock has not activated the options I just detailed (at least on most devices).
This is the most delicate part of the entire process, since each mobile brand works in a different way and some bootloader unlocks can be a real odyssey. The good part is that details of each brand can be found on the Internet to unlock it, so following the steps we are going to see, you would only have to adapt the process to each model.
Bootloader Unlocking and Custom Recovery installation
Let’s get started with the meat of it. I’m going to explain the entire process to follow in a generic way and there will be parts where I specify what I personally had to do for my device model, and I will try to give other examples that may be useful.
Before starting with the entire process, we are going to download the Custom Recovery software image that we mentioned earlier and that we are going to use. For this, there are several websites where you can search and find these images for each brand and model, since there is also a distinction between devices of the same brand. The most famous is TWRP, although there are also other pages like Orangefox:
Additionally, only if your device is a Samsung, you will need to download the Odin software to perform the step of loading the Custom Recovery image on the device instead of doing it through console:
In my case, I search for my Motorola model and find the image that corresponds to me:


We save this image in the platform-tools folder. Once this is done, the first step will be to open a cmd with administrator permissions (just in case) on our Windows machine from the aforementioned platform-tools folder. We have to make sure that inside are both the adb.exe executable and fastboot.exe. With the mobile device connected to the computer as we have been explaining throughout the post, we begin to execute the following commands:
- adb devices → Checks if our device is available for command execution and displays it
- adb reboot bootloader → We start the bootloader mode or boot manager of our Android
- fastboot devices → Checks if the device is connected and recognizes the bootloader mode by displaying it
- fastboot flash recovery [Custom Recovery image] → The flash command is used to write data on a partition, which in this case is the Recovery partition that we mentioned and explained a few paragraphs above. Therefore, what we are doing is replacing the default recovery mode with a custom one.
If everything has gone perfectly the first time (which would seem like practically a miracle to me), your terminal would have approximately the following appearance:

Before continuing with the process from this point, we are going to talk about the problems that you will almost certainly have to solve, because as I mentioned earlier, this is the most troublesome part of the entire process:
- PROBLEM 1: The OEM has not been unlocked correctly or completely.
- PROBLEM 2: The fastboot devices command doesn’t show your device.
- PROBLEM 3: You are trying to install an image that is not the one that corresponds to your device. Please make sure you select it correctly.
If you’ve been lucky enough to do it right the first time without having to resolve any errors, tell me in the comments and let me know what Android device model you used! 😀
Problem 1: The OEM has not been unlocked correctly or completely
To recognize this problem, you will find yourself in the image installation part. After finding the device with the fastboot devices command and executing fastboot flash recovery, a message will appear showing the error ‘not allowed in locked state’ as can be seen below:

To check if the OEM has really been unlocked, we can execute the following command at this same point in the process:
- fastboot flashing get_unlock_ability
The value of this parameter must be 1 if it is unlocked correctly. If it has shown us the error from the previous image, the value will be 0:

There is a command that in theory performs the OEM unlock from the console, which is the following:
- fastboot oem unlock
Maybe you’ll be lucky and it will work for you, but it has given me an error on different devices:

At this point, we will have to do a little search on how to unlock the OEM according to our manufacturer. I present my case with Motorola so that it serves as a reference for you, since it is very similar on all devices. I simply searched for ‘oem unlock motorola’ on Google and it ended up taking me to the following link on their official website:
I registered with my email (don’t do it if you don’t have a Motorola) and requested the code to unlock it (the manufacturer gives you their consent to carry out this action, so to speak). The email arrived immediately:

Once this was done, I followed the steps that appeared in the URL mentioned above:

These steps will sound familiar from having seen them above. The key command, which will also sound familiar, is the following:
- fastboot oem unlock <UNIQUE_KEY>
Executing that command with the code received by email will perform the OEM unlock and we can now install the image. Problem solved 😎
Bonus: Unlocking the OEM on a Xiaomi device
As additional content, I’m going to tell you about the experience I mentioned at the beginning of the post with the Xiaomi device (in fact, the error screenshots in this section are with that mobile). When accessing the developer options of devices from this brand, in addition to the OEM unlock option, there is another one called Mi Unlock Status:

When accessing this section, we see a message from the device indicating the permissions needed to unlock the OEM, which are quite a few:

If we press Agree and decide to give our soul to our Asian friends, steps will appear to continue with the process:

In summary, you need to have a Mi account linked to the device and the SIM card with data and Internet connection inside it. When meeting these requirements, you will have to download the application to your computer from the following link:
Once downloaded and with the device connected to the PC, when accessing the application, you must access the same Mi account used on the Xiaomi. Once inside, it will verify that all the conditions mentioned above are met, and the application will allow you to request the unlock, which can take up to 70 hours. You will have to be the one who reopens the application and repeats this last process to finally achieve the device unlock. Keep in mind that when performing this action, the device is reset to factory values, so you would lose all data stored on the phone.
Problem 2: The fastboot devices command doesn’t show your device
The location of this problem is quite simple: when we are in bootloader mode and execute the fastboot devices command, no device is shown. This is because it is necessary to install some Google drivers to be able to perform some actions of the adb and fastboot tools. First, we will download these drivers that are found on the following Android portal:
You can also download it directly through the following link:
Once downloaded, we are going to unzip the folder and copy it to our platform tools folder. Well, with our device connected by USB to our computer in bootloader mode, we are going to do the following:
- Ctrl + X (or right-click on the Windows icon) → Device Manager → Other devices
An Android device connected with a yellow signal with an exclamation mark should appear:

We will right-click on the Android device and select the Update drivers option. Next, the steps to follow are as follows:
1. Browse my PC for drivers

2. Let me pick from a list of available drivers on my computer

3. Show all devices → Next

4. Have Disk

5. Browse → We select the android_winusb.inf file from the drivers folder

6. Next

7. Close

As you can see, the drivers for adb and bootloader interfaces have been installed. Once the process is finished, the icon (and perhaps the device) will have disappeared and in its place Android ADB Interface will appear at the top of the driver panel. Now yes, you can return to your console and re-execute the fastboot devices command, and your device will appear.
Using the Custom Recovery and installing Magisk on the root system
Well, if you’ve had to solve one (or both) of the problems detailed above, congratulations, the worst is over. What remains is a mere formality to finish the process. We return to this point:

At this point, we need to boot the device in recovery mode as explained above. We have several options:
- If we are in bootloader mode we will use the command: fastboot reboot recovery.
- If the device has restarted and we are connected to the computer: adb reboot recovery.
- If we have the device turned off, we will turn it on by pressing the unlock and volume up buttons (this combination may change depending on the brand).
Once this is done, the TWRP menu will open. We will select the Install option as shown below:

The next thing we will do is navigate through the folders until we find the Magisk zip file, located in /sdcard/Download:

Once selected, the last step of the installation will appear in which we will have to swipe to confirm the process:

After a brief installation period, we will restart our Android to verify that everything has worked correctly. When running the Magisk application, it will ask us to reinstall it due to the new permissions obtained on the system. Once this is done, we will open the application and observe that, unlike what happened with the state of the application at the beginning of this post, all options are unlocked:

On this occasion, the Root Checker application will detect that we have privileges on the system:

Finally, we have administrator privileges on our device, which will allow us to work with it in pentesting environments to perform tests.
At first glance, it may seem like a long and tedious procedure, but having controlled what needs to be done in each part of the process, it happens faster than you imagine. Try it and tell me how it went 😉
Bonus: Installing the Burp Suite certificate through Magisk
I’m going to give you the process to install the Burp Suite certificate through Magisk since it’s extremely simple. First, we will have to configure the proxy on our mobile device in the same way we did on a virtual device in the post about tunneling and intercepting traffic on Android. We will select the IP of our wifi network to set it both in Burp Suite and in Android (both screenshots come from that article):


Once this is done, we install the certificate as it was done in the age of the dinosaurs, from the device’s browser by accessing the URL http://burpsuite:

As we already explained in the post I mentioned two paragraphs ago, this way the certificate is installed in the user’s Trusted credentials, not the system’s. We don’t care:

If you remember the Magisk application, there is a section called Modules. It is currently empty, but we are going to install our first module so that our certificate allows us to intercept http traffic. To do this, we will access the following GitHub repository:
It details that what this module does is move certificates installed by the user to the system’s Trusted credentials. To do this, in the releases tab, we will download the burpcert-magisk-module zip file:
Once we have downloaded the file, we will access the Magisk → Modules application and select the Install from storage option:

We will select the previously mentioned file:

Once this is done, this module is installed and enabled:

At this point, we go back to access the device’s Trusted credentials, where the Burp Suite certificate has been moved to the system tab:

After this verification, we can now intercept http traffic to perform our pentesting tests on Android devices.
Conclusion
Although it may seem like a tedious process in some of its parts, I guarantee you that using a physical device to perform security testing is much more comfortable than using virtual devices, avoiding wasting a lot of storage on your computer’s hard drive. I assure you that the configuration is very fast and will be worth it. Tell me how it went and if you are happy with your new working tool :)
Cheers!