Xposed presence #3
Comments
|
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 |
|
Yep, right I think |
|
@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. 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 #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
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: 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. |
|
Good work :) |
|
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 Error Msg: 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. 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. |
|
@Entropy512 great input! Just for reference here other methods do detect xposed: http://d3adend.org/blog/?p=589 |
|
Yeah - I'm fairly certain that's not being used yet. I'm 90% certain that what is happening when systemless xposed is active is that SystemPartitionFileFinder sees a modified app_process binary. What I can't figure out is why some people were saying that Nexus devices running AOSP-derivative firmware were having success with Android Pay in the past few months... The chances of someone's build system generating an IDENTICAL app_process binary are slim to none... |
|
This may be a dumb brute force solution, but instead of hooking snet, couldn't we create an For example, something like: #define SYSTEM_IMAGE_PATH "/storage/XXXX-XXXX/system.img.ext4"
#define SYSTEM_MOUNT_POINT "/data/local/tmp/system"
mkdir(SYSTEM_MOUNT_POINT, 0755);
mount(SYSTEM_IMAGE_PATH, SYSTEM_MOUNT_POINT, "ext4", MS_RDONLY, "");
chroot(SYSTEM_MOUNT_POINT);
...
execv("/system/bin/app_process", argv);EDIT: Well, chroot wouldn't work. Creating a new mount namespace and mounting the image directly to /system would be better. |
|
@Entropy512 Could we verify your idea somehow? We need get latest snet sources and check how they actually do see Xposed installed. (I could try to do it, but I don't know yet how to get sources) I have Nexus 5X and Nexus 6P for testing and I am ready to test. Just for reference: Substrate - hooking C on Android - https://koz.io/android-substrate-c-hooking/ |
|
Still cannot see any snet sources on Android.
Could it be that architecture of whole snet has changed? But I see that Android loads APK from here: https://www.gstatic.com/droidguard/C4C74D1D1373D60A118D28109D7FFAECA7A892F4 There is *.so file inside the APK. |
|
FYI: #3 (comment) This doesn't exists anymore. I also checked |
|
Here's the .smali of the decompiled apk listed from the gstatic link: |
|
@d8ahazard It is just a wrapper for native code calls. All native code is in |
|
Can you guys check this? Maybe you would have more ideas, since NDK hacking is new for me :D I just got idea but I havent been successful yet. |
|
I apologize if I am over simplifying things... Would it be possible to intercept the JSON response, modify ctsProfileMatch to true, then pass the response on to the requesting app? Targeting the response rather than the request? See "Read the compatibility check response": |
|
That's what NoDeviceCheck currently does. Doesn't work with any app that verifies the attestation server-side... Which seems to be all of them that use SafetyNet at this point. (Snapchat, Android Pay) |
|
So, guys... Here is what I tried so far... I took systemless xposed and replaces Then I added some zero bytes to the end of original So, it seems that SNET doesn't check where
For me it seems it checks something else in Any ideas what else could be checked in |
|
just anything what can point on Xposed. even app_usage has info about Xposed. https://github.com/rovo89/Xposed/blob/master/app_main2.cpp#L38 If you have AOSP sources, you can modify app_process randomly to see what could change SNET from success to fail. |
|
Based on the discussion I had misinterpreted the way No Device Check functions. I take it no one has been able to intercept the server response to modify isValidSignature to true? I may be over simplifying again.. |
|
What If we could use this https://github.com/evilsocket/arminject to hook open method in google play services and if it requests app_process point it to app_process.orig? It would work on native level, so application calls and native calls would be changed. |
|
Does anybody have simple app which uses SafeNety checks the way Android Pay use? |
|
@pylerSM Netmarble games detect xposed in android. Here for details SudoCode755/SudoHide#1 |
|
I think fundamentally there is no way to have a "simple" app for something that matches how we believe Android Pay and Snapchat - since you need SOMETHING doing a server-side attestation check, which means an app that uses some sort of service you control. |
|
I have scottyab's app on my phone running CM13 + Xpossed with Root Cloak and No Device Check. It is doing a device side validation check and fails. Based on the conversation he is looking to add server side validation and needs help. |
|
There's also this app that has a server check:
|
|
Hello! I worked on skipping phone verification when creating Google account. It's probably the same problem as with Android Pay. B Android sends check-in request regularly using com.google.android.gsf.checkin.CheckinTask class. Maybe it's possible to spoof this request with data from device without xposed. There is sample check-in request: http://pastebin.com/SLdggG1r |
|
/sub |
|
@FastKatt317 There's a "Subscribe" button in the GitHub sidebar for doing that, no need to comment. |
|
Sorry, @dgw , didn't see it. Viewing on a Nexus7 |
|
It's at the bottom of the page on mobile, @FastKatt317, below the comment field.
|
|
Use Magisk with Systemless Xposed. |
|
Couldn't this just be focused on hiding the very xposed presence first of all? Also, these are just my 2c, but this should be more focused on ≤4.4 android versions - since everything after already has perfectly working other forms of safetynet bypass. |
|
As far as I know, there is no way to pass SafetyNet with Xposed on any version. Or do you just mean in general bypassing SafetyNet, no Xposed? |
|
I mean that this module should just focus on having Xposed to work with safetynet on <kitkat. First, because for all practical purposes, there are already tools (well, one, magisk) that take care of that for the remainder droid versions, and it'd just make for effort duplication. Second, and more importantly, because regardless I don't think there's any way to bypass dm-verity, selinux and whatever without kernel support. |
|
Xposed does not work with SafetyNet on any version, as I said. Magisk works, but only without xposed installed, or with the module disabled (I guess that is simpler than uninstalling and reinstalling without Magisk). |
and others
Need to know whether Xposed has any impact on "success/fail" state. If yes, we can hide it.
The text was updated successfully, but these errors were encountered: