Sovereignty White Paper | Pisces Moon OS — The SPI Bus Treaty & Eleven Engineering Problems

Abstract

This paper documents eleven engineering problems solved while building Pisces Moon OS — a multi-app handheld operating system that ships on three ESP32-S3 deployment targets, including the no-PSRAM Cardputer ADV (320 KB internal SRAM, four concurrent radios in active operation). The work produced two architectural artifacts with no prior published equivalent on this hardware class: the SPI Bus Treaty, a formal shared-bus arbitration protocol that names and codifies the mutex discipline required for concurrent SD, LoRa, and display operation on a single SPI bus; and a three-layer hardware-enforced ELF module sandbox built on the ESP32-S3 Permission Management System and Xtensa exception handler hijacking — a runtime application isolation mechanism on a non-MMU SoC that, to the best of our knowledge, has no published implementation for a general-purpose OS on this hardware.

The engineering progression is verifiable against a public codebase. Problems 1–6 were discovered on the LilyGo T-Deck Plus during 2025 field operations in dense RF environments (downtown Los Angeles; 80+ access points; 100+ BLE advertisers). Problems 7–9 emerged porting the same OS to the LilyGo T-LoRa Pager — hardware-variant collisions (GPIO 21 dual-function, SPI bus state corruption, lazy session-file creation) that only surface when one OS targets two physically different boards in the same product family. Problem 10 is the platform-wide ELF sandbox. Problem 11 is the proof the methodology generalizes: the same architectural patterns ported down to the Cardputer ADV (ESP32-S3FN8 variant, no PSRAM) running concurrent WiFi STA, BLE observer, GPS, and LoRa with 125 KB free heap during active wardrive scanning — on hardware the industry sells for single-purpose firmware.

This paper presents the eleven problems with their solutions, the architectural methodology those solutions express — name the constraint, document the protocol, make it a platform contract — and the live demonstration plan that walks an audience through the work on physical hardware. The methodology is the contribution. The protocols (SPI Bus Treaty, UART Peripheral Map, lazy app-state allocation) are its expressions.

What the Talk Delivers

▸ The question that started the project

The LilyGo T-Deck Plus looks like a BlackBerry. Why doesn't it work like one?

Not "why doesn't it run BlackBerry OS" — but why doesn't this $80 device, with a QWERTY keyboard and a screen and four radios and a CPU faster than the one in a 2009 smartphone, behave like a general-purpose handheld computer? Why does the ESP32-S3 reference firmware ecosystem treat a multi-radio QWERTY pocket device as a single-purpose appliance — a Meshtastic node, a wardriver, a remote, a sensor — when the silicon is plainly capable of more?

The honest answer is: because nobody had asked the platform to be more, and the moment you ask, ten interlocking engineering problems emerge — none of them in Espressif's manual, because Espressif documents primitives, not integration targets. This paper is the record of asking that question and following the engineering wherever it led. Pisces Moon OS is the operating system that resulted. The eleventh problem is what made it portable across the entire memory tier of the chip class.

A note on prior art that is sometimes raised: Sailfish, postmarketOS, KaiOS, and similar handheld Linux distributions run on application processors with MMUs, virtual memory, gigabytes of RAM, and a Linux kernel underneath. This is a different engineering problem entirely. The ESP32-S3 has no MMU, no virtual address spaces, no Linux, and on the most-constrained Pisces Moon target — the Cardputer ADV — 320 KB of total SRAM. The thing that makes those distributions possible on application-processor hardware is the thing that is absent here, which is why this project exists.

The proposed DEF CON 34 talk is a 45-minute walk through the engineering record of a multi-app operating system shipping on hardware the industry treats as single-purpose. The audience leaves with three concrete artifacts:

A named architectural protocol they can use immediately — the SPI Bus Treaty, presented as a four-rule contract that solves a class of bus-arbitration crashes any multi-radio ESP32-S3 project will encounter. Reference implementation is open source.
A methodology for solving structurally similar problems — name the constraint, document the protocol, make it a platform contract. The Treaty was the first expression on the S3. The UART Peripheral Map (ESP32-P4) is the second. Lazy app-state allocation (Cardputer ADV) is the third. Same methodology, three different hardware contexts.
A hardware-enforced ELF sandbox on a non-MMU SoC — using the ESP32-S3 Permission Management System and a custom Xtensa exception handler. No prior published ESP32-S3 project documents this combination for runtime third-party application isolation under a multi-app OS.

The demo is live on stage. The codebase is public. The engineering is verifiable in commits and on the devices themselves. There is no theoretical content in the talk — every claim is a piece of code that runs on a $50 device the audience can buy and reproduce.

Field Validation — Lincoln Heights, Los Angeles

Core 0 ran the Ghost Engine continuously. Core 1 ran a foreground application. The architectural claim made visible.

II.

