yashsingh1/xdaforums huggingface dataset:
[Magisk] ipdev:
[MENTION=7550078]pndwal[/MENTION]
[MENTION=4667597]Didgeridoohan[/MENTION]

Thank you.

After reading your posts this morning before work, I found my palm and forehead were not only acquaintances but, they are still good friends. :D

See attached image. Doh!

--

I will truncate some of this message for now.

Remember I was trying to break it and this next part was found in the process.

It was something I partially noticed before when I was trying to FORCE Hardware attest on a device that was not.

--

Does it need to be an older device or just not the same device?

Tested on my Pixel 4a and Poco F2 Pro since they are Hardware attest.

Sure enough, I could select anything besides the actual device.

I can use Poco F2 Pro to force basic on my Pixel 4a.

I can use Pixel 4a to force basic on my Poco F2 Pro.

So the ro.product.model does not have to be an older device that was basic attest. ?

This would mean you could sidestep instead of downgrading the device?

My Poco F2 Pro was still hardware attest between the global and eea builds but, that did not surprise me.

Sharing the same device name.

Not sure if Pixel 4 is hardware attest but, it should work switching between Pixel 4 and 4 xl since they are different names.

OnePlus also I believe but, I'd have to double check on their name structure for their newer devices.

To make every one smile, I quickly grabbed and attached a screen shot from Poco F2 Pro.

Xiaomi Pixel 4A, that has to make everyone at least smirk a little. ;)

Hopefully someone with a Hardware attest device can check and confirm or deny my results.

Cheers all. :cowboy:
[Magisk] pndwal:
Haha... Not too hard!

And yes, that is a VERY interesting discovery!...

I wonder now if a simple failed check between Model prop(s) and Hardware TEE values actually circumvents Hardware Attestation...

Telling question is: Does this work within OEM's Models?... Do you get Basic Attestation using Pixel 4XL for your 4a?...

The implications of that would be VASTLY improved and up-to-date device specific functionality! :good: PW
[Magisk] zgfg:
I'm not sure if I understood your point but I actually don't use (I did test it, too) MHPC to force Basic attest, but my own system.props file where I spoof only ro.product.model, not the other three or four similar ro.product.* props

(the story started with HardwareOff module before MHPC was extended with the corresponding CTS profile option)

But the point is, I never redefine my ro.product.model to another/older device.

Instead, I just change it from my stock value "Mi 9T" to something else. Over time I used: "Unknown", "Undefined" and later started to use: "davinci" (it is the code name for Mi 9T, but not officially used for the model prop)

IMO, it's not only about that prop. It's about the combination with maybe ro.product.manufacturer (and fingerprint).

E.g., when G finds my manufacturer "Xiaomi" but with model "xyz", it's something unexpected and it drops to the Basic attest
[Magisk] Didgeridoohan:
[MENTION=7280276]ipdev[/MENTION], [MENTION=7550078]pndwal[/MENTION], [MENTION=7786725]zgfg[/MENTION]

