MobSF: static and dynamic analysis for Android, iOS and Windows apps

What MobSF actually does for a mobile app assessment

MobSF is a security research platform for mobile applications on Android, iOS and Windows Mobile. The README lists its use cases as mobile application security, penetration testing, malware analysis and privacy analysis. That combination is the point: most mobile tooling picks one of those jobs. A decompiler shows you code, a proxy shows you traffic, a manifest linter shows you exported components. MobSF runs all of them from one upload and writes the results into a single report.

The intended user is a security engineer or pen tester who receives a binary and has to produce findings. It is not a developer-facing linter. The Static Analyzer accepts APK, IPA, APPX and source code, so the same interface works whether you were handed a release build or a repository. The Dynamic Analyzer supports Android and iOS and is described as a platform for interactive instrumented testing, runtime data and network traffic analysis. Instrumentation is done with Frida, which appears in the dependency list as frida and frida-tools.

The project is explicit about CI use. The README says MobSF integrates with a DevSecOps or CI/CD pipeline through REST APIs and CLI tools. That matters because it changes what you are evaluating: not just a web UI, but an HTTP surface you can call from a pipeline. The package also ships a console entry point named mobsf, declared in pyproject.toml under [tool.poetry.scripts].

Architecture: a Django service, a scanner library and a Frida bridge

The repository layout tells you most of the story. There is manage.py at the top level, which is the standard Django entry point, and the application code lives under mobsf/. Dependencies in pyproject.toml include django, gunicorn for non-Windows platforms and waitress for Windows, whitenoise for static file serving, and sqlite3 in the Docker image's apt list. So the default deployment is a single Django process serving an HTML UI and a REST API, backed by SQLite, with the analysis work happening in the same process or in subprocesses it spawns.

Static analysis is delegated to libraries rather than written from scratch. libsast handles pattern-based source scanning, apkid identifies packers and protectors, apksigtool and arpy deal with APK structures and signing, macholib and openstep-parser cover Mach-O and iOS property lists, and asn1crypto handles certificate parsing. PDF report generation goes through pdfkit, which in the Dockerfile pulls in wkhtmltopdf and a set of font packages. That is a real constraint: the container is not small, and the report path depends on a headless renderer.

Dynamic analysis is the part with the hardest environment requirements. The Dockerfile sets MOBSF_ADB_BINARY=/usr/bin/adb and installs android-tools-adb, and it pins JAVA_HOME=/jdk-22.0.2. Frida is a runtime instrumentation toolkit, so the analysed app has to run somewhere MobSF can reach it, which means an emulator or a physical device attached over ADB. The README does not document a fallback for dynamic analysis without a device, and it does not document rollback behaviour for the environment it configures. Treat the dynamic path as a lab setup, not a feature you switch on.

Installing MobSF with Docker and running a first APK scan

The README gives Docker as the quick setup path. The two commands below pull the image and start it on port 8000, and the README states the default username and password are mobsf/mobsf. Run the second command and open http://localhost:8000 in a browser.

docker pull opensecurity/mobile-security-framework-mobsf:latest
docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

# Default username and password: mobsf/mobsf

The --rm flag means the container's writable layer is discarded on exit, including the SQLite database that holds scan history. If you want results to survive a restart, that is the first thing to change, and the README's quick setup does not address it. The image also declares DJANGO_SUPERUSER_USERNAME and DJANGO_SUPERUSER_PASSWORD as environment variables both set to mobsf, so the credentials are visible in the Dockerfile and should be overridden before the service is reachable from anywhere but your own machine.

For a non-Docker install the material points elsewhere rather than giving steps. The README links the documentation at mobsf.github.io/docs, and pyproject.toml declares python = "^3.12" with a Poetry package definition. A typical Poetry-based flow would install the declared dependencies and then start the Django application through manage.py, but the README does not spell out that sequence, so follow the linked documentation rather than guessing at flags.

poetry install
python manage.py runserver

Once the service is up, the first real use is an upload. In the web UI you select the Static Analyzer, choose an APK file, and submit it. What you should see is a report page with sections for the manifest, permissions, certificate and signing information, the app's components, and code-level findings produced by the pattern scanner. On the command line the project installs a mobsf entry point, declared as mobsf = "mobsf.__main__:main" in pyproject.toml, which is the hook the README refers to when it mentions CLI tools for pipelines.

