Mobile code quality
bb-huge π€ , Personal bug bounty findings hub and bug bounty orchestration for multiple agents
npx -y skills add ShulkwiSEC/bb-huge --skill mobile-code-qualityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 18 stars18 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Detects code quality vulnerabilities in mobile apps (Android/iOS). Trigger on: SQL injection in SQLite, JavaScript injection in WebViews, intent injection, unsafe deserialization, NSKeyedUnarchiver, NSCoding, Java serialization, Parcelable, buffer overflow, JNI native code, PIE disabled, NX disabled, stack canary absent, RELRO, ARC disabled, third-party library CVE, vulnerable dependency, outdated SDK, targetSdkVersion, update enforcement missing, implicit Intent, URL loading in WebView, object persistence, memory corruption, OWASP dependency check. Covers MASVS-CODE-1/2/3/4.
The file declares its own license as MIT. That is the authorβs claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
8.0 KB, as published. Nobody here has run it
Mobile Code Quality
What Is Broken and Why
Mobile code quality vulnerabilities arise from using deprecated/unsafe APIs, failing to validate input from local storage or IPC, insecure object deserialization, and shipping with exploitable native code. SQL injection via string-concatenated SQLite queries is common. WebViews that load arbitrary URLs without scheme/host validation allow navigation to attacker-controlled content. Java/Kotlin deserialization of untrusted Parcelables or ObjectInputStream can lead to type confusion and arbitrary code execution. Native code (JNI/NDK) compiled without stack canaries, PIE, or NX creates exploitable memory corruption conditions.
Key Signals
rawQuery("SELECT * FROM users WHERE id='" + userInput + "'")β string-concatenated SQLwebView.loadUrl(intent.getStringExtra("url"))β unvalidated URL loadObjectInputStream.readObject()on data from Intent extras or ContentProviderNSKeyedUnarchiver.unarchiveObject(with:)without class whitelist (iOS < 12)- Native library without PIE:
checksec --file=libapp.soshowsNo PIE - Gradle
implementationdependency with published CVE in OSS Index targetSdkVersionbelow 30 β misses numerous security improvements- Implicit Intent used to send sensitive data:
sendBroadcast(Intent("ACTION"))without package target - No version check / forced update mechanism β vulnerable older versions remain in production
Methodology
SQL Injection:
- Identify SQLite query construction in decompiled code β search for
rawQuery,execSQLwith+concatenation - Trace input sources: Intent extras, ContentProvider queries, user input fields
- Test: inject
' OR '1'='1via deep link parameter or IPC
WebView URL loading:
- Find all
webView.loadUrl()/WKWebView.load(URLRequest)calls - Trace the URL source β does it come from user input, Intent, or remote config?
- Inject
javascript:orfile://scheme payloads
Deserialization:
- Search for
ObjectInputStream,Parcel.readValue,NSKeyedUnarchiverin source - Check if input is from untrusted source (Intent extras, network, files)
- Attempt to pass crafted gadget chain via Intent Parcelable extra
Binary hardening:
# Android β check native library protections
apktool d app.apk
for so in app/lib/**/*.so; do checksec --file="$so"; done
# iOS β check binary protections
otool -hv Payload/App.app/App # check MH_PIE flag
otool -Iv Payload/App.app/App | grep stack_chk # stack canary
Dependency scanning:
# Android β OWASP Dependency-Check
dependency-check --project "app" --scan app.apk --format HTML
# iOS β check Podfile.lock or Package.resolved for known CVEs
Payloads & Tools
# semgrep β Android SQL injection patterns
semgrep --pattern 'rawQuery($QUERY + $INPUT, $_)' --lang java android-src/
semgrep --pattern 'execSQL($QUERY + $INPUT)' --lang java android-src/
# adb β inject SQL via deep link
adb shell am start -W -a android.intent.action.VIEW \
-d "app://search?q=' OR '1'='1" TARGET_PKG
# checksec β native library hardening
checksec --file=libapp.so
# Look for: Canary: No, NX: No, PIE: No, RELRO: No
# MobSF β automated scan
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf
# Upload APK β check "Binary Analysis" and "Code Analysis" sections
# iOS β class whitelist check (correct pattern)
# Should use: NSKeyedUnarchiver.unarchivedObject(ofClass: Target.self, from: data)
# Not: NSKeyedUnarchiver.unarchiveObject(with: data) (deprecated, no type restriction)
Bypass Techniques
- Parcelable deserialization confusion β Android's Parcel reads type information from data; craft Parcel with type confusion to trigger unexpected code paths
- WebView scheme confusion β
intent://URIs in WebView can launch app components on Android;file://cross-origin reads possible withsetAllowFileAccessFromFileURLs - Dependency CVE chaining β vulnerable transitive dependency (not direct dependency) often missed by basic scans
- Native format string β JNI function using
printf(userInput)without format string β info leak or code execution
Exploitation Scenarios
Scenario 1 β SQLite Injection via Deep Link
Setup: App's search feature constructs rawQuery("SELECT * FROM notes WHERE title LIKE '" + query + "'"). Deep link passes query parameter. β Trigger: app://search?q=' UNION SELECT password FROM users --. β Impact: All user passwords extracted from local database.
Scenario 2 β WebView File Read via Intent
Setup: WebViewActivity loads intent.getStringExtra("url") without validation; setAllowFileAccessFromFileURLs(true). β Trigger: Malicious app sends Intent with url=file:///data/data/TARGET/shared_prefs/auth.xml. β Impact: Victim's SharedPreferences (containing tokens) read by attacker via WebView.
Scenario 3 β Native Buffer Overflow
Setup: JNI function processes image metadata with strcpy(buf, userControlledString) β no bounds check, no stack canary. β Trigger: Craft image with oversized EXIF field. β Impact: Stack smash; exploitable for code execution in native context.
False Positives
rawQuerywith parameterized query:rawQuery("SELECT * FROM t WHERE id=?", arrayOf(id))β safe- WebView loading only
file:///android_asset/orhttps://with host whitelist - Deserialization of trusted, internally generated data with known class whitelist
- Old
targetSdkVersionin a library module that doesn't affect app runtime security features
Fix Patterns
// Android β parameterized SQLite query
db.rawQuery("SELECT * FROM notes WHERE title LIKE ?", arrayOf("%$userInput%"))
// Or use Room with @Query annotation (handles binding automatically)
// Android β WebView URL whitelist
val allowedHosts = setOf("api.target.com", "assets.target.com")
webView.webViewClient = object : WebViewClient() {
override fun shouldOverrideUrlLoading(view: WebView, request: WebResourceRequest): Boolean {
return request.url.host !in allowedHosts // block if not whitelisted
}
}
// iOS β typed NSKeyedUnarchiver (safe)
guard let obj = try? NSKeyedUnarchiver.unarchivedObject(ofClass: MyModel.self, from: data) else { return }
// iOS β force update check
let storeVersion = fetchAppStoreVersion()
if currentVersion < minimumSupportedVersion { showForceUpdateDialog() }
# CMakeLists.txt β enable hardening flags for native code
target_compile_options(mylib PRIVATE -fstack-protector-strong -D_FORTIFY_SOURCE=2 -fpie)
target_link_options(mylib PRIVATE -Wl,-z,relro,-z,now -pie)
Related Skills
[[mobile-platform-interaction]] is the delivery layer for many code quality vulnerabilities β exported components and deep links are how untrusted input reaches rawQuery() and webView.loadUrl(). SQLite injection via string concatenation here is the mobile equivalent of [[sql-injection]] on the web, with identical methodology and payloads adapted for Android's rawQuery. Deserialization of Parcelable data mirrors web-side unsafe deserialization and [[xxe]] in the sense that both exploit parser trust of attacker-controlled structured input.