FlutterGuard is an Android app that performs fully offline, no-root static security audits of Flutter APKs, mapping permissions, embedded SDKs, endpoints and potential secrets for authorized analysts.
| Tool | anasfik/FlutterGuard — offline on-device static security auditor for Flutter APKs on Android |
| Category | Mobile static analysis / APK auditing (Kotlin, Android 8.0+) |
| Primary Use | Triaging installed Flutter apps or APK files for manifest risks, secrets, endpoints and SDK inventory during authorized app assessments |
| Safe Use | Intended for authorized security assessments, app-vetting workflows, and your own or client-authorized applications; static findings are explicitly framed as leads, not proof of vulnerabilities |
| Telemetry Note | The tool declares no INTERNET permission, contains no accounts, ads or analytics, and produces only local reports; scans run in a foreground service visible to the user and in Android notifications |
Most tooling for auditing mobile applications assumes a desktop: pull the APK, unpack it, decompile DEX, wrestle with an AOT Dart snapshot and hope your Dart SDK matches the build. FlutterGuard, written in Kotlin and MIT-licensed from anasfik/FlutterGuard, inverts that assumption entirely. It is an Android application, targeting Android 8.0+ (API 26), that performs the audit on the phone itself — no root, no PC, and, notably, no network access at all, since the app ships without the INTERNET permission. For an authorized assessor who wants a fast triage of a Flutter application before deciding whether a heavier desktop toolchain is justified, this is a pragmatic first pass.
The motivation section of the README is unusually candid about why Flutter specifically deserves this treatment. Flutter apps bury their logic in libapp.so, debug builds can carry a 100 MB Dart kernel, and secrets scatter across assets, resources.arsc and native bridge libraries. FlutterGuard addresses this by parsing the formats that matter on-device: binary XML for the manifest, resources.arsc, DEX strings, the libapp.so string pool, kernel_blob.bin, NOTICES.Z, environment files and embedded X.509 blobs. The stated philosophy — findings are leads to investigate, not proof of a vulnerability — is repeated throughout the documentation and is the right epistemic framing for a static analyzer.
What the tool actually surfaces breaks into several coherent layers. The artifact pass recovers the package name, version, SDK range, ABIs, base APK hash, every native library with size and a SHA-256 prefix, installer provenance, signing scheme (v1/v2/v3/v4), signer DN, certificate fingerprints and debug-certificate detection. The Flutter-specific pass determines whether the target is genuinely Flutter, whether it is AOT or JIT, kernel_blob.bin size, the Dart engine version, obfuscation state, and a Dart package inventory recovered from NOTICES.Z and package: URIs. That engine fingerprint matters because desktop follow-ups like Blutter or reFlutter need the exact engine build to proceed.
The manifest risk layer covers the classic Android audit checklist: permissions, exported activities, services, receivers and providers, debuggable, backup flags, cleartext policy and the network security config — including the subtleties of base-config versus domain-config, loopback-only cleartext, user-CA trust, pin sets and debug-overrides. Deep links are aggregated per scheme, which is where a lot of real-world mobile findings live. The screenshots in the README show exactly this kind of output: an exported service, cleartext traffic and user-CA trust flagged in one findings list.
The secrets and endpoints pass is where FlutterGuard earns its keep for app-vetting workflows. It pattern-matches API keys for Google, AWS, Stripe, Supabase, Sentry, Firebase, OpenAI, GitHub, Slack, Sendgrid and Telegram, plus OAuth client IDs, JWT-like blobs, database and broker URIs with inline credentials, private key blocks with a real body, and .env/.env.prod files with credential counts. The corpus table in the README gives concrete grounding: one real app shipped a plaintext .env.prod with thirteen credentials; another shipped a 113 MB JIT kernel with a debug certificate on a debug build. Hosts are classified as first-party, staging, internal, saas:X or ip-literal, and API routes are recovered from the Dart snapshot.
The third-party fingerprint table is the most ambitious component, covering roughly 135 services matched by zip path, DEX descriptor, pub package or host. Beyond the expected Firebase, Play Services, billing, ads and attribution entries, it inventories auth providers (Auth0, Clerk, Appwrite, Stytch, WorkOS), realtime SDKs (Agora, LiveKit, Stream, Sendbird), payments (Stripe, RevenueCat, PayPal, Paddle) and backends (PocketBase, Nhost, Supabase). LLM providers are itemized individually — OpenAI, Anthropic, Gemini, Groq, Mistral, Cohere, DeepSeek, OpenRouter, xAI and more — and on-device runtimes are signalled by well-known localhost ports such as localhost:11434 (Ollama) and localhost:1234 (LM Studio). The README notes this pass often surfaces ad, analytics and crash SDKs the user never suspected, which is arguably the most report-worthy output for a privacy review.
Version diffing is treated as a first-class feature rather than an afterthought. Every scan is stamped and retained, and a <package>.hist snapshot written next to each report powers a change card listing added and removed hosts, routes, dependencies and findings. The README's argument — that the diff between two versions of the same app is where the real findings live — is sound tradecraft; a new endpoint or a newly embedded credential appearing between releases is a far stronger signal than any single static snapshot. Bulk work is supported through Advanced → Scan all Flutter apps, a queued mode with per-app live progress, a per-app timeout, and confirmation dialogs stating the cost.
The grading model is deliberately modest: A clean, C well-built with hardening gaps, F for something fundamental such as a shipped debug build, debug certificate, pervasive cleartext or embedded credentials. The README explicitly calls it a triage label, not a score, and tells you to read the findings rather than the letter. That restraint is welcome — a finding-level view with masked evidence by default, an explicit Reveal action per row, and exports that keep sensitive values masked unless you opt in, all show a privacy-conscious design applied to the tool's own outputs.
The consent model is equally deliberate. On first run you choose whether to enable installed-app inventory; declining still leaves Scan an APK file available, and consent can be withdrawn in Settings. The headless entry point refuses to scan without prior consent rather than bypassing the disclosure — a design decision worth respecting, since it means scripted use cannot quietly paper over the privacy disclosure. Reports live in internal storage and are pulled from debug builds via run-as; release builds are not debuggable, so extraction requires a debug build. Installation is straightforward: the signed FlutterGuard-<version>.apk from GitHub releases, or the Google Play listing where available — noting that Play serves builds signed with Google's key, so switching distribution channels requires an uninstall that deletes local report history.
An interesting bonus for assessor workflows is skill/SKILL.md, which packages FlutterGuard as an audit skill for coding agents such as Claude Code, Codex and OpenClaw, describing when to run repeatable version-diff scans and when to escalate to a desktop toolchain for decompilation, AAB inspection, or real signature verification. The repo topics confirm this agent orientation (claude-code-skill, codex-skill, openclaw-skill) alongside conventional tags like apk-security, flutter-security and static-analysis. Every detector rule is documented as originating from a manual finding in CORPUS.md, drawn from eleven real Flutter apps plus one non-Flutter negative control (Primal, correctly identified as not Flutter) — an evidentiary approach that gives the rule set traceable provenance rather than speculative coverage.
At 31 stars, FlutterGuard is a young project, but the README's engineering discipline — bounded and atomic history, provenance-aware artifact previews, capped render windows, staged pipeline visibility — suggests a maintainer thinking carefully about operational reality. Its main limitation is inherent to the approach: static, on-device analysis of a compiled artifact will not substitute for dynamic testing, deobfuscation of AOT snapshots, or proper cryptographic verification. As a fast, private, offline triage layer for authorized mobile assessments and privacy reviews, however, it occupies a genuinely useful niche that desktop-heavy workflows have left open.
anasfik/FlutterGuard.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.