DEV Community: ChirallyActive

I Built a "Honeypot Vault" Using a Custom Esoteric Language

ChirallyActive — Tue, 07 Jul 2026 18:44:52 +0000

Security usually feels like a static, boring wall. I wanted to build something different—something active.

I’m excited to share CyberFuck, a project where I combined synthwave aesthetics, custom-built esoteric interpreters, and active-defense honeypot logic to create a "Vault" that doesn't just store your secrets—it traps anyone trying to steal them.

The "Why"

Most encryption tools are passive. You store a file, and it sits there, waiting to be brute-forced. I wanted to explore "active defense." What if your data could fight back? What if the encryption itself was proprietary enough that standard tools couldn't even parse it?

The Tech Stack

Backend: Node.js + Express (wrapped for Serverless deployment).

The Engine: A custom-built Brainfuck interpreter that uses a proprietary dialect.

Frontend: HTML5/CSS3 with Glassmorphism, custom local typography, and pixel-art video loops for that 90s hacker movie vibe.

Deployment: Render for the backend/serverless functions.

The Secret Sauce: Proprietary Obfuscation

The heart of CyberFuck is a custom Brainfuck dialect. Because standard Brainfuck interpreters are open-source and common, they are useless for security.

By engineering my own mathematical offset algorithms and a hidden "Auth-Signature," I’ve ensured that no standard interpreter on the web can parse these files. If a snooper tries to run a CyberFuck vault through a generic interpreter, they’ll get nothing but syntax errors or corrupted gibberish.

How it works (The Honeypot)

The vault uses a "Signature Verification" method:

Auth Check: Before the data is output, the interpreter checks for a specific "Auth-Signature."

The Trap: If you provide the wrong 4-character PIN, the interpreter fails the signature check. Instead of "failing quietly," it triggers a WEBHOOK TRIGGERED alert, logging the breach attempt and neutralizing the data output to prevent further brute-forcing.

Challenges Faced

The biggest technical hurdle was memory management. Building a Brainfuck interpreter from scratch in JavaScript meant handling potential infinite loops. I had to implement strict execution limits to ensure that even if someone feeds the vault malicious, corrupted code, the server stays up and the system remains stable.

Give it a spin

If you’re interested in esoteric security, check out the repo and try to break the vault yourself!

Try the live app: https://cyberfuck-3p8b.onrender.com/

View the Source: https://github.com/Amaterus1125/Cyberfuck

I’m looking for feedback on the honeypot logic—does anyone see a way to bypass the signature check without the correct key?

If you enjoyed this, feel free to give the repo a star on GitHub! I'm constantly tweaking the offset algorithms to make the encryption even harder to reverse-engineer.

Improving my Cross-Distro Package manager made in Rust

ChirallyActive — Sat, 04 Jul 2026 15:30:08 +0000

Chiral: A Cross-Distro Linux Package Manager in Rust

Most Linux package managers assume one thing:

You are staying inside a single Linux ecosystem.

That assumption breaks real-world systems.

So I built something different.

GitHub:
https://github.com/Amaterus1125/Chiral-CrossDistro-Package-Manager

🧠 Introduction

Linux is powerful, but fragmented:

apt → Debian/Ubuntu
pacman → Arch
dnf → Fedora

This creates inconsistency when working across environments.

Chiral is my attempt to unify that experience.

⚗️ What is Chiral?

A cross-distro Linux package manager written in Rust.

It allows installing packages across distributions without relying on the host package manager.

📦 Example usage

chiral install htop
chiral install fastfetch
chiral list

🧬 Core design (simplified)

Chiral resolves packages using multiple sources:

fn resolve_package(name: &str) -> Option<Package> {
    try_arch(name)
        .or_else(|| try_debian(name))
        .or_else(|| try_custom_repo(name))
}

🐧 Arch Linux support

Chiral reads the official repo database:

fn try_arch(pkg: &str) -> Option<Package> {
    let db = fetch_arch_db()?;
    let entry = db.find(pkg)?;

    verify_checksum(&entry.sha256)?;

    Some(entry.into())
}

📦 Debian support

It parses Packages.gz metadata:

fn try_debian(pkg: &str) -> Option<Package> {
    let index = fetch_packages_gz()?;
    let entry = index.lookup(pkg)?;

    verify_sha256(&entry.sha256, &entry.path)?;

    Some(entry.into())
}

🌐 Custom repository support

Chiral supports optional checksum sidecars:

package.tar.gz
package.tar.gz.sha256

Verification logic:

fn verify_custom(pkg: &str, hash: &str) -> Result<()> {
    let file_hash = sha256(pkg)?;

    if file_hash != hash {
        return Err("Checksum mismatch");
    }

    Ok(())
}

🔐 Self-update security model

Chiral verifies its own binary before replacing itself:

fn self_update(asset: &File) -> Result<()> {
    let digest = fetch_github_digest(asset)?;

    if !verify_sha256(asset, digest) {
        panic!("Update rejected: integrity check failed");
    }

    install_new_binary(asset)?;
    Ok(())
}

🛡 Security model (v4.0.0)

All package sources are validated using SHA-256:

Arch → repo database checksum
Debian → Packages.gz metadata
Custom repos → optional sidecar hash
GitHub → release asset digest

Failure model:

Any mismatch = immediate rejection (fail closed)

⚙️ Implementation details

Written fully in Rust 🦀
Uses sha2 crate for hashing
Statically linked binary
Graph-based dependency resolution
No shell execution in verification pipeline
Cross-distro filesystem normalization layer

🧪 Example install flow

User request → Resolve package →
Fetch metadata → Verify checksum →
Download → Validate → Install

🎯 Design goal

Not to replace Linux package managers.

But to unify them under one abstraction layer where:

installation is distro-agnostic
integrity is consistent
behavior is predictable

🧭 Future work

Windows support layer (experimental)
GPG verification for repo trust chains
Signed Chiral repository format
Reproducible builds
Expanded ecosystem support

📌 Status

Early-stage but fully functional.

Actively evolving with focus on:

security
cross-distro compatibility
system-level reliability

🔗 GitHub

https://github.com/Amaterus1125/Chiral-CrossDistro-Package-Manager

🧠 Closing thought

Linux doesn’t need more package managers.

It needs fewer assumptions.

I built my own package manager in Rust while building a Linux distro from scratch

ChirallyActive — Sun, 28 Jun 2026 09:21:21 +0000

A few months ago I decided to build a Linux distribution entirely from scratch using LFS (Linux From Scratch) and BLFS. Every package — GCC, glibc, systemd, XFCE — compiled by hand. No shortcuts.

About halfway through I ran into a problem: there's no package manager for LFS systems. You're just supposed to compile everything manually forever.

So I built one.

What is Chiral?

Chiral is a cross-distro binary package manager written in Rust. It works on any Linux system — including custom LFS/BLFS distros, Arch, Debian, and anything in between.

The key idea: instead of being tied to one distro's repos, Chiral uses a 3-way fallback chain:

1. Your own GitHub packages/ repo
         ↓ not found?
2. Debian stable repos
         ↓ not found?
3. Arch Linux repos

If a package exists anywhere in that chain, Chiral finds it and installs it.

Install in one line

curl -L https://github.com/Amaterus1125/Chiral-CrossDistro-Package-Manager/releases/latest/download/chiral -o chiral
chmod +x chiral
sudo mv chiral /usr/local/bin/chiral

100% static musl binary. No Rust, no dependencies, runs on any Linux including a fresh LFS system with nothing installed.

How dependency resolution works

When you run chiral install gtk3, it:

Queries the Arch Linux API for gtk3's full dependency list
Walks the entire tree recursively using BFS
Checks each dep against your system before downloading
Builds a topological install order so deepest deps go first
Installs everything in order, gtk3 last

gtk3
 ├── glib2       ← installed 1st
 ├── cairo
 │    └── pixman ← installed before cairo
 ├── pango
 └── gdk-pixbuf2

The smart part: before downloading anything, Chiral checks if a dep is already on your system via pacman, dpkg, pkg-config, ldconfig, PATH, rustup, and direct filesystem scanning. It works alongside existing package managers without conflicting.

Commands

chiral install <package>   # install with full dep resolution
chiral remove  <package>   # clean remove — tracks every file
chiral update  <package>   # update one package
chiral upgrade             # update everything
chiral search  <query>     # search available packages
chiral list                # list installed packages
chiral info    <package>   # version, source, files
chiral deps    <package>   # dry run — see what would install
chiral self-update         # update chiral itself

chiral info even works on packages not installed by Chiral:

chiral info rust
# Package : rust
# Status  : not managed by chiral
# Version : 1.93.1
# Source  : rustup (installed outside chiral)

The technical bits

Dependency resolution uses BFS to walk the full tree, then Kahn's algorithm for topological sort. Circular deps are detected and broken automatically.

File tracking DB records every installed file path so chiral remove is perfectly clean:

[steam=3.5.0-1|arch]
/usr/local/bin/steam
/usr/local/lib/steam/...

Self-updating — sudo chiral self-update hits the GitHub releases API, compares versions, downloads the new static binary and replaces itself.

Auto-sync — a GitHub Actions workflow runs every Sunday, checks Arch and Debian for newer versions of packages in the repo, repacks them and commits automatically. The package repo updates itself.

Root vs user mode — runs system-wide as root (/usr/local) or per-user as a regular user (~/.local). No configuration needed.

Why I built this

LFS teaches you how Linux actually works by making you build it yourself. But once you've built it, you're stuck installing everything by hand forever. There's no package manager for a system you assembled from scratch.

I wanted one. So I built it in Rust, made it work on any Linux regardless of what's installed, and gave it the ability to pull packages from three different sources so it can find almost anything.

The name comes from chirality in chemistry — molecules that are mirror images of each other. The two UI modes (Dextro and Levo) reflect this. Dextro is the default orange helix animation. Levo is a DNA sequencer animation that shows base pairs (A═T, G≡C) scrolling as packages install.

What's next

Orphan detection (chiral autoremove)
Conflict detection
KDE support on my custom distro

GitHub: Chiral Package Manager

Built by one person while building a Linux distro from scratch. If you're doing LFS/BLFS or want a package manager that works everywhere, give it a try.