(Optional) blacklist mode

[paquitopacoto]

Hey, @qwq233. Thanks for the great FOSS version. Works really well! 🙂‍↕️

I was wondering if you'd think about adding some kind of special use_blacklist_mode empty file that would make target.txt work in a reversed way, so that it works on everything by default but we can exclude any apps we need manually. It feels like it would save everyone a few headaches.

Another interesting thing would be to support wildcards.

I don't see any reason to use a static whitelist, feels like they are making the same mistake as with the original root solutions that exposed su by default instead of just giving it to the few apps that need it. Until the recent managers switched it around and made it sane.

There are more and more apps out there, like Revolut, that are starting to check attestation results manually. And soon the list is going to get unwieldy.

com.google.android.gsf
com.google.android.gms
com.android.vending
io.github.vvb2060.keyattestation
io.github.vvb2060.mahoshojo
icu.nullptr.nativetest
com.reveny.vbmetafix.service
com.reveny.nativecheck
com.zhenxi.hunter
io.github.huskydg.memorydetector
me.garfieldhan.holme
com.revolut.revolut
com.revolut.junior

Either way thanks a ton for sharing your version. While I understand the original team issues about contributions and the like I didn't like having closed source modules at this privilege level, and this is a life saver.

[0ctobot]

It may be the case that some third party apps are implementing key attestation checks but the amount of them is still pretty miniscule in the grander scheme of things. Most of your unwieldy list are detector apps some which don't actually perform bootloader checks.

You can check TS via logcat to see which apps on your target list are actually making attestation requests, I suspect it will be less than you think.

Anyway, I don't truly know enough to speculate but I suspect there is a reason why the whitelist format was used in the first place. Perhaps to avoid creating unnecessary overhead, I'm not sure if that would be the case.

Another concern would be, as I discovered with this fork the other day - adding android to target.txt resulted in me being unable to unlock my devices. Treating everything as though it needs to be run through TS by default could create some weird edge case problems like this as well.

Perhaps if anything, blacklist mode could be made opt-in, but I'm not certain that it makes sense as default behavior, it gives a bit of driving nails with a wrecking ball vibes.