Eleven Engineering Problems, Solved As One Integrated Platform

Each problem is presented with three components: what failed, why diagnosis was hard, and the specific solution. Problems 1–6 are T-Deck Plus discoveries. Problems 7–9 emerged porting to the T-LoRa Pager. Problem 10 is platform-wide (ELF runtime). Problem 11 is the Cardputer ADV result — proof the architecture generalizes to no-PSRAM hardware.

▸ On the word "first"

The novelty claim is in the integration target, not the components. Mutex-arbitrated SPI is not new. Dual-core task pinning is in the datasheet. PSRAM heap redirection is documented in ESP-IDF. Espressif's technical reference manual is exhaustive about every individual primitive on the ESP32-S3 — and it has no reason to document, and does not document, what happens when you ask the chip to run continuous wardriving plus an LLM client plus a 60fps UI plus LoRa mesh plus GPS, on shared peripherals, under a single multi-app OS, on three physically different devices spanning the entire memory tier of the chip class. That use case is downstream of the manual. The contribution is that no prior published ESP32-S3 project documents handling all of these together as one integrated platform — and the integration itself is the engineering, because the problems are not independent. The SPI Bus Treaty constrains what the encryption solution can look like. The dense-RF instability fix consumes stack budget the dual-core sync fix is also competing for. The PSRAM redirect changes what's possible for the deferred SD mount handling on the T-LoRa Pager. Solving any one in isolation is a weekend. Solving them in coordination, so they don't interfere with each other, is the actual work. The protocols are the deliverable — not the techniques they're built from, and not any individual problem's solution viewed in isolation.

Problem 1 · T-Deck Plus

The SPI bus conflict — and the protocol that solved it

What failed

The MicroSD card and the SX1262 LoRa radio share the ESP32-S3's SPI bus. Under sustained concurrent load (Ghost Engine writing wardrive CSV; LoRa mesh receiving), the device hit Guru Meditation panics with non-deterministic call stacks. Each crash pointed at a different instruction address.

Why diagnosis was hard

The Guru dump identified where, not why. The collision timing was non-deterministic, so the crash address changed every time. Bench environments did not reproduce — the collision requires both subsystems under sustained simultaneous load, which only occurs in field RF environments dense enough to keep both busy. No prior project on this hardware had operated both devices under that condition concurrently.

Solution — the SPI Bus Treaty

A formal four-rule arbitration protocol enforced by a recursive mutex (spi_mutex): (1) hit-and-run — open, write, close, release immediately; (2) no extended holds; (3) radio-traffic mutual exclusion via shared boolean flag; (4) destructive operations (the Nuke) run under Treaty discipline at boot, before the Ghost Engine spawns. v1.2.0 audit: 54 take sites, 56 give sites verified across 12 files. The Treaty is the public contract every component and every ELF module must obey. Published as a standalone whitepaper at spi-bus-treaty.html.

Problem 2 · T-Deck Plus

Memory exhaustion under simultaneous workloads

What failed

The ESP32-S3's 320 KB internal SRAM exhausted under concurrent wardrive, Gemini client, BLE scanner, GPS, LoRa, and UI. The 8 MB PSRAM was present but the heap allocator defaulted to internal SRAM. Different subsystems crashed depending on which allocation lost the race, presenting as N separate bugs.

Why diagnosis was hard

SRAM exhaustion has no single signature. The crashes appeared in unrelated code paths and read as independent failures until the pattern resolved into one root cause.

Solution

CONFIG_SPIRAM_USE_MALLOC=1 with a size threshold routes large allocations to PSRAM. The contribution is recognizing the pattern across apparently-unrelated crashes — not the flag, which is documented in ESP-IDF.

Problem 3 · T-Deck Plus

Dual-core SD synchronization corruption

What failed

Concurrent SD writes from Core 0 (Ghost Engine) and Core 1 (user apps) corrupted SdFat's internal linked-list structures. The heap walker entered an infinite loop, triggered the watchdog, and rebooted.

Why diagnosis was hard

Bench environment with one access point: rare. Downtown Los Angeles with 80+ APs and the Ghost Engine writing multiple times per second: near-certain. Root cause required correlating crash frequency with WiFi network density across multiple field sessions.

Solution

A FreeRTOS mutex created before either core starts. Every SD operation acquires the mutex with a timeout, executes, and releases immediately. A wifi_in_use boolean prevents the Ghost Engine and the AI client from operating the radio simultaneously. Validated downtown LA: 40+ access points, continuous Ghost Engine logging, zero crashes after implementation.

Problem 4 · T-Deck Plus

Dense RF environment instability

What failed

150+ concurrent BLE advertisers in real urban RF caused BLE callback stack overflow. The overflow corrupted adjacent memory, appearing as GPS parsing errors, display glitches, and unrelated reboots — three apparent symptoms from one root cause.

