Open pndwal opened 1 year ago
pndwal
commented
1 year ago I originally put the comments above here: https://github.com/kdrag0n/safetynet-fix/pull/235#issuecomment-1378288343 in response to erroneous information about MHPC.
I've now made this issue since there's been no response...
I'm also aware that the issue of random failures w/ 2.4.0 is of more pressing concern... See here: https://github.com/kdrag0n/safetynet-fix/issues/248
TAbdiukov
commented
1 year ago Hi @pndwal , apologies for the erroneous PR of #235 . It was my mistake
Through the irony of fate, I ended up with ctsProfile Mismatch issue today! And as per my situation, I learned that for ROMs emulating Pixel experience, another package can be used: Pixelify. reference
Pixelify's main target is to make non-Pixel devices experience as close to pixel as possible, but in the process, it patches internal ROM information to report back a Pixel device.
I hope this information is useful
TAbdiukov
commented
1 year ago Regarding MagiskHidePropsConf -while it still works, since January 10, 2023, it reads,
This project is dead, and has been for some time. I have not been involved in the Android modding scene for some time and I no longer have the energy to take it up again. If anyone feels like taking over give me a holler.
Hopefully either someone picks up the repo to keep it going, or builds something new. Because otherwise, it already is beginning to suck, see https://github.com/Magisk-Modules-Repo/MagiskHidePropsConf/issues/164 and https://github.com/kdrag0n/safetynet-fix/issues/257
pndwal
commented
1 year ago Regarding MagiskHidePropsConf -while it still works, since January 10, 2023, it reads,
This project is dead, and has been for some time. I have not been involved in the Android modding scene for some time and I no longer have the energy to take it up again. If anyone feels like taking over give me a holler.
Hopefully either someone picks up the repo to keep it going, or builds something new. Because otherwise, it already is beginning to suck, see Magisk-Modules-Repo/MagiskHidePropsConf#164 and #257
Actually @Didgeridoohan hasn't had time to update this due to real life since Nov 2021, and just recently has said he hasn't got time for either MHPC or his XDA staffing roles for personal reasons and therefore MHPC is deprecated...
Apart from lack of fingerprint prop library updates the module continues to work well for a host of prop changes users may wish to apply systemlessly... Fingerprint changes for passing device integrity attestations were much used, but users make changes to countless other device props for various reasons...
The point I made above and in your issue is simply that MHPC is compatible with all Magisk builds; it simply has not become incompatible or broken in combination with 24.0+ builds....
Also, there are some efforts to keep forked builds updated, (see the XDA thread) but as these seem to be focused on merging new fingerprint/security patch prop submissions, forked builds may have little benefit over old official MHPC. See below...
It is true that for the purpose of passing new PI deviceIntegrity verdict MHPC will generally no longer help if USNF is used, but that's also fortuitous...
USNF now does fingerprint prop spoofing across the board to facilitate the mismatch required for many devices slated by Google for hardware-backed verdict enforcement using props to identify these (so a mismatch bypasses enforcement), and it targets the attestation/droidguard gms process specifically which is far better (for device-specific compatibility/functionality incl high end cameras, OEM appstores and backup services etc, etc) better than the global prop changes accomplished by MHPC anyway...
So it's not that MHPC 'sucks' at all, or that it is in any way broken, incompatible, or won't support late Magisk or devices; its just that whereas @kdrag0n was earlier not willing to provide requisite fingerprint/security patch prop changes only needed for uncertified ROMS (custom, China region, developer, beta, etc) and directed users to set these with MHPC module, the new need for such spoofing for stock ROMs in order for many devices to pass PI deviceIntegrity has meant he must now include it in order for USNF to stay relevant, especially as a fingerprint mismatch that still universally passes simply cannot be done with global spoofing without breaking untold functions in countless devices... ie universal but passing fingerprint prop spoofing is simply now beyond the scope of MHPC as targeted spoofing is needed using a hooking framework like Zygisk (or Riru etc)... MHPC will still work / be relevant for many other modding purposes however...
What we need when USNF fails (as it does currently) is an integrated fix or an interim solution such as @Displax has recently supplied in his forked USNF builds... đŸ™‚
@kdrag0n
We generally won't need to set fingerprint any longer to pass CTS Profile match for either old S/N or new PI deviceIntegrity even in custom, China region, developer, beta uncertified ROMs etc w/ USNF 2.4.0 because we now have mismatched but passing fingerprint set for gms natively (to bypass hardware evaluation type enforcement in some devices for PI deviceIntegrity verdict) and working (passing) for all devices I'm aware of, so readme wording does need adjusting...
The statement in this pull request: https://github.com/kdrag0n/safetynet-fix/pull/235#issue
is/was false however...
While @Didgeridoohan hasn't updated it for some time and has now sunsetted the whole project (he's now too busy with real life) MHPC certainly still works fine W/ Magisk 24+!!!... The issue cited there as 'related issue' is only asking for module update notification support (ie. an enhancement) since we got JSON based updates instead of notifications through old repo...
MHPC can still be used with no inherent problems w/ latest Magisk and may still be useful in some edge cases, I don't know, but the statement "MagiskHide Props Config is an easy way to do so on Magisk v23 and older" will only cause confusion.
Further, w/ native fingerprint spoofing the statement "You must already be able to pass basic CTS profile attestation" will no longer apply as even devices that couldn't pass with fallback and bypasses allowing Basic evaluation type use will generally pass with this addition...