zalexdev/strykerapp

What It Is

StrykerOSS is a free, open-source mobile penetration-testing suite for Android, intended for authorized security testing only. It bundles network, wireless and web security tools behind one UI and runs a Debian trixie arm64 chroot under /data/local/stryker/release, so heavyweight tools such as Nmap, Metasploit, Nuclei, Hydra and SearchSploit execute natively on the phone. A built-in terminal opens straight into that chroot, so no separate shell app is needed. The app is version 6.0, package com.zalexdev.stryker, targeting SDK 28 with a minimum of SDK 24.

Modules cover LAN discovery and port scanning, Nmap with NSE scripts, Nuclei web scanning, Metasploit console and payload generation, handshake capture and Hashcat cracking, a MAC changer, BLE Fast Pair analysis, DuckyScript-compatible USB HID injection, USB-gadget profiles, an OpenStreetMap view of captured BSSIDs, and an in-chroot VNC desktop. A custom "Arsenal" database lets you store exploits and scanners with {IP}, {PORT}, {MAC}, {GW} and {MASK} placeholders.

It is aimed at security testers and researchers who want a portable toolkit and already understand the underlying tools; it is not a guided beginner scanner.

Requirements and Setup

You need a rooted Android device (Magisk or KernelSU recommended), about 1 GB of free internal storage, and, for Wi-Fi attacks such as handshake capture and deauthentication, an external monitor-mode USB adapter (Atheros AR9271 or Realtek 88XXAU recommended). HID Attacks and USB Arsenal additionally require a gadget-capable kernel with the relevant CONFIG_USB_CONFIGFS* options, kernel 3.19 or newer, and a populated /sys/class/udc/.

For end users the documented flow is: install the APK on the rooted device (adb install StrykerOSS-6.0.apk or sideload), launch it once, and let the in-app installer request su and runtime permissions, download and unpack the Debian trixie arm64 chroot core, mount it at /data/local/stryker/release, and install optional components. After that, open the drawer and choose Terminal for a shell inside the chroot, then connect a supported USB Wi-Fi adapter if you need monitor mode. Project downloads and updates are published through the project site and Telegram channel.

Build from Source

The repository uses a standard Android Gradle build with Java 8 sources, ndk-build for native code and R8 minification for release:

# Debug APK
./gradlew assembleDebug

# Release APK (minified + R8)
./gradlew assembleRelease

# Install on a connected device
./gradlew installDebug

APKs are written to app/build/outputs/apk/. Release signing uses STRYKER_RELEASE_STORE_FILE, STRYKER_RELEASE_STORE_PASSWORD, STRYKER_RELEASE_KEY_ALIAS and STRYKER_RELEASE_KEY_PASSWORD in ~/.gradle/gradle.properties or via -P/environment. Without them, the release APK is left unsigned.

Constraints

Root is mandatory for the core chroot workflow, so the app does not run as a normal unprivileged Android application. Wireless features depend on specific external adapters and kernel driver support, and USB gadget features depend on kernel configuration. The project keeps targetSdk = 28; contributors are told to stay on that unless they are ready to migrate all storage and permission paths. The app is GPL-3.0, while bundled third-party components (terminal emulator, Xorg/SDL, wordlists, PoCs and others) keep their own GPLv3-compatible licenses, documented in THIRD-PARTY-NOTICES.md and the in-app licenses screen. All use must be limited to systems you own or have explicit permission to test.

HotRepo's take

StrykerOSS appears once in HotRepo's records, on the 2026-11-10 Java daily list at position 9, with 2,026 stars and 302 forks and a gain of 5 stars that day. That single snapshot places it among the upper ranks of the Java daily list but does not show a sustained trend, so it should be read as one day's placement rather than evidence of broad adoption. The more concrete signal is scope: the README documents a real Android application with a chroot installer, module layout and build/signing instructions, and the requirements around root, monitor-mode adapters and kernel configs sharply limit who can actually use it.