Description
The idea to carry your precious key material along in a specially secured hardware item is almost as old as public keys themselves, starting with the OpenPGP card. Nowadays, an USB plug or NFC are the hardware interfaces of choice, and password-less log-ins are fortunately becoming more popular and standardised.
Meanwhile there are a few products available in that field, for example
yubikey - the "market leader", who continues to sell off buggy, allegedly unfixable firmware ROMs from old stock. Needless to say, it's all but open source, so assume backdoors.
nitrokey - the "start" variant is open source, but the hardware was found to leak its flash ROM content via the SWD debugging interface (even when the flash is read protected !)
solokey(2) - quite neat hardware, with a secure enclave called "TrustZone-M". Unfortunately, the OSS firmware development is stuck in a rusty dead end and cannot use it.
I plan to base this project on the not-so-tiny USB stack, which is extremely easy to retarget, and to rewrite / refactor the crypto protocols to use the keys only via handles, so the actual key material can be stored securely. My Initial testbed is the devkit for the solokey2, the NXP LPCXpresso55S69.
Goals
Create a proof-of-concept item that can provide a second factor for logins and/or decrypt a PGP mail with your private key without disclosing the key itself. Implement or at least show a migration path to store the private key in a location with elevated hardware security.
Resources
LPCXpresso55S69, tropicsquare tropic01, arm-none cross toolchain
This project is part of:
Hack Week 25 Hack Week 24
Activity
Comments
Be the first to comment!
Similar Projects
Creating test suite using LLM on existing codebase of a solar router by fcrozat
Description
Two years ago, I evaluated solar routers as part of hackweek24, I've assembled one and it is running almost smoothly.
However, its code quality is not perfect and the codebase doesn't have any testcase (which is tricky, since it is embedded code and rely on getting external data to react).
Before improving the code itself, a testsuite should be created to ensure code additional don't cause regression.
Goals
Create a testsuite, allowing to test solar router code in a virtual environment. Using LLM to help to create this test suite.
If succesful, try to improve the codebase itself by having it reviewed by LLM.
Resources
Smart lighting with Pico 2 by jmodak
Description
I am trying to create a smart-lighting project with a Raspberry Pi Pico that reacts to a movie's visuals and audio that involves combining two distinct functions: ambient screen lighting(visual response) and sound-reactive lighting(audio response)
Goals
- Visuals: Capturing the screen's colour requires an external device to analyse screen content and send colour data to the MCU via serial communication.
- Audio: A sound sensor module connected directly to the Pico that can detect sound volume.
- Pico 2W: The MCU receives data fro, both inputs and controls an LED strip.
Resources
- Raspberry Pi Pico 2 W
- RGB LED strip
- Sound detecting sensor
- Power supply
- breadboard and wires
Capyboard, ESP32 Development Board for Education by emiler
Capyboard is an ESP32 development board built to accept individual custom-made modules. The board is created primarily for use in education, where you want to focus on embedded programming instead of spending time with connecting cables and parts on a breadboard, as you would with Arduino and other such devices. The board is not limited only to education and it can be used to build, for instance, a very powerful internal meteo-station and so on.
- github.com/realcharmer/capyboard
- github.com/realcharmer/capyboard-starter
- github.com/realcharmer/capyboard-docs
- github.com/realcharmer/capyboard-examples
- docs.capyboard.dev
Hack Week 25
My plan is to create a new revision of the board with updated dimensions and possibly even use a new ESP32 with Zigbee/Thread support. I also want to create an extensive library of example projects and expand the documentation. It would be nice to also design additional modules, such as multiplexer or an environment module.
Goals
- Implement changes to a new board revision
- Design additional modules
- Expand documentation and examples
- Migrate documentation backend from MkDocs to Zensical
Hack Week 24
I created a new motherboard revision after testing my previous prototype, as well as a light module. This project was also a part of my master's thesis, which was defended successfully.
Goals
- Finish testing of a new prototype
- Publish source files
- Documentation completion
- Finish writing thesis
Backfire TV - Take back control of your Firestick by andreabenini
Take Back Control of Your Amazon Firestick.
Tired of Ads, a cluttered launcher, and buttons you can't change? BackFireTV is a project to liberate your Firestick from Amazon's walled garden and make it truly yours. They call it the firestick. To fight fire with fire, you need a backfire.
That's the soul of BackFireTV. To truly liberate it and return back to its core capabilities this project uses a linux script, one Android app and ADB access against Amazon's restrictive policies. We leverage these internal tools to create a "backfire" against the incessant ads and locked ecosystem, transforming your Firestick back into the useful, customizable device it was always meant to be.
The Problem
The Amazon Firestick starts as an excellent, affordable streaming device. However, Amazon's
aggressive Ad policies and restrictive ecosystem have turned it into an increasingly annoying
and a less useful device. It comes with frustrations:
- Messy interface. The less the better was probably the best slogan for the early device,
its interface is now cluttered and chaotic when you probably need just a couple of buttons
for starting your favorite applications.
- Constant Ads. The default launcher is filled with commercials and sponsored content.
- Bloated Interface. A cluttered and slow home screen you can't customize.
- Locked Buttons. Dedicated buttons for services you don't use (like popular streaming
providers) that can't be easily changed.
- Lack of Control. A closed ecosystem that limits what you can do.
I could overlook them all if the device was provided for free. But since you pay and you own it it should be legit to do whatever you please in your personal device and network.
The Solution: BackFireTV
BackFireTV hacks your Firestick to give you back control. It uses a clever system of DHCP hooks
and ADB (Android Debug Bridge) commands to remotely manage your device, block annoyances and
customize your experience from the moment it connects to your network.
The dhcp lease action starts a nohup command on the firestick and forgets about it, the daemon
then manages running programs, hacks remote control features and keys. It can be paused or
resumed, no rooting required.
Features
- Custom Launcher. Automatically replaces the default Amazon launcher with the lean and clean Wolf Launcher.
- Ad-Free Experience:. Blocks annoying ads and sponsored content for a cleaner interface.
- Button Remapping. Reprogram the physical buttons on your remote. For example, make the Disney+ button launch Kodi or your favorite application.
- Works on every firestick 4K. Tested on: Firestick TV 4k (1st/2nd gen), Firestick TV 4k Max.
- No rooting required. It runs on basic user permissions with standard privileges. It also works on standard devices: latest firmware, with or without external hw attached (usb storage, network cards, usb hubs, ...).
- No banned apps. This hack relies on the linux subsystem underneath, no matter what Amazon does on the AppStore, this script can always be sideloaded and cannot be banned (no fingerprints on android app layer).
- Toggle to default anytime. Standard amazon launcher can still be toggled any time for administrative tasks or just as a comparison. Feel free to manage it as usual and switch back to
vex8s-controller: a kubernetes controller to automatically generate VEX documents of your running workloads by agreggi

