Rather than spoofing a single date to everything in target.txt, would it be possible to define distinct spoof dates for specific targets on the list?
The reason this would be useful is related to a new restriction requiring that the os_patch_level (i.e. system="YYYYMM" date in TS security_patch.txt) must now match with the *.security_patch props.
These props must be spoofed by PIF for the few remaining fingerprints that are still capable of achieving a legacy <A13 PI verdict of STRONG (with a valid keybox). Otherwise, that verdict drops to BASIC which is less than required by Google Wallet's special requirements. Unfortunately, as the props must equal the original fingerprint value and all these private print dates are over a year old, achieving a legacy <A13 PI verdict of STRONG currently prevents the newer A13+ PI verdict from achieving STRONG (and vice versa).
In summary, while Droidguard (gms) obtains the legacy <A13 PI verdict, it is Play Store (vending) that obtains the newer A13+ PI verdict. Therefore, it would be ideal if separate dates could be spoofed as part of the keybox injection into KM, depending on which target raised the attestation request.
Is it remotely feasible to achieve this goal in principle? I do realise you have a lot going on here and if possible I doubt it's simple!
Thanks for reading.
Rather than spoofing a single date to everything in target.txt, would it be possible to define distinct spoof dates for specific targets on the list?
The reason this would be useful is related to a new restriction requiring that the os_patch_level (i.e. system="YYYYMM" date in TS security_patch.txt) must now match with the *.security_patch props.
These props must be spoofed by PIF for the few remaining fingerprints that are still capable of achieving a legacy <A13 PI verdict of STRONG (with a valid keybox). Otherwise, that verdict drops to BASIC which is less than required by Google Wallet's special requirements. Unfortunately, as the props must equal the original fingerprint value and all these private print dates are over a year old, achieving a legacy <A13 PI verdict of STRONG currently prevents the newer A13+ PI verdict from achieving STRONG (and vice versa).
In summary, while Droidguard (gms) obtains the legacy <A13 PI verdict, it is Play Store (vending) that obtains the newer A13+ PI verdict. Therefore, it would be ideal if separate dates could be spoofed as part of the keybox injection into KM, depending on which target raised the attestation request.
Is it remotely feasible to achieve this goal in principle? I do realise you have a lot going on here and if possible I doubt it's simple!
Thanks for reading.