com.android.insecurebankv2

The APK is signed with the v1 (JAR) scheme only — no v2 or v3 signature. v1-only signatures are vulnerable to Janus (CVE-2017-13156) on Android < 24: an attacker can prepend a malicious DEX without invalidating the signature, allowing arbitrary code injection into the legitimate APK. Pre-Nougat devices represent a small but non-zero install base.

`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.android.insecurebankv2.MyBroadCastReceiver.onReceive(Context, Intent)` passes an attacker-controlled value as the SMS destination address to `SmsManager.sendTextMessage`. The taint analyzer traces it back to an incoming `Intent` extra. Whoever sends that Intent (a hostile app broadcasting to an exported receiver, a malicious caller of an exported component) chooses the recipient, turning the send into a data-exfiltration primitive: the app SMSes device data to a number the attacker picks. The message body carries data the analyzer traces to a stored secret / credential source, so an actual credential is being exfiltrated — not just an empty relay. SMS leaves the device entirely — there is no on-device audit trail and the carrier bills the send.

`void com.android.insecurebankv2.MyBroadCastReceiver.onReceive(Context, Intent)` calls `getSharedPreferences` with `MODE_WORLD_READABLE` set on the mode argument. Files / databases / shared-prefs created with these flags are readable (and/or writeable) by every other app on the device — credentials, tokens, anything stored there leaks. Both flags have been deprecated since API 17 and rejected outright since API 24.

`com.android.insecurebankv2.DoLogin.RequestTask.postData()` compares a runtime value against the hardcoded string literal `devadmin` via `String.equals(...)`. The literal is a well-known backdoor / privileged-role account name, so this is a hardcoded / backdoor credential check baked into the client: the account name (and any password compared the same way) ships in every copy of the APK and is recovered with a one-command `unzip` + `baksmali`. A credential compiled 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.

`void com.android.insecurebankv2.ViewStatement.onCreate(Bundle)` loads a `file://` URL into a WebView while JavaScript is enabled, and the URL is rooted in EXTERNAL storage (`Environment.getExternalStorageDirectory()` / `Context.getExternalFilesDir()`). External storage is world-readable on older Android and shared across apps, so any app — or a user with a file manager — can drop a crafted HTML/JS file at the loaded path. Because JavaScript runs, that attacker-controlled content executes inside the WebView: stored XSS, exfiltration of local files reachable through the `file://` origin, and abuse of any `addJavascriptInterface` bridge. All three signals co-occur in this method — a `file://` const-string, an external-storage directory lookup, and `setJavaScriptEnabled(true)`.

The provider `com.android.insecurebankv2.TrackUserContentProvider` 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 receiver `com.android.insecurebankv2.MyBroadCastReceiver` 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.

`com.android.insecurebankv2.PostLogin.doesSUexist` spawns an operating-system process by calling `Runtime.exec` (`Runtime.exec` / `ProcessBuilder.start`). If any part of the command line is derived from untrusted input (an intent extra, a file, a network response, or user text) without strict validation, this is OS command injection (CWE-78): an attacker can run arbitrary shell commands with the app's permissions. Even a fixed command is a capability worth review — confirm where the command string comes from and whether the invoked binary is trusted.

`targetSdkVersion=22` 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.

`void com.android.insecurebankv2.DoLogin.RequestTask.1.run()` feeds `ContentValues.put` data the taint analyzer traces back to a credential / identifier / location source. Writing credential or PII material to SharedPreferences, a DataStore, or a SQLite database in plaintext leaves it readable to anyone who can reach the app's private storage — a backup extraction, a rooted device, an `adb backup`-eligible app, or a debuggable build. The same code path catches token / cookie / device-id / geolocation values flowing through this method.

`void com.android.insecurebankv2.ViewStatement.onCreate(Bundle)` builds a filesystem path via `java.io.File(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.android.insecurebankv2.ViewStatement` 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=15` (< 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.

The manifest declares `android.permission.READ_CONTACTS` but no DEX class references the Android API this permission guards. Either the permission is dead weight left over from a removed feature, or the functionality that needs it lives in a native library / dynamic feature module the static analyser can't follow. Either way, the user-visible permission prompt is broader than the app actually requires.

The manifest declares `android.permission.READ_CALL_LOG` but no DEX class references the Android API this permission guards. Either the permission is dead weight left over from a removed feature, or the functionality that needs it lives in a native library / dynamic feature module the static analyser can't follow. Either way, the user-visible permission prompt is broader than the app actually requires.

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.

Of 33 app-owned classes (excluding framework / AndroidX / Kotlin / Google Play / OkHttp / Retrofit / RxJava / similar curated-out packages), only 0% 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.

The app declares one or more runtime-grantable permissions but no class calls `Activity.shouldShowRequestPermissionRationale` or `ActivityCompat.shouldShowRequestPermissionRationale`. Users denied a permission once will be re-prompted without any context for why the app needs access — typically leading to permanent denial without informed consent, which Google's Permissions Best Practices and MASVS-PRIVACY-2 both call out as a privacy / UX smell.