Damru — Android-Native Stealth Browser Automation
A real Android OS in Docker (Redroid) driven through Playwright and CDP, with OS-level stealth and zero JavaScript injection.
- Source repo
- akwin1234/damru
- Stars
- ★ 342
- Last updated
- 3mo ago
- License
- NOASSERTION
- Primary language
- Python
- FA score
- 42/100 · Major gaps
At a glance
- How it runs
- Works with
- Platform-specific
- Cost
- Free, no paid service needed
- Setup effort
- High · needs real infrastructure
- You'll need
- Typical use
- Scraping teams that must get past Cloudflare Turnstile, DataDome or similar WAFs and want a genuine Android fingerprint rather than a desktop one.
- Not a fit if
- Teams running native Windows Docker
- Hosts on Debian or other unsupported Linux distributions
- Users who need to drive a physical Android phone
- Source review
- 42/100 · Major gaps
What does this agent do, and when should you use it?
Damru is an open-source stealth browser automation framework whose core idea is to avoid injecting any JavaScript into the page. Instead it boots a full Android system (Redroid) inside Docker and drives Chrome through Playwright over the Chrome DevTools Protocol. Spoofing happens at the OS, binary and protocol layers: resetprop rewrites build.prop values, Vulkan/GLES .so drivers are patched for GPU identity, libfakemem.so intercepts sysinfo via LD_PRELOAD, and wm size/density plus iptables shape display, WebRTC and IPv6 behaviour. The project bundles 155 real Android device profiles, Chrome/WebView version rotation and roughly 184 TLS/JA3 variants, and exposes AsyncDamru, Damru and DamruPool Python entry points plus a python -m damru CLI. It requires Ubuntu 24.04 or WSL2 with a bundled kernel, Docker and binderfs support, explicitly refuses physical phones, and describes itself as Beta.
At runtime Damru connects to a Redroid container over ADB, applies the selected device profile through resetprop (ro.product.model, ro.build.fingerprint, SDK level) and sets screen geometry with wm size and wm density. It patches the Vulkan/GLES driver binaries so the container reports an Adreno or Mali GPU instead of SwiftShader, loads libfakemem.so via LD_PRELOAD to intercept sysinfo/sysconf for RAM and CPU, and installs iptables rules that block WebRTC private-IP leaks and disable IPv6. Chrome-side behaviour is shaped through CDP calls such as Emulation.setHardwareConcurrencyOverride and Target.setAutoAttach so workers inherit overrides, plus Preferences/flag patching, TLS cipher rotation and DoH disablement so DNS resolves through the proxy ISP. Timezone and locale are derived from the proxy exit at session start. Users then interact through AsyncDamru/Damru page objects or CLI commands such as setup, check preflight, force-profile, stealth-open-url, benchmark, screenshot, record and ui.
- Scraping teams that must get past Cloudflare Turnstile, DataDome or similar WAFs and want a genuine Android fingerprint rather than a desktop one.
- Anti-bot and fingerprinting researchers who need to compare detection logic across 155 device profiles and switchable TLS/JA3 configurations.
- Mobile QA teams that want to run end-to-end Playwright scripts against a real Android runtime instead of a desktop viewport emulation.
- Automation engineers running several independent Android identities concurrently via DamruPool across two or three containers.
- Researchers who want to watch or manually drive a worker through the local
python -m damru uidashboard or an optional scrcpy viewer.
How do you install or deploy this agent?
Start from Ubuntu 24.04 (or WSL2 where you accept Damru's bundled kernel), install ADB and a Python virtual environment, then install from Git and bootstrap:
sudo apt update && sudo apt upgrade -y
sudo apt install adb wget curl git jq python3-venv -y
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -U pip setuptools wheel
pip install git+https://github.com/akwin1234/damru.gitThen install host dependencies and the pre-baked Redroid image, and verify the environment:
python -m damru install-deps -y
python -m damru install-image
python -m damru check-envThe baked image is fetched from https://dl.damru.dev/assets/damru-baked.tar.gz; if you have no local tarball, use python -m damru install-image --download. The ~3.3 GB chrome-apks.zip bundle (python -m damru install-apks --download) is only needed when baking or running raw Redroid yourself.
How do you use this agent?
The smallest programmatic invocation opens a page through AsyncDamru:
from damru import AsyncDamru
async def main():
async with AsyncDamru(chrome_apk="/home/damru/chrome-apks/145.0.7632.75") as browser:
page = await browser.new_page()
await page.goto("https://example.com")
if __name__ == "__main__":
import asyncio
asyncio.run(main())On the CLI side, run the read-only preflight first, then apply a profile or open a URL with full stealth:
python -m damru check preflight --json
python -m damru force-profile --serial 127.0.0.1:5600 --device pixel_8_pro
python -m damru stealth-open-url --serial 127.0.0.1:5600 --url https://example.com
python -m damru uiProxy, timezone and locale are set in damru/config.py; when TIMEZONE and LOCALE are left as None, they are inferred from the proxy exit at session start.
What are this agent's strengths and limitations?
- Zero JavaScript injection: spoofing lives in OS props, GPU binaries, syscalls and CDP, so pages show no Object.defineProperty or function .toString() traces.
- Ships 155 real Android device profiles, with default random selection restricted to 51 original plus 49 high-confidence profiles so fidelity and diversity stay controllable.
- Provides a pre-baked Docker image plus install-deps/install-image automation, avoiding native recompiles and Chrome installs on every run.
- Covers both automation surfaces: a Python library (AsyncDamru/Damru/DamruPool) and a broad CLI (preflight, force-profile, benchmark, screenshot, record).
- Documents reproducible benchmark evidence, including a third-party browsers-benchmark run at 10/10 targets plus per-site screenshots in the repository.
- Narrow host support: only Ubuntu 24.04 native or WSL2 with Damru's kernel, and binderfs must be enabled — Debian 13 was tested and failed on CONFIG_ANDROID_BINDERFS.
- Heavy resource floor: each Redroid worker defaults to 2 vCPU and 2 GB, one worker is best with 8 GB host RAM, and image baking needs roughly 35 GB of temporary disk.
- Self-described Beta: the README warns behaviour still depends on host kernel, Docker, ADB and Redroid, so multi-container stability varies by environment.
- No physical device support, and the MuMu Player path is labelled unfinished and non-functional, leaving Redroid as the only practical target.
- Licensed under PolyForm Noncommercial 1.0.0, so commercial adoption needs a separate arrangement; GitHub metadata reports the licence as NOASSERTION.
How does this agent compare with similar options?
The README names undetected-chromedriver as the closest alternative: it patches a desktop Chrome binary on x86, whereas Damru runs a full Android OS in Docker and spoofs at the OS, binary and CDP layers, covering GPU, TLS/JA3, device properties and network signals that desktop tools cannot reach. It also contrasts with JavaScript-injection tools such as puppeteer-stealth, which are detected through function .toString() and prototype-chain inspection, and notes that Camoufox and Fingerprinting Chromium did not reach the same stability once ported to mobile.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Damru — Android-Native Stealth Browser Automation This agent | 42 · Major gaps | CLIFree | ★ 342 | 3mo ago | Python | — |
| Lightpanda Browser | 66 · Some gaps | CLIFree | ★ 37k | 1d ago | Zig | OpenAI API · Claude API |
| Invisible Browser Agent | 57 · Major gaps | MCP serverFree + model costs | ★ 876 | 1d ago | Python | Codex · Claude Code |
| CloakBrowser Stealth Browser | 50 · Major gaps | Library / SDKFreemium | ★ 32k | 2d ago | Python | — |
How does FollowAgents rate this agent?
Why each dimension lost points
README explicitly requires root access, modifies build.prop, iptables, LD_PRELOAD injection, and binary patching—high-privilege operations—but offers no least-privilege design or user confirmation flow; data flows (proxy, ADB, CDP) are described but lack transparent logging or sensitive-data handling notes; dependencies have version ranges but no security audit; rollback is unmentioned; source attribution is clear in LICENSE and README, earning source_attribution a 2, while others score 1.
README self-describes as Beta, dependent on host kernel, Docker, ADB, and Redroid behavior, indicating environmental fragility; dependency ranges are broad (playwright>=1.40,<1.60) without pinning; failure messages appear in test scripts with retries and error prints, but framework-level systematic error handling is undocumented, so all items score 1.
README clearly defines target audience (developers, security researchers) and scenarios (scraping, QA, anti-bot research), and explicitly states no physical device support and MuMu as experimental, showing clear boundaries; however, trigger precision (e.g., auto device selection, proxy config) relies on implicit behavior not detailed in docs, so trigger_precision scores 1.
README is well-structured with install steps, quick start, FAQ, known limitations (Beta, physical device warning), and a clear license (PolyForm Noncommercial 1.0.0); but version is only 0.1.0, CHANGELOG link exists but content not provided, naming stability (e.g., CLI commands) is not promised, and maintenance responsibility points to a personal email, so several items score 1.
Project claims bypass of multiple anti-bot systems, but evidence is limited to README screenshots and self-assertions, lacking reproducible benchmark results or independent verification; output usability depends on environment setup, cost (Docker, Redroid, proxy) is high, and marginal value over existing tools (e.g., undetected-chromedriver) is not fully demonstrated, so all items score 1.
Performance claims in README (e.g., 100% bypass rate, CreepJS 85%+) lack traceable raw data or third-party reproduction; test scripts exist but no run results are provided; facts and inferences are mixed (e.g., 'world's first' marketing language), so all items score 1.
- The project requires root access and modifies system-level configurations (build.prop, iptables, LD_PRELOAD), which may cause irreversible effects on the host environment; use in an isolated environment is advised.
- Performance claims in README (e.g., 100% bypass rate) lack reproducible raw data or third-party verification and should be treated with caution.
- Dependency version ranges are broad and not pinned, potentially introducing incompatibilities or security risks.
- The project explicitly does not support physical devices, yet test scripts include a physical device serial number, posing a risk of misuse.
- License is PolyForm Noncommercial 1.0.0; commercial use requires separate licensing—comply with the terms.