add spoof props feature to expand usable pool of prints

[osm0sis]

Any untrusted keybox results in the print-related device props being checked, and that's why the discrepancy with prints that pass STRONG with unrevoked hw keybox not passing DEVICE with sw keybox. If Tricky Store added custom print prop spoofing all working prints could be viable for both DEVICE with sw and STRONG with hw.

Tested and confirmed my theory with Tricky Store installed with my PIFork to do only the props.

/data/adb/tricky_store/spoof_build_vars:

MANUFACTURER=Google
MODEL=Pixel
FINGERPRINT=google/sailfish/sailfish:8.1.0/OPM1.171019.011/4448085:user/release-keys
BRAND=google
PRODUCT=sailfish
DEVICE=sailfish
RELEASE=8.1.0
ID=OPM1.171019.011
INCREMENTAL=4448085
TYPE=user
TAGS=release-keys
SECURITY_PATCH=2017-12-05

/data/adb/modules/playintegrityfix/custom.pif.json:

{
    "*.build.id": "OPM1.171019.011", // for ro.build.id
    "*.security_patch": "2017-12-05", // for ro.build.version.security_patch
    "*api_level": "25" // for ro.board.api_level, ro.board.first_api_level, ro.product.first_api_level and ro.vendor.api_level
}

It then passes DEVICE integrity with AOSP sw keybox, and I determined api_level was definitely required to do so. (Other prints with build times later than ~March 2018 also require .security_patch).

However! That print won't pass STRONG with hardware keybox anymore while the props remain spoofed, and adjusting *api_level made no difference.

So basically a new optional spoof_props feature could be added (with wildcarding preferably), and you'd spoof the print props if you want a wider pool of working prints for DEVICE integrity, but if you want STRONG you'd need to disable print prop spoofing. Or it could be somehow added to spoof_build_vars (rename to spoof_vars?) if Tricky Store could somehow automatically determine when to ignore the props entries to pass STRONG with an unrevoked hw keybox. Thanks!

[osm0sis]

Current list of known important props DroidGuard checks (though very few are actually enforced):

build.version.extensions.ad_services
build.version.extensions.r
build.version.extensions.s
build.version.extensions.t
build.version.extensions.u
build.version.extensions.v
init.svc.adbd
persist.graphics.egl
persist.sys.knox.userinfo
persist.sys.oplus.region
persist.sys.pif
persist.sys.pihooks.first_api_level
persist.sys.pihooks.security_patch
persist.sys.pixelprops.games
ro.board.api_level
ro.board.first_api_level
ro.boot.flash.locked
ro.boot.hardware.revision
ro.boot.vbmeta.digest
ro.boot.vbmeta.device_state
ro.boot.verifiedbootstate
ro.build.characteristics
ro.build.id
ro.build.release_type
ro.build.stock_fingerprint
ro.build.type
ro.build.version.oplus.api
ro.build.version.oplus.sub_api
ro.build.version.oplusrom
ro.build.version.oplusrom.confidential
ro.build.version.ota
ro.build.version.sdk
ro.build.version.security_patch
ro.config.tima
ro.config.timaversion
ro.debuggable
ro.gfx.driver.1
ro.hardware.egl
ro.oplus.image.my_stock.type
ro.product.first_api_level
ro.product.vndk.version
ro.secure
ro.separate.soft
ro.superior.device
ro.treble.enabled 
ro.vendor.api_level
ro.vendor.build.version.sdk
ro.vendor.oplus.market.enname
ro.vendor.oplus.market.name
ro.vendor.oplus.regionmark
ro.version.confidential
ro.vndk.version
ro.zygote
sys.usb.state

[osm0sis]

@5ec1cff which direction would be better, add props to spoof_build_vars (and maybe rename to spoof_vars), or have them in their own separate spoof_props file?

[aviraxp]

I honestly think build vars spoof should be a separate module, tricky store's core part is binder hook and certificate chain generation, but most of the issues are sbout play integrity...

[osm0sis]

That's a fair debate!

In addition to needing spoofed props to gms.unstable for additional prints to pass as I demonstrated above, lots of people asking why it doesn't have the global bootloader props included as well. So all-in-one or everything-separate... Tough call.

My lean would probably be to want everything needed to pass Device and Strong in one module so that it can fully replace all the other things (except root hiding). I do think the code here is cleaner and works more as expected than previous implementations.

[badabing2005]

Whichever direction it goes, props spoofing and build vars spoofing should be together.

[osm0sis]

I have managed to get my PIFork spoofing both prints to pass STRONG (hw keybox) and DEVICE (sw keybox) with TS's spoof_build_vars disabled, by exposing more control over the spoofed components (i.e. disabling spoofProps and spoofProvider), similar to what I proposed above for TS, though manually via settings file (so far).

https://github.com/osm0sis/PlayIntegrityFork/commit/a7c2f348eaa0d29a209be9ab4f4623e665a36370

So @aviraxp, you could go ahead and remove spoof_build_vars if you like now, since PIFork already has all the missing print-related features here, and with the new granular settings would widen the pool of working prints for DEVICE integrity with sw keybox as I've demonstrated. It's arguably that or implement all the things for prints in TS too (I'm sure you'd do a better job) so I can Archive PIFork and TS can completely replace all PIF modules. 😘

[osm0sis]

🙌