The model prop can be set to anything. It can be gibberish as far as Google's concerned... If it doesn't match their criteria the device will use basic attestation (from what we've seen so far). But, [MENTION=7280276]ipdev[/MENTION]'s find is interesting. It implies that it also matches the manufacturer to the model (as stated above by [MENTION=7786725]zgfg[/MENTION]). If no match, use basic attestation.

The reason I'm using "old" devices for the default value of the module is to be sure you use a device that doesn't have the necessary hardware for the stronger check, since it has been reported many times that using a model prop that does match a device with the proper hardware will cause CTS to fail with evalType=HARDWARE. Edit: And "old" device from the same OEM... Forgot to add that part. This is so that OEM specific features might still work.

From those reports (I don't have that any devices to test this so I rely on reports by others, and that makes it damned hard to make these things work properly), I'm guessing that if you do pick another device from the same OEM [MENTION=7280276]ipdev[/MENTION], that does use hardware backed key attestation, CTS will fail (but it would be nice with a confirmation).

Of course, Google is probably changing things up all along and any testing and experimenting we do one day is completely null and void the next... :D
[Magisk] Didgeridoohan:
As [MENTION=7550078]pndwal[/MENTION] very correctly has pointed out, it did not register with me that you aren't passing basic integrity... That could be caused by a few reasons.

If you did have EdXposed or similar installed that will eventually trip SafetyNet. And you might not even get it back after uninstalling EdXposed, unless you also clear data for Google Play Services.

Another reason might be that MagiskHide have started failing on your device. Easily fixed by making sure that it is enabled and if it already is, toggle it off and on again.

My last post about your issue with not being able to pick a different model for the "Force BASIC key attestation" feature still stands though.

And, as I said previously, logs are great tools when trying to help with this stuff... :good:
[Magisk] pndwal:
... But not necessarily! (... but I don't really know much :eek: )

I wondered about this not only because it's now clear Hardware TEE 'list' device model prop(s) DON'T always mandate Hardware Attestation, but also because [MENTION=7280276]ipdev[/MENTION]s question was "Does it need to be an older device or just not the same device"?

... And [MENTION=7280276]ipdev[/MENTION] has already debunked this assumption! :)

Exactly! While this is most likely, we do need confirmation (I don't have rooted Hardware TEE device to test either) hence the observation "Telling question is: Does this work within OEM's Models?... Do you get Basic Attestation using Pixel 4XL for your 4a?..."

In the event that it passes, however, users could have more 'F'un (& 'F'ixes) w/ "f" mode selected! ... We'll also need to guess again regarding mechanism used if it's not Manufacturer dependant.

My thinking is that this could happen if a simple mismatch between Model prop(s) and device specific Hardware programmed TEE values causes Attestation to default to Basic.

Still a big IF, of course, and proof with be in the pudding. [MENTION=7280276]ipdev[/MENTION] could confirm. :good: :) PW.
[Magisk] Didgeridoohan:
Bloody hell... My mind is just completely shot at the moment. I'm struggling with even the most basic stuff...

I missed an important part in the text you quoted. I'm using "old" devices from the

same OEM

so that OEM specific features might still work (and as we've seen and are talking about here, that's were things seem to fail). That's the whole point of the feature. Otherwise we could just set whatever value for the model prop and get basic attestation immediately.
[Magisk] Some_Random_Username:
You can find a collection of OnePlus devices getprop/system.prop files at https://github.com/oxygen-updater/build-props , I think it may help you :)
[Magisk] zgfg:
Yeah, we've seen that on Pixels

On my Xiaomi, setting ro.product.model to anything does not affect (Mi Account, System Apps updater, etc).

Even Settings/About shows the correct model - only All Specs takes the spoofed value

Anyway, I would strongly suggest to disable MHCP (spoofed props) before any OTA
[Magisk] Didgeridoohan:
Fingerprints list updated to v105

There's been a ton of prints submitted lately. All tested and added to the list.

As usual the list will update when you run the props command, or by using the -f run option (use -h for details) or from the "Edit device fingerprint" menu if you've disabled automatic updates.

Lot's of thanks go out this time. Many friendly users helping out making the module what it is. Thank you (in no particular order) [MENTION=4168589]TheUndertaker21[/MENTION], [MENTION=11140049]Feeleepino[/MENTION], [MENTION=7815705]TheGame455[/MENTION], [MENTION=10304663]retroboy80[/MENTION], [MENTION=7280276]ipdev[/MENTION], [MENTION=11129403]Mirardt[/MENTION], [MENTION=8642859]Dr.MI[/MENTION], [MENTION=8234677]Some_Random_Username[/MENTION], [MENTION=11159389]pungat[/MENTION], [MENTION=11130029]dynux90[/MENTION] and [MENTION=6345368]Displax[/MENTION].

New prints

Meizu 16th

OPPO Find X2 Neo European

POCO X3 NFC Global

Redmi K30 Ultra

Redmi Note 9 Pro European

Redmi Note 9S European

Samsung Galaxy A01 Core

Samsung Galaxy A40

Samsung Galaxy M21

Samsung Galaxy Note 20 Ultra

Xiaomi Redmi 7A

Updated prints

Google Pixel 2 to 4a (all variants)

OnePlus 7, 7 Pro, 7T, 7T Pro, 8, 8 Pro and Nord (most variants)

POCO F2 Pro
[Magisk] TheUndertaker21:
Amazing.

Also exposed is passing now thanks to you.

Just need to flash the Canary version of edxposed
[Magisk] geekopa:
Xiaomi Redmi Note 8. Codename ginkgo (not Pro or 8T which is called willow). It just received LOS Android 10.

Official MIUI build.prop

ro.system.build.fingerprint=xiaomi/ginkgo/ginkgo:10/QKQ1.200114.002/20.8.27:user/release-keys
ro.build.version.security_patch=2020-09-01

though cts profile still fails for me (checking is basic, and not hardware backed anyway). I also tried post-fs and am out of ideas till I get the logs (Will get them 2morrow)
[Magisk] nri_tech1183:
@Didgeridoohan

I recently flashed Blissrom on my Redmi Note 7 Pro and google is recognizing my device as Pixel 4 instead of Redmi Note 7 Pro.

The biggest issue is I'm not at all able to use Outlook and pass the Microsoft Intune verification as the Device Identifier value reports as Not available. Hence I'm not able to link to my companies O365 and access emails. Nor bale to use Teams or any Microsoft tool.

My phone inst rooted. But I tried rooting and Magisk passes all CTS properly so no issues.

Rest all apps working perfectly incl. banking apps etc. either in root or no root.

I flashed Resurrection rom to test and same issue on Microsoft apps and google recognizing device as Pixel.

In all these roms I came across this setting: Device identifier. I toggled it but no luck passing/registering on Microsoft.

What might have possibly gone wrong?

Can MagiskHide Props Config rescue here?

Has google blacklisted my phone or something?
[Magisk] Didgeridoohan:
That print /date combination doesn't pass CTS, so no need for logs.
[Magisk] pndwal:
Yup, that's the only point of using a real device it seems.

But [MENTION=7280276]ipdev[/MENTION] has shown even non-matching Hardware TEE model gives Basic Attestation!

We only need confirmation this needs to be a DIFFERENT manufacturer by trying with same.

[MENTION=7280276]ipdev[/MENTION] got Basic w/ Poco F2 Pro props on Pixel 4a, and Pixel 4a props on Poco F2 Pro.

He could try Pixel 4 XL on 4a to confirm.

[MENTION=7786725]zgfg[/MENTION] could try MI 9 on MI 9T.

Simple! PW
[Magisk] Didgeridoohan:
Looks like the Bliss maintainer for that device is using a Pixel 4 XL fingerprint in the ROM.

ui_print("Target: google/coral/coral:11/RP1A.200720.009/6720564:user/release-keys");

Why? No idea, ask them...

As far as I know, Microsoft checks for modifications to your device (unlocked bootloader, custom ROM, root, etc). You might be able to get things working again with Magisk and MagiskHide, but I can't help you with that. There are a few threads regarding Microsoft and their apps around. Search around and you'll probably find something. Here's one: https://xdaforums.com/apps/magisk/microsoft-intune-company-portal-t3611588
[Magisk] nri_tech1183:
Ok.

I just flashed stock miui rom and on first boot during setting up the it gave this error "Find device storage corrupted your device is unsafe now"

Can this be the reason as well for Intune/Ms app failure?
[Magisk] Didgeridoohan:
No idea... That sounds like a MIUI thing so you're likely better of searching/asking in your device's forum.
[Magisk] zgfg:
Cannot make any useful test, these days it always pases for me with Basic CTS attest, without the need to fake ro.product.model

Hence be careful when making conclusions, test also with the stock value (if passing, all conclusions could be false-positive)
[Magisk] pndwal:
Ok, so are you actually getting Basic evalType with NO model prop changes on MI 9T? PW
[Magisk] zgfg:
Yes, as stated. This started to happen two weeks ago or something, ir was definitely all reported here or in Magisk thread (not only me)
[Magisk] pndwal:
Thanks...

So it's possible all this excitement is for nothing!

... unless [MENTION=7280276]ipdev[/MENTION] can confirm he still gets evalType 'Hardware' on Poco F2 Pro and/or Pixel 4a w/ no charge to model prop(s). :)

Like Didge, I can't test at present, but soon will root my RedMI 8T... PW
[Magisk] dimm0k:
am I pretty much stuck between a rock and a hard place? Google Pixel 4XL, magisk and unable to pass SafetyNet. passing basicIntegrity, but failing ctsProfile. only way to pass both is to use the "HARDWARE OFF" module, but using that causes some apps to not recognize the biometrics to unlock like the Wells Fargo app. am I missing something to have my cake and eat it too?
[Magisk] ipdev:
As I mentioned. ;)