Description
vex8s-controller is an add-on for SBOMscanner project.
Its purpose is to automatically generate VEX documents based on the workloads running in a kubernetes cluster. It integrates directly with SBOMscanner by monitoring VulnerabilityReports created for container images and producing corresponding VEX documents that reflect each workload’s SecurityContext.

Here's the workflow explained:
- sbomscanner scans for images in registry
- generates a
VulnerabilityReportwith the image CVEs - vex8s-controller triggers when a workload is scheduled on the cluster and generates a VEX document based on the workload
SecurityContextconfiguration - the VEX document is provided by vex8s-controller using a VEX Hub repository
- sbomscanner configure the VEXHub CRD to point to the internal vex8s-controller VEX Hub repository
Goals
The objective is to build a kubernetes controller that uses the vex8s mitigation rules engine to generate VEX documents and serve them through an internal VEX Hub repository within the cluster.
SBOMscanner can then be configured to consume VEX data directly from this in-cluster repository managed by vex8s-controller.
Resources
Help Create A Chat Control Resistant Turnkey Chatmail/Deltachat Relay Stack - Rootless Podman Compose, OpenSUSE BCI, Hardened, & SELinux by 3nd5h1771fy
Description
The Mission: Decentralized & Sovereign Messaging
FYI: If you have never heard of "Chatmail", you can visit their site here, but simply put it can be thought of as the underlying protocol/platform decentralized messengers like DeltaChat use for their communications. Do not confuse it with the honeypot looking non-opensource paid for prodect with better seo that directs you to chatmailsecure(dot)com
In an era of increasing centralized surveillance by unaccountable bad actors (aka BigTech), "Chat Control," and the erosion of digital privacy, the need for sovereign communication infrastructure is critical. Chatmail is a pioneering initiative that bridges the gap between classic email and modern instant messaging, offering metadata-minimized, end-to-end encrypted (E2EE) communication that is interoperable and open.
However, unless you are a seasoned sysadmin, the current recommended deployment method of a Chatmail relay is rigid, fragile, difficult to properly secure, and effectively takes over the entire host the "relay" is deployed on.
Why This Matters
A simple, host agnostic, reproducible deployment lowers the entry cost for anyone wanting to run a privacy‑preserving, decentralized messaging relay. In an era of perpetually resurrected chat‑control legislation threats, EU digital‑sovereignty drives, and many dangers of using big‑tech messaging platforms (Apple iMessage, WhatsApp, FB Messenger, Instagram, SMS, Google Messages, etc...) for any type of communication, providing an easy‑to‑use alternative empowers:
- Censorship resistance - No single entity controls the relay; operators can spin up new nodes quickly.
- Surveillance mitigation - End‑to‑end OpenPGP encryption ensures relay operators never see plaintext.
- Digital sovereignty - Communities can host their own infrastructure under local jurisdiction, aligning with national data‑policy goals.
By turning the Chatmail relay into a plug‑and‑play container stack, we enable broader adoption, foster a resilient messaging fabric, and give developers, activists, and hobbyists a concrete tool to defend privacy online.
Goals
As I indicated earlier, this project aims to drastically simplify the deployment of Chatmail relay. By converting this architecture into a portable, containerized stack using Podman and OpenSUSE base container images, we can allow anyone to deploy their own censorship-resistant, privacy-preserving communications node in minutes.
Our goal for Hack Week: package every component into containers built on openSUSE/MicroOS base images, initially orchestrated with a single container-compose.yml (podman-compose compatible). The stack will:
- Run on any host that supports Podman (including optimizations and enhancements for SELinux‑enabled systems).
- Allow network decoupling by refactoring configurations to move from file-system constrained Unix sockets to internal TCP networking, allowing containers achieve stricter isolation.
- Utilize Enhanced Security with SELinux by using purpose built utilities such as udica we can quickly generate custom SELinux policies for the container stack, ensuring strict confinement superior to standard/typical Docker deployments.
- Allow the use of bind or remote mounted volumes for shared data (
/var/vmail, DKIM keys, TLS certs, etc.). - Replace the local DNS server requirement with a remote DNS‑provider API for DKIM/TXT record publishing.
By delivering a turnkey, host agnostic, reproducible deployment, we lower the barrier for individuals and small communities to launch their own chatmail relays, fostering a decentralized, censorship‑resistant messaging ecosystem that can serve DeltaChat users and/or future services adopting this protocol
Resources
- The links included above
- https://chatmail.at/doc/relay/
- https://delta.chat/en/help
- Project repo -> https://codeberg.org/EndShittification/containerized-chatmail-relay
Exploring Rust's potential: from basics to security by sferracci
Description
This project aims to conduct a focused investigation and practical application of the Rust programming language, with a specific emphasis on its security model. A key component will be identifying and understanding the most common vulnerabilities that can be found in Rust code.
Goals
Achieve a beginner/intermediate level of proficiency in writing Rust code. This will be measured by trying to solve LeetCode problems focusing on common data structures and algorithms. Study Rust vulnerabilities and learning best practices to avoid them.
Resources
Rust book: https://doc.rust-lang.org/book/
Looking at Rust if it could be an interesting programming language by jsmeix
Get some basic understanding of Rust security related features from a general point of view.
This Hack Week project is not to learn Rust to become a Rust programmer. This might happen later but it is not the goal of this Hack Week project.
The goal of this Hack Week project is to evaluate if Rust could be an interesting programming language.
An interesting programming language must make it easier to write code that is correct and stays correct when over time others maintain and enhance it than the opposite.