DEV Community: Bartosz Osiej

I built an eBPF ransomware detector in Rust

Bartosz Osiej — Wed, 26 Aug 2026 08:27:07 +0000

I built an eBPF ransomware detector in Rust

Kernel-level tracing, sliding-window alerts, and a cyberpunk TUI — in 1.7MB.

Why?

Ransomware detection typically requires expensive enterprise solutions. I wanted something that:

Runs at the kernel level — catches file operations before they hit disk
Works in real-time — no post-mortem analysis, immediate alerts
Ships as a single binary — no agents, no daemons, no dependencies
Is open source — auditable, free, and community-driven

That's Halcyon Process Monitor.

The core idea

Ransomware encrypts files rapidly. A normal user opens maybe 10-20 files per second. Ransomware? Hundreds or thousands.

Halcyon traces every openat syscall at the kernel level using eBPF, maintains a 1-second sliding window per process, and alerts when any process exceeds a configurable threshold:

Process opens 50+ files in 1 second → ALERT

Simple. Effective. No machine learning needed.

Architecture

┌─────────────────────────────────────────────────────────────────┐
│                        KERNEL SPACE (eBPF)                      │
│                                                                 │
│  sys_enter_execve ──┐                                           │
│  sys_enter_openat  ──┤                                           │
│  sys_enter_connect ──┤   ProcessEvent    PerfEventArray         │
│  sys_enter_accept  ──┼──► (map)    ────► (per-CPU buffers)     │
│  sys_enter_sendto  ──┤                                           │
│  sys_enter_recvfrom ─┘                                           │
└──────────────────────────────────┬──────────────────────────────┘
                                   │
┌──────────────────────────────────▼──────────────────────────────┐
│                     USERSPACE (Rust)                            │
│                                                                 │
│  reader thread ──► channel ──► Monitor ──► TUI / JSON / Web    │
│       │                  │         │                            │
│       │                  │    sliding window                    │
│       │                  │    + alerting                        │
│       │                  │    + process tree                    │
│       │                  │    + file ranking                    │
│       │                  │    + network tracking                │
│       │                  │    + heatmap                         │
│       └──► perf buffer   └──► search/filter                    │
└─────────────────────────────────────────────────────────────────┘

The kernel side is written in #![no_std] Rust using aya, and compiles to eBPF bytecode. The userspace side uses aya's userspace libraries to load the programs and read events.

The eBPF program

Here's the kernel-side code that traces openat syscalls:

// process-monitor-ebpf/src/main.rs
#[kprobe]
pub fn sys_enter_openat(ctx: ProbeContext) -> u32 {
    let pid = bpf_get_current_pid_tgid() >> 32;
    let uid = bpf_get_current_uid_gid() as u32;

    // Read comm (process name)
    let mut comm = [0u8; 16];
    unsafe {
        bpf_get_current_comm(&mut comm as *mut _ as *mut _, 16);
    }

    // Read filename from registers (x86_64: rsi = filename)
    let mut filename = [0u8; 256];
    let ptr = ctx.arg(1) as usize;
    unsafe {
        bpf_probe_read_user_str(
            &mut filename as *mut _ as *mut _,
            256,
            ptr as *const _,
        );
    }

    // Send event to userspace
    let event = ProcessEvent {
        pid,
        uid,
        kind: EventKind::Open,
        comm,
        filename,
    };

    unsafe {
        EVENTS.output(&ctx, &event, 0);
    }

    0
}

Key points:

bpf_probe_read_user — never dereference userspace pointers directly (eBPF verifier rejects that)
PerfEventArray — per-CPU buffers avoid lock contention
Fixed-size structs — no allocations in kernel code

The sliding window

The real intelligence is in userspace. The monitor maintains a rolling 1-second window per PID:

struct SlidingWindow {
    events: VecDeque<Instant>,
    threshold: u32,
}

