DEV Community: Aethel-Systems

Text Compression Still Wastes Bits on Structure

Aethel-Systems — Wed, 27 May 2026 09:27:20 +0000

We have become far too comfortable with the 8-bit byte.

In modern systems, we treat the byte as the indivisible atom of information. When we "compress" data, we usually look for repeating sequences (LZ77) or statistical probabilities (Huffman/ANS). But there is a hidden layer of redundancy that these general-purpose algorithms often leave untouched: The physical overhead of the data format itself.

The "Byte Container" Tax

Think about the character '2'. In ASCII, it is stored as 0x32 (00110010).

If you are storing a long list of numeric sensor logs, every single digit carries that 0x3 prefix. A general-purpose compressor might notice the pattern, but it still treats the data as a stream of 8-bit containers. However, the essence of '2' is just the value 2. To store the value 2, you only need 2 bits (10).

General-purpose compression looks for patterns between containers. I’ve been experimenting with a technique I call Literal Casting, which looks for waste inside the container.

How Literal Casting Works

The logic is to strip away the physical form dictated by standards like ASCII or fixed-width integers and store only the minimal significant bits.

1. Dimensionality Reduction

Instead of storing the character '2', we extract the core value 2 and store it using the minimum number of bits required. To prevent the bitstream from becoming overly fragmented, I use a "Floor Bandwidth" ($B_f$). For example, if $B_f = 2$, any value requiring 1 or 2 bits is normalized to 2 bits.

2. Ambiguity and Type Profiles

The challenge with stripping prefixes is ambiguity. How do you distinguish a literal ASCII '2' from a raw binary 0x02 once both are reduced to the 2-bit value 10?

The solution is to use Type Profiles—predefined semantic environments for data chunks:

Numeric/Hex ASCII: The decoder knows to OR the value with 0x30 to restore the digit.
Sparse 16/32: Designed for machine words with high zero-prefix redundancy.
UTF-8 Mixed: Strips fixed framing bits from multi-byte Unicode scalars.
Base64 Bridged: Reinterprets the Base64 alphabet as a 6-bit sextet stream.

Technical Implementation

To make this work reliably, the bitstream is split into two independent parts for each chunk:

The Pointer Stream: Encodes the bit-width of each record using a custom prefix code.
The Data Stream: Tightly packs the actual literal values.

Because this operates at the bit level, I use a dual CRC32 approach: one for the compressed payload and one for the original source to ensure absolute parity after reconstruction. If the estimated bit-cost of "casting" exceeds the raw binary size, the system automatically falls back to a raw pass-through.

I’ve implemented this logic in a small C project called LAZ (Literal-cast Absolute Zero). It’s a zero-dependency compressor that targets these specific industrial and structured data redundancies where general-purpose tools often over-calculate.

Project Link: LAZ

I Kept Bricking NFC Cards — So I Built a 1KB Crash-Proof Storage Engine

Aethel-Systems — Fri, 10 Apr 2026 12:52:24 +0000

The "Tear-off" Nightmare

If you’ve ever worked with NFC development, you know the "Tear-off" effect.

You are in the middle of writing a block of data to a MIFARE Classic card. The user’s hand shakes, the phone moves 1cm away from the tag, and boom—the RF field collapses. You just suffered a partial write. The data is corrupted, the checksums fail, and in the worst-case scenario, your application-level logic "bricks" the card because it's now in an inconsistent state.

In my project AECardTools, I decided that "good enough" wasn't enough. I wanted an NFC storage system that was physically impossible to brick, even if you pull the card away mid-write.

Here is how I built a Log-structured Copy-on-Write (LCOW) engine that fits inside a tiny 1KB NFC chip.

The Challenge: 1024 Bytes of Chaos

A MIFARE Classic 1K card is not a "hard drive." It's a collection of 16 sectors, each protected by keys. Normally, developers overwrite data in place. If the power cuts at byte 8 of 16, you are toast.

To solve this, I implemented three core concepts:

Never Overwrite: We never modify the "current" valid data. We always write to a new location.
Atomic Commits: Data is only considered "real" once a single, tiny pointer (the Anchor) is updated at the very end.
Maximizing Payload (The 900-Byte Hack): Standard MIFARE 1K usually only gives you 752 bytes of user data because the "Sector Trailers" (which store Keys A and B) take up space.

The Trick: In AECardTools, I treat the card as a raw encrypted canvas. I store the Sector Keys locally in the app's encrypted database. This allows me to reclaim the Key A/B areas for data storage, pushing the usable capacity to roughly 900 bytes.

The Architecture: How LCOW Works

The engine (written in Python via Chaquopy for the heavy lifting, and Kotlin for the NFC I/O) treats the card as a series of versioned logs.

1. The Ping-Pong Anchors

I reserved the very last sector (Sector 15) as the "Command Center." It contains two "Anchors."

Anchor A and Anchor B act like a toggle switch.
Each anchor contains a Transaction Sequence Number (TSN) and a pointer to the current root block.

2. The Write Flow

When you save a new file to the card:

Find Free Space: The engine looks for sectors not occupied by the current version.
Write New Data: It writes the new encrypted payload to these "shadow" sectors. If the user pulls the card away now, the old data is still sitting safely in its original sectors.
The Atomic Flip: Only after the data is 100% verified does the engine write a new TSN+1 to the other Anchor.

3. The Recovery

When the app scans a card, it looks at both Anchors.

If Anchor A says TSN: 10 and Anchor B says TSN: 11, the engine instantly knows that Version 11 is the truth.
If the write was interrupted, Version 11 would have a failed CRC or an older TSN, and the engine would automatically "roll back" to Version 10. Zero data loss. Zero bricking.

4. Architecture diagram

To bridge the gap between high-level Python logic and raw Android NFC hardware, I implemented a Neuromorphic FFI Bridge. Here is the high-level architecture:

┌─────────────────────────────────────────────────────────────────┐
│              AECardTools: Sovereign Architecture                │
├─────────────────────────────────────────────────────────────────┤
│ [UI Layer] (Kotlin / Jetpack Compose)                           │
│  - HexCanvas & Registry Editor UI                               │
│  - Security Disclaimer & Transaction Monitoring                 │
└───────────────┬─────────────────────────────────────────────────┘
                │ Reactive StateFlow
┌───────────────▼─────────────────────────────────────────────────┐
│ [ViewModel / Session Manager]                                   │
│  - Global NFC Session tracking                                  │
│  - Hardware I/O Orchestration                                   │
└───────────────┬─────────────────────────────────────────────────┘
                │ JNI / Chaquopy FFI Bridge
┌───────────────▼─────────────────────────────────────────────────┐
│ [Python Core Engine] (The "Brain")                              │
│  ┌────────────────────┐    ┌─────────────────────────────────┐  │
│  │    LCOW Engine     │    │      Cryptography Module        │  │
│  │ - Virtual Address  │    │ - Argon2id Key Derivation       │  │
│  │ - Transaction Logs │    │ - XChaCha20-Poly1305 (AEAD)     │  │
│  │ - GC Controller    │    │ - Merkle Tree Integrity Check   │  │
│  └──────────┬─────────┘    └─────────────────────────────────┘  │
└─────────────┼───────────────────────────────────────────────────┘
              │ Callbacks
┌─────────────▼───────────────────────────────────────────────────┐
│ [NFC Hardware Layer] (Kotlin / android.nfc.tech)                │
│  - Universal Protocol Manager (IsoDep / NfcA / NfcB)            │
│  - Sensitive Instruction Interceptor (Brick Protection)         │
└──────────────────────────────┬──────────────────────────────────┘
                               │ RF Field (13.56MHz)
                    ┌──────────▼──────────┐
                    │  MIFARE Classic 1K  │
                    └─────────────────────┘

The real magic happens in the memory remapping. I treat the 16 sectors not as rigid silos, but as a virtualized block pool managed by the LCOW engine:

PHYSICAL STORAGE (1024B)             LOGICAL VIEW (AEFS v5.5)
┌──────────────────────────┐         ┌──────────────────────────┐
│ Sector 0: Genesis Block  │────────▶│ 0x000 - 0x01F: Metadata  │
├──────────────────────────┤         ├──────────────────────────┤
│ Sectors 1-14:            │         │ 0x020 - 0x2EF:           │
│                          │         │                          │
│ [ LOG-STRUCTURED POOL ]  │────────▶│ [ SEAMLESS PAYLOAD ]     │
│ (42 Data Blocks)         │         │                          │
│                          │         │ (Encrypted Canvas)       │
├──────────────────────────┤         └──────────────────────────┘
│ Sector 15: Superblock    │
│ [Block 0]: Anchor A (Ping)◀───┐      ATOMIC FLIP LOGIC:
│ [Block 1]: Anchor B (Pong)◀───┴──[ Active pointer toggles ]
│ [Block 2]: GC / Bitmap   │       [ only after successful  ]
│ [Block 3]: Keys & ACL    │       [ verify-after-write     ]
└──────────────────────────┘

Hardening the Security: Sovereign Keys

Since I'm using the Key A/B sectors for data to hit that 900-byte goal, the security model changes.

Most NFC apps rely on the card's hardware to check keys. But MIFARE Classic's "Crypto1" algorithm is famously broken. Instead, I implement Sovereign Encryption:

The card is just a "dumb" encrypted block device.
The encryption (XChaCha20-Poly1305) and key derivation (Argon2id) happen entirely inside the Android app.
Even if someone cracks the RFID hardware layer, they just see a 900-byte blob of high-entropy noise.

The Result

By combining a Copy-on-Write strategy with a Local Key Management system, I turned a cheap $0.50 RFID tag into a robust, atomic, and encrypted mini-vault.

It’s a reminder that even when working with "ancient" hardware from the 90s, modern software patterns like LCOW can solve physical-layer reliability problems.

If you're building anything with NFC, you might find this useful 👇

👉 GitHub: AECardTools

Escaping EDK II bloat: Building a linker-less systems language that weaves its own PE32+ binaries

Aethel-Systems — Thu, 12 Mar 2026 02:52:50 +0000