Why diagnosis was hard

Bench environments never exceeded twenty nearby devices. The bug was unreachable in a laboratory. Three apparently independent failure modes had to be correlated back to a single stack overflow.

Solution

BLE task stack sized for urban RF density. Scan result buffer hard-limited, with new results discarded when full rather than crashing. GPS UART receive buffer increased from 128 to 512 bytes with explicit drain loops around the blocking WiFi scan call. All three required simultaneously.

Problem 5 · T-Deck Plus

Security architecture under Treaty constraints

What failed

AES encryption of Ghost Partition data holds the SPI bus for extended periods during write operations — violating Treaty rule 2 and causing LoRa interrupt collisions through the same mechanism as Problem 1. The standard tool for the standard requirement crashed the device.

Why diagnosis was hard

Not solvable within the original framing. If AES write operations violate the Treaty and Treaty violations cause crashes, the requirement and the hardware constraint were irreconcilable as stated. The solution required reframing the threat model: not "how do we encrypt the data" but "what does the adversary actually need to access the data."

Solution — with honest limitations

Sector-level zero-overwrite of Ghost Partition index files before FAT unlinking, executed under spi_mutex at boot before Ghost Engine spawn. ~1 MB/sec sustained write; a typical session wipes in under 200ms; heavy sessions (2 MB+) take 2–3 seconds. The wipe defeats PhotoRec, Recuva, and TestDisk against the targeted files — no sector structure remains to reconstruct. Honest v1.2.0 limitation: the nuke target list in security_config.h hardcodes specific paths and filenames. A v1.2.0 audit identified that the wardrive CSV target paths in the list (/wardrive/wardrive_NN.csv) do not match the wardrive's actual output (/wardrive_NNNN.csv at SD root). v1.2.0 nuke therefore covers the Ghost Partition's index files but leaves wardrive session CSVs on the card. The right shape for the fix — dynamic discovery of sensitive files rather than a hardcoded target list — is identified; research on the cleanest implementation is ongoing. It does not defeat chip-off NAND forensics even within targeted files, due to SD controller wear-leveling: when a logical sector is overwritten, the controller may write to a different physical NAND block, leaving the old block intact but unmapped. A forensic lab can desolder the NAND IC and read physical blocks directly. The limitation is documented in the threat model. The architectural answer to both gaps — dynamic target discovery and physical-layer recovery — points toward an encrypted partition with key destruction, where destroying the key makes the data irrecoverable regardless of what wear-leveling retained. Research on this approach is ongoing and will land in a future release when the design is verified end-to-end.

Problem 6 · T-Deck Plus

Undocumented GPS module variation across production batches

What failed

LilyGo shipped T-Deck Plus units with two different GPS modules across batches operating at different UART baud rates. Code correct for one batch failed silently on the other — no error output, the GPS simply did not work. The variation was undocumented in official product documentation and absent from community forums at the time.

Why diagnosis was hard

Silent failure without exception is the hardest category of embedded hardware problem. The code was syntactically correct, compiled clean, and executed without error. The hypothesis "undocumented hardware-batch variation" is unreachable without prior knowledge that this type of manufacturing variation occurs.

Solution

Baud-rate auto-detection. The driver attempts initialization at each supported rate, validates NMEA sentence structure, and latches the first configuration that produces valid output. Future variants are handled without code changes.

Problem 7 · T-LoRa Pager port

GPIO 21 dual-function collision across hardware variants

What failed

On the T-Deck Plus, GPIO 21 is TOUCH_RST (GT911 capacitive touch reset). On the T-LoRa Pager, the same physical pin is SD_CS (SD card chip-select). The shared OS initialized touch at boot, pulling SD_CS low and corrupting the SD mount before any application code ran.

Why diagnosis was hard

Same SoC, same manufacturer, same product family — but completely different pin functions on two boards. The failure read as an SD driver issue, then an SPI timing issue, then a power sequencing issue before the GPIO collision hypothesis was reached. The LilyGo schematic PDF contained its own labeling errors that delayed root-cause identification.

Solution

Conditional compilation: all touch initialization gated on #ifdef DEVICE_TDECK_PLUS. Compile-time exclusion, not runtime disable — the GPIO state cannot be permitted to enter the wrong configuration even briefly during initialization. First documented case of this specific cross-device collision.

Problem 8 · T-LoRa Pager port

SPI bus state corruption across peripheral initialization

What failed

SD CMD0 returned 0xFF (no response) eight times consecutively on every cold boot, despite the same physical SD card mounting on the T-Deck Plus. Three independent causes converged on the same symptom: (1) Arduino-ESP32 core 2.0.16 SPI/SD driver bug, partially fixed in 2.0.17; (2) wrong default SPI pin map — the generic ESP32-S3 devkit pins are different from the T-LoRa Pager PCB; (3) bus state corruption from display and LoRa initialization leaving the SPI peripheral block in a state SD CMD0 refused to accept.

