970698af83
End-to-end pipeline now produces a labeled envelope from a single command.
Drives the orchestrator through an 8-phase XMRig-shaped schedule and
renders a 3-panel envelope (CPU%, RSS, IO write rate) with phase bands
sourced from labels.jsonl. Real telemetry, simulated load — validates the
collection + labeling shape before a real VM is involved.
Components:
- tools/load_mimic.py phase-driven load generator. Reads phase
commands on stdin; CPU/IO behavior matches
the named phase (clean=idle, armed=light burst,
infecting=disk burst+CPU, infected_running=
CPU saturation+stratum-shaped writes,
dormant=quieter than clean).
- tools/run_envelope_demo.py spawns load_mimic, drives EpisodeRunner with
a default 85s schedule that includes the
classic infected_running → dormant → re-entry
pattern.
- tools/plot_envelope.py reads telemetry + labels from an episode dir,
writes envelope.png with colored phase bands.
orchestrator: EpisodeRunner now takes an optional phase_schedule and an
on_phase callback. Walks the schedule emitting one label per transition.
Backwards-compatible — existing single-phase tests still green.
Doc fix (user pushback): README + architecture + threat-model no longer
imply the Pi5 is the deployment target. Pi5's actual role here is the
WireGuard-side collector for episode tarballs. Deployment target is
generic ("constrained Linux device"). The "gateway observer" concept
remains a deployment pattern, decoupled from the Pi5's collector role.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| collectors | ||
| docs | ||
| etc | ||
| exploits | ||
| orchestrator | ||
| receiver | ||
| samples | ||
| tests | ||
| tools | ||
| training | ||
| vm | ||
| .gitignore | ||
| pyproject.toml | ||
| README.md | ||
| uv.lock | ||
CIS490 — Behavioral Malware Detection Dataset & Model
Course project for CIS490 (Cybersecurity). The end-goal is an ML model that watches performance metrics on a real device, decides whether the device has been breached, and triggers a hardware-level reset when confidence is high enough.
This repository covers the dataset side of that pipeline: we run real, public malware samples against intentionally vulnerable Linux VMs and capture labeled time-series telemetry that mirrors what the same model would see in deployment on an arbitrary target Linux device.
Note on the topology: in this project the Pi5 is the WireGuard-side collector that receives episode tarballs from one or more lab hosts — it is not the deployment target for the model. The deployment target is generic ("any constrained Linux device"). See
docs/architecture.md.
The work is grounded in the trust-over-time scoring model from IEEE 9881803 and a related proprietary follow-on that pairs detection with blockchain-anchored hardware reset.
What lives where
| Path | What it holds |
|---|---|
docs/architecture.md |
Lab topology, KVM choice, snapshot loop, deployment-mirror reasoning |
docs/threat-model.md |
Train/serve parity rule and the oracle-vs-deployable feature split |
docs/data-model.md |
On-disk JSONL schema, per-episode layout, phase enum |
docs/transport.md |
Sender/receiver design — how episodes get to the central collector over WG |
docs/deploy.md |
One-command install for the lab-host and receiver roles |
docs/lab-setup.md |
KVM prereqs, VM build, snapshot, virtio-serial wiring |
orchestrator/ |
State machine that drives the boot → arm → detonate → observe → revert loop |
collectors/ |
One module per telemetry source (host /proc, QMP, perf, pcap, guest agent) |
vm/ |
qcow2 images and snapshot scripts (binaries gitignored) |
exploits/ |
Metasploit resource scripts for repeatable exploitation |
samples/ |
Sample manifest (sha256-pinned). Binaries never committed. |
training/ |
Model training code (deferred — schema first) |
Quick orientation
- Why VMs? We need a clean snapshot/revert loop and we need to run real malware without burning hardware. KVM gives us both at near-native speed.
- Why is the network isolated? A host-only bridge keeps malware off the internet and off the WG overlay. The Pi5 gateway is the lab-side observer, playing the same role it would play in a deployed setting.
- Why JSONL and not a database (yet)? Schema-last: collect first, decide storage shape after we see what's actually useful. JSONL is crash-safe, append-only, and reshapes trivially into Postgres/Timescale/Parquet later.
- Why two models? One trained on features that exist on a real Pi (deployable), one trained on host-side QEMU-only features (oracle). The accuracy gap measures how much detection power a privileged rootkit can take from the deployed model. See docs/threat-model.md.
Status
Project bootstrap. Skeleton, documentation, and design decisions in place; collection and orchestration code in progress.