If you have ever tried to write a lightweight UEFI application or a custom bootloader, you probably know the friction involved.

You either wrestle with the massive, convoluted build system of EDK II, or you spend hours tweaking fragile linker scripts just to force a standard C/Rust compiler to output a valid PE32+ image. Traditional toolchains are built on a philosophy of separation: the compiler handles the logic, and the linker handles the physical geometry.

But in bare-metal environments, physical geometry is logic.

I wanted a toolchain that deeply understands the binary format it is producing, without the historical baggage of POSIX or traditional build systems. So, I started building Aethelium—a system language and "kernel forge" designed exclusively for bare-metal and UEFI development.

Not for your Host OS (The "Compiler Strike")

Before getting into the architecture, I should clarify what Aethelium is not. It does not target macOS, Linux, or Windows. It does not generate ELF or Mach-O executables for your host machine.

It is so strictly separated from the traditional OS ecosystem that if you try to pull in C-style legacy code like #include <stdio.h> or call malloc(), the compiler physically intercepts the token, prints [COMPILER STRIKE] The paradigm barrier starts here, and terminates with exit code 1010.

It is designed from the ground up to target raw x86 silicon and UEFI firmware.

Bypassing the Linker: The "Weaver-Filler" Architecture

In a traditional pipeline (Compiler -> Assembler -> Linker), the compiler generates intermediate object files, leaving the linker to "guess" where the code should go based on abstract symbols. This creates unnecessary friction when all you need is a raw binary payload or a specific EFI header.

Aethelium completely drops the assembler and the linker. Instead, it uses a dual-engine architecture in a single pass:

1. The Weaver: Before a single line of logic is translated, the Weaver pre-calculates the entire physical "skeleton" of the binary. It manually constructs the PE32+ headers, section alignments, base relocations, and fixed memory slots.
2. The Filler: The compiler frontend then lowers the AST and encodes raw x86-64 machine code (handling REX prefixes and ModR/M bytes directly in C) directly into these pre-calculated physical offsets.

Hardware as a First-Class Citizen

Because Aethelium is deeply tied to the metal, hardware constraints are baked directly into the language grammar. You don't need __attribute__((...)) hacks or opaque inline assembly blocks.

Here is what a bare-metal UEFI entry point looks like:

// =========================================================
// Aethelium UEFI Entry Point
// =========================================================
 
// Direct entry point with gate-specific calling conventions
@entry
@gate(type: \efi)
func efi/main(image/handle: ptr<Void>, sys/table: ptr<EFI/SystemTable>) : UInt64 {
 
    // The compiler natively understands the UEFI ConOut protocol
    print("Hello, Bare-Metal World!")
 
    // First-class Hardware block:
    // Direct processor state control. The compiler emits raw opcodes here.
    hardware {
        loop {
            hardware\isa\pause()
        }
    }
 
    return 0 // EFI/SUCCESS
}

Navigable Namespaces

One of the more opinionated design choices in the language is the strict rejection of flat namespaces. Instead of snake_case with underscores (e.g., sys_cpu_id), Aethelium uses / for namespaces (e.g., sys/cpu/id).

It treats system capabilities as a navigable, hierarchical tree. To accommodate this logically at the lexer level, mathematical division uses the ÷ operator. It’s a controversial shift, but it fundamentally changes how you architect low-level APIs.

The Current State

Aethelium is currently a self-hosted bootstrap effort written entirely in C and
assembly. It is fully capable of producing zero-dependency, zero-bloat UEFI "Hello World" binaries, performing hardware state snapshots, and directly probing VGA/COM1 ports without any external dependencies.

If you are interested in compiler architecture, manual x86 opcode encoding, or how to manually construct PE32+/ISO files from scratch in memory, the complete source code of the compiler is open.

You can explore the raw plumbing here:

Aethel-Systems / Aethelium

Aethelium: A hardware-first, runtime-less language for modern systems programming. Bypassing linkers and bulky frameworks to emit UEFI and bare-metal binaries directly.

Aethelium

A Hardware & Kernel-First, Runtime-Less Systems Language Toolchain for Bare-metal & Native Windows.

Aethelium is an independent, self-contained systems programming language toolchain. By abandoning the cumbersome traditional "compiler-assembler-linker" workflow, it not only focuses on providing extremely streamlined build solutions for UEFI environments and bare-metal development, but also fully supports building zero-runtime, zero-C-dependency, high-performance native applications (Win64 EXE) on Windows platforms.

🏗 Core Architecture

Aethelium employs a unique "Weaver-Filler" dual-engine architecture, achieving direct mapping from high-level semantics to low-level target platform binaries (PE32+/Mach-O/ROM/BIN):

Binary Weaver (toolsASM) Responsible for the orchestration of low-level binary physical layouts. In the late stages of compilation, the Weaver precisely weaves the skeleton of the target binary in memory according to target environment specifications (such as boot sector offsets, UEFI section alignment, relocation tables, exception sections, etc.).
Logic Filler (toolsC) A compiler frontend implemented in C. It is…

View on GitHub