Why diagnosis was hard

Three independent root causes producing one symptom. Fixing any one in isolation did not fix the problem. All three required simultaneous resolution.

Solution — deferred mount with cold SPI restart

SD initialization deferred entirely out of the boot sequence into a background FreeRTOS task (late_sd_init_task) that runs after all other peripherals complete initialization. The task calls SPI.end(), waits 20 ms for the bus to discharge, calls SPI.begin() with the correct pin map as a cold restart, then retries the SD mount up to ten times. Apps poll a g_sd_ready flag with timeout before SD access. The T-Deck Plus does not require this pattern because its peripheral init sequence happens to leave SPI in an SD-mountable state — a coincidence, not a design guarantee. The deferred-mount pattern is now recommended for any new ESP32-S3 hardware target.

Problem 9 · T-LoRa Pager port

Ghost Engine silent failure — the phantom session file

What failed

The Ghost Engine ran full sessions on the T-LoRa Pager — WiFi scanning, BLE scanning, live counts incrementing in the UI — and wrote nothing to the SD card. The invariant that defines Pisces Moon OS — the device is always collecting — was silently violated. The device appeared to be collecting. It was not.

Why diagnosis was hard

No crash, no error, no indication. Three causes converged invisibly. The deferred SD mount completed after the wardrive task's 15-second startup window. A fallback path set a phantom session filename like /wardrive_0015.csv without ever calling sd.open() with O_CREAT. Subsequent writes used O_APPEND without O_CREAT — a flag combination that appends to existing files but cannot create missing ones. SdFat silently dropped every write. Only discoverable by transferring the SD card to another device and observing empty files.

Solution — lazy session-file creation

ensure_session_file() is called on every scan-loop iteration. It is a fast no-op once the filename is set. On the first iteration where g_sd_ready is true and sd_in_use is false, it claims the next available session via _find_next_session_number() and writes the CSV header. The filename is adopted only after the header write succeeds — if open or write fails, the next iteration retries cleanly. T-Deck Plus behavior is unchanged. The Ghost Engine invariant is restored on all targets.

Problem 10 · Platform-wide

ELF module execution without hardware isolation on a non-MMU SoC

What failed

Pisces Moon OS supports runtime ELF module loading from the SD card — compiled third-party applications deployed without reflashing the firmware. A buggy or malicious ELF module executing with full access to the OS address space can corrupt OS SRAM, crash the Ghost Engine, or panic the system. The ELF runtime in v1.1.x had no hardware boundary between module code and OS memory.

Why diagnosis was hard

The ESP32-S3 has no MMU and therefore no virtual address spaces. Standard OS isolation techniques — process boundaries, page table enforcement, address space randomization — are unavailable. The hardware does have a Permission Management System (PMS, documented in TRM Ch. 15), but it operates at the SRAM region level rather than the process level. Its use for runtime application isolation in a general-purpose OS has no published prior art on this hardware class.

Solution — three-layer sandbox

Layer 1: xt_set_exception_handler() registers a custom handler for PMS violation exceptions (EXCCAUSE_LOAD_PROHIBITED and EXCCAUSE_STORE_PROHIBITED) that intercepts before the ESP-IDF panic handler. If the faulting PC is inside the ELF PSRAM region, execution redirects to a fault trampoline in IRAM that kills the ELF task and returns the OS to the launcher — the Ghost Engine never pauses. If the faulting PC is in OS code, the original panic handler is invoked. Layer 2: Direct register writes to the PMS base address mark OS SRAM read-only during ELF execution and restore permissive defaults after exit. Layer 3: ELF runs in a dedicated FreeRTOS task at priority 5, below Ghost Engine priority 7, with semaphore-based completion signaling and a configurable timeout. Honest limitation: the sandbox protects against buggy ELFs, not adversarial code. The PMS write-protects OS SRAM but cannot prevent an ELF from reading arbitrary addresses. No MMU means no virtual address spaces — adversarial code with full read access can still leak. Documented as "buggy-resistant, not adversarial-proof."

Problem 11 · Cardputer ADV — the generalization proof

Concurrent multi-radio operation on no-PSRAM ESP32-S3

What failed

The M5Stack Cardputer ADV ships with the ESP32-S3FN8 variant: 320 KB internal SRAM, no PSRAM. Pisces Moon's entire memory architecture assumed 8 MB PSRAM availability. At the moment the wardrive task spawned, free heap measured 97 KB. WiFi initialization requires ~54 KB. NimBLE observer initialization requires ~48 KB. The honest read of the heap measurements was that concurrent multi-radio operation on this hardware was impossible.

Why it mattered

