Xposed presence

[pylerSM]

Need to know whether Xposed has any impact on "success/fail" state. If yes, we can hide it.

[hkpD]

It seems that Xposed does not have an impact on the "success/fail" state because I tried completely resetting my phone and tried adding a card in Android Pay and it still would not let me because I was running CM12.1 without root and Xposed

[pylerSM]

Yep, right I think

[Entropy512]

@haloali That's not really a good test of this, since SNet is pretty much an "if anything fails, it's a total failure" - so flipping Xposed on/off in a configuration that fails anyway tells you nothing.

The key would be to install Xposed on a firmware that normally passes SafetyNet checks and see what happens. I have guests visiting at the moment, I'll try this on my Z3 when I get more free time. (I'm running rooted stock for now, haven't had time since vacation to return to Omni.)

[Oggie7797]

I concur. Checking for xposed on a system that's guaranteed to fail is a poor test.

[sovanyio]

Wondering if the xposed check is as simple as scanning the logcat for the xposed string.. could be as simple as turning off logging for xposed.

[Entropy512]

@sovanyio What xposed check? Do we actually have confirmation that there is one? The original issue is just to determine if it does - I suspect it doesn't. There's no mention of xposed in the SafetyNet teardown at https://koz.io/inside-safetynet/

[sovanyio]

You're right, its not explicitly called out. But it seems like another huge target that Google would check for in addition to su. I'll try installing xposed on my gpe rom later to see if that alone trips it.

[bengalih]

I can confirm that Xposed framework blocks Android Pay from working.
On my HTC M8 (bootloader unlocked/rooted) I could not get android pay to work by disabling root, installing RootCloak and No Device Check.
Only AFTER fully removing Xposed (and keeping root disabled) could it work.
So the presence of Xposed is certainly influencing Andoid Pay.

Can this be made to block it?

[sovanyio]

Second. I smell a coming cat-and-mouse game with this though. If they are just doing a simple logcat check for 'Xposed' and we get around that, they could certainly detect the filesystem modifications and then what?

[Entropy512]

Thing is it may not explicitly be looking for Xposed - it may simply be looking for modifications to the app_process binary - Someone really needs to look into how an attestation is generated, I'll try to do a bit of looking tonight.

[Entropy512]

OK, so I've traced through some of the SNet code at #2 and have hit a brick wall...

It appears that the attestation info is part of the GBundle whose source is at com/google/android/snet/GBundle.java - see snet_attest_bundle - This appears to be somehow derived from GBundle's paramBundle

com/google/android/snet/Snet.java indicates that this GBundle's paramBundle is the paramBundle passed to the Snet class when it is created. It appears that this is passed by enterSnet or enterSnetIdle. However, I'm not seeing what is calling enterSnet - I'm guessing that this is probably somewhere within Google Play Services.

[humulos]

I don't know if my input is helpful, certainly don't understand the mechanics behind any of this but I can definitely confirm that simply having xposed installed does prevent Android Pay from working, so something that it affects is being checked. Here is what I checked, all with the Bootloader locked via BootUnlocker

1. Xposed enabled, all modules on (including Rootcloak and No Device Check), SuperSu enabled: Android Pay Fail
2. Xposed enabled, all modules on, SuperSu disabled: Android Pay Fail
3. Xposed enabled, all modules off, SuperSu disabled: Android Pay Fail
4. Xposed disabled, all modules off, SuperSu disabled: Android Pay Fail
5. Xposed uninstalled, all modules off, SuperSu disabled: Android Pay Pass

Thank you for your work on this, I really miss using NFC payments, but Xposed is far more valuable to me.

[pylerSM]

Try to just uninstall Xposed Installer (do not uninstall Xposed binary) and tell us result.

[rich0]

I suspect the key is going to be in messing with how the attestation is performed. It doesn't sound like they're using signature chaining (Palladium style) and remote attestation, so it is probably defeatable.

I've seen statements online (which may or may not be true) that it is checking for modifications to the system partition. I'd be curious as to whether just sticking a random text file in /system or installing busybox/etc without rooting or installing xposed causes failures. I'd think that doing a full hash of system is going to be too slow, so they're probably looking for specific markers which we could evade.

The other approach is just patching the software doing the attestation to just always pass, or intercept the call to it. Or just patch Android Pay to not do the check.

As long as they're not doing full remote attestation with signature chains we should be fine. If they go that route then you're stuck cracking TPMs.

[Entropy512]

I'm fairly certain some of the Android Pay checks are server-side - see the link I posted 20 days ago in this thread. That explains why patching the response isn't working.

The attestation code does not seem to be in the snet bundle, so it's probably somewhere in GMSCore itself - I haven't had time to look for it.

Extra files may not trigger it, but I would NOT be remotely suprised at all of a critical core component such as the ART engine were being, at the least, checked for size and modification time. (I am assuming "xposed disabled" above involves a modified engine still being present but not "doing its thing" but I could be wrong, I'm a bit rusty on my Xposed.)