Displax / safetynet-fix

SafetyNet & Play Integrity API workarounds for Magisk

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Seem to be unable to get it working on graphene os

garandal245 opened this issue · comments

just to preface this is on rooted graphene os i understand if you dont want to assist since im a % of a %. Before anyone else says ik you shouldn't root graphene and i don't really care, i care more about my privacy and aslong as i am actually careful with which app i provide root too its security isnt as compromised

cant seem to get it working on graphene at all attempted 2.0, 2.0 strong, and 1.3 none of them worked

Testing SafetyNet:

Testing Play Integrity API:

Device model: pixel 7 pro
Android version: 13
ROM name/version: grapheneos 2023071100

issue.log

Checklist

  • [ ✅] I confirm that the SELinux status is Enforcing on my device.
  • [ ✅] All information is present
  • [ ✅] Screenshots are attached
  • [ ✅] Logs are attached

That's how GMS works in GrapheneOS (sandbox).
Cannot be fixed by the module.

i care more about my privacy and aslong as i am actually careful with which app i provide root too its security isnt as compromised

Unfortunately, that's not at all correct. You've substantially reduced the security of the OS and you've turned many kinds of vulnerabilities into full persistent root compromises. You've lost many of the security features of the OS, including both Android features and GrapheneOS added features. You can check if you're running GrapheneOS with the security properties intact using Auditor. You're also likely to soft brick the device and lose your data in a future update since there's no official support for what you're doing and it's not considered as part of making low-level changes. Many of those low-level changes could break it.

That's how GMS works in GrapheneOS (sandbox).

The weak SafetyNet / Play Integrity software attestation checks some things like the SELinux domain. It would be entirely possible to spoof it, but we don't do that. Proper usage of the hardware attestation API can't be spoofed and over time services are going to check for that instead of these weak checks, which makes us wary of giving users false hope by getting services temporarily working until they move to hardware attestation. We're still open to spoofing these things to an extent if the changes are uninvasive. There's no inherent reason it can't be done, but a bit more would have to be spoofed due to it checking things like SELinux domain.