com.insecureshop

`com.insecureshop.util.CustomWebViewClient.onReceivedSslError` calls `SslErrorHandler.proceed()` — the WebView accepts the navigation despite a TLS error (invalid cert, expired cert, hostname mismatch, …). This is permanent MITM: any attacker can present any cert and the WebView will load the page, including JavaScript that reads cookies, shared-prefs (via `JavascriptInterface`), or saved-form values.

`android:debuggable="true"` is set on `<application>`. Debug builds expose JDWP, allow attaching a debugger to any process, and bypass platform tamper-detection paths — a release APK in this state is trivially modifiable on any unrooted device.

`void com.insecureshop.LoginActivity.onLogin(View)` calls `Context.createPackageContext(...)` with flags `0x3` (CONTEXT_INCLUDE_CODE, CONTEXT_IGNORE_SECURITY). `CONTEXT_IGNORE_SECURITY` disables the caller-signature check, so code is loaded from another package even when it is signed by a different key. `CONTEXT_INCLUDE_CODE` loads and can run that package's DEX inside THIS app's process. An attacker who can install, replace, or spoof the package name of another package then executes arbitrary code with this app's identity and permissions (CWE-940: improper verification of source of a communication channel / cross-package code loading).

The certificate's Common Name matches the Android SDK's well-known debug key. Production builds signed with this key share an identity with every other `android-debug-key`-signed app — the package signature no longer uniquely identifies your release, breaking signature-permission models, KeyStore key separation, and Play Store upload verification.

The signing certificate uses RSA with a 1024-bit key — below the 2048-bit floor current NIST guidance considers acceptable. Modern Android signing should use RSA-2048+ (preferably 4096), or EC-P-256+.

`android:usesCleartextTraffic="true"` opts the entire app out of Android's default cleartext block (on by default for targetSdk≥28). Any HTTP request the app makes is observable and modifiable by a network-path attacker.

`com.insecureshop.util.Prefs.setPassword` persists a credential into SharedPreferences.Editor.putString of a password without at-rest encryption. Data written to SharedPreferences, a DataStore, or a SQLite database in plaintext is readable by anyone who can reach the app's private storage — a backup extraction, a rooted device, an `adb backup`-eligible app, or a debuggable build.

`void com.insecureshop.CustomReceiver.onReceive(Context, Intent)` calls `startActivity` with an Intent that the taint analyzer traces back to a `putExtra(...)` call carrying credential-shaped data. If this Intent is dispatched implicitly — no `setComponent` or `setPackage` on the same register — any app declaring a matching `<intent-filter>` (including a hostile one) receives the extras. Static analysis can't always tell whether the Intent was scoped; the `requires_review: true` evidence flag flags this callsite for manual confirmation.

The provider `com.insecureshop.contentProvider.InsecureShopProvider` is exported (or implicitly exported via its intent-filter) and declares no `android:permission` to gate access. Any other app on the device can launch / bind to / call into it without consent. It sets `android:readPermission` but no `android:writePermission` or `android:permission`, so any app can still WRITE to it (data injection / integrity risk).

The service `net.gotev.uploadservice.UploadService` is exported (or implicitly exported via its intent-filter) and declares no `android:permission` to gate access. Any other app on the device can launch / bind to / call into it without consent.

The `FileProvider` `androidx.core.content.FileProvider` (authority `com.insecureshop.file_provider`) declares `android:grantUriPermissions="true"` and its `<paths>` resource (`res/xml/provider_paths.xml`) contains `<root-path path="/"/>`, which shares the entire device filesystem the app's UID can read (`/`). A grantable `FileProvider` hands any app that receives a `content://` URI (via `FLAG_GRANT_READ_URI_PERMISSION` / `FLAG_GRANT_WRITE_URI_PERMISSION`) temporary access to files beneath the shared root. With the whole base directory exposed, a caller that obtains — or coerces the app into issuing — such a grant can reach files far beyond what the sharing feature intended — the app's whole internal files directory for a bare `files-path`, up to the app's own private data when the shared root is the filesystem root.

