yashsingh1/xdaforums huggingface dataset:
[Magisk] Lughnasadh:
FYI: Migration deadline (for app developers) and full turndown deadlines for SafetyNet Attestation API have been extended.

Migration Deadline: End of January 2024

Full Turndown: End of January 2025

Discontinuing the SafetyNet Attestation API | App quality | Android Developers

developer.android.com
[Magisk] V0latyle:
Thank you, I'll update the OP.

As a notice to everyone else: This only matters to you in 2 circumstances:

You are using an app that has not migrated to Play Integrity. Apps that have not migrated will not receive SafetyNet attestation responses beyond January 2025.

You are an app developer. New apps must use the Play Integrity API; SafetyNet onboarding ceased in January 2023.
[Magisk] HippoMan:
Ah ... so the final end of Life As We Know It (regarding rooting and modding) has been postponed for an extra year.

This gives developers more time to turn their otherwise non-banking apps into banking-like apps which are crippled or don't run at all under root.

We should enjoy our apps on our rooted devices now, while we still can.
[Magisk] chiteroman:
Developers don't need to use Play Integrity and check the Strong integrity, they can just get the certificate chain of our devices and verify it in their servers. Unless you found an TEE exploit or bug to report a locked bootloader, or spoof somehow a valid X509Certificate we are f*cked.

And after getting a bypass and publish here, Google will blacklist everything and we are f*cked again XD.

They will be a tech "gods". So we will need two phones...

For 2025 say goodbye to root and custom ROMs.

That's why Microsoft are forcing users to implement a TPM device in all computers, it will be the same history...
[Magisk] V0latyle:
Bro...

This changes literally nothing. Most contemporary apps have already been migrated to Play Integrity. Developers have always had the ability to use SafetyNet attestation to determine device and OS integrity. Play Integrity does the exact same thing. It is completely up to the app developers to require hardware backed attestation, via a vis MEETS_STRONG_INTEGRITY, and nothing is changing regarding that. I do not know of any apps that require that result; all of the apps that otherwise detect root are doing so via their own methods completely outside of Google Play Services.

The SafetyNet turndown has not, does not, and will not affect our ability to use every day root or our ability to spoof basic/device integrity responses.
[Magisk] V0latyle:
Absolutely false.

TPM is required by default for Windows installation, but is optional - as in, you can bypass the installation requirements with a simple command line switch, and doing so does not affect the performance or security of the PC.

This has nothing to do with TPM. If it did, Google would probably revoke CTS approval for any device whose bootloader can be unlocked. Doesn't make a whole lot of sense when the entire Nexus and Pixel line has been unlockable. As far as certificates and keys goes...Nothing has changed in this regard. Any device with an unlocked bootloader, broken root of trust, or Android version prior to 8.0 cannot provide a hardware backed guarantee of device and software integrity. This wasn't possible under SafetyNet, and it isn't possible under Play Integrity. We can still pass BASIC_INTEGRITY née SN basicIntegrity=TRUE, and DEVICE_INTRGRITY née SN CTSProfileMatch=TRUE, resulting in MEETS _BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY as if SN evaluationType was BASIC.
[Magisk] zgfg:
Exactly. Retiring SafetyNet (SN) and enforcing only Play Integrity (PI) - currently both are available in the Google Play Services - six months earlier or later does not mean 'end of modding'

@HippoMan - if enforcing PI would mean 'end of modding' than you would already not being able to use Google's own Wallet (first app that has switched from SN to PI almost a year ago). But you can still use Wallet since attesting PI does not mean that device must pass Strong Integrity (it's up to the app and its developers/owners to choose if Device Integrity would be enough or Strong Integrity will be mandatory)

Even more, then apps never needed to switch from SN to PI - they could continue to use the old SN but by requiring CTS attestation by Hardware & that would also and already mean 'the end of rooting and modding' (being actually the same thing as using PI but requiring Strong Integrity instead of the weaker Device Integrity)

Hence once again, Google has defined and now postponed the date when apps must stop using SN but:

