NM Project indexCode and recorded results
All projects

Secure systems · Active

ephrun

Linux tooling for encrypted ELF artifacts, short-lived key delivery, and in-memory execution through memfd.

View source

At a glance

Evidence and scope

Repository measurements and recorded project results. Test and benchmark claims were inspected, not rerun during this catalog refresh. Physical line counts use the stated file scopes.

Implementation
2,727 linesNine C/header files under ephrun/ and keypush/; test programs, probes, and shell wrappers excluded.
Tests and harnesses
2,173 linesNine C probes/tests and shell harnesses; binary fixtures and operational wrappers excluded.
Kernel matrix
4 completedLinux 5.15–6.8 showed the same environment-specific failures and no version-specific regression; two older targets were skipped by runner transport.
Format coverage
KCAP1–3Round trips, compatibility reads, corruption/wrong-key rejection, and deterministic vectors.
Reviewed sources · 2026-10-15 · cd4f08a1d001

48 tracked files · 9 documentation files · 0 workflow files. Inventory includes data and vendored or generated files; workflow presence does not establish a passing run.

Download inventory and line-count file scopes

Executive summary

ephrun packages a Linux ELF executable as an encrypted artifact, obtains a decryption key at runtime, decrypts into a memory file, and executes it without writing the plaintext binary back to disk. Keys can come from a passphrase-wrapped capsule, a Linux kernel keyring entry, or a protected file. Companion tools push short-lived keys over SSH or an authenticated sealed UDP exchange. The project is designed to protect artifacts at rest and raise the extraction cost on a host; it explicitly does not protect a running process from root, the kernel, debuggers, or runtime memory inspection.

Problem and context

Some deployments need an executable present on a machine but prefer not to leave the unpacked artifact on persistent storage. ephrun separates artifact encryption at build time from key availability at runtime and explores several operational key-delivery shapes.

What was built

  • Key generation and sealed-box encryption for ELF artifacts.
  • KCAP3 passphrase-wrapped capsules with Argon2id parameters in a versioned

    • header and read compatibility for earlier capsule versions.

  • A Linux runtime loader using memfd and fexecve.
  • Four key-source modes: capsule, keyring ID, keyring label, and protected file.
  • SSH and ephemeral UDP key-push tools with keyring timeouts.
  • Threat-model, format, acceptance, operating, and decision documents.

How it works

The trusted build side generates an X25519 key pair and encrypts the executable for its public key. The target obtains the corresponding private material from one of the configured sources. elfdec-run decrypts into a memory-backed file, scrubs the key-source environment it controls, and executes that file descriptor.

Capsules add a passphrase-derived authenticated-encryption layer around the private key. Kernel-keyring modes can make raw key material time-limited and avoid a target-disk key file.

Evidence and validation

The acceptance criteria cover the KCAP3 wire format, derivation parameters, round trips, reference vectors, earlier-version read compatibility, and build integration. The repository also checks threat-model invariants and documents a kernel matrix for the execution path. Test binaries and fixed artifacts make the pack, source, decrypt, and execute chain reproducible.

Boundaries

This is not digital-rights management. A hostile root user, compromised kernel, ptrace-capable observer, loader compromise, or runtime memory instrumentation can recover or alter a running workload. Dynamically linked deployment adds a pre-main loader surface; static builds are the documented hardening path, not a guarantee against a hostile kernel.

Repository map and first run

make
bash test.sh
./ephrun/genkey

Use HOWTO.md for the shortest supported pipeline, SPEC.md for the ELFENC and KCAP formats, SECURITY.md for provided and non-provided properties, and tests/KERNEL_MATRIX_REPORT.md for the recorded Linux behavior.

Continue exploring

Secure systemsdeaddrop

A Go client and relay for short-lived encrypted handoffs, with capsule pairing, optional end-to-end identity, and a detailed protocol specification.

Secure systemsURTB

A C terminal tunnel using shared capsules and XChaCha20-Poly1305 across ESP-NOW, LoRa, Unix sockets, and generic process streams.

Secure systemscompartment

A small Linux isolation toolkit with two zero-dependency C tools, one policy format, worked profiles, and explicit security boundaries.