Home

Awesome

MagiskHide Props Config

By Didgeridoohan @ XDA Developers

This project is dead, and has been for some time. I have not been involved in the Android modding scene for some time and I no longer have the energy to take it up again.

If anyone feels like taking over give me a holler.

<a href="https://forum.xda-developers.com/apps/magisk/module-magiskhide-props-config-t3789228"><img src="https://img.shields.io/badge/-XDA-orange.svg"></a> Support Thread

What's this?

This module is a very complicated way of doing something very simple. Complicated for me, that is... The aim is to make it easy for you, the user. The module changes prop values using the Magisk resetprop tool, something that is very easy to do with a Magisk boot script and some simple commands. This is very useful for a lot of things, among others to help pass the SafetyNet CTS Profile check on custom and uncertified ROMs (see here for further details on this). And of course for any normal modification of your device that is done by altering build.prop or similar files.

What this module does is that it adds a terminal based UI for those that don't want (or can't) create a boot script for themselves, making the process of creating such a boot script very simple. With this module I'm also maintaining a list of certified build fingerprints for a number of devices, so that it's easy to pick one you want to use.

Keep reading below to find out more details about the different parts of the module.

Keep in mind that this module cannot help you pass CTS if your device uses hardware backed key attestation to detect an unlocked bootloader. There is currently no known way to circumvent that.

Documentation index

Warning
Installation and usage
What option should I use?
Passing SafetyNet's CTS Profile
Forcing BASIC attestation for the bootloader check
Simulating another device
MagiskHide props
SELinux
Custom props
Settings, etc
Issues and logs
Miscellaneous

Warning

Let's start off with a warning.

This module changes your devices prop values. Fingerprint, model and whatever prop you want (depending on what options you use). This may have consequences (everything in life does, live with it). Your device might be perceived as a different device (which can create issues with the Play Store, YouTube video resolution, OTA updates, etc) and cause system instabilities and even bootloops.

Read through the documentation to find more details and how to fix your device if things go south.

Prerequisites

Installation

Install through the Magisk Manager Downloads section. Or, download the zip from the Manager or the module support thread, and install through the Magisk Manager -> Modules, or from a custom recovery.

The current release is always attached to the OP of the module support thread. Any previous releases can be found on GitHub.

Usage

After installing the module and rebooting, run the command props in terminal (you can find a terminal emulator on F-Droid or in the Play Store), and follow the instructions to set your desired options. If you use Termux, you'll have to call su before running the command.

You can also run the command with options. See below or use -h for details.

If you want further details as to what this module does and can do, keep reading. To get an overview of what is available, take a look at the index above. If experiencing issues, take a look at the part about Issues, support,etc, and don't forget to provide logs when asking for help.

Run options

Usage: props NAME VALUE
   or: props [options]...

Entering a property NAME and VALUE will save
this information to the module settings as custom
prop values.

Options:
  -d    *Update to fingerprints test list during start.
  -f    *Update fingerprints list during start.
  -l    *Save module logs and info.
  -h    *Show this message.
  -nc   Run without colours.
  -nw   Run without connecting to the web during start.
  -r    *Reset all options/settings.
  -s    *Open script settings menu.
  -t    Activate test mode.
  -u    *Perform a module update check during start.

Options marked with an asterisk (*) cannot be combined with each other.

The settings option (-s) can be used even if the module boot scripts did not run.

What option should I use?

Not passing SafetyNet

If you can't pass the CTS profile check of the SafetyNet check there are a few things that you might have to do.

