Skip to main content

Mobile App Insecurity: Insecure Storage & Broken Cryptography — How They Happen, How to Test, and Real PoCs

 Mobile apps run our world — from banking and shopping to healthcare and communication — yet many still store sensitive data in ways that would make any security engineer’s heart stop. While developers focus on features, deadlines, and user experience, security often gets bolted on at the very end… if at all.

This is how two of the most common and dangerous mobile vulnerabilities make it into production:

✅ Insecure Storage
✅ Broken Cryptography

These weaknesses open the door for attackers to steal tokens, passwords, private keys, personal information, and even full account takeovers. The scary part? Attackers don’t need physical access to your phone. With today’s automation tools, bad actors can reverse engineer apps in minutes.

This article breaks all of that down — in a human, friendly way — and walks through how to test these flaws using tools like Frida and MobSF, with practical proof-of-concept examples.

Why This Still Happens in 2025

It’s easy to blame developers, but the truth is messier:

  • Teams assume OS-level protections (Android/iOS sandbox) are enough.

  • Devs store data "temporarily"… but temporary becomes permanent.

  • Crypto is complex — so many roll their own or copy snippets from StackOverflow.

  • Business wants features delivered faster than proper security reviews allow.

  • Product managers don’t understand the risk of what’s being stored.

As a result, we see things like:

  • Access tokens saved in plaintext

  • PIN codes written to shared preferences

  • AES encryption with a hard-coded key in the app

  • JWTs stored unencrypted in an SQLite DB

  • Sensitive logs written to logcat

  • iOS apps storing authentication tokens in NSUserDefaults

Let’s break down the two core categories.

1. Insecure Storage — The Silent Killer

"Insecure storage" means an app stores private data without proper protection. Even if the app "feels safe" to users, local storage often tells a darker story.

Common Insecure Storage Mistakes

  • Saving JWTs, OAuth tokens, or session IDs in plaintext

  • Storing usernames and passwords in local files

  • Caching PII in logs (email, phone, address)

  • Putting secrets inside:

    • SharedPreferences / UserDefaults

    • SQLite databases

    • External storage

    • Logcat

    • Plain JSON files in the app directory

Attackers can extract these easily with:

adb shell
run-as com.example.app
cat shared_prefs/auth.xml

Or by simply running “rooted device” + a file explorer.

Tools for Detecting Insecure Storage

🔍 MobSF (Mobile Security Framework)

MobSF is a one-click static/dynamic mobile analysis framework that flags:

  • Hardcoded secrets

  • Insecure storage paths

  • Database vulnerabilities

  • Insecure crypto logic

  • Logging leaks

How to use MobSF

  1. Install MobSF

  2. Drag and drop the APK/IPA

  3. Review results → especially "Android Manifest Issues" and "File Analysis."

MobSF will literally show you output like:

SharedPreferences contains keys:
  - auth_token
  - refresh_token
  - user_password

If you see that… the app is already compromised.

POC: Extracting Sensitive Data (Android)

Let’s assume we have an app storing a JWT token in SharedPreferences.

Step 1 — Identify package

adb shell pm list packages | grep myapp

Step 2 — Access its internal directory

adb shell
run-as com.myapp.secure
cd shared_prefs
cat auth.xml

You might see something like:

<string name="jwt">eyJhbGciOiJIUzI1NiIsIn...</string>

That's a valid, usable session token — game over.

2. Broken Cryptography — When Encryption Makes Things Worse

Cryptography is supposed to protect data. But when implemented incorrectly, it can be worse than storing things in plaintext.

Most common crypto mistakes

  • Using AES in ECB mode

  • Hardcoding encryption keys

  • Hardcoding IVs

  • Using Base64 and calling it “encryption.”

  • Using obsolete algorithms (DES, RC4, MD5, SHA1)

  • Custom / homemade crypto algorithms

  • Encoding instead of encrypting

  • Not rotating keys

  • Encrypting without authentication (no HMAC)

