Reproducible Build Verification for v5.37.4

[xrviv]

We attempted to independently reproduce the official Play Store build of Tangem Wallet v5.37.4 as part of WalletScrutiny's ongoing reproducibility monitoring.

Result: not reproducible.

This is a follow-up to our v5.36.1 finding. The same root cause applies.

What we did

• Checked out ref v5.37.4 (commit faa8bdeaa975522b118251d4fbf9329ac41c08d1)
• Built using ./gradlew bundleGoogleRelease inside a containerized environment (Ubuntu 22.04, OpenJDK 17, Android SDK 35, NDK 25.1.8937393)
• Extracted splits via bundletool with device-spec.json targeting arm64-v8a, API 33, xxhdpi
• Compared unpacked contents against the official Play Store split APKs

Differences found

split_config.arm64_v8a — 8 non-signing differences:

File	Status
lib/arm64-v8a/libdexprotector.so	Present in official only — absent from source build
lib/arm64-v8a/libalice.so	Present in official only — absent from source build
lib/arm64-v8a/libargon2.so	Present in both, but contents differ
AndroidManifest.xml	Binary diff

base.apk — 432 non-signing differences (including AndroidManifest.xml; up from 151 in v5.36.1)

split_config.en and split_config.xxhdpi — 4 non-signing differences each (AndroidManifest.xml, resources.arsc, stamp-cert-sha256)

Key observations

DexProtector post-build transformation: libdexprotector.so is a filename associated with DexProtector (commercial bytecode protection by Licel). dexprotector-annotations.jar is present in app/libs/ in the repository. A source build produces none of these additional libraries, consistent with a post-build APK transformation step using tooling not present in the public repository.

version-control-info.textproto revision mismatch: The official base.apk contains META-INF/version-control-info.textproto with revision 3f2d7e5e16740402063a4146622be5af724381c9, which does not match the public tag commit faa8bdeaa975522b118251d4fbf9329ac41c08d1 and was not found in the public repository. This suggests the official APK was built from a commit that has not been published.

Built arm64 split unchanged: Our built split_config.arm64_v8a.apk hash is identical to our build of v5.36.1, confirming the native code in that split did not change. The official arm64 split hash did change between versions, consistent with DexProtector re-processing the APK independently for each release.

Ongoing blocker: google-services.json

The public source does not include a production com.tangem.wallet Firebase client entry in app/google-services.json. A googleRelease build requires stub injection to proceed; a fully self-contained public build remains unavailable from the published source without modification.

Request

To enable independent reproducible build verification, we would appreciate:

1. Documentation of the full release build process, including any post-build transformation steps (e.g. DexProtector) applied before distribution
2. Publication of the build commit used for each release, or alignment of the public tag with the actual build commit (the version-control-info.textproto revision mismatch blocks this)
3. A production-complete google-services.json, or documentation of an alternative for community builds

We are happy to re-verify if the build process changes. Our full verification report is available on WalletScrutiny.

[xrviv]

Follow-up: v5.39.1 — still not reproducible (same root cause)

We re-ran the verification against v5.39.1 (versionCode 1769, commit be403681c5d24ffceddca013a048ab0a1b205844). Result: not_reproducible — the same DexProtector root cause reported for v5.36.1 and v5.37.4. This is now the third consecutive release with the same finding, and we haven't yet heard back on the questions below.

Since v5.37.4 we improved the methodology in two ways that make this report harder to attribute to test-harness noise:

1. Version metadata is now injected (-PversionCode=1769 -PversionName=5.39.1), and we confirmed the built base.apk carries versionCode='1769' versionName='5.39.1' — identical to the official. So none of the differences below is a version-code artifact.
2. We decode every differing AndroidManifest.xml and resources.arsc (via aapt2/apktool) instead of treating them as opaque binary diffs.

DexProtector is now visible at three independent layers

Layer	Official (Play Store)	Built from public source
Native runtime	lib/arm64-v8a/libdexprotector.so and libalice.so present	both absent
Application class	com.tangem.tap.ProtectedTangemHiltApplication	com.tangem.tap.TangemHiltApplication
Resource table	hundreds of agc_<SHA-256>-named string resources present	absent

The Protected…Application wrapper and the agc_<hash> resource entries are consistent with DexProtector's protection being applied to the official binary after the public build — tooling that isn't in the published repository. (dexprotector-annotations.jar is in app/libs/, but the protector itself and its post-build step are not.)

Per-artifact result (4-APK split set)

Artifact	Verdict
base.apk	not reproducible — protected Application wrapper, agc_<hash> resources, differing config assets
split_config.arm64_v8a.apk	not reproducible — libdexprotector.so + libalice.so (official only)
split_config.en.apk	not reproducible — resources.arsc resource-table differences
split_config.xxhdpi.apk	reproducible (decoded res/ identical; only Play-injected manifest metadata differs)

Tested set: not reproducible — 1 of 4 artifacts reproduced. The remaining config-split manifest differences (splitTypes, com.android.vending.derived.apk.id, the Play source stamp) are benign Google Play distribution artifacts.

Still blocked: google-services.json

As in v5.37.4, the public source has no production com.tangem.wallet Firebase client entry in app/google-services.json, so a googleRelease build still requires stub injection. A fully self-contained public build remains unavailable from the published source without modification.

What would let us verify a clean reproduction

Unchanged from the v5.37.4 issue:

1. Documentation of the full release build process, including the post-build DexProtector step applied before distribution.
2. Publication of the exact build commit per release (or alignment of the public tag with the actual build commit).
3. A production-complete google-services.json, or documented guidance for community builds.

Even a confirmation that DexProtector is applied post-build, plus the release commit, would let us classify these releases precisely rather than inferring. We're glad to re-verify as soon as the build process or documentation changes. Our full v5.39.1 report (with archived diffs and decoded evidence) is available on WalletScrutiny.