fixed signingInfo spoofing on Android 9 to 12 #25
Conversation
0c80ebe to
4e7b1ea
Compare
|
The 2nd Environment:
|
|
Thanks for testing @MikronT . |
|
Tested Android 10 in an emulator, works OK. Can't test Android 9 because Magisk doesn't support pre-system-as-root installations in AVD, but I haven't spotted any relevant code change in the classes we reflect, so it should work just as well. RFR. |
|
After further testing some Google apps appeared to be misbehaving even after applying the patch. All apps are up to date. Confirmed fully operational (checked) vs misbehaving (unchecked):
Both Google Calculator and Google Contacts throw similar errors into logcat about not being able to find Google Play Store (which is installed, up to date, and operational) and complain about missing APIs. Google Calculator (crashes on startup): Google Contacts (unable to find account, sign in prompt only) throws lots of similar errors about not being able to find UsageReporting.API, Phenotype.API, ClearcutLogger.API, and People.API: Google Wallet produces lots of stacktraces similar to this one: Don't know if these logs are any kind of helpful though |
|
I'm unable to reproduce the Calculator and Contacts issues. Is your self-check OK? Are you using a recent version and fresh install of MicroG? Regarding Google Wallet, I don't think it was ever supported but I might be wrong. In any case, these tracebacks don't seem related to FakeGApps directly, and certainly not to this patch or #23. |
|
I'm using the latest versions and I'm on a fresh install of the ROM and microG. Self-check is OK, all permissions are granted, no potentially conflicting Magisk modules installed (yet). These problems do seem unrelated to FakeGapps, so maybe there's something else going on. Other Google apps and third-party apps that depend on Google services run fine, no crashes, no lags. So thank you for the quick fix! |
|
I try app-debug in fresh install: App updated that begin to function with it: App updated that don't function and give some login error or don't start: App that don't start show for a moment always same error of old version of PlayServices or GoogleTV and Messages say App Interupted at begin. |
|
Tested this on my Android 11 device with the latest version of Gmail and YouTube and I can confirm it works 👍 Looking at the code, I wonder why a |
|
@Fs00 Thanks for testing :) .
I did this just to account for the unlikely possibility that some obscure vendor has not ported the class onto a newer Android version, or has backported it into an older Android version. AOSP isn't the ultimate source of truth unfortunately, so I think it's reasonable to make as little assumptions as possible on private APIs implementation in XPosed modules. Now, to avoid the nested try/catch, one similarly robust way would be to check if the class exists before invoking the constructor, but I fully adhere to the EAFP principle. It can still be flattened by creating a Even though I'm fairly happy with my implementation, I’m not opposed to a simpler SDK-level check either if that’s the consensus. It feels like a minor detail, so if everyone feels strongly I’m happy to adjust accordingly. |
The SigningDetails class used to be embedded in the PackageParser class. This was leading to a `ClassNotFoundException` on those older versions. See https://cs.android.com/android/platform/superproject/+/android12L-release:frameworks/base/core/java/android/content/pm/PackageParser.java;l=5897;drc=ed537a2acf627c6820a218c177dfdaa12f50c068
4e7b1ea to
cc74a3e
Compare
I'd say that this is what I disagree with (didn't know that acronym 😅) as it doesn't seem a good fit for this context to me, but I'll let @whew-inc judge since he's the maintainer here.
Makes sense. Out of curiosity, have you ever heard/seen situations in which this happened? I imagine that a vendor messing with system services such as the PackageManager could have some trouble passing the CTS. |
No, that was just me being pedantic tbh, this is why I said that I wouldn't mind using a SDK level check instead. Even though I believe the try/catch solution to be more """robust""" by design, the gain in robustness is also probably way too marginal to be observable in the real world. Maybe one more striking argument would be that the try/catch approach prevents "developer mistakes": I can see myself including or excluding Android 12L by mistake. Maybe there are some other edge-cases I did not see, like beta versions or other transient versions. I'm more confident acknowledging that I'm dumb and safeguarding against it than trying to pretend I'm smart (and be disproved later on 🤪). |
I personally agree with you. An SDK check here will probably be fine, as the existing sdk version checks hasn't had any issues with a specific vendor (AFAIK). But I also agree with @gilbsgilbs that the try-catch approach seems more robust, in case that a vendor messes around with this Android code. Since the proposed approach in this merge request is short and readable, I have no problem with it. |
|
Thank you everyone involved! Especially @gilbsgilbs for fixing spoofing yet again ❤️ Edit: A new release should be available tomorrow. |
The SigningDetails class used to be embedded in the PackageParser class. This was leading to a
ClassNotFoundExceptionon those older versions.See https://cs.android.com/android/platform/superproject/+/android12L-release:frameworks/base/core/java/android/content/pm/PackageParser.java;l=5897;drc=ed537a2acf627c6820a218c177dfdaa12f50c068
I did not test this PR because I don't own an older Android device.tested on emulated Android 10. Reported by @Fs00 (#23 (comment)). @Fs00, can you check that it works better for you also?app-debug.zipapp-debug.zip (rename to.apk, GitHub doesn't allow uploading.apkfiles directly).