Security teams see this constantly in real-world apps.

POC: Hardcoded Key Extraction

Let’s say this code exists inside the APK:

private static final String KEY = "1234567890123456";

Frida can hook into the encryption function and grab both the key and decrypted data at runtime.

Using Frida to Test for Crypto & Storage Issues

Frida is the weapon of choice for runtime hooking, API tracing, bypassing root/jailbreak detections, and intercepting encryption calls.

Why Frida?

  • Live intercept of encryption/decryption

  • Hook functions and print arguments

  • Bypass SSL pinning

  • Bypass root detection

  • Extract runtime secrets

  • Inspect how the app stores tokens

Frida POCs

POC 1 — Dumping Encryption Keys

frida-script.js

Java.perform(function () {
    var Crypto = Java.use("com.app.security.CryptoManager");

    Crypto.encrypt.overload('java.lang.String').implementation = function (data) {
        console.log("[*] Encrypt called");
        console.log("Input:", data);
        var out = this.encrypt(data);
        console.log("Output:", out);
        return out;
    };

    Crypto.getKey.implementation = function () {
        var key = this.getKey();
        console.log("[*] Encryption Key:", key);
        return key;
    };
});

Run the script

frida -U -f com.myapp.secure --no-pause -l frida-script.js

Output example:

[*] Encryption Key: 1234567890123456

Boom — hardcoded key captured.

POC 2 — Dumping SharedPreferences Using Frida

Even without ADB or root:

Java.perform(function () {
    var sp = Java.use("android.app.SharedPreferencesImpl");
    sp.getString.overload('java.lang.String', 'java.lang.String')
      .implementation = function (k, def) {
          var value = this.getString(k, def);
          console.log("[SharedPreferences]", k, "=", value);
          return value;
      };
});

This prints all tokens as soon as the app reads them.

Combining MobSF + Frida for Full Coverage

MobSF tells you:

  • Where insecure data exists, which files store secrets

  • Which crypto functions are used

  • How data flows

Frida allows you to:

  • hook live functions

  • bypass protections

  • extract secrets

  • observe crypto logic in real time

Together, they give complete visibility.

Advanced Testing Tips for Pentesters

Here’s how professionals test mobile apps:

✔ Test Insecure Storage on Android

  • Check /data/data/<package>/shared_prefs/

  • Check /data/data/<package>/databases/

  • Analyze logcat for sensitive logs

  • Dump files using Frida if the device is not rooted

  • Scan app with MobSF for:

    • File system writes

    • Insecure permissions

    • WebView cache leaks

✔ Test Insecure Storage on iOS

  • Look at NSUserDefaults

  • Check keychain access groups

  • Inspect the app sandbox using a jailbroken device

  • Analyze the IPA with MobSF

✔ Test Broken Cryptography

  • Identify crypto libraries used

  • Check for:

    • AES ECB

    • Hard-coded keys

    • Hard-coded IVs

    • Weak hashes

  • Hook using Frida:

    • Cipher.getInstance()

    • SecretKeySpec()

    • MessageDigest()

  • Extract encryption keys in real time

  • Attempt to decrypt the app data locally

Real-World Impact — Why These Bugs Matter

These vulnerabilities can lead to:

Account Takeover

If an attacker extracts:

  • refresh token

  • auth token

  • cookies

They can impersonate users indefinitely.

Credential Theft

Passwords stored in local files = disaster.

API abuse

Stolen API tokens → internal endpoints exposed.

Fraud

Payment apps storing card data improperly risk massive exploitation.

Reputation loss

Leaking private messages, health data, or photos can destroy user trust.

How Developers Can Fix This

1. Use Secure Storage APIs

  • Android Keystore

  • iOS Keychain
    These ensure hardware-backed protection.

2. Never Store Sensitive Data Unless Necessary

If you can avoid it — DO.

