Hacking into android platform by exploiting sqlite database

In my previous article I covered how to access SQLite databases on Android. Here we’ll look at how to explore those databases to gather more information.

Among Android’s databases, some contain sensitive information:

lockscreen.db

Browser sessions, browser history, cached images, and more.

You can also explore databases of installed apps to read or modify their stored values. For example, some people use apps like GameGuardian to change game scores. With direct SQLite access you can do the same — and more — without any third-party tool (root access required).

Account credentials

Navigate to:

/data/system/users/0/accounts.db

Here you’ll find cryptographic hashes of account passwords (e-mail, Google, etc.). Android stores these in encrypted form.

Notably, on Android 2.3 (Gingerbread), account passwords were stored in plain text without encryption — a significant vulnerability. This was fixed in later versions.

On a rooted device, anyone with physical access could navigate to the root directory and read plain-text passwords from older Android versions.

Browser databases

/data/data/com.example.browser/databases/example.db

Browser databases contain history, bookmarks, cached images, downloaded files, web searches, saved passwords, sessions, cookies, and more.

Here’s an example of a session ID from a browser database on my device:

Session IDs aren’t always useful — they expire when you log out or disconnect. But if the session is still active on the server, someone could reuse it to log into your account before it expires.

This attack requires physical access to a rooted device.

Notice: Accessing someone else’s account or data without permission is illegal and can result in serious consequences. This is purely educational.

Cached profile photos

Ever wondered where profile photos are cached locally?

When you view your Gmail account, the profile photo you see is served from Google’s servers. The URL for that photo is stored in Gmail’s local database — nothing surprising, every app does this.

The password.key file

/data/system/password.key

This file stores a salted hash of the device lock screen password, combining SHA-1 and MD5:

The salt is stored in:

/data/system/com.android.providers.settings/databases/settings.db

Here’s the relevant Android source code that shows how the hash is generated:

public byte[] passwordToHash(String password) {
    if (password == null) {
        return null;
    }
    String algo = null;
    byte[] hashed = null;
    try {
        byte[] saltedPassword = (password + getSalt()).getBytes();
        byte[] sha1 = MessageDigest.getInstance(algo = "SHA-1").digest(saltedPassword);
        byte[] md5 = MessageDigest.getInstance(algo = "MD5").digest(saltedPassword);
        hashed = (toHex(sha1) + toHex(md5)).getBytes();
    } catch (NoSuchAlgorithmException e) {
        Log.w(TAG, "Failed to encode string because of missing algorithm: " + algo);
    }
    return hashed;
}

Open settings.db to find the password_salt value.

Video Tutorial: 👉 https://youtu.be/QQUX7brNECo

I’m not going into how to crack those files here — that’s out of scope for this article. Hopefully you now have a clearer picture of how Android handles its databases.

Happy Hacking ;-)