fa1574a0a6
Lays down the design surface for the CIS490 behavioral-malware-detection dataset and model. No code yet — schema and topology are decided first so collection can start without rework. Docs: - README: project goal, navigation - architecture: lab topology, KVM choice, episode state machine, deployment-mirror reasoning - threat-model: train/serve parity rule, oracle-vs-deployable feature split, two-model evaluation strategy - data-model: per-episode JSONL layout, row schemas, phase enum - transport: WG-native shipper/receiver design, idempotent uploads - deploy: one-command install for lab-host and receiver roles - lab-setup: KVM prereqs, VM build, snapshot, virtio-serial wiring Skeleton: orchestrator/, collectors/, vm/, exploits/, samples/, training/ (each with a short README explaining purpose). Extended .gitignore to exclude qcow2 images, pcaps, sample binaries, secrets. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| collectors | ||
| docs | ||
| exploits | ||
| orchestrator | ||
| samples | ||
| training | ||
| vm | ||
| .gitignore | ||
| README.md | ||
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 a Raspberry Pi or similarly-constrained target.
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.