A lightweight, browser-based Android forensic triage and Termux command-line training environment

Online Lab: https://go.certinstructor.org/sim/termux/

1. What Is This Simulator?

The Termux Android Forensics Simulator is a lightweight, browser-based training environment designed to introduce learners to Android command-line investigation and basic mobile forensic triage without requiring a physical Android device, root access, or a complex forensic laboratory.

The simulator recreates a Termux-style terminal running inside an Android environment and provides a collection of simulated Linux and Android commands.

Instead of simply teaching commands such as ls, cat, or grep, the lab uses those commands in a forensic investigation context.

You can:

• Explore a simulated Android/Termux filesystem

• Inspect applications and package information

• Examine permissions and Android services

• Identify suspicious applications

• Investigate possible spyware indicators

• Examine simulated DNS and process artifacts

• Search for Indicators of Compromise (IOCs)

• Perform a lightweight MVT-style IOC scan

• Practice evidence acquisition concepts

• Understand the limitations of a non-root Termux environment

The environment is intentionally designed as a training and simulation platform. The evidence, applications, processes, domains, and forensic findings are simulated and should not be interpreted as evidence from a real device.

2. The Main Objective

The goal is not to turn Termux into a full mobile forensic toolkit.

Instead, the lab teaches an important practical concept:

What can an investigator discover from an Android device using only a lightweight, non-root command-line environment?

This distinction is important because Android applications normally operate inside a security sandbox.

A normal Termux session does not automatically have unrestricted access to:

• Other applications' private data

• System logs

• Other applications' processes

• Protected Android databases

• /data/app

• Root-only system information

Therefore, the simulator deliberately demonstrates both:

What you can investigate

and

What requires ADB, root, or a proper forensic acquisition.

This makes the lab useful for understanding Android forensic triage rather than simply memorizing commands.

3. Getting Started

Open:

https://go.certinstructor.org/sim/termux/

The interface contains two main areas:

Terminal

The terminal behaves like a simplified Termux shell.

You can type commands directly into the terminal and press Enter.

The simulator also supports:

• Command history

• TAB completion

• Up/down arrow history navigation

• Pipes (|)

• Output redirection (> and >>)

• Basic environment variables

• A Termux-style extra-key bar

Investigation Guide

The guide contains two learning tracks:

1. Termux Basics

2. Android Forensics

The Android Forensics track is the primary investigation path.

Each lesson provides:

• An investigation objective

• Commands to execute

• Hints

• Evidence to look for

• Progress tracking

• Completion flags

4. Start With Basic Termux Commands

Before investigating Android artifacts, it is useful to understand the environment.

Try:

whoami

This shows the current Termux user.

Then:

pwd

This displays the current working directory.

You can also inspect the underlying simulated Android/Linux environment:

uname -a

You should see information including:

• Linux

• Android

• ARM64 (aarch64)

• The simulated kernel version

These commands establish an important forensic principle:

You are operating as an unprivileged application user, not as root.

5. Understand the Termux Filesystem

Termux uses its own filesystem structure inside the Android application sandbox.

Check the home directory:

echo $HOME

You will see a path similar to:

/data/data/com.termux/files/home

Then check the Termux installation prefix:

echo $PREFIX

The simulator uses:

/data/data/com.termux/files/usr

You can inspect installed command binaries with:

ls $PREFIX/bin

This demonstrates an important difference between a traditional Linux server and Termux.

Termux operates inside an Android application environment rather than behaving like a conventional root-access Linux server.

6. Basic File Investigation

The simulator includes a small filesystem that can be manipulated just like a command-line environment.

For example:

mkdir case
cd case

Create a file:

echo "forensic test" > note.txt

Read it:

cat note.txt

Search its contents:

grep forensic note.txt

Other useful commands include:

ls
ls -l
tree
head
tail
wc
find

These commands are simple, but they form the foundation of command-line forensic work.

7. Android Forensics Track

The main purpose of the simulator is the Android Forensics track.

The investigation follows a simplified mobile incident-response scenario.

The simulated case involves a phone exhibiting suspicious behavior such as:

• Unexpected battery drain

• Suspicious banking-related pop-ups

• Unknown applications

• Excessive permissions

• Hidden services

• Possible spyware activity

• Suspicious network indicators

The investigation progresses from initial inventory → application inspection → evidence collection → IOC analysis.

8. Step 1 — Inventory Installed Applications

Start by identifying third-party applications:

pm list packages -3

The -3 option is useful during triage because it focuses on third-party applications rather than the large number of built-in Android packages.

Next, inspect installation sources:

