gbrl (General Binary Restractor & Logger) is a cross-platform behavioral analysis engine built in pure Go. It combines a Linux ptrace-based sandbox for native binaries with a WASM runtime that intercepts WASI system calls — enabling sandboxed execution of untrusted code on any platform.
Monitor and control native Linux binaries via ptrace syscall interception and process_vm_readv memory forensics.
make build
sudo ./run.sh /bin/python3 target_script.pyRun WASI-compatible WebAssembly binaries through a wazero runtime with policy-enforced interception of fd_write, path_open, clock_time_get, random_get, and poll_oneoff.
go run ./cmd/gbrl-wasm path/to/module.wasm[F1]— Step to next syscall[F2]— Send SIGKILL[F3]— Dump memory[F4]— Policy configuration[Q]— Quit
The gbrl-malclass tool batch-classifies WASM binaries for malicious behavior by running each sample in an instrumented sandbox, recording every WASI system call, extracting behavioral features, and producing a classification verdict.
go run ./cmd/gbrl-malclass samples/*.wasmHow it works:
- Each WASM sample is loaded into the wazero runtime with a custom
RecordingInterceptorthat implementsinterceptor.SyscallInterceptor - Every WASI call (
path_open,fd_write,network_connect,execve,clock_get,random_get) is recorded with its arguments into a thread-safe call log - After the guest exits, features are extracted from the call log: file paths accessed, total bytes written, network attempts, subprocess spawns, etc.
- A rule-based classifier scores the sample as benign, suspicious, or malicious based on feature weights
- A CSV report (
malclass_report.csv) is generated for downstream ML training, and raw memory dumps are captured for samples that triggered policy violations
What it's used for:
- Automated malware triage — quickly separate benign WASM modules from suspicious ones before manual analysis
- ML training data generation — the CSV output provides structured feature vectors (16 columns per sample) for training classifiers (XGBoost, random forest, etc.)
- Supply chain vetting — scan third-party WASM plugins/modules before deploying them
- Forensic evidence collection — samples flagged as malicious get full WASM linear memory dumps for offline reverse engineering
Benefits over alternatives:
| Approach | gbrl-malclass | Docker sandbox | Static analysis |
|---|---|---|---|
| Startup time | ~5ms per sample | ~500ms+ | N/A |
| Syscall-level visibility | Yes (6 WASI hook points) | Limited (OS-level) | None |
| Structured ML features | Built-in CSV export | Requires extra tooling | Requires manual labeling |
| Memory forensics | Automatic for flagged samples | Requires separate setup | Not possible |
| Cross-platform | Any WASI-compatible module | Linux-only | Any format |
Example output:
=== gbrl-malclass Report ===
Total: 4 | Malicious: 1 | Suspicious: 1 | Benign: 2 | Errors: 0
crypto_miner.wasm: malicious (80%)
- attempted network connection
- accessed /etc/
- excessive file opens (>20)
key_stealer.wasm: suspicious (60%)
- accessed .ssh
- accessed .env
The engine is composed of layered internal packages:
internal/launcher— Spawns a child process under ptrace with optional namespace isolationinternal/monitor— Ptrace event loop handling syscall entry/exit, policy evaluation, and memory forensicsinternal/memory— Tracee memory access viaprocess_vm_readvand memory dump facilitiesinternal/policy— YAML-defined security policy with blocked-syscall maps and prefix trie for filesystem pathsinternal/heuristic— Shannon entropy-based ransomware detection with per-FD trackinginternal/executor— WASM guest lifecycle using wazero with custom WASI function overridesinternal/interceptor— Syscall interception interface for WASI hooksinternal/telemetry— Lock-free ring buffer for event logging and async CSV writer