- Google does not require that all apps would have to use PI (after the Jan 31, 2025, Google will not block by any means apps that don't use SN neither PI)

- and Google does not require that apps who choose to use PI would have to require Strong Integrity (they can continue allowing Device Integrity as almost all of them do now)
[Magisk] HippoMan:
Given that you're not aware of developers trying to use MEETS_STRONG_INTEGRITY in order detect rooting or modding, that's good to know. So January 2025 will not be a "drop dead date", after all.

But sadly, more and more developers are still trying to detect rooting and modding in whatever ways they choose to do so, and this will continue to make it increasingly difficult to use their apps on our rooted/modded devices. There are already non-banking apps (such as the McDonald's app, to name but one example) that are doing so. Let's hope that few other app developers follow suit.
[Magisk] V0latyle:
Yeah, but that's not Google's fault by way of Play Integrity, and that's what I've been trying to say.

App developers could require the STRONG attestation, but doing so would mean that their app would not work on older devices, because Android versions prior to 8.0 are not capable of hardware backed attestation. That's probably why they're using their own methods to detect root. As far as why, there's not really any single answer. I would imagine the developer of any app that can be used for payment such as the McDonald's app would want to ensure that the device their app is installed on isn't compromised, and as we've talked about before, "compromised" includes rooted, even if deliberately. To the corporate beancounters who only care about dollar signs and lawsuits, there is no difference between people like you and me who want to use our devices the way we want, and the oblivious user who isn't aware their phone has been hijacked by a rootkit.
[Magisk] HippoMan:
I know that you have been expressing that, and I agree with you. I am not blaming Google.

I know that this outcome would be a result of decisions made by developers.

Nonethless, irrespective of whose decision it is, the end result of these efforts will be fewer usable apps on rooted/modded devices.
[Magisk] V0latyle:
Well, that's the cat and mouse game. They'll figure out some method by which to determine whether a device is "compromised", and we'll figure out a way to beat it. But that's all outside the scope of Play Integrity.
[Magisk] pndwal:
Seems to me that PI strongIntegrity etc is neither here nor there now... Devs that want it have strong attestation to secure boot handed to 'em on a platter and w/o device integrity APIs... This'll be the game changer...

I can't see much alternative to the two phones scenario personally, and I now doubt banks with any acumen will ever move to strongIntegrity PI verdict enforcement with this in the mix either... But what do I know?...

strongIntegrity seems to have been Google's big white 🐘...

😆 PW
[Magisk] intel_core_i7:
I don't know if you can answer this question but are you running latest EU rom for your phone? If no then try updating to see if it passes
[Magisk] chiteroman:
Oh, there is new update for my phone XD. I will update and see what happens :D
[Magisk] chiteroman:
New Xiaomi.EU update 14.0.3 don't pass Strong. But 14.0.1 yes :o
[Magisk] pndwal:
What mods were you running with 14.0.1 custom MIUI that might have affected strongIntegrity? PW
[Magisk] chiteroman:
Nothing, just a clean install (from bootloader) of 14.0.1 pass Strong.
[Magisk] pndwal:
Did it still pass after Magisk installed and main + droidguard (attestation) gms processes added in denylist? PW
[Magisk] chiteroman:
I was using Magisk Alpha + Shamiko + LSPosed and I pass it. (Hiding gms)
[Magisk] pndwal:
Ah... But passed before Magisk/Shamiko too w/ just XiaomiEU SNF right?... PW
[Magisk] intel_core_i7:
I have no idea but at least until some early builds of 22H2, the UEFI requirement is bs, I can still run it in legacy BIOS

Rikka's key attestation app bootloader status (locked/unlocked) can be bypassed (strong integrity still fails) with an xposed module... Best way they can actually check for bootloader locked status is via a third party server meaning internet required
[Magisk] intel_core_i7:
I wonder if it works when you revert to last build. I know one xiaomi phone which can do that (caught the moment in a telegram group before I told the guy to delete the fingerprint screenshot) but looking at the version number you told it's probably a different phone
[Magisk] chiteroman:
My phone is a POCO X3 Pro but Strong bypass is possible because they are spoofing somehow the certificate chain of Google Pixel 2.
[Magisk] intel_core_i7:
Hmm okay, it's totally a different model. I think it's best to delete the message RIGHT NOW since there're too many people using that phone. If google knows this then there are many users are going to be affected because there are at least 2 models having this "bug"
[Magisk] pndwal:
Not bs... The hardware is required:

https://support.microsoft.com/en-us...ure-boot-a8ff1202-c0d9-42f5-940f-843abef64fad

Isn't that exactly what I said in the post you quoted?! 🤔...

And @swer45 said this also!; That's how banks can have strong (reliable) attestation to B/L status without Google device integrity attestations... Use of server end validation is a given of course, as outlined in the Google model... 😜 PW
[Magisk] chiteroman:
Also spoofing device fingerprint will be useless when all devices provide a well implemented props attestation.
[Magisk] intel_core_i7:
It is "required" to make people panic and buy new hardware. I have 2 systems, one which only has Legacy BIOS and one with the third generation intel core i chip, also doesn't have any kind of TPM/TCM chip equipped (TCM is Chinese based version of TPM, I think you've known that already.

The first system is a sony vaio laptop, which did an upgrade from Windows 10 1511 to 21H2 via the official ISO, all programs and user data were kept. It also did an upgrade to an early version of 22H2 via that same method and it did work. Updating to later builds keeps failing so later 22H2 builds may actually need an UEFI based system, I don't have a spare computer to confirm this myth.

The second system as I said, doesn't have any kind of a TPM chip present and can still receive the latest canary builds via registry and temp file bypassing by injecting a dummy .dll file, has secure boot turn off but I have to admit that it boots via UEFI, so the hard UEFI requirement may be correct for latest updates. Earlier builds? Not so much

The "requirement" here probably implies that you would receive/ clean install windows 11 via windows update/official ISO seamlessly without any tinkering, not meaning it's critical for windows 11 to actually boot and function on your computer.
[Magisk] V0latyle:
Not necessarily

Exactly. The TPM requirement (and other minimum requirements) can be disabled per the guide I linked above. Microsoft to my knowledge has not made it impossible to do so, nor have they implemented any sort of mechanism that prevents Windows from booting or running if those requirements are disabled.

Well, the difference here is that Microsoft's implementation of Secure Boot is at the OS level, and it's not supposed to be able to be bypassed or disabled - meaning that a computer without TPM isn't supposed to even be able to boot Windows 11. Android is distinctly different in this regard - it will not refuse to boot if the bootloader has been unlocked.

While Google supports AOSP, they don't own Android, and Play Services is separate from AOSP. Indeed, Play Services continue to function despite device state, and Google doesn't enforce any sort of security requirements on the behalf of third party apps.

In other words, this whole anti-root philosophy has nothing to do with Android, little to do with Google, and everything to do with the end app developers.
[Magisk] pndwal:
As I said, I don't know much about this, but MS says UEFI is required and I can't update my old Pentium machine with Win 10... Says hardware not compatible. On the other hand my wife and daughter's later laptops update with no issues... I might look into your dummy .dll method sometime; thanks for the info.

However just as Google stipulated hardware requirements for CTS/VTS certification including basic keystore implementations before even Android 6.0 (Android already had a simple, hardware-backed crypto services API, provided by versions 0.2 and 0.3 of Keymaster HAL), long before ever using it to attest to device integrity, it seems that MS is doing the same for Windows machines with UEFI...

Just from Googling it seems MS is requiring UEFI hardware to better support large drive sizes (3TB+) and OS on SSD among other things going forward... Windows was UEFI compatible from Windows 7 (x64)/ Windows Server 2008 (x64) and UEFI is expected to replace traditional bios completely in the near future...

Apparently TPM 2.0 provides PCs with a modern hardware root-of-trust to help protect from both common and sophisticated attacks like ransomware and more sophisticated attacks from nation-states and elevates the standard for hardware security by requiring that built-in root-of-trust. (David Weston, director of enterprise and OS security at Microsoft blog post)

Like Google, MS does not have only secure boot attestation in mind when setting minimum hardware requirements. These machines require a hardware TEE OS just like Android/ARM in order to decode DRM content, store and analyse biometric data etc etc securely, and TPM's purpose is to protect encryption keys, user credentials, and other sensitive data behind a hardware barrier.

Even the fact that MS may not require secure boot components to be running on Win 11+ machines does NOT make the hardware requirements stupid... Secure boot attestation ability is only part of the picture; the hardware / TPM cryptographic keys may in fact be used by a raft of other functions and processes required on modern devices, and like Android MS sets minimum requirements. PW
[Magisk] chiteroman:
TPM is much better and more secure than a TEE or Strongbox. Also it's more difficult to hack, wait when games or another apps requiere TPM to work...

This is happening in Android but will be the same for Windows.
[Magisk] HippoMan:
Given that every Win11 system is already rooted in the same way that Android can be rooted, does this mean that every Win11 system will always fail this integrity test, if any 3rd-party app decides to perform this check?

If so, Microsoft's integrity check can be implemented in the following way:

bool system_has_integrity() {
return (false);
}

;)
[Magisk] V0latyle:
You bet

Yes

Yes and no.

Without Secure Boot + TPM, the Windows 11 installation is supposed to fail. Not sure whether Windows 11 will normally boot if Secure Boot and/or TPM is disabled post installation.

The difference I was trying to illustrate is that Android by design accommodates unlocked bootloaders - non-secure boot - whereas Windows 11 isn't supposed to, and bypassing that requirement involves modifying the registry, something Microsoft does not officially support or condone. In other words, Android doesn't care whether the bootloader is unlocked or not; since Secure Boot is implemented in the bootloader itself, Android will happily boot and run on an unlocked device, whereas Windows 11 (without unofficial modification) will not.

I think you get what I'm trying to say. AOSP is by definition an open source project; anyone can view, decompile, modify, etc. While Android and GMS are pretty heavily intertwined in the sense that Google owns the only official app market, it's still possible to strip everything Google from AOSP and use it without any Google services.

Maybe I was being too verbose. My point is that Google doesn't force any developers to use any particular attestation result. The only thing they do enforce is requirements for their own apps - you can still use Play Store on a custom build of Android running on hardware that's never passed CTS.

I didn't know this was possible. Interesting.

No, but the difference is (if I understand the Windows 11 requirements correctly) you cannot install and run Windows 11 on a PC with TPM/secure boot missing/disabled by default and bypassing this requires essentially unintended and therefore presumably unauthorized modification.

Android on the other hand doesn't care.

I probably made an incorrect assumption here, based on reactions from people who've made false assumptions themselves, such as: Play Integrity is the doom of Android rooting because Google will force STRONG_INTEGRITY for all devices. What I was trying to point out is that Android doesn't care whether or not a device is unlocked or rooted, and Play Integrity itself doesn't either - it simply reports what it thinks device state is, so the only role Google really has in this whole thing is its own proprietary apps (such as GPay/Wallet) that depend on PI responses.

Well...Administrator privileges =/= root access. Root is typically a temporary elevation of normal user permissions while administrator has admin privileges all the time. Sudo is more akin to the Windows SYSTEM account used by core processes, and to my knowledge even admin accounts can't go that deep.
[Magisk] pndwal:
Apparently it will:

https://learn.microsoft.com/en-us/w...desktop/disabling-secure-boot?view=windows-11

Also from link above, official method to disable secure boot without manually modifying registry: Disable Secure Boot. Results in Windows (since Secure Boots debut in Win8) happily running without secure boot and no different with Android 11.

Yup... This is really the relevant point in all of this...

Nah... their 'role' has been to mandate TEE, keystore etc in hardware used for Android and to publish methods for other (third party) apps to use these functions for reliable attestation to 'device integrity' so as to remain competitive in the secure Mobile OS arena...

👀 PW
[Magisk] pndwal:
Couldn't do better than @V0latyle's response above on this one...

As I said I'm really no Windows expert; You'd know much more about such tests than me too. 😉 PW
[Magisk] zgfg:
Few cents on Windows Secure Boot and TPM:

Secure Boot can be validated in System Information, by PC Health or in Power Shell:

https://www.howtogeek.com/283803/how-to-check-if-secure-boot-is-enabled-on-your-pc/

It can be also validated programmatically by the following code (C#):

using System.Diagnostics;
using Microsoft.Win32;

Func<bool> verifySecureBoot = () =>
{
var rc = 0;
try
{
var key = @"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\State";
var subkey = @"UEFISecureBootEnabled";
var value = Registry.GetValue(key, subkey, rc);
if (value is not null)
rc = (int) value;
}
catch { }
return !rc.Equals(0);
};

var secureBoot = verifySecureBoot();
Console.WriteLine("UEFISecureBootEnabled: {0}", secureBoot.ToString());

Screenshots attached

Windows PowerShell:

- Start

- Search for PowerShell

- right click, Run as Administrator

Execute (first command for Secure Boot, second for TPM):

Confirm-SecureBootUEFI

Get-Tpm
[Magisk] V0latyle:
@pndwal you don't have to respond to EVERYTHING I said, lol. I stand corrected on Windows and TPM, you only had to state that once brother.

@zgfg thanks for pointing that out, useful knowledge for anyone who wants to upgrade
[Magisk] pndwal:
Sorry... Fixed... 🤷 PW
[Magisk] chiteroman:
This can be spoofed easy, it's just a software check.
[Magisk] chiteroman:
Nooooo :(

Someone know a way to hide Permissive SELinux?
[Magisk] chiteroman:
I found it myself :D
[Magisk] immortalwon:
I was thinking about testing kernelsu, how did u get the right kernel?
[Magisk] chiteroman:
I'm using this: https://de8ug.blogspot.com/2023/05/d8g-kernel-v14-real-of-gamer-poco-x3-pro.html but KernelSU it's a bit outdated. I will try to compile myself the original kernel.

The good point of D8G is that I can use Permissive SELinux and pass Play Integrity (thanks to @huskydg).

Only install kernel, don't use any "plugins" this kernel includes.
[Magisk] V0latyle:
@pndwal and others, any knowledge of the "under the hood" link between Play Integrity responses and Play Protect certification?

Did some experimenting on my Pixel 5, stock rooted TQ2A.230505, with USNF MOD 1.2:

Disabled UNSF module, rebooted, confirmed Play Integrity reports fail of both BASIC and DEVICE labels. Play Store still reports "Device is certified", even though Play Integrity check in store dev options shows no labels

Cleared Play Store cache. Still reports "Device is certified"

Cleared all Play Store data. Certification simply disappears, it does not explicitly say "Device is uncertified"

Enabled USNF module, rebooted. Confirmed pass of both BASIC and DEVICE labels. Play Store does not report certified.

Cleared Play Store data. Now reports "Device is certified"
[Magisk] rodken:
Ironic.

-- I went through the same experimental regime a few months ago on my OnePlus 8 and was able to hit pay dirt.
[Magisk] zgfg:
Device is certified takes some time

Long ago (before PI) it's been discussed about. IDK how it works now

Eg, once (like two years ago), after deleting Data for PlayStore app, I needed couple of hours to get it showing Device is certified - until then, it was neither Certified nor Not certified, but SN was passing with no problem
[Magisk] V0latyle:
What do you mean?

In this case it was immediate. Clearing data then relaunching Play Store updates the certification status. Interesting that it doesn't seem to explicitly indicate whether a device is not certified, only if it is
[Magisk] Lughnasadh:
It once took close to a day for it to show up as either certified or not certified for me after clearing Play Store data. That was a while ago. Once it does show up , it has always indicated either "Device is certified" or "Device is not certified".
[Magisk] V0latyle:
Interesting, did you have dev options enabled in Play Store?

I only got "Device is certified", I never got the "not certified" message

Also, were you clearing all Play Store data or just cache?
[Magisk] Lughnasadh:
Currently, I do have dev options enabled in Play Store and it shows "Device is not certified". It has also shown this without dev options enabled. Cleared both Play Store data and cache. I don't ever remember it being different than this.
[Magisk] V0latyle:
Interesting. I should have taken screenshots.

I assume you're failing DEVICE_INTEGRITY?
[Magisk] Lughnasadh:
Yeah, I'm failing all three. Not trying to pass though as I don't need to.
[Magisk] rodken:
I was disabling/enabling a great number of modules to get a feel for how GPay would behave out on the field with or without 'device certification' in-play.