The Cardputer is the most accessible ESP32-S3 device in the M5Stack catalog. If Pisces Moon ran only on hardware with PSRAM, the platform thesis weakened — "the chip is more capable than its marketing implies" would only hold for the high-tier variants. The industry's expectation for a no-PSRAM ESP32-S3 is single-purpose firmware. The chip is sold and priced for that workload.

Solution — three architectural changes

Lazy app-state allocation: every always-on app buffer was moved from static memory to app-lifetime allocation. Mesh Messenger channel buffers, audio playlists, RetroPack ROM tables, ELF browser app lists, recorder file metadata — all allocated on app entry, released on app exit. The OS no longer reserves RAM for dormant apps. Result: 81 KB of static memory returned to the heap before the user did anything. Static footprint dropped 190 KB → 109 KB. Free heap at task spawn: 97 KB → 219 KB.

WiFi mode-locking with hard teardown: CLIENT mode (Gemini client) and SCANNER mode (wardrive) made mutually exclusive at the OS level. Mode transitions perform full esp_wifi_stop() and esp_wifi_deinit() teardown before re-init in the new mode. Hardware-honest arbitration, not software-flag arbitration.

PlatformIO PSRAM-flag isolation: -DBOARD_HAS_PSRAM defines stripped from the Cardputer build target. The ESP-IDF heap allocator no longer attempts PSRAM allocations that would silently fall through to internal SRAM.

Verified result (May 2026): 219 KB free heap after WiFi STA init. 174 KB after NimBLE observer init. 125 KB free heap during active wardrive scanning with 24 BLE devices, 14 WiFi networks, and GPS lock at 27 satellites. Four concurrent radios. Real-time SD logging. Persistent multi-app state. 47 applications. On a chip with 320 KB total internal SRAM and no PSRAM.

Two-device mesh validation (bench, May 20, 2026): Mesh Messenger send/receive confirmed between T-Deck Plus and Cardputer ADV with Cap LoRa-1262 on the LongFast channel, concurrent with active wardrive logging on both devices and SD transcripts written to /mesh_logs/messages.csv. The same Mesh Messenger application, same LoRa protocol, same SPI Bus Treaty discipline, holding across the 8 MB PSRAM and no-PSRAM ends of the chip tier simultaneously.

▸ Why Problem 11 is different

Problems 1–10 prove the operating system works. Problem 11 proves the architecture works. The same Treaty, the same Ghost Engine model, the same ELF sandbox, the same application catalog — generalized from 8 MB of PSRAM down to zero PSRAM, with no change to the user-facing application contract. The Cardputer running Pisces Moon is, to the best of our knowledge, the most capable multi-radio handheld operating system shipping on a no-PSRAM microcontroller in the current market. The methodology — name the constraint, document the protocol — held across the entire memory tier of the chip class.

III.

The Methodology

The eleven problems share a structure. Each involved a behavior the hardware permits but the documentation does not constrain. Each surfaced under conditions — sustained concurrency, dense RF, hardware-variant edge cases, no-PSRAM extremes — that prior projects on this hardware had not produced. Each was solved by writing down what the unconstrained behavior must become, and enforcing it as a contract.

The methodology is three steps:

Name the constraint. The hardware permits behavior X. The system requires behavior Y. The gap is named — "SPI Bus Treaty," "WiFi Mode-Locking," "Lazy App-State" — so it can be referenced in code, reviewed in commits, and enforced at module boundaries.
Document the protocol. The constraint is written down as a finite set of rules that every component must obey. The Treaty has four rules. WiFi mode-locking has three. Lazy app-state has one. The rules are short enough to be remembered and specific enough to be checked.
Make it a platform contract. The rules are not "best practice" — they are obligations binding on first-party OS code, third-party ELF modules, and any future hardware target. Violation produces immediate crashes or test failures. The contract is enforced by code, audit, and convention together.

The SPI Bus Treaty is one expression. The UART Peripheral Map on the ESP32-P4 is another — four UART controllers across four physical connections, formal role assignments, zero collisions. Lazy app-state allocation on the Cardputer ADV is a third — the assumption "always-on apps deserve always-on memory" named, removed, replaced with an explicit lifetime contract. Three protocols, three hardware contexts, one methodology. The protocols are deliverables. The methodology is the contribution.

The historical precedent is instructive: Unix filesystem locking conventions (1970s) established formal rules for competing processes sharing a filesystem. The Apollo Guidance Computer's priority scheduling protocol (1969) established formal rules for competing tasks sharing a processor under load. Nintendo's N64 RSP time budget (1996) established formal rules for competing subsystems sharing a signal processor. In each case the solution was a protocol — a named standard that could be taught, documented, and enforced across an entire platform. The contribution here is applying that pattern to a hardware class where no published prior expression existed.

IV.

Platform Architecture

Pisces Moon is not a single product. It is a platform with two architecturally distinct application tiers, deployed across seven hardware targets, composable through a documented protocol.