So yes.

I can use a Pixel 4 (4XL) and I get BASIC test on my Pixel 4a.

The only way to get HARDWARE test back on my 4a was to use the prop setting for 4a. (actual device)

Poco F2 failed because the global and eea builds are the same save for slight difference in bloat/spy ware.

They both use Poco F2 as product.model.

It was a quick dumb test but, I would have questioned if there was a difference or not until I tried it.

Using Redmi K30 Pro, I get BASIC test and pass just fine.

I am not sure if Redmi K30 Pro is a device that uses HARDWARE test.

Redmi K30 Pro is the same as Poco F2 just different brand release.

Slight prop name changes but, both are lmi.

The miui Android 11 beta for Poco F2 is the K30 Pro beta.

@ zgfg

Good point and yes I do.

I reset MHPC in between testing and make sure I get HARDWARE test and fail SafetyNet.

Just to make sure I am not dragging any change along for the ride.

--

On the other side of this topic..

Pixel 3a XL Google Stock Android 11 uses BASIC test out of the box.

Since it is a current certified rom, and using BASIC test, it only needs MagiskHide enabled to hide the secure prop values to pass BASIC SafetyNet.

I can get HARDWARE test on my Pixel 3aXL if I use full device simulation and choose Pixel 4 or 4XL

This obviously fails SafetyNet since it uses hardware.

