Repository navigation
fix: Restore incognito, device attestation and module resource handling - #289
Merged
Merged
Conversation
Android refuses to load a dex file that the app can still write to, and the DroidGuard VM arrives as an ordinary writable download. Every flow therefore died in DexClassLoader with `SecurityException: Writable dex file ... is not allowed`, so microG could never produce a real attestation result: YouTube's devicekey request went out carrying the internal "ERROR : kotlin.NotImplementedError" fallback text and was rejected with HTTP 400. Drop the write permission right after the download and again before each load, which also repairs VMs that were cached writable by older builds. Refs microg#283.
…ntext Module code runs under GmsCore's class loader and package identity, but a Dynamite context is a ContextWrapper around the calling app, so resources and assets were answered by that app's tables and module code resolved GmsCore resource ids against the wrong resources. Also probe for our own card capture activity with the installed package instead of a literal com.google.android.gms, which no longer names this build and silently finds real Play services or nothing at all. Ports the remaining self-targeting gaps from ReVanced#308.
microg#273 set the provider's default protocol to TLSv1.2 for device compatibility, but microg#274 touched the same file for the armeabi-v7a split and reverted it to TLSv1.3. The default protocol picks the class behind the SSLContext.Default service this provider advertises, so apps that need it (YouTube's SSL guard) fail with "Unable to find a default SSL provider" on devices whose conscrypt has no TLS 1.3 support. Restores microg#273, which matches the ReVanced build that works on those devices.
hasCapabilities now answers from Google's account_state endpoint, which only a Google-registered package name and certificate can call. A renamed build fails that lookup (UNREGISTERED_ON_API_CONSOLE) and so returned "not in cache" for every capability a client asked about, which clients read as an unusable account: YouTube's incognito mode failed with "No account is found for youtube-incognito" even though the account was signed in and working. When the account state is unknown, answer allowed and log the account and the unresolved capabilities, instead of reporting the account as unusable. Known denials are still denied.
2 tasks done
|
it also Fixes: MorpheApp/morphe-patches#2971 |
Author
Yes |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
1.
fix(auth): a capability check that cannot be answered no longer blocks the accounthasCapabilitiesnow answers from Google'saccount_stateendpoint, which only aGoogle-registered package name and certificate can call. A renamed build always
fails that lookup (
UNREGISTERED_ON_API_CONSOLE), so every capability came back as"not in cache", which clients read as an unusable account YouTube's incognito mode
failed with
No account is found for youtube-incognitodespite a working signed-inaccount.
When the account state is unknown we now answer allowed and log the account and
unresolved capabilities; known denials are still denied.
2.
fix(conscrypt): default the SSL provider to TLSv1.2 again#273set the provider's default protocol to TLSv1.2 for device compatibility, but#274(the armeabi-v7a split) touched the same file and reverted it to TLSv1.3. Thatdefault picks the class behind the advertised
SSLContext.Default, so apps needingit (YouTube's SSL guard) fail with "Unable to find a default SSL provider" on
devices whose conscrypt has no TLS 1.3.
3.
fix(chimera): serve GmsCore resources and assets from the Dynamite contextModule code runs under GmsCore's class loader and package identity, but a Dynamite
context is a
ContextWrapperaround the calling app, so resources/assets wereanswered by the wrong tables and GmsCore resource ids resolved against the wrong
resources. Also probes for our own card-capture activity with the installed package
instead of the literal
com.google.android.gms.4.
fix(droidguard): make the VM apk read-only before loadingAndroid refuses to load a dex the app can still write to, and the VM arrives as an
ordinary writable download every flow died in
DexClassLoaderwithSecurityException: Writable dex file … is not allowed, so no real attestation wasever produced (YouTube's
auth/devicekeycarried the internalNotImplementedErrorfallback and was rejected 400). Drops the write permissionright after download and again before each load, repairing VMs cached writable by
older builds.
Verification
AccountStateClient: requestAuth failed: Error=UNREGISTERED_ON_API_CONSOLE→HasCapabilitiesHandler: handle: no account state for Account {…}, allowing […],with zero
youtube-incognitoerrors.Writable dex filegone; a real DroidGuard token is produced.Fixes: #283