pm list packages -i

Look for applications whose installation source does not match the expected source.

For example, an application that looks like a system component but has an unexpected or missing installer can deserve additional investigation.

What are we looking for?

Not every sideloaded application is malicious.

Instead, the investigator is looking for anomalies that justify deeper examination.

This is a recurring principle throughout the lab:

An unusual artifact is an investigation lead, not automatically proof of compromise.

9. Step 2 — Inspect Suspicious Application Permissions

Once a suspicious package has been identified, inspect it with:

dumpsys package <package-name>

For example:

dumpsys package com.google.android.system.update

Review the requested permissions.

Particular combinations can be interesting during forensic triage, such as:

READ_SMS
RECEIVE_SMS
SYSTEM_ALERT_WINDOW
RECEIVE_BOOT_COMPLETED
BIND_ACCESSIBILITY_SERVICE

The important point is not that one permission automatically proves malware.

Instead, investigators should ask:

• Why does this application need the permission?

• Does the application function justify it?

• Does its name match its actual behavior?

• Was it installed from a trusted source?

• Are multiple sensitive capabilities combined?

This is how permission analysis becomes a forensic investigation rather than a simple checklist.

10. Step 3 — Check Accessibility Services

Accessibility services deserve particular attention because legitimate accessibility functionality can interact deeply with the Android user interface.

The simulator provides:

settings get secure enabled_accessibility_services

This can reveal enabled accessibility services.

During an investigation, an unexpected service associated with a suspicious application can become an important lead.

Again, context matters.

Accessibility services have legitimate uses, so the presence of one is not by itself evidence of malware.

11. Step 4 — Investigate Device Administrators

Some forms of spyware attempt to make removal more difficult by registering themselves as device administrators.

The simulator provides:

dumpsys device_policy

Review the active administrators.

A suspicious application appearing as an active device administrator deserves further investigation because device-admin privileges can provide additional control over the device.

On a real Android device, an investigator can also examine the corresponding settings through the Android security/device-administration interface.

12. Step 5 — Check for Unexpected Root Access

Check whether the su binary is present:

which su

If the device owner did not intentionally root the device, the unexpected presence of a root-management mechanism can be an important forensic indicator.

However, this must also be interpreted carefully.

A rooted device is not automatically a compromised device.

The investigator should establish:

• Whether rooting was intentional

• Which rooting framework was used

• When rooting occurred

• Which applications have elevated privileges

• Whether there are additional indicators of compromise

13. Step 6 — Locate an Application APK

The package manager can provide the APK location:

pm path com.google.android.system.update

This is useful because identifying the actual application file allows investigators to move from metadata analysis to file-based analysis.

However, there is an important limitation.

A normal Termux application generally cannot simply read another application's protected private data.

For actual acquisition, the investigation may require:

• A PC with Android Debug Bridge (ADB)

• Appropriate device authorization

• Root access

• Or a dedicated forensic acquisition method

14. Step 7 — Simulated ADB Acquisition

The simulator includes an educational representation of the ADB workflow.

For example:

adb devices

Then:

adb pull com.google.android.system.update

The simulator clearly marks this operation as requiring a PC/ADB or a rooted device.

The purpose is to demonstrate the forensic workflow, not to pretend that a browser-based Termux session can bypass Android's security model.

Once an APK has been acquired in a real investigation, investigators can perform additional analysis such as:

SHA-256 hashing
Static analysis
Permission analysis
Reverse engineering
Malware sandbox analysis
Threat-intelligence comparison

15. Step 8 — Investigate IOC Evidence

More sophisticated spyware may not appear as an obvious suspicious application.

This is particularly important when investigating advanced spyware.

Instead of relying only on application inventory, investigators can look for Indicators of Compromise (IOCs).

The simulator provides a small evidence directory:

cd ~/case

List the evidence:

ls

You will find simulated artifacts such as:

dns_log.txt
processes.txt
iocs.txt

Inspect the IOC list:

cat iocs.txt

The indicators are categorized into areas such as:

[domains]
[processes]
[files]

This demonstrates how forensic tools can compare collected artifacts against known indicators.

16. Step 9 — Search Network Evidence

Inspect the simulated DNS log:

cat dns_log.txt

You can search for a specific indicator:

grep secure-linkediin dns_log.txt

A match means that the simulated evidence contains the specified IOC.

In a real investigation, a matching domain would require additional validation.

Investigators would normally ask:

• When did the connection occur?

• Which application generated it?

• Is the domain genuinely malicious?

• Is the domain still active?

• Does the IOC belong to a known malware family?