Not sure where this is taking me but, using full device simulation changes enough to get HARDWARE test.

So bootloader version and board name do not seem to affect it because they are still bonito (3a XL) values. ?

Running full simulation using Pixel 4a on my OnePlus 5T was still BASIC test.

So there must be another part in the chain. :confused:

--

Cheers all. :cowboy:

---------- Post added at 01:36 AM ---------- Previous post was at 01:06 AM ----------

Disable the hardware off module.

You may need to reboot after disabling the module before setting it in MHPC.

I am not sure if needed.

Use the Force BASIC key attestation option in this module.

Follow the prompts and select Pixel 4 as the device to use.

Not the 4 XL. It has to be a different device, not the same as you are using.

Reboot and check SafetyNet.

If it passes then see if it fixes your fingerprint sensor issues.

Good luck.

Cheers. :cowboy:
[Magisk] pungat:
After I tried it with new list fingerprint it didn't work, the cause was evalType = HARDWARE

so I followed method at: github.com/Magisk-Modules-Repo/MagiskHidePropsConf/blob/master/README.md#force-basic-key-attestation

IT WORKS!!

thank you [MENTION=4667597]Didgeridoohan[/MENTION], [MENTION=6345368]Displax[/MENTION]
[Magisk] Didgeridoohan:
[MENTION=7280276]ipdev[/MENTION] Full on experimental mode... :D Thanks for sharing and really interesting. I just wish I could join in the experimental fun times.

I'm gonna leave the module as it is though. Most users just want to force basic attestation and be done with it. Google is probably changing things in the backend all the time, and the option works as advertised. Power users and tinkerers can set whatever value they find works best.