If you are using a custom ROM (or have a stock ROM on a device that isn't certified by Google) you most likely need to change the device fingerprint to one that has been Google certified. Use the "Edit device fingerprint" feature.

If you have a stock device, or a custom ROM and using a certified fingerprint, but still can't pass CTS you most likely need to force BASIC key attestation.

Simulating other devices

Simple: use the "Device simulation" feature.

Working with props

If you need to change props edited by MagiskHide, use the "MagiskHide props" feature.

For adding custom props or removing props from your device, there are the "Custom props" and "Delete props" features.

Spoofing device's fingerprint to pass the ctsProfile check

If your device can't pass SafetyNet fully, the CTS profile check fails while basic integrity passes, that means MagiskHide is working on your device but Google doesn't recognise your device as being certified (if basic integrity fails there is generally nothing this module can do, please check I can't pass the basicIntegrity check).

This might be because your device simply hasn't been certified or that the ROM you are using on your device isn't recognised by Google (because it's a custom ROM). Stock ROMs usually do not need this feature.

To fix this, you can use a known working device fingerprint (ro.build.fingerprint), one that has been certified by Google, usually from a stock ROM/firmware/factory image, and replace your device's current fingerprint with this. You can also use a fingerprint from another device, but this will change how your device is perceived.

NOTE: If you're using a fingerprint for an Android build after March 16th 2018 you might have to change the security patch date to one that matches the fingerprint used. You can use the Custom prop function of this module to change ro.build.version.security_patch to the desired date. If you don't know the security patch date you can try finding it with trial and error (although it's a much better option to find the actual date from the ROM/firmware/factory image in question). The dates are always either the 1st or the 5th of the month, so try different months one after the other until the CTS profile passes.

There are a bunch of tested certified fingerprints available in the module, just in case you can't get a hold of one for your device. For some devices there are several fingerprints available, for different Android versions. When picking a fingerprint you will also have to pick which version you need.

After having applied a device fingerprint from the module, whenever that particular print is updated in the included prints list, the chosen fingerprint will be automatically updated when the fingerprints list is. Just reboot to apply the new fingerprint. If there are several fingerprints available for the same device, this option only applies for fingerprints of the same Android version. In that case, if you want to update to a newer version you will have to update the fingerprint manually.

If you are using a Treble GSI ROM you can enable the Use vendor fingerprint option (for more details, see below) in the Edit device fingerprint menu.

Use vendor fingerprint (for Treble GSI ROMs)

When using a Treble GSI ROM with a stock vendor partition, it is sometimes possible to use the vendor fingerprint to make the device pass the CTS profile check. Enabling this option will make the module scripts pull the vendor fingerprint on each boot and use this to spoof the device fingerprint. This in turn means you will only have to enable this option once and even if you update your vendor partition the fingerprint used will always be the latest one.

Matching the Android security patch date

For some devices, if the fingerprint is for an Android build after March 16th 2018, it is necessary to use a security patch date that matches the fingerprint used. For the module provided fingerprints this is done automatically, but if you enter a fingerprint manually you will have to update the security patch date yourself (if they don't already match). If you're setting a fingeprint without using the internal fingerprints list, use the Custom props function of this module to change ro.build.version.security_patch to the desired date.

Can I use any fingerprint?

It's usually possible to use any certfied fingerprint to pass CTS on your device. It doesn't have to match either device or Android version. If you don't use a fingerprint for your device, the device might be percieved as the device that the fingerprint belongs to, in certain situations (Play Store, etc). The Android version generally doesn't matter much, and if you're using a ROM with an Android version much newer than what is officially available for your device, you are going to have to use an older fingerprint if you want to use the one for your device. But, like already stated, that doesn't really matter (most of the time, there might of course be exceptions).

There are some situations where it might matter what fingerprint you use and Google Play is a prime example. When changing the device fingerprint for your device it is very possible that apps will be filtered in the Play store for that particular device and Android version. If you suddenly find yourself not being able to find certain apps or the latest updates of apps (like YouTube), it might be because you have changed the device fingerprint.

How do I submit a fingerprint?

If you have a device fingerprint that you want to submit to the module, just post it in the Support Thread together with device details and the matching security patch date. To make sure that the device simulation feature works properly with the print you submit, please also include the values for ro.product.manufacturer and ro.product.model (use the getprop command or the Android Dumps or firmware.mobi methods outlined below). Also see Finding a certified fingerprint below.

Finding a certified fingerprint

If you need a certain fingerprint from a device, here are a few tips on how to find it. Also remember that you might need to get the security patch date that corresponds to the fingerprint you find (see Matching the Android security patch date above).

Make sure that you get the actual device fingerprint, since there might be props that look similar to what you need. Here's an example, taken from a Google Nexus 6 (device name Shamu):

google/shamu/shamu:7.1.1/N8I11B/4171878:user/release-keys

The getprop method

You can get a certified fingerprint for your device by running the getprop command below on a stock ROM/firmware/factory image that fully passes SafetyNet.

getprop ro.build.fingerprint

If you're already on a custom ROM that can't pass the CTS profile check, this might not be an option... Head over to your device's forum and ask for help. If someone can run the getprop command on their device for you, you're good to go. Or, you can try the other method described below.

Note that this is sometimes the only surefire way of getting the proper fingerprint.

The stock ROM/firmware/factory image method

Another way to find a certified fingerprint is to download a stock ROM/firmware/factory image for your device and extract the fingerprint from there.

XDA member @ipdev has spent quite some time creating an automated script for extracting the necessary information from a downloaded stock ROM/firmware/factory image, and it can even create a fingerprints list for you. You can find it together with instructions on how to use it here: https://github.com/ipdev99/mHideGP

Note that the following is possibly not the best way of finding the fingerprint. The main problem is that it might be hard to find the actual, certified fingerprint since there might also be other similar props that aren't certified.

You can find the file to download in your device's forum on XDA Developers (either as a firmware file, a proper stock ROM, or in the development section as a debloated stock ROM), from the manufacturer's website, or elsewhere on the great interweb (just remember to be careful when downloading unknown files, it's dangerous to go alone!).

Once you have the file downloaded, there are several different ways that the fingerprint can be found. In all cases you'll have to access the file somehow, and in most cases it's just a matter of unpackaging it. After that it depends on how the package is constructed.

The Android Dumps method

Android Dumps is a great resource for finding props for different devices. Check it here.

The firmware.mobi method

Sometimes you can also find up to date and certified fingerprints at firmware.mobi.

Custom fingerprints list

You can add your own fingerprint to the list by placing a file, named printslist (no file extension), in the root of your internal storage with the fingerprints. It needs to be formated as follows: device name=fingerprint. The fingerprints added to this list will be found under the Custom category in the fingerprints menu. If you create the printslist file in Windows, make sure that you use a text editor that can handle Unix file endings, such as Notepad++ and similar editors (not regular Notepad). Here's an example:

Google Nexus 6 (7.1.1):Motorola:Nexus 6=google/shamu/shamu:7.1.1/N8I11B/4171878:user/release-keys

NOTE 1: If you're using a fingerprint for an Android build after March 16th 2018 you might have to change the security patch date to one that matches the fingerprint used. This can be done directly in the fingerprints list, by adding two underscores directly followed by the date at the end of the fingerprint (__2018-09-05). You can also use the Custom props function of this module to change ro.build.version.security_patch to the desired date. If you don't know the security patch date you can try finding it with trial and error (quite tedious). The dates are usually always either the 1st or the 5th of the month, so try different months one after the other until the CTS profile passes.
NOTE 2: If you want the device simulation feature of the module to work properly with the prints from the custom list you will also have to include the manufacturer and model in the list. This is done by adding the values for these two props right before the equal sign (=) that separates the device name from the fingerprint. Separate the device name and android versions and the two values with colons (:). See the example above.

Keeping your device "certified"

If you're using a custom ROM, the chances of it being perceived as uncertified by Google are pretty high. If your ROM has a build date after March 16 2018, this might mean that you can't even log into your Google account or use Gapps without whitelisting your device with Google first.

Magisk, and this module, can help with that.

Before setting up your device, install Magisk, this module and use the configuration file described below to pass the ctsProfile check. This should make your device be perceived as certified by Google and you can log into your Google account and use your device without having to whitelist it. Check here for usable fingerprints (only use the part to the right of the equal sign).

If you're having issues getting your device certified, take a look in the Magisk troubleshooting guide linked below.

In case you can't get the Play Store to report your device as "certified", see "Issues" below.

Current fingerprints list version

The fingerprints list will update without the need to update the entire module. Keep an eye on the module support thread for info.

Just run the props command and the list will be updated automatically. Use the -nw option to run the script without updating the list or disable it completely in the script settings (see "Prop script settings" below). If you've disabled the this setting you can update the list manually in the Edit device fingerprint menu or by running the props command with the -f run option.

If you already have a device fingerprint set by the module, and it has been updated in the current fingerprints list, it will be automatically updated when the prints list gets an update. Just reboot to apply. This function can be turned of in the script settings (see "Prop script settings" below)

Current fingerprints list version - v137

Please add support for device X

Adding device fingerprints to the list relies heavily on the users. You guys. I've looked up a fingerprint from time to time, but it is a bit time consuming and I don't have that time...

If you want a specific device fingerprint to be added to the module, see Finding a certified fingerprint above. If you can find a fingerprint for the device you have in mind, submit it for inclusion in the list of certified fingerprints.

Please update fingerprint X

Fingerprints included in the module are updated once in a while. Mainly if a user (that's you) provides the updated fingerprint, but sometimes I do look up new fingerprints (that is purely based on how much time I have on my hands and how bored I am though, and I have very little time and a very interesting life). Take a look at Finding a certified fingerprint to get some hints as to how you can find a print to submit.

If you have an updated fingerprint available (and you've posted it for me to update the list), but I haven't yet updated the fingerprints list (which might be a while depending on how much IRL stuff I have to do), it is still perfectly possible for you to use the updated fingerprint.

You can enter the fingerprint manually in the Edit device fingerprint menu in the module, you can use the configuration file, or you can make a custom fingerprints list.

Force BASIC key attestation

Google now enforces the use of hardware backed key attestation on devices that has the necessary hardware (all devices that shipped with Android 8+ and even some older devices).This can be circumvented by tricking the device into not using the hardware attestation, and it might also be needed to change the prop models (ro.product.model) to something other than your devices actual model. This feature can help with that.

@kdrag0n over on XDA Developers have a Magsk module that will trick keystore into thinking that the hardware isn't available and this will then force basic attestation. You can find that module together with details on how it works here: https://forum.xda-developers.com/t/magisk-module-universal-safetynet-fix-1-1-0.4217823/

The Universal SafetyNet fix not only trickes the keystore into using basic attestation, from v2.1.0 it also changes prop values that might be necessary to trick Google Play Services into letting you pass the CTS profile check, so if you're using that module you most likely will not need to use the Force BASIC key attestation feature of this module.

If you aren't successful in passing CTS by changing the model, you could try using the Xposed (although it is recommended to use LSPosed if you want to have the best chance of passing SafetyNet) module XprivacyLua and restrict Google Play Services. Instructions on how to install LSPosed and XprivacyLua and how to use that module can be found with a simple web search, I won't cover that here.

This feature of the module has nothing to do with the device fingerprint, but uses the included fingerprints list to find the necessary value to use for the ro.product.model prop (and related props).

As long as Google doesn't roll out hardware based key attestation universally, it seems like we can fool SafetyNet into using the basic attestation by changing the ro.product.model prop (to pass the CTS profile check even with an unlocked bootloader). The module scripts will also alter related partition specific props (odm, product, system, vendor and system_ext) to match, if they are available. Thank you to @Displax over at XDA for finding this: https://forum.xda-developers.com/showpost.php?p=83028387&postcount=40658

The prefered method is to pick a device manually from the list of devices (based on the module fingerprints list) or set your own custom value. Do NOT pick your own device, instead try a device that is as close to your actual device as possible. The closer it is to your actual device the less is the likelyhood that things will stop working as a result of the model prop change.

It is also possible to use a custom value, if that's what you prefer.

If a device isn't picked from the list or a custom value entered, this feature will by default use an old devices model prop value, based on your device or currently set fingerprint, to make sure that it is recognised as a device without the necessary hardware (picked from the available devices in the module fingerprints list). Using an actual model value from an old device may also help with keeping OEM specific features working (like the Samsung Galaxy Store). If device/OEM specific features still doesn't work after activating this option, or your device is otherwise behaving strangely, try picking a device manually from the included list (see below). If no model prop value from an old enough device is available, the value from ro.product.device will be used instead.

Note that using the Device simulation feature to simulate ro.product.model (and related props) will be disabled when this feature is enabled (all other simiulation props will still work though). It is also worth noting that using the Device simulation feature to change ro.product.model will also force a basic key attestation.

Device simulation

NOTE! This feature is not generally needed to pass SafetyNet's CTS profile test and may even cause issues. Only enable it if you actually need it!

If you want to simulate a specific device (to get access to device specific apps in the Play store, as an example), you can activate this option. It will pull information from the currently used fingerprint (has to be set by the module) and use this to set a few certain props to these values. The props that can be set are (currently):

By default all props are disabled when this option is activated, but it is possible to activate or deactivate each prop individually or all of them at once. It is also possible to activate several props simultaneously by choosing the corresponding numbers in the menu list and entering them separated by a comma. Example: If I would like to activate ro.product.name, ro.product.device and ro.product.manufacturer I would enter "2,3,9".

There are also several partition specific variations of some of the used props (system, vendor, product, odm). If these are available they will also be set to the simulation prop value. This can be disabled in the option settings.

Whenever a fingerprint is set by the module, the ro.build.description prop will be set automatically independently from if the general device simulation option is enabled or not. It can of course also be disabled.

Set/reset MagiskHide Sensitive props

Up to and including Magisk v23 MagiskHide changes some sensitive props to "safe" values that won't trigger apps that might be looking for them as a sign of your device being tampered with (root).

This feature is enabled by default and will automatically change any triggering values it finds to "safe" values.

The props in question are: General

Rootbeer, Microsoft, etc

SafetyNet, unlocked bootloader, etc

Samsung

There are a few props that will only change if a triggering value is detected, and these are (by default these will be set in the late_start service boot stage but can be set during post-fs-data if this is changed in the settings): Recovery mode

MIUI cross-region flash

And lastly there are props that will only change after boot is completed. These are: SafetyNet, unlocked bootloader, etc

ro.build.selinux used to be changed by MagiskHide, but since some root detectors has a broken implementation of detecting this prop it is simply removed instead of changed (MagiskHide did this since Magisk build 20412).

If, for some reason, you need one or more of these to be kept as their original value (one example would be resetting ro.build.type to userdebug since some ROMs need this to work properly), you can reset to the original value by simply disabling this prop in the module. Keep in mind that this might trigger some apps looking for these prop values as a sign of your device being rooted. If you want to further customise the prop in question you can use the "Add/edit custom props" feature.

It is possible to change or reset each prop individually or all of them at once. It is also possible to change several props simultaneously by choosing the corresponding numbers in the menu list and entering them separated by a comma. This will change any props set to a sensitive value to a safe value and vice versa. Example: If I would like to change ro.debuggable, ro.secure and ro.build.tags I would enter "1,2,4".

SELinux Permissive

If MagiskHide detected that SELinux was in a permissive state it would change permissions for a couple of SELinux related files on the device, to prevent detection of this state. This has been implemented in the late_start service script.

Change/set custom prop values

It's quite easy to change prop values with Magisk. With this module it's even easier. Just enter the prop you want to change and the new value and the module does the rest, nice and systemless. Any changes that you've previously done directly to build.prop, default.prop, etc, you can now do with this module instead. If you have a lot of props that you want to change it'll be a lot easier to use the configuration file (see below).

A custom prop can also be set by running the props command with the prop name and value directly in the command prompt (no need for using the ui). See Run options.

When setting a custom prop you can also pick in what boot stage it should be set in. This can also be changed later for each individual custom prop. There are four options:

It is also possible to set a delay for when the prop is supposed to be set. This is useful if a prop value is originally set late during boot, or even a while after the device has finished booting. Pick this option while setting a new prop or editing one that has already been set and enter the amount of seconds you want the delay to be. By default the script will wait for "Boot completed" to be broadcast before starting to count the delay. This option can be disabled on a per prop level if necessary. Note 1: A prop with a delay will automatically be set during the late_start service boot stage.
Note 2: The delay will usually be sligtly longer than the entered value (mostly counted in tenths of a second), due to small delays in execution of the scripts.

Removing prop values

If you would like to delete a certain prop value from your system, that can be done with the Magisk resetprop tool. With this module you can easily set that up by adding whatever prop you want removed to the "Delete props" list. Be very careful when using this option, since removing the wrong prop may cause isses with your device. See "Device issues because of the module" below if this happens.

Prop script settings

There are a couple of persistent options that you can set for the props script. These are currently "Boot stage", "Script colours" and "Fingerprints list check". The options are found under "Script settings" when running the props script. The settings menu can also be opened by using the -s run option (use -h for details).

Boot stage

It's possible to move the execution of the boot script from the default system.prop file to either post-fs-data or late_start service. If there are any kind of issues during boot or that props don't set properly, try changing the boot stage to either post-fs-data or late_start service instead. Just keep in mind that this might cause other issues like the fingerprint not setting properly (if set during late_start service) or that post-fs-data will be interupted by having too many props causing the script to run too slow.

It is also possible to set individual props, like fingerprint, security patch date and custom props individualy. There'll be an option under the corresponding menu

If boot stage is set to late_start service, general execution or for specific prop types, it is also possible to enable a soft reboot after these props are changed. This can sometimes be needed for a prop to properly be set to memory at such a late stage in the boot process, so if a prop doesn't appear to be set properly during the late_start service boot stage, try enabling this option. This feature is disabled by default since it has the possibility to cause issues on some devices.

Note: post-fs-data runs earlier than system.prop and late_start service runs after, right at the end of the boot process. Having to many props set in post-fs-data may have an adverse effect on the boot process and may result in props not being set properly. Using the default system.prop file or late_start service is prefered if possible.

Script colours

This option will disable or enable colours for the props script.

Automatic module update check

This option will disable or enable the automatic check for a module update when the props script starts. If the update check is disabled, it can still be performed manually from within the script, in the main menu, or with the -u run option (use -h for details).

Automatic update of fingerprints list

This option will disable or enable the automatic updating of the fingerprints list when the props script starts. If the fingerprints list check is disabled, the list can be manually updated from within the script, under the Edit device fingerprint menu, or with the -f run option (use -h for details).

Automatic fingerprint update

Whenever there is an update to the fingerprints list and if you have a fingerprint applied for a device that is on the list, the fingerprint will automatically be updated (if there is an update to that particular fingerprint). This option will not update a fingerprint to one for a different Android version if there are several fingerprints available for the same device.

Backround boot script

By default, parts of the module post-fs-data boot script is executed in the background, but the parts that don't might still cause issues on some devices. If there are issues with the boot scripts not running during boot, try enabling this option to execute the script entirely in the background. Keep in mind that this might cause other issues, so only enable if necessary.

Export settings

If you have a lot of different props set it can be handy to have a configuration file (see below) tucked away for future installs of the module. With this feature you can export the current module settings to a configuration file for future use. The file will be saved on your internal storage, in the /mhpc directory.

Configuration file

You can use a configuration file to set your desired options, rather than running the props command. This is particularly useful if you have a large amount of custom props you want to set. Download the settings file, extract it from the module zip (in the /common folder) or copy it from the module directory under /data/adb (in the /common folder), fill in the desired options (follow the instructions in the file), place it in the root of your internal storage (/sdcard), in /data or in /cache (or /data/cache if you're using an A/B device) and reboot. You can also use the configuration file when first installing the module. Just place the file in the root of your internal storage (or one of the other previously mentioned locations) before flashing the module and the installation script will set everything up.

NOTE! If a configuration file is used during boot there will be a reboot during the late_start service boot stage, to load the newly set up values. This can cause issues for devices that have to boot through recovery for Magisk to be active (A-only SAR devices), so a manual reboot after the automatic one will be necessary (or just use the configuration file at install instead).

If you edit the configuration file in Windows, make sure that you use a text editor that can handle Unix file endings, such as Notepad++ and similar editors (not regular Windows Notepad).

Using the configuration file can also be done directly at the first install (through Manager or recovery) and even on a brand new clean install of Magisk, before even rebooting your device (also see "Setting up the module on a clean Magisk/ROM flash" below). Just place the file in one of the above mentioned locations prior to installing the module.

NOTE! Upon detecting the file, the module installation/boot script will load the configured values into the module and then delete the the configuration file, so keep a copy somewhere if you want to use the same settings later.

Setting up the module on a clean Magisk/ROM flash

After having made a clean ROM flash, the configuration file can be used to set the module up as you want without even having to boot first. First flash the ROM and Magisk. After that you can place the configuration file (see above) with your desired settings (fingerprint, custom props, etc) in the root of your internal storage (/sdcard), in /data or in /cache (or /data/cache if you're using an A/B device) and then install the module. This will set the module up just as you want it without having to do anything else. It is also possible to place the configuration file after having installed the module and rebooting. This will set everything up during boot, but it is possible that this won't work an all device/ROM combinations. If you experience issues, let the ROM boot once before setting everything up.

Miscellaneous MagiskHide issues

If you're having issues passing SafetyNet, getting your device certified, or otherwise getting MagiskHide to work, take a look in the Magisk and MagiskHide Installation and Troubleshooting Guide. Lots of good info there (if I may say so myself)...

But first: have you tried turning it off and on again? Toggling MagiskHide off and on usually works if MagiskHide has stopped working after an update of Magisk or your ROM.

Issues, support, etc

If you have questions, suggestions or are experiencing some kind of issue, visit the module support thread @ XDA.

Known issues

For the moment, nothing special (I think). If you've got issues, take a look at the most common problems listed below.

I still can't pass the ctsProfile check

If you've picked a certified fingerprint from the provided list, or you're using a fingerprint that you know is certified, or you've forced basic key attestation but still can't pass the ctsProfile check, try one or more of the following:

Device issues because of the module

A common reason for issues with booting the device or with system apps force closing, etc, is having enabled Device simulation. This feature is not needed for passing SafetyNet's CTS profile check. Only enable it if you actually need it, and keep in mind that it may cause issues when activated.

In case of issues, if you've set a prop value that doesn't work on your device causing it not to boot, etc, don't worry. There are options. You can follow the advice in the Magisk troubleshooting guide to remove or disable the module, or you can use the module's built-in options to reset all module settings to the defaults or to disable the module without resetting.

Create a file (named reset_mhpc or disable_mhpc depending on your needs, keep reading for details) in the root of your internal storage (/sdcard), in /data or in /cache (or /data/cache if you're using an A/B device) and reboot. If you want to reset the module, name the file reset_mhpc, or if you want to disable the module name it disable_mhpc. If you disable the module it can later be enabled again from the Magisk Manager.

If your device does not have access to /sdcard, /data or /cache through recovery (or there's no custom recovery available), you can disable all modules by booting to Safe Mode (see the Magisk troubleshooting guide for details), or disable Magisk by flashing a stock boot/recovery image. If you use Safe Mode, boot back into regular Android again and all modules will be disabled. Now you can place the reset or disable file in the root of your internal storage (/sdcard), and lastly either reenable the module from the Magisk app or reinstall Magisk by flashing a patched boot/recovery image again. At the next boot the module will be reset/disabled and you should be up and running again.

The reset file can be used in combination with the configuration file described above to keep device fingerprint or any other settings intact past the reset. Just make sure to remove any custom props that might have been causing issues from the configuration file.

props not found

There are two common reasons why you would get an error saying "not found" when running the props command in a terminal emulator.

You need to first run su. This is especially true if you use Termux, but can also happen on some devices. If you still get "props not found" after running su it is likely that you have somehow disabled the module. Check in the Magisk Manager and make sure that the module is enabled. If neither of these options apply, check below on how to provide logs for troubleshooting.

The boot scripts did not run

Sometimes there are issues with the boot scripts and as a result the props command won't work. A common cause for this is having EdXposed installed (see above). Always try rebooting to see if things start working, but if they don't, make sure to share the logs (that have been saved automatically to your internal storage) in the module support thread.

This issue can in rare cases be caused by the module post-fs-data boot script taking too long to execute. This can be worked around by enabling the script setting to execute the script entirely in the background. This has the potential of causing other issues though, so only enable it if you need it.

If the issue is caused by having changed any of the script settings (for boot stages, etc), you can still enter the settings menu by using the -s run option.

It might still be possible to use the module, even though you can't run the props command. Use the configuration file to set your desired options and make sure that all the boot options (CONFPRINTBOOT, CONFPATCHBOOT, CONFSIMBOOT and CONFBOOT) are set to use the default boot stage (since the boot scripts don't seem to run properly).

An option is marked as "disabled"

A couple of the options in the props script will be automatically disabled in some circumstances. These are:

I can't pass the ctsProfile check

See "I still can't pass the ctsProfile check" above.

Also see "Props don't seem to set properly" below.

I can't pass the basicIntegrity check

This module can usually only really help with the ctsProfile check, by spoofing the device fingerprint. If you can't pass basicIntegrity, there's probably something else going on with your device, but there is a possibility that changing the device fingerprint can make this pass as well. If you can't get things working, see "Miscellaneous MagiskHide issues" above.

Props don't seem to set properly

If it seems like props you're trying to set with the module don't get set properly (ctsProfile still doesn't pass, custom props don't work, etc), go into the script options and change the boot stage at which the props are being set, or change the boot stage for that particular prop, to late_start service. See "Boot stage" or "Custom prop values" above. This might happen because the particular prop you're trying to set get assigned it's value late in the boot process and by setting the boot stage for the prop to the last one available (late_start service) you optimise the chances of the module setting the prop after the system.

If the boot stage already is set to the late_start service stage you might need to activate the soft reboot option for that particular setting. Sometimes a soft reboot is required after setting a prop for the value to be properly loaded into memory.

This may also be caused by the post-fs-data.sh script being set to run in the background because of the execution taking to long. Try disabling this option in the script settings and see if that changes anything.

There is also a possibility that the prop value you are trying to set is too long. This is only an issue on Magisk releases up until build 22006, where the prop value is limited to 91 characters. Builds after that should not have this issue.

My build.prop doesn't change after using the module

Magisk doesn't alter the build.prop file when changing or removing a prop value, it simply loads a new value or prevents the prop to load instead of adding or removing it from build.prop. If you want to check if a prop has been changed use the getprop command in a terminal emulator to check. Example:

getprop ro.build.fingerprint

If the prop has been removed, the command should return nothing.

My device's Android security patch date changed

For some fingerprints it is necessary to also change the security patch date to match the fingerprint used (the actual patch won't change, just the displayed date). This is automatically done by the module when using a fingerprint from a build after March 16 2018. If you do not want this to happen you can manually add ro.build.version.security_patch to the custom props and load back the original date, but keep in mind that this may result in the fingerprint not working and SafetyNet will fail.

My device's model has changed

In order to fool SafetyNet into using basic key attestation for the bootloader state check rather than hardware (which we cannot fool), the device model sometimes has to be changed to one that does NOT match the actual device. If your device uses hardware backed attestation, you might have to do this to pass the CTS profile check of SafetyNet. See Force BASIC key attestation for more details.

The Play Store is broken

If you suddenly can't find some apps, or that you aren't offered the latest version of an app, it might be because of having changed the device fingerprint. See Can I use any fingerprint? for details.

The interface looks weird

If the interface of the props script looks strange, with a lot of gibberish along the lines of "\e[01;32m", that means that your terminal emulator of choice can't display colours properly (the "gibberish" is a colour code). Check the terminal emulators preferences if it is possible to change the terminal type to something that can display colours. You could also run the props command with the -nc option (No Colour), or disable colours in the script settings.

Boot takes a lot longer after setting props

If boot takes longer than usual after setting a new fingerprint or a custom prop, try changing the boot stage to post-fs-data.

There's a reboot during boot

This happens when any prop is set during the late_start service boot stage and the soft reboot option is enabled. A soft reboot can sometime be necessary to properly load the new prop values, but also has the potential for causing issues on some devices.

The screen goes black momentarily at boot

See the section directly above about an additional reboot. Same thing.

The Play Store is "uncertified"

If your device's Play Store reports that the device is "uncertified", this is usually fixed by making sure that you pass SafetyNet and then clearing data for the Play Store (and possibly rebooting). More details in the Magisk troubleshooting guide.

Logs

In case of issues, please provide the logs by running the props script and selecting the "Collect logs" option (or running the props script with the -l run option, use -h for details, or collecting them manually as described below). All the relevant logs and module files, together with the Magisk log, the stock build.prop file and current prop values will be packaged into a file that'll be stored in the root of the device's internal storage, ready for attaching to a post in the module support thread, together with a detailed description of your problem.

The logs will also automatically be saved to the root of the device's internal storage if there's an issue with the module scripts.

If there are issues with other apps or your system as a result of using this module, a logcat/recovery log/etc showing the issue will most likely be necessary. Take a look in my Magisk troubleshooting guide for guidance on that.

Collecting logs manually

If you can't run the props script for some reason, or the automatic option mentioned above doesn't work, the module logs are stored in /data/adb/mhpc and all files in that directory would be useful for troubleshooting. The Magisk log (retrieved from /cache or saved from the Magisk Manager) and magisk.log.bak would also help. Providing the output from terminal might be useful as well.

Please provide the above mentioned files in an archive (zip-file), for simplicity and convenience.

Donations

If you've had any help from me or this module, any kind of donation to support the work involved would of course be appreciated.

Source

GitHub

Credits and mentions

@topjohnwu @ XDA Developers, for Magisk.
@Zackptg5, @veez21 and @jenslody @ XDA Developers, for help and inspiration.
@Some_Random_Username @ XDA Developers, for all the OnePlus fingerprints.
@Displax @ XDA Developers, for all the prints and the basic attestation workaround.
@ipdev @ XDA Developers, for being always helpful, bringing tons of fingerprints to the module list and the mHideGP script.
And of course, everyone that provides fingerprints for me to add to the list. The module wouldn't be the same without you guys. Thank you!

Previous releases

Any previous releases can be found on GitHub.

Releases up until v2.4.0 are compatible with Magisk v15 to v16.7.
Releases from v2.4.1 are compatible with Magisk v17 to v18.1.
Releases from v4.0.0 are compatible with Magisk v19+.
Releases from v5.0.0 are recommended for Magisk v19.4+.
Releases from v5.2.5 will only install on Magisk v20+. Releases from v5.4.0 will only install on Magisk v20.4+.

Changelog

v6.1.2

v6.1.1

v6.1.0

v6.0.2

v6.0.1

v6.0.0

v5.4.1

v5.4.0

v5.3.6

v5.3.5

v5.3.4

v5.3.3

v5.3.2

v5.3.1

v5.3.0

v5.2.7

v5.2.6

v5.2.5

v5.2.4

v5.2.3

v5.2.2

v5.2.1

v5.2.0

v5.1.2

v5.1.1

v5.1.0

v5.0.1

v5.0.0

v4.0.3

v4.0.2

v4.0.1

v4.0.0

v3.5.2

v3.5.1

v3.5.0

v3.0.3

v3.0.2

v3.0.1

v3.0.0

v2.7.2

v2.7.1

v2.7.0

v2.6.5

v2.6.4

v2.6.3

v2.6.2

v2.6.1

v2.6.0

v2.5.0

v2.4.3

v2.4.2

v2.4.1

v2.4.0

v2.3.6

v2.3.5

v2.3.4

v2.3.3

v2.3.2

v2.3.1

v2.3.0

v2.2.2

v2.2.1

v2.2.0

v2.1.6

v2.1.5

v2.1.4

v2.1.3

v2.1.2

v2.1.1

v2.1.0

v2.0.0

v1.2.1

v1.2.0

v1.1.0

v1.0.0

Current fingerprints list

List v137

MIT Licence

Copyright (c) 2018-2021 Didgeridoohan

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.