Devices with mismatching system and vendor security patch levels

[kdrag0n]

As reported by @bwegge:

Hi, firstly thanks a lot for this effort and quick remedy.

My phone is a Huawei Mate 10 Pro on EMUI 9.1.0.345, which worked with Magisk and SafetyNet passing until earlier this week.

On that phone, for some reason, the ro.vendor.build.security_patch is set to a lower date (2018-06-19) than the ro.build.version.security_patch (2019-12-01) out of the (unrooted) box. So for SafetyNet to pass, the correct value for ro.build.version.security_patch should NOT be changed to the vendor patch date and instead remain unchanged at 2019-12-01. So unfortunately, this code in post-fs-data.sh actually destroys the correct security_patch version and SafetyNet/ctsProfile fails if I use this module. I disabled this script, and indeed this got SafetyNet to pass with ctsProfile on my phone again :)

[hrap1919]

I can confirm the same thing. Moto G7 Power, Android 9, ro.build.version.security_patch=2019-10-01, ro.vendor.build.security_patch=2018-11-05. SafetyNet passes only if the values do not change.

Anyway, thanks a lot for the new keystore binary:)

[kdrag0n]

Please send the values of all of the fingerprint properties on your device. It may be possible to fix this without ditching the security patch adjustments entirely.

[Didgeridoohan]

The ro.build.version.security_patch value needs to match the device fingerprint, or CTS will fail.

Edit: on most devices with build dates after March 2018 (there are always exceptions it seems).

[kdrag0n]

The issue I'm trying to address with the security patch adjustments is older devices with newer custom ROMs. Such ROMs usually ship old fingerprints from stock, an old vendor SPL from stock, and a new system SPL from AOSP. Setting the system SPL to match the vendor SPL makes CTS pass in these cases. As it turns out, however, some devices intentionally ship with mismatching system and vendor SPLs as their registered CTS profile.

My idea was to check whether the system and vendor fingerprints match as an indication of mismatching SPLs. I might just remove the SPL logic entirely because it's not the main focus of my module anyway, but it's a nice touch to make SafetyNet pass with no additional changes on a lot of older devices.

[Didgeridoohan]

In those cases it would work, yes, since then there's a possibility that the vendor date is the correct one for that particular print. But since this edit of the security patch date has a larger risk of causing CTS failure on any newer device I'd say it's likely better to drop it...

[bwegge]

Hi, thanks for the quick response(s). After the discussion here, I also think that the patch does or assumes "too much", at least for rooted stock ROMs where the device fingerprint and system SPL already constitute the "good" values for CTS to pass. For custom ROMs, I guess it should be up up to the developer or user of that custom ROM to provide a matching pair of build fingerprint and SPL value. If the custom ROM is rooted with Magisk, the users could still use the "MagiskHide Props Config" module to override the device fingerprint and SPL with good known values. (In fact, this is what I did first on my phone with the SafetyNet fix installed, after I realized that CTS still wouldn't pass, and before I found out that there is code in the SafetyNet fix that overrides the system SPL.) PS: If still relevant, which fingerprint properties values do you need?

[kdrag0n]

It would still be useful to see the values of your fingerprint properties with getprop | grep fingerprint. I probably won't add any more SPL edits because I agree that it's somewhat out-of-scope for this nodule, but it'd be helpful to see what the situation looks like in the wild.

[bwegge]

OK, here's the result:

$ getprop | grep fingerprint
[ro.bootimage.build.fingerprint]: [Huawei/generic_a15/generic_a15:9/PPR1.180610.011/root201912261901:user/test-keys]
[ro.build.fingerprint]: [HUAWEI/BLA-L29/HWBLA:9/HUAWEIBLA-L29S/9.1.0.345C432:user/release-keys]
[ro.huawei.build.fingerprint]: [HUAWEI/BLA-L29/HWBLA:9/HUAWEIBLA-L29S/9.1.0.345C432:user/release-keys]
[ro.odm.build.fingerprint]: [Huawei/Boston/Boston_BLA-L29:9/PPR1.180610.011/20191226180710:user/release-keys]
[ro.product.fingerprintName]: [HUAWEI-Z106]
[ro.vendor.build.fingerprint]: [kirin970/kirin970/kirin970:9/PPR1.180610.011/root201912261806:user/release-keys]
[sys.fingerprint.deviceId]: [0]

[kdrag0n]

Thanks for the info, the idea would have worked for your device but I'll leave it alone for now.