`com.insecureshop.util.Util.getUserCreds()` builds a credential map from two hardcoded string literals, mapping `shopuser` → `!ns3csh0p` via `java.util.Map.put(...)`. Both the username/key and the password/value are compiled into the APK, so anyone who unpacks the app (a one-command `unzip` + `baksmali`) recovers the credential verbatim. A secret baked into client bytecode is shared by every install and cannot be rotated without shipping a new build — the classic hardcoded-credential (“backdoor login”) weakness, CWE-798.

`targetSdkVersion=29` is more than two Android releases behind the current API level (35). The app opts out of platform-side hardening shipped in newer releases (scoped storage, runtime broadcast restrictions, permission auto-revoke, mutable PendingIntent default flip, …) and is likely to be rejected by Google Play under their rolling target-API requirement.

`com.insecureshop.LoginActivity` looks like a sensitive screen (credential entry) but no class in its hierarchy calls `setFilterTouchesWhenObscured(true)`. A malicious overlay drawn via `SYSTEM_ALERT_WINDOW` or injected by a hostile accessibility service can capture taps that look like they land on the legitimate UI.

`void com.insecureshop.ChooserActivity.onCreate(Bundle)` builds a filesystem path via `java.io.File(String)` from data the taint analyzer traces back to incoming IPC input (`Intent.get*Extra` / `getData` / a `Uri` path part / `Bundle.getString`). The sender controls that string: a value like `../shared_prefs/prefs.xml` escapes the intended directory (path traversal, CWE-22), and even without `..` it can name a private file the feature never meant to expose — the MASTG-DEMO-0122 pattern, where an extra picks the file a `FileProvider` then shares. `com.insecureshop.ChooserActivity` is an exported activity, so any app on the device can send it this input. This is an intra-procedural taint result flagged for review — confirm the resolved path is not canonicalised and checked against the intended base directory before it is used.

The app declares `minSdkVersion=16` (< 24) and references no `android:networkSecurityConfig`. On Android releases before API 24 the platform default trust store includes **user-installed CAs**, so without an explicit config the app trusts any CA the user — or a corporate/MITM device-admin box — has installed. Such an attacker can transparently intercept the app's TLS traffic. From API 24 the default switched to system-only trust anchors, so this exposure applies specifically to the pre-24 install base. (This is the `minSdk < 24` counterpart of `manifest.no_network_security_config`, which covers the `targetSdk >= 24` no-NSC case — the two are disjoint.)

`android:allowBackup="true"` lets `adb backup` extract the app's private data on a debug-bridged device, and (on Android <12) lets Auto Backup ship the same data to the user's Google Drive — tokens and credentials in `shared_prefs/` / `databases/` ride along. `android:fullBackupContent and dataExtractionRules` are not declared, so that backup path is unscoped and captures everything by default.

`@string/aws_Identity_pool_ID` contains a value matching the pattern for AWS Cognito identity pool ID. It is a `<string>` resource. `res/values/` strings ship in every APK and are trivially extracted with `apktool` or by reading `resources.arsc`. Anyone with the APK can read this value, but it isn't a rotatable secret — the exposure is mitigated at the source (tighten access control or restrict the key), not by rotation.

No reference to `Debug.isDebuggerConnected`, `PackageManager.checkSignatures`, or other classic tamper-detection APIs. For apps handling sensitive data MASVS-RESILIENCE expects at least one active-debugger check + a signature self-check.

`android:networkSecurityConfig` is unset. The app falls back to the platform default trust store and has no per-domain policy hooks — no certificate pinning, no per-host cleartext restrictions, no debug-only trust anchors.

Of 60 app-owned classes (excluding framework / AndroidX / Kotlin / Google Play / OkHttp / Retrofit / RxJava / similar curated-out packages), only 2% carry single-character simple names — the share R8 / ProGuard typically produces. Class, method, and field names are intact, which gives a reverse engineer a free map of your business logic and accelerates RE of any custom anti-tamper / crypto / licensing code shipped with the app.

No reference to known root-detection libraries (RootBeer, SafetyNet, Play Integrity) and no su-path string constants in the DEX. For apps handling credentials, payments, or DRM content, MASVS-RESILIENCE-1 expects at least one runtime check + server-side attestation. Absence is a build-hygiene signal that the threat model didn't consider rooted devices.