neitzert/picardProtocol-Introspecting Chunk Adapter for Resilient Data
Protocol-Introspecting Chunk Adapter for Resilient Data
For the self-taught, the unconventional, and anyone who was ever told to stay in their lane. Keep building, keep exploring.
PICARD encrypts your data, slices it into chunks, and scatters those chunks across whatever protocol endpoints you configure: DNS TXT records, social media APIs, MQTT brokers, S3 buckets, Bluetooth advertisements, or all of the above at once. Pull it back and it reassembles. With multi-adapter scatter, no single endpoint holds enough ciphertext to reconstruct anything. No central server. No monthly storage fees. It mounts as a regular filesystem.
Not efficient. Protocol-agnostic.
[!IMPORTANT] Research project. PICARD is a working computer science experiment, not a production storage system. Read the research and legal notice before you proceed.
[!WARNING] Experimental: Run at your own risk. These adapters use hardware vulnerabilities as storage primitives. Results are hardware-specific, non-deterministic across machines, and irreversible in the case of DRAM bit flips. Use only on hardware you own and control. Running against shared or cloud infrastructure is unauthorized access in most jurisdictions.
PICARD can now store chunks in DRAM bit states and CPU cache residency -- entirely outside the operating system's view.
| Adapter | What it does |
|---|---|
rowhammer | Writes bits by hammering adjacent DRAM rows until charge leakage flips target bits. Reads by examining the victim row directly. Local, ephemeral, non-ECC DDR3/4. |
halfdouble | Two-hop variant. Near/far aggressor ratio bypasses DDR4 Target Row Refresh (TRR). Reaches hardware that classic rowhammer no longer affects. |
throwhammer | Hammers a remote host's DRAM over RDMA. The remote CPU is not involved at all -- the NIC DMA-reads directly to DRAM. Requires RDMA fabric. |
cpu-cache | Stores bits in CPU L3 SRAM via Flush+Reload. N_REPS=5 majority-vote encoding across page-isolated slots. BER below 5e-4 on i7-12700KF. Cross-process on the same host; cross-VM where page deduplication is active. |
All four are ephemeral (power cycle erases). See docs/adapters.md for hardware requirements and threat model.
plaintext
→ AES-256-GCM encrypt (Argon2id key, per-block salt + nonce)
→ PCHK chunk (protocol-sized pieces)
→ scatter across adapters (DNS, Redis, Reddit, S3, MQTT, …)
→ sealed envelope (HKDF sub-key, correlation tag per adapter)
retrieve
← fan out to all adapters
← collect, verify, assemble
← decrypt
Each block is independently encrypted with its own random salt and nonce. Chunks scatter round-robin or via RAID profiles. No adapter sees plaintext; no adapter sees enough ciphertext to reconstruct anything.
The local index (an AES-256-GCM encrypted SQLite database) maps paths to chunk locations. Lose the passphrase, lose the data.
It was a cool Berlin morning. From my patio I stared at a plain stucco wall capped by red brick. A blur of wings caught my eye, a small bird veering into a drain hole near the roofline and vanishing. Another head appeared from a different hole, chirping. Five drain holes, five nests. The gutters were meant to move water, not host families, yet the birds had found shelter, cover, and easy access. I had never noticed because I had never bothered to look.
Our digital infrastructure carries more than it was designed to store. DNS TXT records accept arbitrary text within spec. MQTT retained messages persist data on the broker. ICMP echo packets carry a payload field. Social media APIs accept freeform structured text. Each of these protocols defines fields intended for metadata, discovery, or diagnostics. Those fields can carry bytes just as well as their designers' intended use cases.
picard web opens a browser dashboard at http://localhost:8471.
Storage surface by category, adapter health, and encryption details at a glance.
259 adapters browsable by category, with required parameters and one-click add.
pip install picard-store
export PICARD_PASSPHRASE="your-passphrase" # or picard will prompt
picard init # create picard.toml
# edit picard.toml to add your adapters, then:
picard put myfile.txt --as /docs/myfile.txt
picard get /docs/myfile.txt -o recovered.txt
picard ls
picard tree /
From source:
git clone https://github.com/neitzert/picard
cd picard
pip install -e ".[dev]"
python -m pytest --tb=short -q
# picard.toml
[general]
block_size = 65536
[[adapters]]
name = "dns-primary"
type = "dns"
enabled = true
params = { nameserver = "10.10.10.10", domain = "chunks.example.com" }
[[adapters]]
name = "s3-backup"
type = "s3"
enabled = true
tor_proxy = true # route through Tor SOCKS5
params = { bucket = "picard-chunks", prefix = "data/" }
[[adapters]]
name = "reddit-stash"
type = "reddit"
enabled = true
browser_mode = "headed" # api | headless | headed
params = { subreddit = "u_myuser" }
[[raid]]
level = "raid5"
adapters = ["dns-primary", "s3-backup", "filesystem"]
[scatter.paranoid]
raid_level = "raid10"
min_adapters = 4
Scatter profiles: quiet, resilient, speed, paranoid
| Command | Description |
|---|---|
picard put <file> --as <path> | Store a file |
picard get <path> -o <file> | Retrieve a file |
picard ls [path] | List files |
picard rm <path> | Delete |
picard cp / mv | Copy / rename |
picard tree / | Directory tree |
picard verify <path> | Chunk integrity check |
| Command | Description |
|---|---|
picard mkdir / ln / head / tail / touch / log / stat / find | Standard filesystem operations |
picard fsck | Consistency check and repair |
picard mount <mountpoint> | FUSE mount |
picard webdav | WebDAV server (port 8471) |
| Command | Description |
|---|---|
picard web | Web dashboard (dark/light, drag-and-drop) |
picard scatter-report | Storage surface map |
picard adapters / profiles | List adapters and scatter profiles |
picard recover | Journal crash recovery |
picard tor-check / tor-serve / tor-peer / tor-mount | Tor operations |
picard init | Create default picard.toml |
Most commands accept --json for machine-readable output.