3. Follow Standard Cryptography Practices

  • AES-GCM, not ECB

  • Proper IV generation

  • No hardcoded keys

  • Use PBKDF2/Argon2 for passwords

  • Implement key rotation

  • Use proven libraries (Google Tink, Bouncy Castle)

4. Obfuscate Code

Not a complete fix, but it makes cracking harder.

5. Run Mobile Pen Tests Before Release

MobSF + Frida + manual review = baseline requirement.

Conclusion

Mobile apps are becoming more powerful — and attackers are adapting just as quickly. Two of the most critical, widespread vulnerabilities today are:

  • Insecure Storage

  • Broken Cryptography

They happen not because developers are careless, but because mobile security is complex. But with the right tools — Frida, MobSF, manual code analysis, and secure design practices — these vulnerabilities can be caught early and eliminated.

Whether you're a pentester, mobile reverse engineer, bug bounty hunter, or a developer, understanding these flaws isn’t optional anymore — it’s the minimum bar for secure mobile development.

Comments

Post a Comment

Popular posts from this blog

Practical XSS: DOM vs Reflected vs Stored — Advanced Payloads & Bypasses

Practical XSS: DOM vs Reflected vs Stored in 2025 (Payloads & Bypasses) If you hunt bugs, run red teams, or build web apps, XSS still matters in 2025. It is one of the easiest ways to jump from “weird UI bug” to full account takeover, even on big platforms. Cross-site scripting (XSS) is when an attacker runs their own JavaScript in someone else’s browser using a vulnerable site. The three main flavors are simple to say, hard to defend: reflected XSS (comes back in a single response), stored XSS (saved on the server), and DOM-based XSS (triggered by client-side code). This guide focuses on real payloads and modern bypass tricks, not just alert(1) . You will see how attackers build and adapt payloads for each type, and how filters, CSP, and WAFs can fail in practice. It is written for people who already get basic HTTP and HTML and want to level up their XSS game. Quick XSS refresher: DOM vs reflected vs stored in simple terms Photo by Markus Winkler In 2025, XSS is still one of the...
Post a Comment
Read more

API Authorization Flaws (Broken Object Level & Function Level Auth)

  API Authorization Flaws: BOLA and BFLA Explained for Real-World Security APIs are the hidden pipes that keep modern apps running. Your banking app, ride sharing app, and social media feed all depend on APIs to send and receive data behind the scenes. When those APIs make simple mistakes in authorization , private data leaks. You do not always need complex malware. Often, attackers just change an ID or call a hidden function. Two of the worst mistakes are Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA). Both BOLA and BFLA appear in the OWASP API Security Top 10 that teams still follow as of 2025, based on the latest 2023 list, where BOLA is ranked number 1 and BFLA is number 5. This post breaks down what these flaws are, how attackers abuse them, and clear steps your team can take to prevent them. What Are API Authorization Flaws and Why Do They Matter? Photo by Markus Winkler To understand API authorization flaws, start with two si...
Post a Comment
Read more

Chain Exploits: From Information Leak to RCE in 2025

 Chain Exploits: From Information Leak to RCE in 2025 A lot of people picture hacking as one big magic trick. In reality, most modern attacks are a chain of small, boring bugs that line up in a very bad way. Two of the most dangerous links in that chain are an information leak and remote code execution (RCE). An information leak is any bug that reveals data that should stay private. RCE is a bug that lets an attacker run their own code on your server or node from far away. On their own, each bug might look minor. Together, they can give an attacker full control of your web app, CI pipeline, or blockchain stack. In 2025, with DeFi protocols, Web3 dashboards, and npm-heavy codebases everywhere, this pattern is more common than people think. This post walks step by step from a tiny leak to full system control, using simple language and real style examples from npm supply chain attacks and DeFi exploits. What Is a Chain Exploit and Why Does It Matter for Security in 2025? A chain explo...
Post a Comment
Read more