yashsingh1/xdaforums huggingface dataset:
[Magisk] Didgeridoohan:
Updated to v5.4.0-v113

Since Google decided to stir things up again, the trick to change model props to force basic key attestation no longer works. It was a nice run... But, all is not lost. There's a new fix by @kdrag0n that does things much more elegantly than a simple prop change:

https://xdaforums.com/t/magisk-module-universal-safetynet-fix-1-1-0.4217823

There's also a new fingerprint included in this update, courtesy of @tsteeples. Thanks.

Changelog

v5.4.0

Removed "Force BASIC key attestation". Google has once again updated SafetyNet and this method no longer works to pass CTS on devices with hardware backed key attestation. Use @kdrag0n's Magisk module instead: https://xdaforums.com/t/magisk-module-universal-safetynet-fix-1-1-0.4217823

Added fingerprint for the Fairphone 3/3 Plus. List updated to v113.
[Magisk] MahoVader:
Works perfectly for me with the new Safetynet fix plus changing the fingerprint to latest certified for my Pixel 2XL with MHPC. Thanks!
[Magisk] whitewallman:
Thanks for MagiskHide! I had one question, after uninstalling MagiskHide module and rebooting, Eval Type remained at basic. It was originally hardware (Pixel 4xl). Why would it still report basic after uninstalling MagiskHide?

Thanks.
[Magisk] zgfg:
You mean MagiskHide Props Config (module, aka MHPC), not Magisk hide - that is an option in Magisk

Does SafetyNet pass for you or not, and fo you use the new Universal SafetyNet Fix?

Apparently (as discussed last days and described on Univ. SafetyNet Fix Github), Google now reports Basic even when using Hardware

But if you use Univ. SafetyNet Fix, then it uses completely different method and it succeeds to force Basic, and you indeed pass with Basic
[Magisk] reizo111:
Yup, thanks for clarification on this. No issues and it works perfectly on my Redmi Note 9 PRO, RR rom based on Android 10.

This should also be mentioned for the reference tbh! - https://github.com/kdrag0n/safetynet-fix/commit/7fe2c90113de2ed821b518fd8c928a24be333d8a

Thanks for it all. I'm just a Python script kiddie myself but this is beyond me when someone comes up with such solutions. Reverse engineering and outsmarting things as crucial as SafetyNet is just not my skillset and it will never be in my whole lifetine. Thanks again.
[Magisk] whitewallman:
Thanks for your reply.

No, I was referring to the MagiskHide Props Config (module). I used it to force basic, assuming that once I uninstalled the module, the Pixel 4xl would revert back to Eval Type: Hardware when tapping "Check Safety net".

I haven't installed the other module you speak of yet. Trying to get back to it's pre MHPC state.
[Magisk] RenVilo:
When I tested my SafetyNet I got an EvalType Hardware error. I installed the Universal SafetyNet Fix and this now changed to EvalType Basic. I installed MagiskHide Props config and still the same issue. I then went into a terminal and added a fingerprint for my Note 9. Now the safetyNet passes but when I try to log into my banking or any other app it says my biometrics has not been enabled and takes me to my settings.. Am I missing something?
[Magisk] jhobc:
I use this module with force basic attestation option enabled on my Mi 9T Pro to set it to K20 Pro Global fingerprint with this I can get max quality on Amazon Prime Video.

Everything is fine with MHPC 5.3.6 + safetynet fix 1.1.0 - Test passing

Buy now with the recent update of the MHPC (3.4.0) this option is gone.

Tried the first option but no success.

It's possible to solve this with the new version?
[Magisk] zgfg:
Trick that was used by MHPC to Force BASIC does not work anymore, since of the latest Google change three days ago

In case:

- if you pass Basic Integrity

- but fail CTS Profile (no matter does it say using Basic or Hardware eval type)

go get Universal SafetyNet Fix.

For that case you cannot fix it anymore with MHPC (see also the next/following post below)

It was lor of discussion here in this thread, how and why, discussion about the new safetynet-fix module, and a link to the new XDA thread for that Universal SafetyNet Fix module (not yet available from Magisk repo).

if you missed all that about, scroll back

Ofc, first of all make sure that Magisk hide (option in Magisk) is enabled - but if disabled, then Basic Integrity fails and you are not (yet) in the case as above