About testing on the OP5T: as far as I know it lacks the hardware to do hardware checks (it shipped with Android 7.1.1 and the requirement for the hardware wasn't introduced until Android 8, IIRC), so it doesn't matter what value you pick. You can't force it to use hardware it doesn't have...
[Magisk] Franc89:
HI HERE

i whant to know if magiskhide_props can hide knox :0x1 to show 0x0 or hide system status from custom to official if yes how to do that?

THANKS
[Magisk] Didgeridoohan:
No... As far as I know (I don't do Samsung), you can't fool Knox with simple prop changes. Going from "custom" to "official" I know nothing about (connected to Knox, maybe?), so that you're better of asking in your device's forum.
[Magisk] Franc89:
My mobile is S9+ japan model

Android 10
[Magisk] Didgeridoohan:
Ok... So here would probably be a good place to ask for help: https://xdaforums.com/galaxy-s9-plus
[Magisk] cmstlist:
So I'm on Pixel 4a, using the attestation fix with 3a selected.

I recently got an OTA notification which reads:

Security update available Improve the security of your device (Pixel 3a)

Is there any way to be totally sure if it downloaded the wrong OTA for the wrong device?
[Magisk] Didgeridoohan:
I wouldn't install that (it probably won't install anyway, but just to be sure)... Deleting the OTA file, disabling the attestation feature and then redo it sounds safer. Or maybe just download the proper OTA file and install that manually.
[Magisk] cmstlist:
Yeah I'm a bit wary of letting it ever boot up with attestation module disabled right now because:

- The moment that happens, Google Pay notices and saves something in the Google Play Services data that makes it distrust the phone

- Last time to fix that I had to clear Google Play Services data

- Doing so also wiped the device's COVID tracing data (for Canadian COVID Alert app) and I don't want that to happen again for public health reasons

(for next time, any idea how I might selectively clear only the part of GP Services data that matters, without clearing the COVID data?)

(also any idea how to browse for the downloaded OTA and inspect it?)
[Magisk] Didgeridoohan:
I've never used Google Pay, so that's not something I can help with.

Sounds like downloading the OTA file and sideloading it is the safest and easiest option.
[Magisk] dimm0k:
This worked like a charm! Luckily I had the hardware off module already disabled so I only had to force BASIC key like you said to a Pixel 4. Now both SafetyNet and biometrics work again! Thank you! also thank you to [MENTION=4667597]Didgeridoohan[/MENTION] for this module to simplify all of this!
[Magisk] pndwal:
Sorry, missed 'same OEM' test bit...

Fantallytastic! (For many reasons).

So Controlled Experiment. :good:

That's the interesting part... And blows my last theory...

Yep. Still seems to me SN is checking model prop(s) against something, but now it seems to be other props!

Unless I'm wrong again, SN is checking for (at least) two matching Hardware TEE device props on a device to use Hardware Attestation.

Seems Force Basic using different Hardware TEE device model selected works because SafetyNet returns mismatched values and defaults to Basic Attestation.

Also, now seems Force Basic using ANY incorrect value actually works for the same reason: the model prop value does not now MATCH other Hardware TEE device prop(s), causing default to Basic Attestation.

Conversely on a device [at least, one with Hardware TEE] not yet flagged by Google to use Hardware Backed Attestation, Full Device Simulation of a Flagged Hardware TEE device 'forces' Hardware Backed Attestation because SafetyNet is now returning matching props for Hardware TEE device.

Agree must be another element here, and there could be several explanations.

[Most obvious is that Hardware TEE implementation is OEM specific. The device props SN looks for may include OEM specific code / values that need to match hardware. (In Pixel 3aXL w/ Pixel 4 test, these WOULD match.) So this failure to launch could be due to a MISMATCH also. You could confirm by simulating Hardware TEE OnePlus device on OnePlus 5T.

Another thing, it was reported when Google initially switched on Hardware Attestation, and switched it off again in short order, that this was due to bad Hardware TEE implementation on devices, specifically OnePlus! Apparently the respite for Hardware Attestation is to allow time for these devices to be 'Fixed'. So could be Hardware Attestation is simply bypassed for OnePlus / your model at the moment.]#

This is all only deduction, so on the question of 'which props', I'd have to have time to study it. PW

#Edit: HaHa, I think [MENTION=4667597]Didgeridoohan[/MENTION]

put his finger on this! (Most likely reason; guess the Pixel 3a XL actually has the hardware.):

https://xdaforums.com/apps/magisk/module-magiskhide-props-config-t3789228/post83656075

---------- Post added at 04:03 PM ---------- Previous post was at 03:32 PM ----------

So can I take that as official? - 'f' stands for 'Full on experimental mode' / 'Fun times for Power Users'! ... Happy with that. :good: :D PW
[Magisk] Some_Random_Username:
[MENTION=4667597]Didgeridoohan[/MENTION] , here's OnePlus 8T EU fingerprint: OnePlus/OnePlus8T_EEA/OnePlus8T:11/RP1A.201005.001/2009210039:user/release-keys__2020-09-01

Note that exact model number is currently unknown, I guess we will know it when device will be officially released on October 14th.
[Magisk] geekopa:
I tried again and this time it passed. I added these props:

ro.system.build.fingerprint=Redmi/begonia/begonia:9/PPR1.180610.011/V10.4.1.0.PGGMIXM:user/release-keys
ro.system.build.fingerprint_real=xiaomi/ginkgo/ginkgo:10/QKQ1.200114.002/20.6.17:user/release-keys/1592537410
ro.build.version.security_patch=2019-09-01
ro.build.version.security_patch_real=2020-05-01
[Magisk] Didgeridoohan:
Could you elaborate on what those "_real" props are? Never seen those before...
[Magisk] bartleby999:
So, I'm experiencing a weird issue - When module is active I can pass CTS but some YouTube videos only show in 480p - Disabling the module allows me to stream 1080p, enabling again only allows 480p.

Anyone else had this issue or know any reason it could be going wrong?
[Magisk] pndwal:
What settings used in MHPC? What device? What ROM? PW
[Magisk] bartleby999:
My bad.

Stock rom on Galaxy Tab S6 (SMT860). I only used the Force Basic Key Attestation option and even then, selected my own device model.

::Edit:: No, I'm an idiot - I didn't use my own device (because of course I couldn't I'm failing so it why would spoofing my own device work) I used SM-A300FU which I'm guessing is a lower spec device. That'll teach me for not paying attention.

Still, it's weird that it's only some YouTube videos that are effected. I'm guessing because HDR is not available on SM-A300FU so youtube doesn't show that option? I'll try a newer Samsung witha spec closer to mine.

::Edit 2:: So, yeah - Using a device much closer to mine (TabS5e) returns HDR support in YouTube.

So it's been an annoying 12 hours (which I thoroughly deserve for not reading prompts correctly), but CTS is passed & I've finally restored HDR support.