yashsingh1/xdaforums huggingface dataset:
[Magisk] ipdev:
I'm not a fan of locked bootloaders but, I flashed the stock rom and locked my Pixel 3aXL to grab props.

PS.

Magisk patched stock on bonito + locked bootloader = Red Boot. Will not allow you to continue boot. ;)

Note to all:

I only tried on my Pixel 3aXL because I knew I could restore it easily and mostly safe.

I will not try on my Poco F1 because I do not know for sure how easy it would be to restore. (Xiaomi can be a pain in the butt sometimes.)

I always expect the worst and have a backup plan before I potentially create a soft-bricked device. I keep my first hard-brick device in eyesight, to remind me that sometimes even backup plans fail.

Not sure if it's a prop file.. ?

Just a simple getprop running the March stock build Pixel 3aXL.

(commit is the second file pushed into the first one.)

Comparison between Locked vs Unlocked bootloader.

GitHub - Link

Between Locked vs Magisk

GitHub - Link

Between Unlocked vs Magisk

GitHub - Link

The getprop results are separate also.

(The ones names p3axl)

GitHub - Link

Also pushed the (magisk patched) getprop from N7(s) N9 N6p.

It seems Magisk does reset the changed properties.

Maybe someone can see something overlooked.

The only other thing I noticed is I have a magisk directory in persist on bonito.

It contains empty directories for the modules I had installed before I started clean flashing (way too many times) factory stock and locking/unlocking the bootloader.

beryllium (Poco F1) has a persist partition, not mounted with the gzr rom I'm running (yes currently fails cts). Using dd to dump the partition and mounting it on my computer, there is no magisk directory.

As you noted, is seems to affect newer devices.

LTE/WiFi and arm/arm64 doesn't seem to make a difference either.

deb and flo running android 10 (aex), angler android 9 (PixelExperience) volantis[flounder] android 7.1 (LineageOS 14.1) all pass.

Encryption doesn't seem to matter, at least for older devices.

Some are not encrypted, some are still FDE and some updated to FBE.

What are we all are missing?

I highly doubt Google is going to start blacklisting their newer devices for no reason.

Maybe someone knows someone who makes an app (or on the inside) that checks SafetyNet, and could find out if there was a change on Google's side??

Cheers all. :cowboy:
[Magisk] Didgeridoohan:
[MENTION=7280276]ipdev[/MENTION] Now that was gutsy... One wrong click and you could have ended up with another paperweight.

I'm going to sit down and do a thorough comparison between failing and passing devices' props later today or tomorrow.

But, you have two props that I've already been eyeing showing in your files:

ro.boot.flash.locked
ro.boot.verifiedbootstate

Both of those would be prime suspects for testing, since neither show up on any of my devices or is permanently set to the "safe" value (newest one being a OnePlus 3T), or your Nexus devices.

So, I went ahead and tested those two and by setting ro.boot.flash.locked to 0 I can 100% reliably get CTS to fail. Yay. The ro.boot.verifiedbootstate prop doesn't seem to change anything though.

So, we have something to work with!

Anyone that's having a failed CTS can try using this module and the custom props feature to change ro.boot.flash.locked to 1. You'll have to set the boot stage to late_start service or the prop might not change.

It's not guaranteed that this will work since there might be other props involved, but it's a start.

Edit: I made a typo... The safe prop value is 1.

Edit 2: Oh yeah... Major thought booboo. :D Since I was doing this while mobile I missed some stuff and didn't realise that those two props already are on the list of props being changed by MagiskHide. I'm gonna keep looking... :good:
[Magisk] fgprodigal:
it's not work for me, either edit ro.boot.flash.locked to 0 or delete this prop
[Magisk] Didgeridoohan:
That's because it's supposed to be 1, and that I made a typo in my last post... :D
[Magisk] fgprodigal:
yes, i conform it by getprop
[Magisk] Didgeridoohan:
You're quick. I edited my first answer to you. Take another look.
[Magisk] fgprodigal:
but this props is '1' originally without any editing
[Magisk] Didgeridoohan:
Like I said, there might be other things involved as well, this is simply a first test.
[Magisk] fgprodigal:
how to export all props like the one above?
[Magisk] Scunkanełi:
Thank you so much for your work, ipdev and Didgeridoohan!

On my device, the props in question without editing them manually are:

ro.boot.flash.locked=1
ro.boot.verifiedbootstate=green

Sadly I guess that means trying to edit them with Props Config won't help with ctsprofile returning false

