Artifact reference

What each file in a Bugbane acquisition contains, and why it matters forensically. Written for analysts opening a decrypted export; the layout is the same as an AndroidQF acquisition. Valid for Bugbane 0.2.3.

Each entry answers two questions, in the spirit of the SocialTIC forensics dictionaries: what is in this file? and why is it useful? Keep in mind that most of these files contain personal data.

Acquisition metadata #

acquisition.json

What: UUID, start/end timestamps, producing app and version (androidqf_version: "Bugbane-<version>"), device info, status, and the list of failed or skipped modules. Why: the first file to read — it tells you whether the acquisition is complete and which artifacts you should not expect. Its UUID and timestamps support your case documentation.

hashes.csv

What: SHA-256 of every artifact in the archive, one per line. Why: integrity and chain of custody: verify the hashes before analysis, cite them in reports.

adb_host_key.pub

What: the public ADB key of the Bugbane installation that made the acquisition. Why: Bugbane acquires through the device’s own Wireless Debugging, so this key legitimately appears among the device’s authorized ADB keys. Any other unknown ADB key deserves attention.

Device configuration #

getprop.txt

What: all Android system properties: model, build fingerprint, security patch level, radio, locale, boot parameters. Why: establishes exactly what device and OS version you are looking at — and MVT reads the device timezone from here. Some spyware alters or leaves traces in properties.

settings_system.txt, settings_secure.txt, settings_global.txt

What: the three Android settings namespaces, as cmd settings list prints them. Why: shows accessibility services, device admins, default apps, ADB state, and other settings stalkerware commonly abuses.

selinux.txt

What: SELinux enforcement status (getenforce). Why: a device not in Enforcing mode is a red flag: something may have degraded the security posture.

mounts.json

What: mounted filesystems and their options. Why: unusual mounts (writable system partitions, overlays) can indicate rooting or tampering.

env.txt

What: the environment variables of the ADB shell. Why: baseline context for the shell the data was collected from; anomalies can indicate a modified environment.

Logs and events #

logcat.txt, logcat_old.txt

What: the full Android log buffers (logcat -d -b all), current and previous boot. Why: one of the richest sources: crashes, permission grants, package installs, network events — often where the first trace of an infection shows up. Also full of personal data.

logs/

What: log files copied from the system: ANR traces (/data/anr/), vendor logs, uiderrors.txt, kernel logs (kmsg, last_kmsg, ramoops console). Why: kernel and crash logs survive events that logcat does not, and can reveal exploitation attempts or components crashing under instrumentation.

bugreport.zip

What: a complete Android bugreport (bugreportz), itself a ZIP with extensive diagnostics, including historical data. Why: the deepest single artifact — MVT parses it for package history, battery stats and more. Bugreports played a key role in Amnesty’s NoviSpy investigation.

bugreports/

What: bugreports generated on the device in the past, if any were kept. Why: snapshots of the device’s state at earlier dates — rare but precious for building a timeline.

Processes and apps #

ps.txt

What: every running process (ps -A) with UID, PID, and state. Why: spyware has to run to work. Process names and unexpected UIDs are directly matchable against indicators.

services.txt

What: registered system services (service list). Why: malware sometimes registers or hooks services; unexpected entries stand out here.

packages.json

What: every installed package (including uninstalled-but-kept ones, via pm list packages -U -u -i): package name, installer, install/update times, APK paths and SHA-256 hashes, plus heuristic flags such as sideloaded. Why: the core artifact for stalkerware detection: package names and APK hashes match directly against indicators, and the installer field shows how an app got there.

apks/

What: copies of the APK files of non-system apps. Why: lets an analyst inspect the actual binaries — hash them, decompile them, submit them for scanning — from the acquisition alone.

root_binaries.json

What: results of a search for known rooting binaries and apps (such as su) across $PATH and common locations. Why: the presence of root tooling changes the whole risk picture: with root, spyware can hide far better.

Filesystem #

files.json

What: a recursive listing of accessible directories: path, size, timestamps, permissions, owner, and SELinux context per file — no file contents. Why: file paths and names match against indicators, and timestamps let you reconstruct what appeared on the device and when.

tmp/

What: a copy of /data/local/tmp/. Why: this world-writable directory is a classic staging ground for payloads delivered over ADB; it should normally be near-empty.