NoDeviceCheck
NoDeviceCheck copied to clipboard
pylerSM
Xposed presence
Need to know whether Xposed has any impact on "success/fail" state. If yes, we can hide it.
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
@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.)
I concur. Checking for xposed on a system that's guaranteed to fail is a poor test.
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.
@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/
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.
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?
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?
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.
OK, so I've traced through some of the SNet code at https://github.com/pylerSM/NoDeviceCheck/issues/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.
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
- Xposed enabled, all modules on (including Rootcloak and No Device Check), SuperSu enabled: Android Pay Fail
- Xposed enabled, all modules on, SuperSu disabled: Android Pay Fail
- Xposed enabled, all modules off, SuperSu disabled: Android Pay Fail
- Xposed disabled, all modules off, SuperSu disabled: Android Pay Fail
- 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.
Try to just uninstall Xposed Installer (do not uninstall Xposed binary) and tell us result.
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.
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.)
As requested, I tried just uninstalling the Xposed Installer, Android Pay wouldn't add my card before or after rebooting. SuperSu was disabled and Bootloader was locked for this attempt.
To answer Entropy512 on xposed disable, you can see this thread on XDA for details of the zip I flashed, which as far as I understand it was just adding an extra file to \data\data\de.robv.android.xposed.installer\ that stops xposed from properly executing.
http://forum.xda-developers.com/xposed/xposed-framework-disabler-incase-t3100669
OK, in that case, you still have a modified system file. I'm 90% certain that it's a change to that file that's triggering the failure.
My Xposed-fu is extremely rusty, but an interesting trick might be: Determine the file size and modification/creation time of the files Xposed modifies from a stock firmware. (Challenge here: This will be different for every device and every build). Then use xposed to fake these out if anything checks them. Won't work if something hashes the file contents though.
It won't work across all devices but would give hints as to what does/does not trigger failures.
I suspect that a long-term solution will have to be to hook whatever generates the final attestation data result, and replace this with something that matches the device running stock firmware. A database will be needed for each device/build to enter this result... :(
To preface this, I again have no real knowledge about how this works, so my ideas may have no basis or plausibility, but...
When xposed does its thing, does it create backups of the system files or does it just directly edit them without copying the files first? If it does create backups, could the module find way to have apps look for the backup files instead of the current system files?
No clue if that is even remotely logical, but just thought I'd throw it out there.
No argument that there is a server-side component. It sounds like something local is calculating a hash (what it is based on is unknown, but it obviously picks up su and xposed), and sending it to the server for validation.
However, as long as there isn't a TPM-backed signature chain involved it shouldn't be straightforward to defeat once it is worked out. You could intercept the framework/system calls from the checking program and feed it unmodified data, or you could intercept the calls to the validation routine and just feed back a valid hash to the caller.
If a TPM were involved you'd be hosed, since it would hash the kernel and sign that, and the kernel would in turn either only run controlled binaries or hash whatever it does run and sign that. You could never get a complete chain of trust without running stock everything from the bootloader to the executables.
I haven't heard any discussion of kernel-related issues, so it sounds like the kernel itself is not being checked (which definitely would rule out TPM checks). That is an obvious weakness right there, if indeed you can get android pay to work with a custom kernel.
So i flashed factory image MRA58K on my Nexus6. Then Elite kernel. with unlocked bootloader no root or recovery. I can get android pay to add a card and i tested at work was able to make a purchase. So at least one custom kernel had no effect. And my unlocked bootloader also was not checked?
All I have to add is: keep trying please! We shouldn't be denied Pay just because we're running modified phones.
Hi guys! I just wanted to weigh in on what rich0 was talking about -
I do a custom GPE ROM with Android Pay. We've also discovered the same Android Pay will only work with SuperSU disabled and Xposed uninstalled. What is of note - is that, yes, Pay will work with a custom kernel. My ROM allows beyondstock and elite kernels, and provided xposed is gone and SU disabled, it works fine.
Additionally, I don't think it's based on the system itself being modified, as I've got a number of custom mods to my /system partition, and again, pay works just fine.
I've been meaning to try playing with the code for this myself as I'm now doing Xposed development as well...maybe tonight I can do some more experimentation with it. My guess is that something somewhere is either looking for XposedBridge.jar in framework, or perhaps the symlinked binaries in /system/bin.
I've also decompiled the pay app and had a look with no success, but haven't taken a good crack at GMSCore. Given what I'm reading in here, I have a few new ideas I will try. If I come up with anything, I'll def. post back here.
Update: So, I forked the module, added some logging to see what other checks may be happening. Found some interesting stuff. Log output is here:
http://pastebin.com/iAPi5piR
OH SNAP! There exists an apk in /data/data/com.google.android.gms/app_dg_cache/BIGSTRING/t witha package name of com.google.ccc.abuse.droidguard. Betcha this is the culprit!!
Edit: I've added more hooks to log every string and file android or wallet is checking, plus the start of hooks to look at what DroidGuard is doing.
I have Xposed enabled on my phone (Verizon HTC One M8) and I am able to add cards and make purchases as long as I disable root in SuperSU app.
Were you able to figure out what DroidGuard is doing? Hopefully this is the check that needs to be bypassed.
I'm not able to add cards in pay with only xposed installed. went so far as to stock my device and start from a clean slate. Using SafetyNet Helper (app) i get this response with only xposed installed. (unrooted)
SafetyNet request: Success Response Validation: Fail
Error Msg: Response payload validation failed
So it appears your module is missing something somewhere....
As soon as I uninstall Xposed, Android Pay works (even with systemless root). I'm stock Moto X 2015 PE. It seems that anything installed to /system will prevent Android Pay from working.
So, I have verified that some of the "Xposed Presence" stuff is simply good-old file checks.
https://github.com/pylerSM/NoDeviceCheck/pull/5
Using my modified version, I've now got it logging the checks it's doing for Xposed, and theoretically, bypassing them. I don't have a stock/official system image installed right now to test further, but this should definitely help.
I'd advise merging the pull request, and building on the methods I've added...
If you can get me an APK, I can test this tonight for sure, and would definitely love too. Stock Nexus 6P, February Security Update, Systemless Root with Xposed.