impl SlidingWindow {
    fn record(&mut self) -> Option<Alert> {
        let now = Instant::now();
        self.events.push_back(now);

        // Remove events older than 1 second
        while self.events.front().map_or(false, |t| now.duration_since(*t) > Duration::from_secs(1)) {
            self.events.pop_front();
        }

        if self.events.len() >= self.threshold as usize {
            Some(Alert {
                pid: self.pid,
                opens_in_1s: self.events.len() as u32,
                timestamp: now,
            })
        } else {
            None
        }
    }
}

50 files per second triggers an alert. You can configure this with --alert-threshold.

The TUI

The terminal interface has 7 panels:

Panel	What it shows
EVENTS	Live event log with search/filter
PROCESSES	Hierarchical process tree with mini-bars
NETWORK	Real-time connections (connect/accept/send/recv)
TOP FILES	Most-opened files with Shannon entropy scores
FILE TYPES	Extension frequency with colored bars
ALERTS	Alert history with timestamps
HEATMAP	Syscall frequency visualization

Built with ratatui, styled in cyberpunk colors.

What else it traces

Halcyon isn't just about file opens. It traces 6 syscalls:

Syscall	Why
`execve`	Process creation — spot suspicious binaries
`openat`	File access — core ransomware detection
`connect`	Outbound connections — spot C2 callbacks
`accept`	Inbound connections — spot reverse shells
`sendto`	Data exfiltration
`recvfrom`	Data reception

Network tracing

New in v0.4 — Halcyon also tracks network activity:

{"type": "connect", "pid": 1234, "comm": "curl", "file": "93.184.216.34:443"}
{"type": "alert", "pid": 2126, "comm": "Cache2 I/O", "opens_in_1s": 50}

This catches ransomware that exfiltrates data before encrypting.

Deployment options

Single binary

sudo process-monitor

Web dashboard

sudo process-monitor --web 0.0.0.0:8080

REST API + WebSocket + Prometheus metrics.

Kubernetes

kubectl apply -f k8s/  # DaemonSet on every node

Go agent

./halcyon-agent watch  # WebSocket live events

C FFI

#include "halcyon.h"
halcyon_monitor_t* monitor;
halcyon_monitor_create("/path/to/bpf.o", 50, &monitor);

Build sizes

Variant	Size
TUI-only	1.7MB
Web-featured	2.5MB

Full LTO, panic = "abort", symbol stripping. A single static binary.

Stats

Metric	Count
Syscalls traced	6
TUI panels	7
Build variants	3 (TUI, web, both)
Binary size	1.7MB (TUI)
Deployment targets	5 (binary, web, k8s, Go agent, C FFI)

What I learned

eBPF is surprisingly accessible — with aya, you write Rust, not C. The verifier is strict but fair.
Per-CPU buffers are essential — shared maps cause contention. PerfEventArray with per-CPU buffers scales to millions of events per second.
The sliding window is the hard part — kernel tracing is straightforward; the intelligence is in userspace.
Rust's zero-cost abstractions matter — a 1.7MB binary with a full TUI, eBPF loader, and sliding window. No runtime overhead.

Try it

# Install
git clone https://github.com/BartoszOsiej/halcyon-process-monitor.git
cd halcyon-process-monitor
./build.sh

# Run (requires root + Linux 5.8+)
sudo target/release/process-monitor-tui

Or Docker:

docker run --privileged -v /sys/kernel/btf:/sys/kernel/btf \
    halcyon-process-monitor process-monitor

Built by Bartosz Osiej — 19, Poland, open to first paid role. Everything here is deployed infrastructure, not a tutorial.

Star the repo: github.com/BartoszOsiej/halcyon-process-monitor

I built a programming language that compiles to Python, Bash, and binary

Bartosz Osiej — Wed, 26 Aug 2026 08:26:01 +0000

I built a programming language that compiles to Python, Bash, and binary

And you can try it in your browser right now.

bartoszosiej.github.io

Why?

Most programming language tutorials stop at a calculator. I wanted something real — a language that could:

Run directly (like Python)
Compile to Python (for ecosystem access)
Compile to Bash (for system scripting)
Compile to binary (for performance)

One source file (.ext) → three targets. That's Externum.