I use "Collect logs" in Props Config and then look into the log file, where you can find a file named "currentprops". You can also use a terminal emulator and run "getprop"
[Magisk] nri_tech1183:
Hi there

As per our earlier conversation here:https://xdaforums.com/apps/magisk/csprofile-false-getting-resolved-t3978829/page2

all was perfectly good for 4 months and today suddenly Magisk reporting

ctsprofile:false

.

I went to Magisk only to find this message...

I haven't changed anything nor have xposed/edxposed installed.

I rebooted phone many time but issue persists..

I haven't updated magisk at all to the latest version & still on v19.4.

Last week somehow all apps got updated on playstore... is that the reason for this trigger?? But then too checked all was good regards to safetynet and cts.

Can I use Safetynet patch + MagiskHide Props Config at same time or do I need to use only one at a time ?

I'm in a mess and currently touring cities so dont have laptop or anything to do any complex configs.

EDIT:I removed Safetynet patch completely and installed MagiskHide Props Config and used fingerprint of Redmi note * but it had no effect then Used Pixel 4 and same issues.

I'm running out of ideas... Why is ctsprofile:false refusing to go ?
[Magisk] hyborian:
Thanks for looking into it. It's like looking for a cure for the virus. I don't have those entries in my build.prop, though, just fyi.
[Magisk] Scunkanełi:
With my limited knowledge, I tried going through all of my props looking for suspicious entries.

I noticed that in njtony's, zyokuro's and my propslogs, there is this similarity:

sys.oem_unlock_allowed=1

At the same time, mizunomidori reported for his SafetyNet passing device:

sys.oem_unlock_allowed=0

Of course I have no idea if Google even checks the value of this prop for SafetyNet. At the same time, it seems kinda dangerous to change the state of this prop (maybe the device will no longer boot?). So please do not try to just change the value here, please let someone with good knowledge look at it instead.

While searching, I came across this
[Magisk] Ardacer:
Great find, I've been digging through props too, there are several strange things, like ro.build.fingerprint and ro.build.fingerprint.true (or something of sorts... why would you have 2 values in your prop file for the same thing, unless it's a magisk thing, but I kind of think it isn't - I've edited both of these to mach a known working fingerprint - and 2 more entries where the same old fingerprint can be seen, forgot what they were, but no luck even with all 4 changed.)

