mavs - Mobile Application Vulnerability Scanner

项目说明

<p align="center">
<img width="459" alt="notify" src="

<h4 align="center">Mobile Application Scanner</h4>
<p align="center">
<a href="
<img src="
</a>
</p>

mavs.sh

This tool performs static analysis on Android APKs and XAPK containers.
What makes this tool different from all the other tools that do this? My goal with this project is to actually exploit things.
Often you find static analysis tools point to things and say ! and the user is left to figure out why. Or worst its a
false positive.

MAVS now runs a single Python engine that covers the same static-analysis ground as
MobSF for Android, while
keeping what makes this tool different: exploitation and guidance for
every finding, and deep Xamarin/.NET embedded-key detection. It is CLI-first so AI
and automation can drive it, with an optional zero-dependency web dashboard.

- -v = Show me why you think its broken (e + how to ), useful for fixing and reporting.
- -e exploit = Show me how to exploit this so called broken thing, or how to manually confirm it. Commands are cut-and-paste ready.
- -j json = Machine-readable report for AI tools and pipelines.

<p align="center">
<a href="demo/ma.png">
<img src="demo/mavs.gif" alt="MA an APK: risk score, A-F grade, findings, and copy-paste exploit guidance" width="900">
</a>
<br>
<em><a href="demo/ma.png">Click for the full report</a> — a still you can read at your own pace.</em>
</p>

Required Dependencies

Only uv and Python 3.12+.
No apktool, dex2jar, apkinfo, or Java are needed. The engine parses the APK in
process. Runtime Python dependencies are intentionally minimal and pinned in uv.lock:

The first run creates a local .venv from the lockfile.

Usage mavs.sh

Equi Python entry points (what mavs.sh calls):

Web interface

-w (or ma serve) starts a local dashboard using only the Python standard
library. It binds to 127.0.0.1 by default, renders the report worst-first with
e and exploit guidance, and lets you upload another APK/XAPK to scan. Files
stay on the host and uploads are size limited.

Current Security Checks

The engine reports findings across these categories, each with a se, CWE,
OWASP MAS, e, and /exploitation guidance. A 0-100 risk
score and A-F grade summarize the result.

Manifest — debuggable build, backups allowed, cleartext traffic (calibrated to
target SDK), screenshot/snapshot exposure (FLAG_SECURE / excludeFromRecents), low
minimum SDK, and exported acti/services/receivers/pro without a permission.

Certificate — signing (Janus, C) and weak signature
algorithms (MD5/SHA-1), parsed from v1 and v2/v3 signing blocks.

Permissions — dangerous requested permissions mapped to concrete risk.

Code (over the DEX string pool) — disabled hostname , trust-all
TrustManager, canAuthenticateAgainstProtectionSpace, WebView Ja / native
bridge / broad file access / ignored SSL errors, weak crypto (ECB, DES, RC4),
weak hashes, insecure Random, world-readable/writable storage, external storage,
logging, runtime exec, dynamic code loading, raw SQL, clipboard, root-detection,
AndroidKeyStore and certificate-pinning usage.

Network — network security config cleartext permits and user-CA trust, hardcoded
http:// URLs, Firebase endpoints, and extracted URLs/emails for recon.

Nati — ELF hardening for bundled .so libraries (executable stack,
PIE, RELRO, stack canary) plus outdated library banners (e.g. libpng).

Trackers — bundled analytics/ad SDKs detected from class descriptors.

Secrets — bundled key/certificate files (.pem, .p12, .jks, …) and embedded
private keys, AWS/Google/Stripe/Slack/GitHub credential patterns. are reported
by type and location, not printed.

Framework — Flutter, Xamarin/.NET, React Nati, Unity, Capacitor, with
framework-specific interception guidance and a manual de checklist.

Managed keys — MA embedded Xamarin/.NET credential constants (below).

Managed authentication-key inspection

MA detects embedded credentials in Xamarin/.NET Android code. It
recognizes direct static strings and compiler-emitted R initializers
(8–512 bytes), requires a
credential-like field name and a direct field read, and reports the assembly,
type, field, consuming methods, byte length and SHA-256 fingerprint. Raw constant
are redacted. String lengths and fingerprints use UTF-8 bytes with lone
surrogates preserved. Authentication/cryptography-related method names increase
confidence; findings still require manual review.

Install uv and use Python
3.12 or later. Dependencies are pinned in uv.lock; the first run creates a local
.venv. Keys-only mode works independently of the legacy Android tools:

A normal ./mavs.sh -f app.apk runs this managed-key check as one analyzer inside the
full scan; -k runs it alone in the original fast keys-only mode. -F skips it when
you want a quick pass over the other checks (it is the slowest stage on Xamarin apps).
Exit status 0 means the supported patterns were inspected, including when findings
exist; status 2 means some co was incomplete or the input was invalid.
Automation should inspect findings and co in the JSON report.

Supported containers: ordinary embedded DLLs, Xamarin v1 XABA assembly stores,
XALZ/LZ4 compressed assemblies, and APKs nested one le an XAPK. Parsing
happens in memory without executing APK code or extracting archi. Input,
entry count, member and aggregate payload-byte limits reject o archives.
These are not CPU or peak-memory sandbox limits: ZIP and managed metadata incur
additional parser allocations.
Unsupported layouts and malformed inputs produce explicit co results.

Limitations: this is a heuristic managed-code check, not whole-app data flow or
an exploit test. Ja DEX, native code, modern native MAUI stores,
obfuscated identifiers, computed or runtime-pro secrets, inlined const
strings, zero-initialized buffers, and local- keys are outside this rule. A scanned assembly can
still contain unsupported initialization patterns. No findings does not mean
an application is secure. A fingerprint match establishes identical bytes,
not that credentials work against a device.

tests/test_scan_engine.py covers the static engine with crafted synthetic inputs
only (in-memory DEX, ELF, ZIP, APK signing blocks, and certificates). It exercises
each analyzer, the manifest se calibrations, the v1/v2/v3 certificate
extraction, framework and secret detection, nati hardening, the full
engine.scan orchestration, the text reporter, and the web dashboard routes. The
managed-key tests package a compiled fixture with fabricated constants into APK,
XABA, XALZ and XAPK containers and check findings, benign/runtime-generated
exclusions, redaction, invalid inputs, and archi. Fixture source and
regeneration instructions are in tests/fixtures/. Real application binaries and
secret are intentionally excluded from the repository.

To run the end-to-end scans that need a real binary manifest, point MA
at your separately obtained samples. test_scan_integration.py runs a full
engine.scan and asserts the expected findings, signing schemes, and XAPK handling;
test_karr_samples.py checks the managed-key detection in depth:

It 170 scanned assemblies per input, exactly two 16-byte fields in
GridtraqPL.Objects.Units.QTAuth, GenerateHash usage, and matching fingerprints
across and containers. It also checks the separate medium-confidence
Syncfusion licensing XOR-key candidate and rejects public PKCS#12 di.
The four package scans run concurrently. This optional test is skipped when the sample
directory is unset. It does not download, install or execute the applications.

项目信息

开发语言：Python

Star 数：26

技术要点

该项目属于安全软件方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Mobile Application Vulnerability Scanner展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。