A note on terminology: whether the Tier 1 deliverable is "an operating system" or "firmware" is sometimes debated. The honest answer is that both are true. It is an embedded OS by every definition that matters to a user — preemptive multitasking, dual-core scheduling, app runtime, persistent background services, hardware-enforced inter-app isolation, shared platform contracts — and it is firmware by the definition that matters to a chip vendor, because it is the thing that gets flashed. The distinction stopped being useful around the time iOS shipped. The paper uses "OS" because that is the property that matters for the engineering claim being made.

Two application tiers

Tier 1 — Native firmware (ESP32 family). C/C++, FreeRTOS, direct hardware access. 47–57 applications per device, compiled into the firmware binary. The Ghost Engine, the SPI Bus Treaty, the Ghost Partition, the ELF module runtime, the UART peripheral map — all live at this tier. Tasks pinned to specific cores; mutexes governing shared hardware; real-time constraints enforced at the compiler level.

Tier 2 — HTML/JS application layer (x86/ARM, Android, browser). 77 self-contained HTML files, each single-file and dependency-free where possible. Runs in a browser or Chromium window with no installation. Deploy with cp. Update with git pull. Runs on Linux x86/ARM, Android APK, the Luckfox Pico 86 Panel (RV1106 / Buildroot), and any modern browser. It does not run on ESP32 hardware. It is not the same layer as the native firmware.

Seven deployment targets

Target 1 — T-Deck Plus ($50) · Tier 1 · Validated

LilyGo T-Deck Plus — ESP32-S3 at 240 MHz, 8 MB PSRAM, QWERTY keyboard, LoRa radio, GPS, WiFi, BLE, I2S audio, MicroSD. 49 native applications. The Ghost Engine runs on Core 0 continuously. The SPI Bus Treaty is the architectural standard that makes this possible. ELF module runtime for SD-card app deployment without reflashing. Ghost Partition security with sector-overwrite Nuke.

Target 2 — T-LoRa Pager ($45) · Tier 1 · Validated

LilyGo T-LoRa Pager — ESP32-S3 at 240 MHz, 8 MB PSRAM, QWERTY keyboard, LoRa radio, GPS, WiFi, BLE, MicroSD. 52 native applications. Validated alongside the T-Deck in field operation May 2026. The port surfaced Problems 7, 8, and 9 — GPIO collision, SPI bus state corruption, and silent session-file failure. The successful port validates the platform thesis: same OS, same Treaty, same Ghost Engine, two physically different devices in the same product family.

Target 3 — Cardputer ADV ($50) · Tier 1 · Validated

M5Stack Cardputer ADV — ESP32-S3FN8, no PSRAM, 320 KB internal SRAM, compact keyboard form factor. With the Cap LoRa-1262 expansion: SX1262 LoRa at 27 dBm plus AT6668 multi-constellation GPS. 47 native applications. Problem 11 result. Four concurrent radios in active operation on hardware the industry treats as incapable of running a multi-app OS.

Target 4 — Pisces Moon Linux (free) · Tier 2 · Validated

Linux distribution targeting x86 and ARM hardware the industry has declared obsolete. Primary reference: Fujitsu Stylistic Q508 ($50–$100 secondary market). 77 HTML applications across 11 categories running in Chromium, no installation beyond a browser. pm_bridge.py daemon unifies T-Deck radio data with the host machine's own radios. WiGLE 1.4 compatible wardrive output. The application file is the application — copy it, run it.

Target 5 — Android APK · Tier 2 · Validated

The 77-application HTML suite wrapped as a native Android APK. Thin wrapper, Chromium rendering, local file access, no telemetry. The wardrive runs as a background service — Android handles concurrent processes natively. Swipe out of Pisces Moon and the phone looks like a phone.

Target 6 — Luckfox Pico 86 Panel · Tier 2 · Validated

RV1106-based embedded Linux panel running a Buildroot environment with LVGL. Dedicated serial daemon plus LVGL application layer. A $30–$50 embedded panel running the same sovereign stack as the $350 field device. The application layer adapts to the form factor.