There was a report of a device passing the test with sys.oem_unlock_allowed=1, though, from user Harmonics. (could be that the device didn't get the play store update?)

Also the busybox magisk module by osmosis is broken, at least for my device (xiaomi mi note 10).
[Magisk] wilsonhlacerda:
Just to let you know, today I checked my girlfriend's device that is FAILING SafetyNet:

Samsung S4 Active I9295

LOS14.1, Android 7

January patch

Magisk stable 20.3

Magisk Hide Props Config 5.2.4-80, S4 Active fingerprint

Play Store last updated 6/mar

Play Services last updated 6/mar

Unfortunately her setup is not equal to mine, although we have same device. But the updated Play Store / Services took my attention! Probably the piece of software on client side that is responsible for the new detection is the updated Play Services and/or Store.

Have you already tried to turn on Magisk Hide to both Play Store and Play Services (completely, not only Magisk default) and clean cache? I'll try that later on her device.
[Magisk] Ardacer:
I tried it, no luck. I have a stock miui note 10 which passes (obviously) and a rooted one running xiaomi.eu, which fails no matter what I do. They are both exactly the same devices (as in, one for my gf, one for me, from the same vendor, bought at the same time), so it might be beneficial to inspect both their props. I'll get to posting them later today.
[Magisk] wilsonhlacerda:
Nice. Also compare versions / last updated date of:

Google Play Store

Google Play Services

Google Framework
[Magisk] oslo83:
I was already spoofing ro.boot.flash.locked to 1 and ro.boot.verifiedbootstate to green.

And i'm still.

It did not helped to keep CTS checks passed since few days.
[Magisk] njtony:
Before that day, I did n’t update or change any programs. I only updated MagiskHide Props Config 5.2.4, and then cts was false. The rollback of 5.2.3 was still false, and then uninstalled Magisk, EDxposed, and updated back to stock boot. Cts still false, I suspect it is caused by unlocking the bootloader
[Magisk] Ava Pug:
i have a pixel 4 xl with ctsprofile fail. heres my diff from unlocked and locked bootloader

https://pastebin.com/Q9g5JN2H
[Magisk] Ardacer:
Here's my diff from locked to unlocked bootloader, xiaomi mi note 10. ONLY difference is the unlocked bootloader, otherwise stock phone from day one. No custom rom, no custom recovery, no custom nothing. No root.

[IMG="diff"]https://i.imgur.com/nDdEV1h.png[/IMG]

After unlock, fails CTS check. It's deff. the unlocking of the bootloader that's causing this. Or is it....

I'll procede to flash magisk on stock image, and try it's options to hide stuff, then report back. If it still fails, it must be the problem, but if it works, perhaps it's something else somehow.

Update: It fails CTS with magisk and all the proper things, repackaged, magisk hide from everything etc. on stock. So it should be the bootloader unlock.
[Magisk] Ardacer:
For people who can't get recommended busybox and magiskhide props config to work, install another busybox into /data/adb/modules/busybox-ndk
[Magisk] Didgeridoohan:
Why?

All you need is a Busybox installed and as long as it's installed properly the scripts will find it. Of course, I do all my testing with [MENTION=4544860]osm0sis[/MENTION]' Busybox so that's the only one that I can be sure that it fully works as intended.
[Magisk] Didgeridoohan:
Thanks to everyone that's contributing. The hunt continues. :good:

Edit: and yes, as soon as I came home and sat down at a computer to start cross-referencing I realised that the two props I posted about earlier already are taken care of by MagiskHide... :laugh: Note to self, don't do work like this while mobile. :D
[Magisk] TraderJack:
Just curious, would this be considered a "Magisk hide" issue and as such shouldn't be reported on Magisk Github?

Technically this is beyond just hide isn't it, since it is failing the ctsProfile before even attempting to hide Magisk.

I'm sure topjohnwu is probably aware of the situation, just didn't know if he felt this was something to be tracked and contributed to on that end, or if we are all just going the route that we think there is a new rogue build.prop somewhere.

My gut tells me that if Google decided to make this change, they aren't just checking a build prop since they are well aware we can easily modify those.
[Magisk] Terrails:
I'm going to try a couple of properties that other people posted, if it doesn't work I'm thinking about installing stock MIUI, making a copy of all the props with and without magisk and then lock the bootloader to see what got changed. I don't know if I'll be locked out of unlocking the bootloader for a couple of days again though, but its worth the wait if it helps solve this issue.
[Magisk] TraderJack:
I've gone ahead and set both of these to 0 using MagiskHide Props config. I figured that if it caused a problem I could always recover by disabling all magisk modules. I know get the following after reboot:

crosshatch:/ # getprop | grep unlock
[ro.oem_unlock_supported]: [0]
[sys.oem_unlock_allowed]: [0]

Still failing ctsProfile however.
[Magisk] Ardacer:
Because it didn't find Busybox installed. Neither osm0sis one, or any other ones for that matter. This is the sole version which works for me.
[Magisk] TraderJack:
Want to add that as soon as you view developer options the OEM Unlock button is still on and immediately upon opening up the dev options screen, it reverts to this:

crosshatch:/ # getprop | grep unlock
[ro.oem_unlock_supported]: [0]
[sys.oem_unlock_allowed]: [1]
[Magisk] Didgeridoohan:
I wouldn't make a Github issue for this... [MENTION=4470081]topjohnwu[/MENTION] is now working full-time at Apple and don't really have the time. The community needs to deal with this one. It might be a new prop check, or something completely different. We just need to try to dig in and figure it out.
[Magisk] Didgeridoohan:
If neither [MENTION=4544860]osm0sis[/MENTION]' Busybox or "any other one" are detected by the script, that just means that none of them are installed correctly... If you want, I could take a look at the install log for the NDK Busybox module.
[Magisk] TraderJack:
If for some reason the BusyBox magisk module isn't working for you, you could try the "Cross Compiled Binaries" module in the repo and install their BusyBox which includes osm0sis patches.
[Magisk] hyborian:
Maybe it needs to be edited directly and not through MagiskHide ?
[Magisk] TraderJack:
Perhaps, but I'm not willing to risk that yet.

I surmise that would have the same result as actually throwing the switch in Dev options which would trigger a factory reset of the device.
[Magisk] Djtrip83:
CTS Profile Failed and Device Not Certified but Root is Fine

Hi [MENTION=4667597]Didgeridoohan[/MENTION]

How are you?

I have been a Magisk user now since Jan 2018.

Big fan and user of your guides. Thank you for putting those together.

My phone is a Pixel 2 with Android 10 March 2020 update.

Root works fine and all my apps do not detect it. MagiskHide is working there.

I have been re-reading your Magisk guides for the last 2 days after Magisk started showing a ctsProfile = false BUT BasicIntegrity = true.

This may (or may not be) be the reason why Google Pay and other NFC-related payment apps are no longer working as well as Play Store stating my Device is not certified while I can access/install all apps.

I have a stock ROM so not sure what is making the phone uncertified. Therefore, I looked into the MagiskHide Props Config tool. First time I bricked the phone so I had to do a clean install.

Second time, I tried to update fingerprint and boot stages. However, ctsProfile still shows as false and I don't know where to look anymore.

See log attached

I can live without Google Pay but I just don't understand what the issue is so keen to hear your views.
[Magisk] TraderJack:
Read last few pages of thread. This is a known issue with Google's cts check now likely detecting an unlocked bootloader. This has started appearing for many people over last few days.

No solution as of yet.
[Magisk] Terrails:
After taking the output from unlocked and locked bootloader on stock MIUI with Poco F1 I found a couple of things that were discussed already:

[ro.boot.flash.locked] is 0 when unlocked and 1 when locked

[ro.boot.verifiedbootstate] is orange when unlocked and green when locked

[ro.secureboot.lockstate] unlocked/locked

I tried these values on my phone before locking the bootloader but that didn't fix safetynet. I guess I'll try to unlock my bootloader now and experiment a bit more.

EDIT: And yes, CTSprofile passed when I locked the bootloader
[Magisk] hyborian:
Let us know, I have Poco too. Just don't unlock bootloader if you are rooted, or with twrp, or custom rom. I am particularly interested too if after unlocking, will it be easy to lock again (i.e. no need to wait).
[Magisk] Terrails:
Didn't have to wait with Mi Unlock, its safe to do, but make sure to use Mi Flash Tool and do "clean install and lock" to clean install miui and lock the bootloader if you plan to do the same, or well in my case I first used "clean install" to get the props from stock ROM and then used the lock option.
[Magisk] Djtrip83:
I have to admit I realised after posting there were a few exchanges on the same topic. :D

If anyone wants to look at my logs, please feel free. Of course I have OEM unlocked, Developer Options enabled and USB/ADB debugging enabled.
[Magisk] Khep:
Xiaomi Mi A2 (Android ONE, no MIUI)

Stock 8.1 V9.6.9.0.ODIMIFE_8.1

Play Store: 18.9.22 (Device not certified)

NO fingerprints (just PIN), Unencrypted, USB debug OFF, TWRP + Magisk 20.3 (Busybox + MagiskHide Props Config)

Hide list: Play Store + Play Services + Google + G Service Framework

Downgraded to the oldest 8.1 version possible.

Do my PROP values look wrong? (I assumed Magisk took care of that already):

[ro.oem_unlock_supported]: [true]

[sys.oem_unlock_allowed]: [0]

ro.boot.flash.locked: [1]

ro.boot.secureboot: [1]

ro.boot.verifiedbootstate: [green]

ro.boot.veritymode: [enforcing]

There is no ro.boot.secureboot.lockstate entry (because 8.1?).

Still failing CTS profile. I can enter intro Ingress Prime game, don't want to test Pokemon Go.

Do not know how to add custom PROP values from the menu, but if needed I can try.
[Magisk] Ardacer:
Thanks! I don't really care, it works now. Your script is amazing btw. Just thought I'd share this workaround, it's possible the problem is specific to some devices.

Also I've edited suspicious prop entries through plugin manually and double checked, no cookie. Aw man I hope this isn't deeper than props...
[Magisk] Terrails:
Just tried adding these props back when the bootloader is unlocked and it doesn't change anything. Makes me think that this is going deeper than the props, which is going to make this a huge pain... google why do you do this.
[Magisk] TraderJack:
That's my belief. As per [MENTION=4381686]Ardacer[/MENTION] post a few pages back there were not very many prop entries that differed. Clearly Google has taken the time to make this change to have stricted enforcement. I doubt they would have simply checked one or two more prop values which they know we can easily modify.

As long as you are testing though, why not replace the entire prop config file from your locked phone on your unlocked phone. I think that will definitely tell us if this can be resolved with changing just a props value. My guess is not.

So likely this is checking for bootloader unlock in some other way. Refer to:

https://developer.android.com/training/safetynet/attestation#possible-results

I wonder if Magisk is actually getting the "advice" parameter returned in its request. If this can be exposed (maybe it is in the magisk log?) then we should at least know the reason for failure.

You may want to try unlocking the bootloader, installing magisk, modifying the props file to that of an unlocked system, then removing magisk. That way we could tell if it truly is just the bootloader being unlocked or Magisk detection.

I'm still poking around to find out the ways in which a system can be programatically queried for bootloader unlock status. I'm not really sure there is a universal way that would be implemented to effect all these devices.
[Magisk] Ardacer:
I'm currently trying to replace all of the props from locked status phone, I agree that it's the best thing to try next. Not really sure how to tackle that, default prop and build prop are way smaller than I expected...
[Magisk] Harmonics:
If it helps you, a few pages back I posted about a safetynet test app, which seems to return the advice status when you use it. But all the advice says, as you can see, is to "lock_bootloader", Google doesn't elaborate what small detail exactly caused it to fail.
[Magisk] TraderJack:
No, I missed that. Well assuming that app is returning the "advice" field from google, it would seem to indicate that the locked bootloader is the cause of the failure. Not that we didn't already mostly assume that, but it would be good to know for sure.

So the question becomes then how is that data being queried....especially if not from a props value (which we need to set an unlocked system with all the props from a locked system to be sure)....

---------- Post added at 10:19 AM ---------- Previous post was at 10:14 AM ----------

For what it is worth, here is a logcat during a run and failure of safetynet within MagiskManager:

https://pastebin.com/RW4JTtGY
[Magisk] Terrails:
I'm going to try to add all the props from the locked bootloader system now, I doubt that it will work though.

EDIT: Nevermind, android 10 doesn't like editing of the files directly since you can't mount /system
[Magisk] mizunomidori:
I'm so desperate that I was planning to relock my device in a root state. Is this the correct step to do it? Unlock > flash twrp > root > flash stock recovery > relock. Though I've been wondering if my device would still maintain root after relock cus I've lurk here and there and there is no way to relock without losing userdata and it's not recommend to relock after rooting. But then I found this vid https://m.youtube.com/watch?v=GV5XPPnSC5w is it worth to try?
[Magisk] TraderJack:
maybe do a getprop on both systems?
[Magisk] Ardacer:
Considering it's not really possible to get build.prop from locked phone, to my limited knoweledge, I did a getprop command and took its output which is larger than regular build.prop file. I've placed that into build.prop of unlocked and it won't boot, so I reverted it. I probably did something wrong.

---------- Post added at 07:38 PM ---------- Previous post was at 07:37 PM ----------

That's how I did the comparison.

Oh, also, if anyone tries messing with this and is a new to this (more than my humble self), do have a backup file and recovery installed that can do file management.

EDIT: just did the getprop | grep finger

and there it is, another prop, ro.build.fingerprint_real that still has unchanged values.

Could this be the thing? I'll try to remove it and try again

edit:

yeah..

no.
[Magisk] pharpe:
Trying to use MagiskHide Props Config on a Pixel 3a with Android 10 but getting this when I run prop

/system/bin/sh: prop: inaccessible or not found

I have Magisk latest stable with osm0sis busybox module installed. Any pointers on how to troubleshoot would be appreciated.

---------- Post added at 10:38 PM ---------- Previous post was at 10:37 PM ----------

Trying to use MagiskHide Props Config on a Pixel 3a with Android 10 but getting this when I run prop

/system/bin/sh: prop: inaccessible or not found

I have Magisk latest stable with osm0sis busybox module installed. Any pointers on how to troubleshoot would be appreciated.
[Magisk] fgprodigal:
'props', not 'prop'
[Magisk] hyborian:
Since old models seem to be passing cts, maybe google checks for model names too ?

Can someone try this ?

https://xdaforums.com/android/general/guide-change-device-model-extra-step-t3559040/page4

.
[Magisk] wilsonhlacerda:
Samsung S4 Active here: pass.

Exactly same device of my girlfriend (but different Android version): fail.
[Magisk] zyokuro:
Doubt it's model names. Could be tied to the latest firmware a device can get to. Devices that has Android Q releases might be getting false ctsProfiles even if the devices are downgraded to previous firmwares.
[Magisk] Tomiie:
I have multiple devices but only my 9T Pro is failing (Android Q, Lineage 17.1). Comparing its props with some of them, do you reckon less is more?

For start, there are way more props on the 9T Pro and some of them with different values. I just did a quick scan.

On the 9T Pro: ro.bootloader [unknown]

Not on other devices: ro.oem_unlock_supported [1]
[Magisk] pharpe:
Well that was dumb. Thanks