Where MobSF is the wrong tool

The first limitation is environmental. Dynamic analysis needs a running Android or iOS target that MobSF can instrument through Frida. If your CI runners are ephemeral containers with no emulator and no attached device, the dynamic half of the product is unavailable to you, and you are evaluating a static scanner with a large dependency tree. The Dockerfile installs ADB and a JDK, which tells you the maintainers expect that machinery to be present, but presence is not the same as a working device bridge.

The second is scope. MobSF analyses a binary you give it. It does not watch an app in production, does not intercept traffic from an already-installed app unless you drive the dynamic environment, and does not replace a human reviewing business logic. Findings from a pattern scanner are candidates, not conclusions. A decompiled string that looks like a hardcoded key may be a test fixture, and a permission that looks excessive may be required by a platform API. Nothing in the tool resolves that for you.

The third is operational weight. The image carries a JDK, Android build tools, ADB, wkhtmltopdf and font packages, and the Python dependency list includes Frida, apkid, libsast and several parsers. That is a lot of surface to keep patched on a host that also accepts untrusted binaries. If your requirement is a fast check inside a build step, this is the wrong shape of tool. The README itself points to mobsfscan for CI/CD, which is a separate, lighter project from the same organisation.

MobSF compared with mobsfscan and with manual tooling

The README names mobsfscan under the heading MobSF in CI/CD. The difference in approach is architectural. mobsfscan is a source-code scanner meant to be invoked from a pipeline; MobSF is a service that hosts a web UI, stores results in a database, and runs both static and dynamic analysis on binaries. If your question is whether a pull request introduced a risky API call, mobsfscan answers it inside the build. If your question is what a shipped APK actually contains and how it behaves at runtime, MobSF is the one that can answer, and mobsfscan cannot.

The other alternative is assembling the toolchain yourself: apktool or a decompiler for the APK, apksigner for the certificate, a manifest reader, a proxy for traffic, and Frida scripts for instrumentation. That gives you full control and no GPL obligations on your own code, and it produces exactly the evidence you asked for and nothing else. The cost is that every analyst rebuilds the same pipeline, and results are not comparable between people. MobSF's value is standardisation: the same upload produces the same report structure, which is what makes it usable as a gate. The trade is that you inherit its dependency tree and its opinions about what counts as a finding.

Licence, releases and the cost of staying current

MobSF is licensed GPL-3.0-only, stated in pyproject.toml and shown in the README badge. This is a copyleft licence. If you modify MobSF and distribute it, or distribute a product that incorporates it, the GPL's terms apply to that distribution. Running the unmodified Docker image as a service inside your own organisation is a different situation from shipping MobSF inside a commercial appliance, and the difference is worth a conversation with someone qualified to have it. This is not legal advice.

The dependency list is broad and includes Frida, which tracks platform internals, plus Android build tooling and a headless PDF renderer. That means upgrades are not purely a matter of pulling a new tag. Release cadence visible in the repository is roughly monthly for patch versions, with v4.5.2 on 2026-08-10, v4.5.1 on 2026-07-06 and v4.4.6 on 2026-03-21. The last push to the default branch was on 2026-09-09, so the project is being worked on, but you should still pin a specific tag rather than tracking latest, because the image bundles a JDK and Android tools whose versions move with the base image.

Maintenance cost lands in two places. First, the host: a service that accepts untrusted APK and IPA files needs isolation, and the README does not describe a sandboxing model. Second, the dynamic lab: emulator images, Frida versions and the analysed app's own anti-instrumentation defences all drift, and each drift is a debugging session. Budget for that before promising runtime analysis to a stakeholder.

Editorial conclusion

Adopt MobSF if you need one tool that produces static findings for APK, IPA and APPX plus a runtime environment for Android and iOS, and you can give it a host with enough memory and, for dynamic work, an emulator or device. Do not adopt it if you only want a lightweight source scanner inside a build step, because mobsfscan from the same project covers that case with far less machinery, or if you cannot run the Docker image or a Python 3.12 environment. Before rolling it out, confirm the exact container tag you intend to pin, the default credentials are changed, and that your team accepts GPL-3.0-only obligations for anything it is bundled into.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. MobSF/Mobile-Security-Framework-MobSF on GitHub
3. Project website
4. README
5. Releases