Target 7 — ESP32-P4 (ELECROW CrowPanel 7") · Tier 1 · Alpha

New silicon class: dual RISC-V HP cores at 360 MHz, low-power Sentinel core at 40 MHz, 32 MB HEX PSRAM at 200 MHz, MIPI-DSI output to a 1024×600 display. The Ghost Engine runs on a separate chip entirely — an ESP32-C6 connected via SDIO — in a four-core architecture: Ghost Engine (C6 radio brain), OS Core (HP Core 0), UI Core (HP Core 1), Sentinel Core (LP Core, software PMU). The UART Peripheral Map replaces the SPI Bus Treaty as the P4 shared-resource protocol. The methodology is identical. The hardware constraint is different. 57 apps registered. Launcher rendering. Touch navigation operational. First boot May 13, 2026.

Application catalog vs. retail comparison

Capability	Pisces Moon (T-Deck Plus, ~$350 full kit)	Nearest commercial equivalent
Form factor	Pocket handheld	$500–$2,000 ruggedized edge device
LoRa mesh radio	Native, infrastructure-free	Rare, usually external module
Passive wardriving	Continuous, Core 0, background	Separate device + manual operation
GPS + RF correlation	Continuous, automatic	Separate device or application
AI integration	Direct Gemini API, operator-provided key, no intermediary	Cloud-dependent, vendor-controlled
Security partitioning	PIN-gated Ghost Partition with filesystem-level separation; logical-wipe Nuke (v1.2.0 targets index files; broader coverage and physical-layer hardening are research-ongoing)	Software-level at best
App deployment	ELF modules via SD card, no reflash	Full firmware reflash required

pm_bridge.py — The Host Intelligence Daemon

The T-Deck Plus is the field device. pm_bridge.py is what turns any laptop, tablet, or Android phone into the analysis workstation that receives its data stream.

pm_bridge.py is a 2,754-line Python daemon with no external dependencies beyond pyserial and websockets. It runs on macOS, Linux, Windows, and Android (via Termux). It serves as the hardware abstraction layer for the 77-application HTML suite, unifying three data sources into one JSON protocol over ws://127.0.0.1:8080:

T-Deck Plus or T-LoRa Pager over USB serial at 921600 baud. GPS-tagged WiFi, BLE, probe requests, LoRa mesh links, and promiscuous-mode 802.11 frames as JSON events. The richest data source — GPS correlation, monitor mode, LoRa.
Host OS radios. macOS CoreWLAN and CoreBluetooth; Linux nmcli and bluetoothctl; Windows netsh; Android termux-wifi-scaninfo. The operator's own machine is the sensor when no field device is connected.
77 HTML apps as WebSocket clients. Apps never know whether data came from the field device or the host machine. The bridge abstracts the source; the apps consume a consistent event stream.

Wardrive output is written in WiGLE 1.4 CSV format. Field sessions are bundled into .pmsession ZIP archives with a manifest.json — portable across devices and analysis tools. Promiscuous-mode 802.11 capture streams at 921600 baud (115200 saturates at ~58 frames/sec); deauth flood detection triggers automatically above ten deauthentication frames in 60 seconds.

VI.

Live Demonstration Plan

The demo is structured to make the engineering claim visible. The devices boot with the Ghost Engine already running. The audience sees architecture in operation, not architecture explained.

Step 1 · 4 min

The Ghost Engine on three devices

T-Deck Plus, T-LoRa Pager, and Cardputer ADV side by side. All three Core 0 wardrive counters incrementing visibly. The Cardputer running on 320 KB SRAM with no PSRAM. Same engine, same protocol, same data — three hardware contexts.

Step 2 · 3 min

Concurrent foreground on Core 1

Switch apps on Core 1 — Snake, Chess, the Gemini terminal. The Ghost Engine counters do not pause. Preemptive multitasking under load on a microcontroller, with the foreground responding in real time.

Step 3 · 3 min

The Treaty enforced in source

Live walk through spi_mutex_take() sites in the codebase, projected. Same protocol enforced in 54 take sites across 12 files. Audit script run on stage shows zero violations.

Step 4 · 3 min

ELF sandbox proof

Load an ELF module that deliberately writes to OS SRAM. The PMS exception handler catches it. The ELF task is killed. The launcher returns. The Ghost Engine on Core 0 never paused during the violation.

Step 5 · 3 min

Nuke under Treaty discipline

Ghost Partition index wipe on synthetic demo data. Display shows bytes wiped and elapsed time. PhotoRec attempted post-wipe against the targeted index files — recovers nothing from those files. The v1.2.0 target-list gap (wardrive CSVs not covered by the current hardcoded list) is acknowledged on stage; research on the dynamic-discovery fix is ongoing. Chip-off NAND limitation also acknowledged honestly.

Step 6 · 2 min

Bridge stream live

T-Deck wardrive data streaming to a host laptop via pm_bridge.py. Edge node architecture made visible: device collects, host receives, both operator-controlled.

Failure mode: If conference RF policy or live conditions prevent active collection, the same firmware replays a captured field session with identical visible behavior. The architecture, codebase, and live device state remain inspectable throughout. The code is public and verifiable at any point during or after the talk.

VII.

Verifiability and Prior Art

Every technical claim in this paper is verifiable against a public codebase. The repositories are AGPL-3.0 licensed. The relevant commits, files, and line ranges for each problem are referenced below.

Repositories — public, AGPL-3.0 Firmware (ESP32-S3, ESP32-P4): github.com/FluidFortune/pisces-moon-os
Linux / Android / Bridge: github.com/FluidFortune/pisces-moon-linux
Browser demo: piscesdemo.fluidfortune.com
In-browser IDE with Web Serial flash: lety.fluidfortune.com Companion documents Engineering Record — full architectural reference: engineering-record.html
SPI Bus Treaty — standalone whitepaper: spi-bus-treaty.html
Device Architecture — three Tier 1 devices compared: device-architecture.html Prior art search (conducted 2025–2026) Searches across GitHub (ESP32-S3 + concurrent SPI + LoRa + SD), Espressif forums, Hackaday, Reddit r/esp32, ESP32 community Discord servers, and the IEEE Xplore embedded-systems index returned no published reference for: (a) a named SPI arbitration protocol on the ESP32-S3 chip class; (b) hardware-enforced ELF sandboxing on a non-MMU SoC using PMS plus Xtensa exception hijack; (c) concurrent four-radio operation on the no-PSRAM ESP32-S3FN8 variant. If reviewers can identify prior art for any of these, please contact the author — the document will be updated to credit it. Field validation record 83+ field sessions logged 2025–2026 — Lincoln Heights, downtown Los Angeles, Pasadena, Mt Tam area. Lincoln Heights demo video: youtu.be/UmZXQFjDws8. T-LoRa Pager and T-Deck Plus simultaneous field operation: May 15, 2026. Cardputer ADV four-radio confirmation: May 2026. Two-device mesh send/receive between T-Deck Plus and Cardputer ADV with Cap LoRa-1262 confirmed at the bench May 20, 2026, concurrent with active wardrive logging on both devices.

VIII.

The Sovereignty Argument

The engineering above is in service of a single principle: that the compute belongs to the person running it.

The SPI Bus Treaty exists so that the Ghost Engine and the LoRa mesh radio can coexist without crashing — because a device that can only do one thing at a time is not sovereign, it is limited. The Ghost Partition exists so that sensitive data is invisible without authentication and irrecoverable by software file-recovery tools — because data the operator cannot protect is not theirs. The ELF module runtime exists so that new applications can be deployed without vendor permission — because a device the operator cannot extend without someone else's approval is not theirs. AI integration routes directly through the operator's own API key or browser session — no intermediary, no vendor logging.

This is not a privacy argument, though privacy follows from it. Not a security argument, though security follows from it. Not a cost argument, though cost reduction follows from it. It is the foundational claim that the person using the compute should be the person in control of the compute. The engineering documented above is what enables that claim to hold under load, under field conditions, on hardware the industry has dismissed. Sovereignty is not asserted in this paper. It is implemented.

IX.

Speaker Note

I am Eric Becker — independent forge, Fluid Fortune. I have not previously spoken at DEF CON. The technical work in this submission was done over eighteen months on personal hardware in personal time, without institutional support, employer affiliation, or sponsor relationship. The talk is the result.

What I can demonstrate on stage:

Three working devices running the operating system this paper describes.
The codebase open in an editor, with the engineering decisions referenced live against specific files and line numbers.
A live Ghost Engine collection while the talk runs — counters on a back screen, visible to the audience.
The ELF sandbox enforcement in real time using a deliberately-malformed module loaded from SD.
Field data from the 83+ session logs, mapped, queryable, inspectable.

What I am not claiming:

That mutexes are new — they are not.
That the ELF sandbox is adversarial-proof — it is not; limitations are documented.
That the Nuke defeats nation-state forensics — it does not. v1.2.0 covers Ghost Partition index files; the wardrive CSV target-list gap is acknowledged and research on a dynamic-discovery fix is ongoing. Chip-off NAND recovery remains a real attack vector against wear-leveled flash regardless of target list. The architectural answer points toward an encrypted partition with key destruction; that approach is research-ongoing and will land when the design is verified end-to-end, not on a fixed release timeline.
That the PIN is unrecoverable. It is not. The PIN is compiled into firmware.bin as a plaintext literal — protected against users with only on-device access, but extractable via esptool.py read_flash by anyone with USB access on devices without Secure Boot v2 + Flash Encryption. Production deployments require Secure Boot v2; enabling it is a one-way eFuse operation and is research-ongoing for production builds.
That the methodology is unique. It is borrowed — from Unix file locking, the Apollo Guidance Computer priority scheduler, Nintendo's N64 RSP time budget. The contribution is applying that pattern to a hardware class where no published prior expression existed.

The talk lands because the codebase exists, the devices boot, and the engineering survives reading. The submission is offered for review on those terms.

Pisces Moon OS — v1.2.0 "Multi-Device" — May 2026

Eric Becker · Fluid Fortune · forge@fluidfortune.com

GitHub: github.com/FluidFortune

Licensed under AGPL-3.0. All technical claims verifiable against the public codebase.

DEF CON 34 CFP — Submission ID 1349.