# ProcessMonitor Current State

## Scope inspected

The repository was inspected in its current state before making changes. The files reviewed were:

- `src/process_monitor_driver.c`
- `src/process_monitor_driver.h`
- `driver/ProcessMonitor.inf`
- `scripts/install_driver.ps1`
- `scripts/uninstall_driver.ps1`
- `config/process_monitor_config.json`
- `service/telemetry_service.py`
- `README.md`
- `project_export.txt`

## Working baseline

The project already has a defensible baseline structure:

- A Windows kernel driver exists and registers process/thread callbacks.
- The driver initializes on load and registers unload logic.
- Registry configuration is read for `Enabled` and `LogLevel`.
- A Python telemetry relay exists and polls `tasklist` to detect process starts and exits.
- The project includes a defensive README describing the work as lawful monitoring rather than stealth behavior.
- The install and uninstall scripts provide a rough deployment path for a lab environment.
- The INF file defines a `ProcessMonitor` device and service for a Windows driver package.

## Inconsistencies and gaps

### 1. Driver/header mismatch

The current C implementation and the header are not fully aligned.

- `src/process_monitor_driver.c` defines a global `PROCESS_MONITOR_CONFIG` with `Enabled` and `LogLevel` only.
- The earlier `project_export.txt` references allowlist/blocklist logic and more complex configuration values, but the active code no longer matches that structure.
- This means the project has partially transitioned from a placeholder allow/block design to a minimal observational design without fully reconciling all older assumptions.

### 2. Old assumptions remain in documentation history

The export file shows earlier design logic including allow/block list handling and an older model of process filtering.

- The live code does not currently implement allow/block lists in the kernel.
- The user-mode telemetry package does not enforce those rules in the kernel; it only treats them as watched data in JSONL output.
- The repository currently mixes historical design intent with the newer defensive monitoring direction.

### 3. INF/service startup mismatch

The INF sets:

- `StartType = 0 ; SERVICE_BOOT_START`

This is a boot-start configuration, while the project description and installation scripts assume a lab-oriented service model and manual or demand-like behavior.

- This is a major operational mismatch for a project being treated as a controlled, testable service.
- It can make deployment behavior confusing and can create startup timing assumptions that are not consistent with the scripts.

### 4. Install/uninstall script assumptions are not fully aligned with the current package

- `scripts/install_driver.ps1` expects `driver/ProcessMonitor.sys` and `driver/ProcessMonitor.inf` to exist.
- The repo currently contains `driver/ProcessMonitor.inf` but not readily a built `ProcessMonitor.sys` binary in source control.
- `scripts/uninstall_driver.ps1` calls `pnputil /delete-driver` with the INF name but does not validate whether the service actually exists or whether the package is installed.

### 5. Python telemetry is functional but still a prototype relay

The user-mode collector is meaningful, but it is still a lightweight prototype rather than a full endpoint collector.

- It polls `tasklist` and records process arrivals and exits.
- It emits JSONL telemetry and watchlist logic.
- It does not yet use a normalized event model.
- It does not yet store data in SQLite.
- It does not yet isolate core logic from collector logic.

### 6. No normalized event model exists yet

There is no single shared event schema in the repository.

- The kernel driver emits `DbgPrintEx` log lines.
- The Python service emits JSONL records with ad hoc fields.
- The config file includes operational metadata, but the project does not yet have a formal event contract.

### 7. No tests exist

No automated tests currently verify:

- event normalization
- configuration parsing
- database schema assumptions
- detection logic
- collector correctness

### 8. Architecture is not yet separated cleanly

The codebase does not yet cleanly separate:

- kernel telemetry
- user-mode collection
- event normalization
- database storage
- detection logic
- GUI structure

This is expected for an early project, but it makes milestone planning important.

## Current status summary

This repository is in a transitional state:

- it has a legitimate minimal kernel process monitor
- it has a basic user-mode telemetry collector
- it has defensive documentation and a safe framing
- it does not yet have the formal end-to-end architecture required for a true EDR-style platform

## Recommendation for Milestone 2

The next architecture step should be to introduce a single normalized event model and tests before layering in SQLite, process collectors, or GUI work. This keeps the project stable and gives future collectors a shared contract.
