csCardputer - Cardputer Adv firmware with security enhancements
Started by hardened_malloc 1984c4b048aecbf9... ·
Hey, I maintain csCardputer, a fork of ratspeak's rsCardputer standalone LXMF/Reticulum firmware for the Cardputer Adv.
Repository: https://github.com/cryptspeak/csCardputer
Web flasher: https://cryptspeak.github.io/webFlasher/
The project started from one goal: adding proper at-rest encryption.
While Reticulum already provides strong end-to-end encryption on the network, the original firmware stored identities, messages, contacts and configuration as plaintext in persistent storage. If someone had physical access to the device, they had access to everything. csCardputer encrypts all persistent data, including the Reticulum identity, LXMF messages, contacts and settings.
Encryption uses AES-256-CTR with HMAC-SHA256 (encrypt-then-MAC). The Reticulum identity is protected with a password using PBKDF2-HMAC-SHA256, and once unlocked it serves as the root secret for deriving independent encryption keys for each category of stored data using HKDF-SHA256. Existing rsCardputer installations can be migrated directly on first boot without losing data.
While the project began as an encryption-focused fork, it has since evolved into a standalone firmware focused on reliability and security for day-to-day LXMF messaging.
A lot of work over the last releases (v0.0.1 → v0.1.2) went into fixing issues that only show up under sustained use: TCP transport stability, name persistence, routing state consistency across reboots, and making sure the system behaves predictably when nodes are unstable or heavily loaded.
Since then, the fork has accumulated a number of improvements beyond encryption:
- Duress password — optionally securely erases stored data and reboots into first-time setup
- Auto-lock — optional, after a configurable period of inactivity
- Listen-before-talk for LoRa to reduce collisions on shared channels
- Fixed packet deduplication behaviour in microReticulum under sustained traffic
- Background LXMF proof-of-work stamps — allows communication with peers that require stamps
- Persistent LXMF routing and reply information across reboots
- Improved peer name resolution using the Reticulum announce cache
- GPS-based clock synchronisation
- Radio diagnostics — live RSSI, SNR, throughput and packet statistics
- Theme system — presets and a built-in editor with RGB sliders and hexadecimal colour input; themes also apply to the boot screen
- UI/UX rework across settings — popups unified, clearer mode selection (not fully polished)
One feature that is not currently included is propagation node support for offline messaging. I had an implementation in progress in an earlier prerelease, but it introduced reliability issues in routing and message delivery that I wasn't comfortable shipping. I'd rather leave the feature out until it can be implemented properly than carry something unreliable.
While reviewing the code, I noticed that signature verification in microReticulum wasn't actually being performed. After investigating, it turned out this matched a previously disclosed vulnerability that hadn't yet been picked up. I immediately included the fix into csCardputer, and opened an Issue at rsCardputer. Since then the fix has been applied upstream.
Hardware support is currently limited to the Cardputer Adv with the SX1262 LoRa cap.
The project is still in beta and maintained by a single developer, but it has become stable enough that I'm interested in broader testing. If anyone tries it on real hardware, bug reports, testing feedback and compatibility notes are very welcome.
I don't have any media to share for privacy reasons. If anyone tries csCardputer and is willing to share a few photos or a short video in this thread, I'd appreciate it. I'd also love to feature some community media on the GitHub project page, with permission.
Have fun testing! Feedback is appreciated.
One question i always wanted to ask anyone who was looking at this problem is why not leverage a hardware solution from say IOT? NXP SE050E looks like it fits the spec but im very far from being an expert. Just figured thats the direction things might move eventually.
For some reason ratspeak on cardputer isn't kept up to date on the cardputer adv launcher, so if you're willing to add cscardputer to the Launcher (and keep it updated) I'll run it 😀
scottyrice wrote:
For some reason ratspeak on cardputer isn't kept up to date on the cardputer adv launcher, so if you're willing to add cscardputer to the Launcher (and keep it updated) I'll run it 😀
Thank you for point this out. It simpy didn't cross my mind, since I was very focused on the technical aspects. I will add it in the upcoming days, and of course keep it updated.
scottyrice wrote:
For some reason ratspeak on cardputer isn't kept up to date on the cardputer adv launcher, so if you're willing to add cscardputer to the Launcher (and keep it updated) I'll run it 😀
Sorry for the delay - I ended up going down a rabbit hole looking into M5Burner (the source M5Launcher pulls cscardputer's firmware from) and found a bunch of security issues along the way that I didn't want to just ignore. Wrote up what I found here: https://malloc.pw/2026/07/11/m5burner-is-a-mess/. Also wrote an alternative for that matter, tho it lacks flashing capabilities: https://github.com/cryptspeak/m5uploader.
Once that's settled I'll get cscardputer added to the Launcher itself and keep it updated going forward, as promised.