Externum = Python_readability ⊕ Binary_performance ⊕ Bash_control

What it looks like

Externum looks like Python but compiles to three targets:

import mathx
import strings

class Fire(Pokemon):
    def __init__(self, name, hp=50):
        Pokemon.__init__(self, name, ["fire"], hp)

fire_team = [p.name for p in squad if p.is_type("fire")]
weakest = min(squad, key=lambda p: p.hp)
nums = [f for f in fibonacci(10) if f % 2 == 0]

If you can read Python, you can read Externum. But under the hood, it's a full compiler pipeline:

source (.ext) → Lexer → tokens → Parser → AST → Compiler → python/bash/binary

The hard part: NV2.0 Hard Mode

The real challenge wasn't the basic language — it was adding a hard mode that turns Externum into something genuinely difficult:

Ownership

p: Ptr[Int] = alloc(Int)
@p = 42
print(@p)     # 42
free(p)       # double-free after this = compile error

Yes, manual memory management in a Python-like language. The type checker enforces single-ownership semantics at compile time.

Traits

trait Speaker:
    def speak(self) -> Str

impl Speaker for Dog:
    def speak(self) -> Str:
        return "woof"

Missing an implementation? Compile error. Wrong return type? Compile error.

Macros

macro SQ(x) { (x) * (x) }
print(SQ(5))  # expands to print((5) * (5))

Textual expansion before parsing — like C macros but with Python syntax.

Concurrency

ch = chan()
spawn(worker(ch))
send(ch, v)
recv(ch)

Thread-backed channels with compile-time safety.

The browser playground

Here's where it gets interesting. Externum runs entirely in your browser:

┌──────────────┐    ┌────────────────┐    ┌────────────────┐
│ Code Editor  │───►│ Externum (.ext) │───►│ Pyodide (WASM) │
│ (browser)    │    │ transpiler      │    │ Python runtime │
└──────────────┘    └────────────────┘    └────────────────┘
       │                                           │
       └───────────── stdout / stderr ◄───────────┘

No server. No API keys. No network requests. The transpiler runs inside Pyodide — Python compiled to WebAssembly. Write Externum code, click Run, see output.

→ Try it now

The issue-command bot

Here's something unique: you can extend the language from GitHub Issues.

/run print(2 + 2) — executes Externum code in CI
/define clamp(x, lo, hi) if x < lo: return lo ... — adds a new stdlib function via PR

The bot parses Issue comments, generates a PR with the new function + tests, and runs the full 192-test suite before merge. The language evolves through community contributions.

DRM system

Every protected build carries a full defense-in-depth stack:

License keys — HMAC-SHA256 signed
Watermark — author/app/build/source-hash in every file
Tamper detection — source SHA-256 + artifact self-hash
Obfuscation — string literals encoded through a runtime helper

externum compile app.ext --protect --app-id game --author buffy --secret s3cret
EXTERNUM_LICENSE=<key> externum run app.ext --protect

Stats

Metric	Count
Unit tests	192
Stdlib modules	7 (structs, strings, mathx, fs, jsonx, net, drm)
Compilation targets	3 (Python, Bash, binary)
PyPI downloads	189+
Docker images	GHCR

Tech stack

Python 3.10+ — the implementation language
Zero dependencies — everything from stdlib
Pyodide — browser runtime via WebAssembly
GitHub Actions — CI/CD with cosign signing, SLSA provenance, SBOM
OpenSSF Scorecard — automated supply-chain security

What I learned

Lexing is harder than you think — especially with bracket-aware indentation, bash blocks, and f-strings
Type systems are beautiful — the ownership checker taught me more about Rust's borrow checker than any tutorial
WebAssembly changes everything — running a full language transpiler in the browser with zero server cost
Community-driven language design works — the /define bot has already added 3 new stdlib functions

Try it

pip install externum
externum repl

# Or try in your browser:
# https://bartoszosiej.github.io/externum/

Built by Bartosz Osiej — 19, Poland, open to first paid role. Everything here is deployed infrastructure, not a tutorial.

Star the repo: github.com/BartoszOsiej/externum