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. The message leaves the device over the mobile network and may be charged to the user. On Android 4.4 (API 19) and later the system also writes text messages sent by an app that is not the default SMS app to the SMS provider, so the send is normally visible in the user's messaging app, but only after the data has left the device.

`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. The app targets API 22, so the flags still take effect on every Android version.

`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` and `targetSdkVersion=22`, both below 24, and references no `android:networkSecurityConfig`. Without an explicit config an app that targets API 23 or lower trusts **user-installed CAs** on every Android version: on Android 7.0 (API 24) and later its default config keeps them, and older releases have no other policy. A CA that the user, or a corporate or MITM device-admin profile, installs can therefore intercept the app's TLS traffic.

`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.