• Are there other correlated indicators?

A single IOC should normally be treated as a lead requiring validation, not as the complete conclusion.

17. Step 10 — Run an MVT-Style IOC Scan

The simulator includes a lightweight MVT-style command:

mvt-android check-iocs ~/case

The simulator checks the exported evidence against the IOC list.

It can identify simulated indicators in:

• Network/DNS artifacts

• Process artifacts

For example, the simulator may report:

WARNING Detected a known malicious network indicator
WARNING Detected a known malicious process indicator

The exercise demonstrates the basic concept behind IOC-based mobile forensic analysis:

Collected artifacts → IOC database → automated matching → investigation/escalation

The simulator references the Mobile Verification Toolkit (MVT) concept, but the browser implementation is a simplified educational simulation rather than the full forensic toolkit.

18. What Can You Actually Detect?

The lab is designed to teach several categories of suspicious behavior.

Suspicious application installation

pm list packages -3
pm list packages -i

Look for:

• Unexpected third-party packages

• Sideloaded applications

• Applications pretending to be system components

Suspicious permissions

dumpsys package <package>

Look for combinations involving:

• SMS

• Contacts

• Location

• Microphone

• Accessibility

• Overlay windows

• Boot persistence

Accessibility abuse

settings get secure enabled_accessibility_services

Look for unexpected services.

Device administrator abuse

dumpsys device_policy

Look for unexpected active administrators.

Root indicators

which su

Look for unexpected root capability.

Network IOCs

cat dns_log.txt
grep <indicator> dns_log.txt

Look for known suspicious domains.

Process IOCs

cat processes.txt

Look for processes matching known indicators.

Automated IOC detection

mvt-android check-iocs ~/case

Use automated matching to accelerate triage.

19. Important Limitation: Non-Root Android

One of the most important lessons in this simulator is understanding what cannot normally be seen from an unprivileged Termux session.

For example:

ps

does not provide unrestricted visibility into every Android process.

Similarly:

logcat

cannot normally provide unrestricted access to other applications' logs.

And:

appops

requires privileges that an ordinary Termux application does not possess.

This is intentional.

The simulator teaches the difference between:

Application-level triage

and

Full forensic acquisition.

20. Suggested Investigation Workflow

A simple workflow for the lab is:

1. Establish the environment
        ↓
2. Inventory installed applications
        ↓
3. Check installation sources
        ↓
4. Identify suspicious packages
        ↓
5. Inspect permissions and services
        ↓
6. Check accessibility/device-admin status
        ↓
7. Check for unexpected root
        ↓
8. Locate suspicious APKs
        ↓
9. Acquire evidence using ADB/root when required
        ↓
10. Examine network/process artifacts
        ↓
11. Search for IOCs
        ↓
12. Run automated IOC matching
        ↓
13. Escalate to full forensic analysis

This workflow mirrors the general logic of real-world incident response:

Identify → Collect → Examine → Correlate → Validate → Escalate

21. Recommended Commands to Try

If you want to explore the simulator without following the lessons strictly, start with these commands:

whoami
pwd
uname -a
echo $HOME
echo $PREFIX
ls
tree

Then explore Android:

pm list packages -3
pm list packages -i
dumpsys package com.google.android.system.update
settings get secure enabled_accessibility_services
dumpsys device_policy
which su

Then investigate the evidence:

cd ~/case
ls
cat iocs.txt
cat dns_log.txt
cat processes.txt
grep secure-linkediin dns_log.txt
mvt-android check-iocs ~/case

Finally, explore the acquisition concept:

pm path com.google.android.system.update
adb devices
adb pull com.google.android.system.update

22. Training Philosophy

This simulator is intentionally lightweight.

It does not attempt to replace:

• Cellebrite

• Magnet AXIOM

• Oxygen Forensic Detective

• Android Debug Bridge

• Amnesty International's MVT

• Full disk/file-system acquisition

• Malware reverse engineering

Instead, it provides a hands-on starting point.

The learner can experiment with commands, make mistakes, inspect simulated evidence, and understand the reasoning behind a mobile forensic investigation without needing a dedicated Android forensic workstation.

Most importantly, the lab teaches a practical mindset:

Don't just run commands. Ask what the output means, why it is suspicious, what alternative explanations exist, and what evidence should be collected next.

Start the Lab

Termux Android Forensics Simulator

https://go.certinstructor.org/sim/termux/

Open the simulator, select Android Forensics, and begin with Take Inventory.

The objective is not simply to find the “malware.”

The objective is to learn how an investigator moves from an unusual observation to a defensible forensic finding.