You can still need MHPC, device fingerprint option for custom ROMs, but in that situation you will not be exactly in the case (conditions) as above. And if, after changing device fingerprint you still fail SafetyNet with the case/conditions as above, then you also need Universal SafetyNet Fix
[Magisk] zgfg:
You can still use Edit custom prop option in MHPC to change props like ro.product.model to something else - that was what the former option Force CTS Basic did (but it doesn't help to pass CTS anymore, hence that option was now removed from the latest MHPC)
[Magisk] Didgeridoohan:
As already stated, the custom props option would be the way to go. Or if you're already using the K20 Pro fingerprint you can just activate device simulation and turn on simulation of the model prop from there.
[Magisk] Didgeridoohan:
Many apps rely on more than SafetyNet to check for a compromised device (if they even use SafetyNet at all). Root hiding tips (although you'll find that there are many apps that you currently cannot hide from):

https://www.didgeridoohan.com/magisk/MagiskHide#hn_Hiding_root_from_apps

Edit: reading your post again it might not have anything to do with root. It might be the edited keystore actually, but that is just a guess on my part since it's a bit outside my scope of knowledge. Might want to check in the SafetyNet Fix thread as well.
[Magisk] Didgeridoohan:
I'm not quite sure what it is you want me to mention...
[Magisk] RenVilo:
Can I ask for a link to the thread you talking about? So I've been playing around today. Fresh rom with Magisk gives me a Hardware error and both checks fail. When I enable "Hide" then basic passes but CTS (I think its that) fails. Previously I had Xposed installed and that seemed to have worked to some extend but yea, would like to get SafetyNet passed but also have the fingerprint working :)
[Magisk] zgfg:
Universal SafetyNet Fix - link to its XDA thread was posted yesterday, scroll back to find
[Magisk] Hemudon:
Bro can you help? My phone has props problems always shown as android phone not as the rom intended to make loke pixel 3 xl or pixel 5, which leats to breaking the backup
[Magisk] Sid220:
@Didgeridoohan new fingerprint for Xiaomi Pocophone F1

Xiaomi/beryllium/beryllium:10/QKQ1.190828.002/V12.0.3.0.QEJMIXM:user/release-keys

Android version: 10

Security patches: 2020-12-01
[Magisk] jhobc:
Thanks custom props plus ro.product.model change did the trick.

But I noticed something. Initially I tested changing the fingerprint on the first option selected the K20 Pro Global but the module set a Mi 9T Pro one.

Should it be that way?
[Magisk] pndwal:
'much more elegantly'?... I hope you understand the implication of your own statement! (Sorry, couldn't resist... but you practically asked for it!)

If USNF is elegant, it must be said (as I did some time ago) that MHPC remains the most elegant (not to mention versatile) solution for MagiskHide related systemless customised prop configuration, (wow!) especially fingerprint props (still required by many in addition to new USNF module to achieve ctsProfile pass) as well as for customising props for myriad unrelated purposes!

Kudos for developing / maintaining this invaluable tool, your ever up-to-date 'wiki' tutorials/references for this and John Wu's Magisk, as well as your help and moderation here and role as XDA staffer. You are eminently qualified for the job.

Many Chinese and other uncertified stock ROM as well as custom ROM users will agree (at least that MHPC is an elegant and well implemented prop tool) and continue to benefit from your efforts. (...and don't say you didn't see this coming. 👏👍)

Kind Regards, PW
[Magisk] Didgeridoohan:
You need to be more detailed about your issue. I don't understand what you mean.
[Magisk] Didgeridoohan:
That is expected. When using the feature to "Edit device fingerprint" only the props directly related to the device fingerprint changes. To change more props, like the model, you need to use the "Device simulation" feature as well.
[Magisk] Didgeridoohan:
@pndwal To be honest, that particular wording was used only as bait for a certain someone...
[Magisk] pndwal:
Haha, but I knew that (still, I'll take it as a compliment)...

And sorry I kept you waiting (been too busy and was just reading back)... 😉 PW
[Magisk] Didgeridoohan:
But of course, the new method is better, IMHBCO. Changing the model prop was just not good and had always a temporary fix. This has the potential of being a more permanent solution, especially with @topjohnwu's work on zygote injection. We'll just have to wait and see though...
[Magisk] pndwal:
Quite, but we had @Displax's method, not Danny's at the time, and I'm not about to complain about that... It worked elegantly enough for me... until it didn't!

I think we're all happy Displax, Didgeridoohan and Danny have risen to the occasion when sorely needed... It's all we can hope for, especially when John Wu said "Let's face it. Fun is over guys" way back in March and all but assigned MagiskHide (outside of userspace) to the dustbin!... (Perhaps he should have been Don Wu).

Thanks to ALL you characters MagiskHide is still as potent as ever, and as you say, there's much potential left.

I too am hoping the latest innovation has real permanence, but also that it's not the last. PW
[Magisk] zgfg:
G will strike back, don't worry😁

Btw, I'm using even more elegant solution, I can pass SN without Magisk or (as I do) only with Magisk and Magisk hide enabled.

As mentioned in USNF thread, as of yesterday released Xiaomi.eu weekly 21.1.13, they have apparently built-in his solution into the firmware - they mentioned SafetyNet fix in ChangeLog and new 21.1.13 alone passes just as previous 21.1.6+USNF (21=yr, 1=mo,, 13=d)
[Magisk] Didgeridoohan:
Xiaomi circumvents SafetyNet in their official firmware? That's insane! Google could probably pull their certification for stuff like that...
[Magisk] pndwal:
EU versions are custom 3rd party debloated versions of MIUI, not endorsed by Xiaomi. 🙂 PW
[Magisk] Didgeridoohan:
Ah... I learned something new today.

Yes, the

most

elegant way to do the new fix is for custom ROMs to implement it directly into the ROM.
[Magisk] Didgeridoohan:
I haven't been able to download these logs yet, because XDA is being a pain in the derrier (404 error). But, I did take an extra look in the previous log and there are a couple of things that stand out. It seems like the Busybox binary is getting downloaded (complete or incomplete), but the md5 checksum doesn't match (possibly because of the incomplete download). Could you do a few things for me:

Run this command and then check (and post) the file size and md5 checksum of the downloaded file:

wget -T 5 -O /sdcard/busybox https://raw.githubusercontent.com/Didgeridoohan/MHPCBB/master/busybox-x86

And, could you post the contents of the /sbin/.core/img/MagiskHidePropsConfig/busybox.md5 file?

Edit: Managed to download the log. The wget issue is present on both devices. The one that seemed to be free of problems simply already had Busybox installed with the module, so no download was necessary.
[Magisk] osm0sis:
So does your GitHub's busybox work or is it just because it's not trying to wget anything anymore?
[Magisk] Didgeridoohan:
Since the Busybox binary was already present there was no need to download anything, thus wget did not throw an error.

It seems like if the device where things were working, [MENTION=8126387]martyfender[/MENTION] was simply updating from the previous module version where I did

not

have a md5 check. On the other device, where things failed, there was no Busybox binary present when installing the latest version, so the script downloaded Busybox and the md5 check failed. I've double-checked the checksum and it's correct, so the clock_gettime error seems to break the download somehow.

Is clock_gettime(MONOTONIC) used to give an ETA for the download? Because the wget progress bar is what's missing from the logs where the error now is.

Wait a minute... The script is downloading the x86 binary, but the device is x86_64, no? Could that be the issue? 32-bit should work on 64-bit, right... [MENTION=8126387]martyfender[/MENTION] Could you also provide the output of this command:

getprop | grep cpu.abi

And if you could replace the module Busybox with this and then provide the propsconf.log from /cache after having run the module script once, that would be great:

https://github.com/Didgeridoohan/MHPCBB/raw/master/busybox-x86_64
[Magisk] osm0sis:
x86 definitely works fine on x86_64. What I'd like to know is if it works without -T 5, or for your idea, works with -q added.
[Magisk] Didgeridoohan:
Good point...

[MENTION=8126387]martyfender[/MENTION] We'll try that next. :D After having run the standard command I posted above, try this and then get the md5 for that file:

wget -q -O /sdcard/busybox-q https://raw.githubusercontent.com/Didgeridoohan/MHPCBB/master/busybox-x86
[Magisk] martyfender:
u0_a90@NX16A8116K:/ $ su
u0_a90@NX16A8116K:/ # getprop | grep cpu.abi
[ro.product.cpu.abi]: [x86]
[ro.product.cpu.abilist]: [x86,armeabi-v7a,armeabi]
[ro.product.cpu.abilist32]: [x86,armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: []
u0_a90@NX16A8116K:/ #

I did not reboot. Also when I ran the props command I briefly saw a busybox error about not being able to run it and trying to download one.

When I add the busybox I had copied from the other tablet and change permission to 755, the props command once again works fine.

I had updated Magisk prior to this with [MENTION=3306843]kantjer[/MENTION] 2018080910.
[Magisk] runekock:
As to wget: clock_gettime(MONOTONIC) failed, in this otherwise unrelated case, it was a libc problem:

https://www.linuxquestions.org/questions/programming-9/clock_gettime-clock_monotonic-fails-465196/

If I'm being too stupid for words here, then please just ignore me...
[Magisk] martyfender:
I am enrolled in the Google Play Services beta and I often extract them and upload to apkmirror. they are the x86 407 builds and not the x86 + x86_64 408 builds, if this helps.
[Magisk] Didgeridoohan:
Only thing that gave us is that now we know that your device is posing as a 32-bit architecture... :)

If you could run the two wget commands and then compare the checksums for the two files saved in your internal storage (busybox and busybox-q), I think we're gonna be done for with testing for this time (unless the test shows something incredibly interesting). It's a weird one...

wget -T 5 -O /sdcard/busybox https://raw.githubusercontent.com/Didgeridoohan/MHPCBB/master/busybox-x86

And:

wget -q -O /sdcard/busybox-q https://raw.githubusercontent.com/Didgeridoohan/MHPCBB/master/busybox-x86

The md5 checksum is supposed to be:

170133693c4af03a6f311179793569ec
[Magisk] martyfender:
What do I use to determine the md5 checksum? It may some time before I am able to run those commands. Yes the devices are 32 bit. 64 bit software doesn't run on it.

Thanks
[Magisk] Didgeridoohan:
No worries. I'm in no hurry. There are a number of apps around that can check the md5, but you could also check it very easily with Busybox md5sum. Just run these command in terminal after running the previous two wget commands:

md5sum /sdcard/busybox
md5sum /sdcard/busybox-q

The string produced should match the checksum I posted earlier.
[Magisk] martyfender:
[MENTION=4667597]Didgeridoohan[/MENTION] With either of those commands I get:

wget: note: TLS certificate validation not implemented

Edit: files were created after all, I was stupidly looking in your mod folder for it. a file size of 0 M is created without the -q command and 1.3 M with the -q command and the md5 matches the one you posted.

u0_a90@NX16A8116K:/ $ su
u0_a90@NX16A8116K:/ # md5sum /sdcard/busybox-q
170133693c4af03a6f311179793569ec /sdcard/busybox-q
u0_a90@NX16A8116K:/ # md5sum /sdcard/busybox
d41d8cd98f00b204e9800998ecf8427e /sdcard/busybox
u0_a90@NX16A8116K:/ #

Does this mean you need to change the command you call in the module, or is there more to it than that?

Thanks
[Magisk] osm0sis:
Please also try one more time without -q, like so:

wget -O /sdcard/busybox-d https://raw.githubusercontent.com/Didgeridoohan/MHPCBB/master/busybox-x86;
md5sum /sdcard/busybox-d;
[Magisk] martyfender:
Are those 2 separate commands or do I enter it all at once?

Thanks

---------- Post added at 05:10 PM ---------- Previous post was at 05:04 PM ----------

u0_a90@NX16A8116K:/ $ su

han/MHPCBB/master/busybox-x86; md5sum /sdcard/busybox-d; <

Connecting to raw.githubusercontent.com (151.101.184.133:443)

wget: note: TLS certificate validation not implemented

wget: clock_gettime(MONOTONIC) failed

d41d8cd98f00b204e9800998ecf8427e /sdcard/busybox-d

u0_a90@NX16A8116K:/ #

The file created is a 0 byte file.
[Magisk] jenslody:
Workaround can be to retry the wget with -q if the first attempt has an or this error.

By the way the TLS-validation stuff is (more or less [mitm]) harmless.
[Magisk] osm0sis:
Yep, definitely seems like -q is the workaround for now until I get some time to look into a proper fix for x86 busybox. Hmm, I wonder if it works on [MENTION=4470081]topjohnwu[/MENTION]'s upcoming "FrankeNDK"-compiled Magisk busybox..
[Magisk] martyfender:
What is that, his own custom compiled version with modifications suited for use with Magisk?
[Magisk] osm0sis:
Yeah, pretty much; a custom NDK he hacked together for optimum/broadest device support. He'll be posting more about it soon after Magisk v17 goes stable. :)
[Magisk] Didgeridoohan:
Your Nextbook tablets are truly awesome for finding bugs, aren't they? :laugh: I'll try to get an update out as soon as possible, probably with something like the suggestion by [MENTION=8340552]jenslody[/MENTION].

[MENTION=4544860]osm0sis[/MENTION] Do you think it could be something with this specific device? That it's missing something, like in the case [MENTION=4610285]runekock[/MENTION] posted about.
[Magisk] osm0sis:
Shouldn't matter how broken bionic is on the device since busybox is statically compiled, so it's more of an incompatibility between the busybox source and the x86 NDK.

I guess the only things we didn't check out were supplying marty with John's x86 busybox binary from our latest internal Magisk build to see if the FrankeNDK headers/libc resolve it, and we should also get him to try -T 5 -q to see if -q alone is sufficient to work around it.
[Magisk] zgfg:
Yes, exactly.

With the official firmware I always needed to fake ro.product.model, with eu not, until three days back when G changed and USNF became mandatory for 21.1.6 at that time

But it's not just fully 3rd pty custom ROM.

These weekly builds are MIUI 12.5 / A11 betas for the upcoming official release accross all supported models. (current official is MIUI 12 / A 10, beta firmwares are not certified and you can't install without TWRP - hence they probably want to make it easier for users if they fake it to pass SN; however with betas you loose Widewine L1 and there is no workaround)

When officially released, it will be again certified firmware, not hiding if Bootloader would be unlocked

Edited
[Magisk] pndwal:
Yes, Danny indicates that this fix can be used without Magisk in his GitHub stating ”MagiskHide is required if the device is rooted", and he states in his XDA USNF thread OP ''Ideally, this workaround should be incorporated in ROMs instead of overriding part of the ROM in a Magisk module. The ROM changes for it are linked above for ROM developers to use."

He details requirements for ROM implementation (2 options) here:

https://github.com/kdrag0n/safetynet-fix#rom-integration

This mod started as a feature of his own ROMs. It was discovered in this one:

https://xdaforums.com/t/rom-pixel-5-official-protonaosp-11-3-0.4188129/#post-83887319

He has since worked on widening compatibility. It's also fairly obvious why ROM Devs without strict anti-spoofing rules (as official LOS and some others have) might want to include this out-of-the-box fix. PW
[Magisk] Drakax:
@Didgeridoohan

Hi guys,

It doesn't work for me :(

Phone: Pixel 3a, rooted

Update: January 2021

Google Pay version: 2.120.344959027

Magisk version: 21.2 (21200)

Magisk manager version: 8.0.5 (4802) (15)

Universal safetynet fix version: 1.1.0

No error during the flashing process/installation through magisk manager and it's appears in the magisk modules list after the reboot but I still get the *Attestation failed* from the SafetyNet check of magisk and the *Couldn't finish setup to pay in stores* error from Google Pay.

Any suggestion?

Thank you in advance!

Stay safe.
[Magisk] zgfg:
You can better ask in its corresponding XDA thread (dev opened) - link was also posted here yesterday or so
[Magisk] Didgeridoohan:
I'm assuming you're on the stock factory image, so editing the device fingerprint isn't necessary. As such, you are indeed in the wrong thread (the link to the new SafetyNet fix thread is in the latest changelog, post #2), but I'll throw a couple of ideas out there anyway.

First thing I would check is if MagiskHide is active. And if it is I would toggle it off and on again, possibly even rebooting after that and then check the toggle once more (just to make sure). Also testing if MagiskHide works, by putting a root app on the list and then see if it can find root. Could also be a Magisk module that's causing issues.

Those are some basics, you can find more details here:

https://www.didgeridoohan.com/magisk/MagiskHide#hn_SafetyNet
[Magisk] AndDiSa:
I just noticed the same for my Huawei M5:

there is e.g. ro.build.fingerprint and ro.huawei.build.fingerprint which contain different values.

I just saw that after applying the latest update ro.build.fingerprint kept did not change as ro.huawei.build.fingerprint did. I tried to "fix" that by applying custom property settings but to no avail. I fear that Google has pulled certification ... at least for some devices.
[Magisk] jcmm11:
License is GPL so altering and redistributing was not an issue
[Magisk] TheKerevas:
How can I have the device recognized in another way? I have a Poco F2 PRO and after updating it recognizes it again as Redmi K30 PRO (I have xiaomi.eu) :(
[Magisk] Didgeridoohan:
Yes, version 1.0.2 was GPL (MIT now). Although only apparent if you check the source, not the distributed file (which is why I missed it at first). IIRC the licence should be included with the distributed files but I might remember wrong on that detail. Nevermind now...
[Magisk] zgfg:
There is still Edit custom prop - defunct "Force Basic" was nothing else than editing ro.product.model (and few others, for Xiaomi you most likely need just that).

See OP post #1 and MHPC Github guide how to use the option (although it is very straightforward, start props, read the options, enter its number, etc)
[Magisk] Didgeridoohan:
Do you want the device to be recognised as a Redmi K30 Pro, or is it being recognised as such somewhere and you do not want that to happen? Clarification necessary...

If the former, follow @zgfg's advice above.

If the latter and you've updated the module to v5.4.0 any changes that were made with "Force BASIC key attestation" should have been reset. Always a possibility for things going wrong though... Details on where you're seeing the Redmi model would be needed, and I would also like to see the module logs.
[Magisk] jcmm11:
I checked the source. You're correct though, the license (and source code changes, if any, - or a pointer to where the changes can be found) should be included.