DEV Community

Cover image for How I Pulled Live Chrome Tokens from Android Without Root using Termux
GnomeMan4201
GnomeMan4201

Posted on • Edited on

How I Pulled Live Chrome Tokens from Android Without Root using Termux

Disclaimer:

This article is intended for educational and research purposes only. All techniques and methods described should only be used in environments where you have explicit, legal authorization.

Unauthorized access, testing, or exploitation of devices or systems is illegal and unethical.

By proceeding, you agree to comply with all applicable laws and regulations, and to use the information solely for lawful, responsible security research and defensive purposes.

There’s this assumption baked into Android’s security model: if you’re not rooted, you’re boxed in.

And for the most part, that’s true — but not always.

Over the past few weeks, I went back and forth trying to recall a technique I stumbled into months ago. It let me access real Chrome based browser token data from a non-rooted Android environment, inspect cookie sessions, and pull out values that shouldn't have been accessible. And after chasing my own digital footprints, it finally clicked.

This post isn’t about exploits. It’s about approach. Thinking laterally. And pushing edge cases in systems that weren’t designed with curious minds in mind.


Setup: Tools I Used

All of this was done on a non rooted Android device using:

Termux (modern version with pkg support)

Proot + Proot-Distro (for chroot-like environments)

Debian VM via Proot

SwiftBackup (for full app data backup)

SQLite3 (for inspecting browser session DBs)

Occasional use of Shizuku / AppOps when needed

Optional: Custom tooling to exfil + clean outputs (badBANANA, etc.)


The Thought Process

  1. Most session tokens are stored in local SQLite DBs, not in memory. Especially for Chromium forks like Kiwi, Brave, and older Chrome builds.

  2. Scoped storage doesn't mean inaccessibility just indirection. If the app data can be backed up or restored (and you know where to look), it's game on.

  3. You don’t need root to simulate elevated environments.

fakeroot, proot, and proot-distro allow full VM-style shells inside Termux which lets you run tooling like sqlite3 cleanly.

You can bind local directories (like exported browser data) into these environments and treat them like mounted volumes.


The Technique

Here’s what actually worked:

  1. Back up the browser's internal storage using something like SwiftBackup.

Target: com.kiwibrowser.browser (Kiwi, a Chrome fork)

Grab the app_chrome/Default/Cookies file inside the data tree.

  1. Move the backup into a Proot-mountable location (like ~/storage/shared or ~/termux_home).

  2. Launch Debian inside Termux using proot-distro login debian, and install:

apt install proot sqlite3 -y

  1. Mount the data as your new root and inspect:

proot -S /path/to/kiwi_backup /bin/bash
cd app_chrome/Default
sqlite3 Cookies "SELECT host_key, name, value FROM cookies;"

That’s it. If the cookies weren’t encrypted (or used legacy storage methods), they’ll spill right out.


Why This Matters

Creative Red Teaming: For anyone doing mobile recon or app security testing, this method lets you analyze target behavior without triggering root-based alerts.

Mobile Forensics: For investigators, this technique is a workaround to extract session data when root isn't an option think corporate analysis or compromised device reviews.

System Design Edge Cases: Android's security isn't "broken," but it assumes you’ll follow the prescribed path. This is a reminder that many security guarantees are conditional and creativity is often more powerful than brute force.


Where This Thinking Can Go

This is just one outcome of a mindset that values layer stacking, creative privilege emulation, and working within (but against) constraints. This same thinking could be used to:

Emulate other app environments for exfil without detection

Clone and analyze in-memory SQLite or WebView storage

Build automated session token scrapers for any app using Chromium base

The point isn’t just that it works it’s that we’re still finding ways to make things work, even when they “shouldn’t.”


Final Thoughts

No root, no exploits, no shortcuts just a layered environment, a bit of persistence, and some old-fashioned sandbox abuse.

If you’re playing with Termux, VM chaining, or building your own toolkits for mobile introspection, this might spark a few ideas. And if you’ve been here before, or found cleaner routes in I’d love to compare notes.

Let the system think you’re playing fair.

Then walk right through the side door.

Top comments (0)