Conversation
Adds a resource-only patch that declares the `app.revanced.android.gms.SPOOFED_PACKAGE_SIGNATURE` meta-data on the Pinterest manifest with the SHA-1 of the certificate the Play Store build is signed with (b6a74dbcb894b0f73d8c485c72eb1247a8f027ca, Signer #1: CN=Carl Rice, O=Pinterest Inc — verified with `apksigner verify --print-certs` on 14.27.0 base.apk). microG-RE (`app.revanced.android.gms`, the MorpheApp fork of ReVanced GmsCore) reads that meta-data via `PackageSpoofUtils.kt` (`play-services-base/core/src/main/kotlin/org/microg/gms/common/`) and, when it signs a Google API request on behalf of another app, tells the Google OAuth server that the caller has *that* signature instead of the patched APK's real one. The Android OAuth client is keyed by `(packageName, signingCertificate SHA-1)`, so with the correct SHA-1 forwarded the token exchange succeeds and "Continue with Google" works normally — the account picker was already appearing, it's only the final token exchange that used to be rejected as `invalid_client`. Default `= true`: on a stock Google Play Services device the meta-data namespace is unknown so the tag is silently ignored (the "Continue with Google" button is already broken on those devices by the signature mismatch, and nothing in the patched APK can fix that path). On a microG-RE device it enables Google login. Zero downside either way. No-op for upstream microG (`microg/GmsCore`), which does not implement per-caller meta-data spoofing and relies on system-level `FAKE_PACKAGE_SIGNATURE` (LineageOS-for-microG / /e/OS / GrapheneOS Sandboxed Google Play / Magisk / KernelSU / APatch FakeGApps module). Also updates the README FAQ ("Continue with Google — does it work?") to document microG-RE support, the SHA-1 that gets forwarded, and the distinction between microG-RE and upstream microG. The patches table between the markers is regenerated as usual by `generatePatchesList` + `.github/scripts/generate_patches_readme.py`.
## [1.7.0-dev.1](v1.6.0...v1.7.0-dev.1) (2026-07-17) ### ✨ New Features * **auth:** SpoofGoogleAuthPatch — restore Google Sign-In on microG-RE ([8d4fc62](8d4fc62))
…module
Extends SpoofGoogleAuthPatch to cover the case where the phone runs a
stock com.google.android.gms as a system app instead of microG-RE
(MIUI/HyperOS and most OEM ROMs ship it that way). In that case the
`androidx.credentials:credentials-play-services-auth` HiddenActivity
resolves the sign-in intent against the stock Play Services build,
which does not understand the microG-RE-specific
`app.revanced.android.gms.SPOOFED_PACKAGE_SIGNATURE` meta-data added
in v1.7.0-dev.1, and the OAuth call is rejected with `invalid_client`
because Google sees the resigned Morphe cert instead of Pinterest's
Play-Store cert. Verified on a Xiaomi with MIUI 14 + Play Services
26.29.32 running as UPDATED_SYSTEM_APP:
ActivityTaskManager: START u0 {act=com.google.android.gms.auth
.api.credentials.GOOGLE_SIGN_IN pkg=com.google.android.gms
cmp=com.google.android.gms/.auth.api.credentials.assistedsignin
.ui.GoogleSignInActivity ...}
The new fix declares the standard signature-spoof metadata used by
rushiiMachine/XSpoofSignatures, an LSPosed module that hooks
`PackageManagerService.generatePackageInfo` in `system_server` and
rewrites the reported signature when the caller has
`FAKE_PACKAGE_SIGNATURE` granted:
<permission android:name="android.permission.FAKE_PACKAGE_SIGNATURE"
android:protectionLevel="normal"/>
<uses-permission android:name="android.permission.FAKE_PACKAGE_SIGNATURE"/>
<meta-data android:name="fake-signature"
android:value="b6a74dbcb894b0f73d8c485c72eb1247a8f027ca"/>
The <permission> declaration is what makes this work on stock ROMs
that don't already define FAKE_PACKAGE_SIGNATURE: the patched app
becomes the definer *and* consumer, and because the protection level
is `normal` the permission is auto-granted at install time. LSPosed's
XSpoofSignatures then intercepts every subsequent call to
`getPackageInfo("com.pinterest", GET_SIGNATURES)` — including the one
stock Play Services makes when it validates the OAuth caller — and
returns Pinterest's real Play-Store SHA-1.
The microG-RE meta-data added in dev.1 is kept so the microG-RE-only
path still works. Both paths coexist because the metadata namespaces
are disjoint; whichever GmsCore implementation actually services the
intent picks up its own key and ignores the other.
Trade-off: XSpoofSignatures runs in sole-signer mode (required for
stock Play Services to accept the spoofed cert), so any third-party
integrity check on the device will see Pinterest's Play-Store cert
instead of the Morphe signing cert. The Morphe Manager update path
still works — the Manager verifies the .mpp signature and the target
APK's package name, not the app's signing cert.
Renames the patch label from "Restore Google login (microG-RE)" to
"Restore Google login (signature spoofing)" to reflect that it now
covers both paths.
Also updates the FAQ ("Continue with Google — does it work?") to
document the two paths and the XSpoofSignatures setup steps
(install .apk, enable in LSPosed, add `android` to scope, reboot).
Idempotency: `upsertAppMetaData` and `upsertManifestChildTag` helpers
replace existing tags in place instead of duplicating on re-patch.
Verified end-to-end on Pinterest 14.27.0 base.apk: aapt2 dump xmltree
shows the four expected additions in AndroidManifest.xml, no other
tags are changed. Applied cleanly by Morphe CLI 1.11.0-dev.1.
## [1.7.0-dev.2](v1.7.0-dev.1...v1.7.0-dev.2) (2026-08-08) ### ✨ New Features * **auth:** support stock Play Services via XSpoofSignatures LSPosed module ([652d65e](652d65e))
…owns it v1.7.0-dev.2 declared `<permission android:name="android.permission.FAKE_PACKAGE_SIGNATURE" android:protectionLevel="normal"/>` on the patched manifest so the permission would exist even on ROMs that don't ship it. The assumption was wrong: XSpoofSignatures's own APK (`dev.rushii.xspoofsignatures`) already declares the permission, so PackageInstaller rejects the patched Pinterest with INSTALL_FAILED_DUPLICATE_PERMISSION: Package com.pinterest attempting to redeclare permission android.permission.FAKE_PACKAGE_SIGNATURE already owned by dev.rushii.xspoofsignatures Fix: drop the `<permission>` upsert entirely. XSpoofSignatures is the definer, patched Pinterest is only a consumer via `<uses-permission>`. Because XSpoofSignatures declares the permission with `protectionLevel="dangerous"`, Android will not auto-grant it. The patched app has no code path that pops the runtime request dialog, so the user has to grant it manually once from a PC: adb shell pm grant com.pinterest android.permission.FAKE_PACKAGE_SIGNATURE Documented the ADB grant step in the FAQ. The `upsertManifestChildTag` helper is kept because it's still used to add `<uses-permission>` under `<manifest>` (which is a direct child, not under `<application>`). Verified end-to-end on Pinterest 14.27.0 base.apk: aapt2 dump xmltree now shows exactly three additions in AndroidManifest.xml — the two existing `<meta-data>` tags (microG-RE + fake-signature) and the `<uses-permission>` — with no `<permission>` element.
## [1.7.0-dev.3](v1.7.0-dev.2...v1.7.0-dev.3) (2026-08-08) ### 🐛 Bug Fixes * **auth:** don't redeclare FAKE_PACKAGE_SIGNATURE — XSpoofSignatures owns it ([ffea710](ffea710))
v1.7.0-dev.2/dev.3 wrote Pinterest's SHA-1 digest
(b6a74dbcb894b0f73d8c485c72eb1247a8f027ca, 40 hex chars) into the
`fake-signature` meta-data. XSpoofSignatures feeds that value straight
into `new Signature(fakeSig)`:
String fakeSig = pi.applicationInfo.metaData.getString("fake-signature");
...
Signature sig = new Signature(fakeSig);
`Signature(String)` parses a whole DER-encoded X.509 certificate in hex —
the same shape `Signature.toCharsString()` emits and what Lanchon's
sigspoof-checker compares against. Passing a digest there produced a
20-byte garbage "certificate", so Play Services computed a SHA-1 of that
garbage and the OAuth call kept failing. The failure is silent: the hook
runs, the spoof is applied, the value is just wrong.
Extracted the real certificate from the v2 APK Signing Block of the
official 14.27.0 base.apk (595 bytes DER → 1190 hex chars) and verified
it reproduces both known fingerprints before wiring it in:
SHA-1 b6a74dbcb894b0f73d8c485c72eb1247a8f027ca (matches apksigner)
SHA-256 341d6881b1ecf38361fbf8c8fbae0aa516b45375c39ef5e78b161869acc1bcfa
(matches the allowlist already enforced in COMPATIBILITY_PINTEREST)
Hardcoding is safe precisely because of that allowlist: the patcher
refuses to run against an APK signed with any other certificate, so the
embedded value cannot drift from the target.
Path A is unchanged — microG-RE's `PackageSpoofUtils` substitutes the
result of `sha1sum(sig.toByteArray())`, so its meta-data still carries
the 40-char digest. The two consumers want different formats and the
patch now documents that explicitly.
Verified on Pinterest 14.27.0: the `fake-signature` value in the patched
AndroidManifest.xml is 1190 chars and byte-for-byte identical to the
certificate extracted from the official APK; the microG-RE meta-data is
still the 40-char digest; `<uses-permission>` is present.
## [1.7.0-dev.4](v1.7.0-dev.3...v1.7.0-dev.4) (2026-08-08) ### 🐛 Bug Fixes * **auth:** fake-signature needs the whole certificate, not its SHA-1 ([3f240f3](3f240f3))
Testing on the target device (Xiaomi, MIUI 14 / Android 13 SDK 33,
APatch + LSPosed "Vector 2.0" with XSpoofSignatures 1.0.1 enabled and
scoped to System Framework, FAKE_PACKAGE_SIGNATURE granted, patched
Pinterest 14.27.0 carrying the correct certificate) still ends with the
sign-in silently returning to the login screen.
Logcat over the window covering the attempt shows the flow reaching
GoogleSignInActivity and tearing back down, while XSpoofSignatures never
logs `Spoofing signature for com.pinterest` — so its
`generatePackageInfo` hook never fired for whatever query stock Play
Services makes to check the caller. Debug-level logs from system_server
are present in the same buffer, so this is not log filtering.
Two candidate causes were not distinguished:
a) the hook does not install on MIUI's modified PackageManager
(XSpoofSignatures targets com.android.server.pm.ComputerEngine on
Android 13+), or
b) Play Services obtains the certificate through a path that does not
go through generatePackageInfo.
Telling them apart needs sigspoof-checker on the device, which is out of
scope for now.
Path A (microG-RE servicing the intent, no stock Play Services present)
was never exercised — on this device stock com.google.android.gms is an
UPDATED_SYSTEM_APP and always wins intent resolution.
So: flip `default` to false and rewrite the docs to say plainly that the
patch is experimental and unconfirmed, instead of describing a working
setup. The values it writes are still correct and verified — the
certificate reproduces both the SHA-1 from apksigner and the SHA-256
already enforced by COMPATIBILITY_PINTEREST — so the patch is kept for
anyone who has an independently verified signature-spoofing setup, with
a pointer to sigspoof-checker for confirming that first.
The FAQ now leads with "use email/password" and drops the step-by-step
that implied a working outcome.
## [1.7.0-dev.5](v1.7.0-dev.4...v1.7.0-dev.5) (2026-08-08) ### 🐛 Bug Fixes * **auth:** disable Google login patch by default — unproven end-to-end ([cf31d99](cf31d99))
Every one of the 13 default patches (SpoofGoogleAuthPatch remains default=false) applies cleanly on the three new APKM bundles as verified with morphe-cli patch --force: 14.28.0 (14288010, minSdk 29) -> 13/13, PATCHING+REBUILDING ok 14.29.0 (14298020, minSdk 29) -> 13/13, PATCHING+REBUILDING ok 14.30.0 (14308020, minSdk 29) -> 13/13, PATCHING+REBUILDING ok Manifest of each patched APK was audited with aapt2 dump xmltree to confirm the resource patches produced the expected shape (Google Ads APPLICATION_ID, Bugsnag API_KEY, AD_ID permission, Google Engage receiver and AD_SERVICES_CONFIG are removed; the Firebase off-switches are inserted). Also correct the 14.27.0 minSdk from 32 back to 29: the base.apk in the 14.27.0 bundle declares minSdkVersion:29 (confirmed with aapt2 dump badging), the previous value was a documentation error. Certificate stays pinned to the existing SHA-256; Signer #1 of every new base.apk matches (b6a74dbcb894b0f73d8c485c72eb1247a8f027ca).
## [1.7.0-dev.6](v1.7.0-dev.5...v1.7.0-dev.6) (2026-08-09) ### ✨ New Features * **compat:** extend Pinterest support to 14.28.0 - 14.30.0 ([bb7a5f0](bb7a5f0)), closes [#1](#1)
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
2 participants
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.
Promotes the current
devline to stable.Patches
feat(compat): extend Pinterest support to 14.28.0, 14.29.0 and 14.30.0.
All 13 default patches apply cleanly on each of the three new APKM bundles
(verified with
morphe-cli patch,PATCHING+REBUILDINGboth ok), and thepatched manifests were audited with
aapt2 dump xmltreeto confirm theresource patches produced the expected shape.
Also corrects the
14.27.0minSdkfrom 32 back to 29 — thebase.apkin the 14.27.0 bundle declares
minSdkVersion:29, the previous value was adocumentation error that needlessly excluded Android 10/11 devices.
Supported range is now 14.20.0 through 14.30.0 (11 releases).
feat/fix(auth): adds
SpoofGoogleAuthPatch, an experimental,off-by-default patch that writes the Pinterest Play-Store certificate into
the two manifest keys read by microG-RE and by the XSpoofSignatures LSPosed
module.
The certificate values are verified correct (they reproduce both the SHA-1 and
the SHA-256 that
COMPATIBILITY_PINTERESTalready enforces), but the patch isnot confirmed to actually restore "Continue with Google" — on the one
device it was tried the spoofing hook never fired. It ships
default = falseand is documented as unproven in the README, so it is a no-op for everyone who
does not deliberately enable it.
Certificate
Signer #1 of every new
base.apkstill matches the pinned SHA-256341d6881b1ecf38361fbf8c8fbae0aa516b45375c39ef5e78b161869acc1bcfa.