As we all know, Google's SafetyNet Team have been disabling the ability to fallback to device integrity for a range of devices recently. They promise to continue this trend until they completely phase out non hardware-backed attestation as per Shawn (@shawnwillden on X) which can happen as early as next year. This has resulted in issues with Pay, RCS, as well as crashing bank apps for EU ROM users en masse for the past few months.
In the past, custom ROMs have had to make an effort to fall back to device attestation, by refusing droidguard's ability to get the cert chain - the team behind EU ROM has also made a commendable effort diligently following this, which brought us to where we are today. At the moment, the ROM fakes the device's identity by injecting other device's build props to GMS/SafetyNet. To circumvent Google's SN team disabling old fingerprints server-side, the EU ROM adopts a very streamlined way to ship updated ones. It got so good that other ROMs and Magisk modules started pulling the data from EU ROMs earlier this year.
However, the bad news is that the number of available device fingerprints rapidly decreases by the day. For the past two months, despite the fingerprint shortage, it has been possible to obtain tens of working private prints from Google Pixel/Nexus OTA and beta images as I did so myself, but this changed as of this week where all Google's legacy devices are completely phased out, with beta builds' prints only truly temporarily effective requiring to be updated monthly.
Basically, the droidguard key attestation block needs to go, or at the very least we desperately need a way to be able to switch it off. The screengrab compares the framework.jar on any stock ROM (right) with the one on EU ROMs (left). Understandably, in an effort to avoid key attestation, the EU ROM's build script has skillfully patched out the function so droidguard/SN never gets to see the certificate. But, this is no longer helpful since we will have to switch to an alternative method in the future that likely relies on SN having access to at least a cert. In the past few days, changes have been propagating across ROMs including the official crDroid, PixelOS/PE, and most user LineageOS/AOSPE builds to include a switchable droidguard/SN block, just like the few months after fallback was introduced in the olden days. This allows their users to return to the stock key-based implementation if needed, giving more flexibility to both the ROM developer and the user once all remaining Pixel props are ultimately disabled in the near future. We would need this on the EU ROM as well.
Obviously I already have a way to achieve this so it is only in the community's interest if we ultimately want to adopt this - but one way to do this can be as simple as just guarding the droidguard restriction with a separate user-controllable toggle - or a device prop entry as the other custom ROMs have done it.
In crDroid, this was achieved incredibly simply as shown. A system prop is added that controls whether the fallback is to be activated or not. I think both Marcos (chiteroman) and Chris (osm0sis) have been getting these commits across the various ROM bases as well right now to prepare for Google's upcoming changes.
*The legality of a very popular workaround that is based off this modification shall be discussed in a separate thread, however - but the moral of the story is that unfortunately it could be just as bad as faking your device's identity to Google's servers.
In the past, custom ROMs have had to make an effort to fall back to device attestation, by refusing droidguard's ability to get the cert chain - the team behind EU ROM has also made a commendable effort diligently following this, which brought us to where we are today. At the moment, the ROM fakes the device's identity by injecting other device's build props to GMS/SafetyNet. To circumvent Google's SN team disabling old fingerprints server-side, the EU ROM adopts a very streamlined way to ship updated ones. It got so good that other ROMs and Magisk modules started pulling the data from EU ROMs earlier this year.
However, the bad news is that the number of available device fingerprints rapidly decreases by the day. For the past two months, despite the fingerprint shortage, it has been possible to obtain tens of working private prints from Google Pixel/Nexus OTA and beta images as I did so myself, but this changed as of this week where all Google's legacy devices are completely phased out, with beta builds' prints only truly temporarily effective requiring to be updated monthly.
Disclaimer
Make no mistake, faking your device's fingerprint is risky at best, and potentially violating Google's ToS. This was, however, partially mitigated by only injecting the device props for droidguard but not your OEM's / 3rd party / Google's other apps. A better alternative would be to change up the strategy from the ground up, which a lot of other custom ROMs have started adopting as of today - the TL;DR of this is that the user will need to be given more control over the implementation.*Strategy - The Why
Currently the EU ROM blocks droidguard's access to the leaf certificate to force the fallback. The problem is this ability will be deprecated in the near future - we cannot keep mandating droidguard and ask it to check our device model. Therefore, we quite urgently need to have a way to be able to switch off this manual barrier to allow GMS to proceed and at the minimum try to validate the certificate chain. This means you can then find a different way to get around your problem, instead of making the ability to fallback to device integrity the single hill that you will die on. Note that it is likely a bit early to completely migrate away from the droidguard restriction (as is the implementation on stock devices), because a lot of users still need the fallback as a reliable workaround for now.Implementation - The How
Basically, the droidguard key attestation block needs to go, or at the very least we desperately need a way to be able to switch it off. The screengrab compares the framework.jar on any stock ROM (right) with the one on EU ROMs (left). Understandably, in an effort to avoid key attestation, the EU ROM's build script has skillfully patched out the function so droidguard/SN never gets to see the certificate. But, this is no longer helpful since we will have to switch to an alternative method in the future that likely relies on SN having access to at least a cert. In the past few days, changes have been propagating across ROMs including the official crDroid, PixelOS/PE, and most user LineageOS/AOSPE builds to include a switchable droidguard/SN block, just like the few months after fallback was introduced in the olden days. This allows their users to return to the stock key-based implementation if needed, giving more flexibility to both the ROM developer and the user once all remaining Pixel props are ultimately disabled in the near future. We would need this on the EU ROM as well.
Obviously I already have a way to achieve this so it is only in the community's interest if we ultimately want to adopt this - but one way to do this can be as simple as just guarding the droidguard restriction with a separate user-controllable toggle - or a device prop entry as the other custom ROMs have done it.
In crDroid, this was achieved incredibly simply as shown. A system prop is added that controls whether the fallback is to be activated or not. I think both Marcos (chiteroman) and Chris (osm0sis) have been getting these commits across the various ROM bases as well right now to prepare for Google's upcoming changes.
Conclusion
The truth is, if we want to be able to support GPay, bank apps, and RCS in the long run, we have got to be able to make the shift quickly when the landscape changes. Alternatively, the EU ROM can just adopt what GrapheneOS is doing and reject Pixel Integrity as a flawed concept as a whole - forget about running bank apps on custom ROMs and call it a day until Pixel's security team ultimately makes a U turn to allow certifications from custom ROM developers.*The legality of a very popular workaround that is based off this modification shall be discussed in a separate thread, however - but the moral of the story is that unfortunately it could be just as bad as faking your device's identity to Google's servers.
