All of this happens on the computer you are reading this on — getting the file, checking it, and writing it to a stick — except the last part, which happens in your computer's start-up menu. When you are through it, How to Use picks up at the signer's first screen.
There is a ready-made image, and it is the sensible way to try SignerOS this afternoon. But a file somebody else prepared is a signer you are trusting them with — and the checksum next to it was published by the same people as the file, so on its own it only proves the download did not get corrupted. Building it yourself is what settles the question: the build is designed so that everyone who compiles the same version gets a byte-for-byte identical result. Download it today; build it before the wallet matters.
LATEST RELEASE
signeros-1.3.0-x86_64.img
▼ Download the imageAlso: every version and its release notes · the source code, which anybody is free to read.
What you get is a ready-made image of a complete USB stick — the startup files and the area your transaction files will live in are already in it. You do not format anything and you do not choose any settings; you write the image and the stick is done.
▲ The image we publish is not signed for Secure Boot, because that signature would have to be made with a key held by someone other than you. Step 03 is about what to do instead — and signing it with a key of your own takes a tenth of a second and no rebuild.
The quick check: that the file arrived intact and is the one that was published. Run one command and compare the result with this, character by character.
LINUX / MACOS
WINDOWS (POWERSHELL)
✕ Not the same? Delete the file and download it again. Never start a computer from an image you could not confirm.
Do this before you sign anything. Signing the image changes it, so the number stops matching by design — and a check afterwards would prove nothing. Check first, then sign.
For when the wallet starts to matter. You need a Linux computer and some patience: everything is compiled from scratch, so the first run takes 30-90 minutes. You do not need the file you downloaded — this is the same source the released image was made from.
THE NUMBER THAT MATTERS
Two numbers come out of a build and either one settles it. The disk image should match the one above, byte for byte. So should the file called bzImage, which is the whole of what the machine actually runs — and that one keeps matching even if you go on to sign the image with a key of your own, because the signature is added to a copy inside the image rather than to bzImage itself.
bzImage and its own checksum are published as assets on the release page — compare against those. The build prints the number for you when it finishes, so you do not have to go looking. Two people on two different computers should get the same one; if yours comes out different, say so publicly — that is the check doing its job.
▲ An honest exception: the numbers published for every version up to and including 1.0.3 cannot be matched by anybody, including us. Three separate faults made those images depend on the computer they were built on, and all three were found because somebody did exactly what this page asks and reported a disagreement. They are fixed from 1.0.4 on, each with a check the build now runs against itself. The full account is in the project's README. If you are comparing numbers, use 1.0.4 or later.
AND WATCH IT PROVE ITSELF
The first starts the real image in a simulated computer and puts it through the whole job: read a transaction, show it, sign it, save it — and refuse a transaction that lies about which address belongs to you. The second re-checks every signature with a second, completely separate implementation written from scratch for the purpose. Asking a program to confirm its own work proves nothing; two independent programs agreeing is evidence.
✕ This kind of check lets you find out that something was tampered with, by comparing with other people. It cannot prevent it. That is exactly why the comparison is worth actually doing rather than assuming.
The image is a picture of a finished stick, not a file you copy onto one. Everything is already inside it, so you do not format anything and you do not pick any settings — you write the image over the whole stick and it is ready. Unpack the download first if it arrived compressed.
If you have the source — because you built the image, or just downloaded the source — the script that writes the stick comes with it. It reads the make and size of the drive back to you and asks you to confirm before touching it, then writes the image and reads it back to check the stick is correct.
It writes output/images/signeros.img by default. For an image you downloaded instead, point it at the file:
--expand-data gives the rest of the stick over to your transaction files afterwards, which is what you want on anything bigger than the image itself.
balenaEtcher needs nothing but the image file: choose it, choose the USB device, press Flash. It handles this kind of image correctly and refuses to write over your computer's own disk — you just do not get the read-back check, or the leftover space handed to your files.
1 · Plug the stick in and find its device (e.g. /dev/sdb) — compare sizes to be sure:
2 · Unmount every partition on it:
3 · Write the image to the whole drive — the plain device name, with no number on the end (/dev/sdX, not /dev/sdX1):
4 · Flush and remove:
The stick now has two areas on it: the part that starts the computer, which nothing should ever touch, and a plain one named PSBT_DATA where your files go. Plain dd leaves the rest of the stick unused — the script above can hand that space to your files instead.
Download the image, or build it on Linux (or in WSL) and copy output/images/signeros.img across. Back up anything on the stick first; it will be wiped.
signeros.img.Use balenaEtcher instead: pick the image → pick the USB → press Flash. Three clicks, works on Windows and Linux, no settings to think about.
// Afterwards the stick shows up with a drive named PSBT_DATA on Windows, macOS and Linux alike. That is where your transaction files go — loose on it, not inside a folder. Whatever you do, do not reformat the stick “to fix it”: the part you would be erasing is the part that starts the computer.
Secure Boot is a setting in your computer's start-up menu that lets it run only software carrying a signature it has been told to trust. Out of the factory it trusts Microsoft and nobody else, and SignerOS is not signed by Microsoft. So the question is never "is SignerOS trusted" — it is "how do you tell this machine to trust it", and that depends entirely on what its start-up menu lets you do.
Try them in this order. The first is the best and most machines allow it. The second is for the ones that do not. The third always works and asks something of you in return.
The machine ends up running your signer because you vouched for it, and it still refuses everything else. Nothing about Secure Boot is weakened.
keys/SignerOS_db.cer onto the stick so the start-up menu can find it, and write the signed image to the stick.// If you are a Linux user reaching for mokutil: that tool manages a different list, and nothing consults it here. This has to be done from the start-up menu.
Plenty of laptops simply do not offer the menu that A needs — it is missing, greyed out, or hidden behind a mode the vendor never shipped. This route does not need the firmware's cooperation at all. It uses shim, a small loader that Microsoft signs and every machine therefore already trusts, and tells shim to accept one exact file: yours.
Verification failed: (0x1A) Security Violation. That is expected on the first start, not a fault. Press Enter.This is not the checksum from step 01 and it is not sha256sum of anything. It is the Authenticode hash, which skips the three parts of the file a signature would change — so it is the same number whether or not you signed the image, which is why one published number is right for everybody. shim_kit.sh prints it too, and python3 scripts/authenticode_hash.py --groups output/images/bzImage recomputes it from a build of your own.
// Why the hash and not your key: a key tells that machine to trust anything signed with it, forever. A hash trusts exactly one file — the one you just checked. A new SignerOS version has different contents and needs this again, on purpose: every new version passes in front of you.
▲ What this costs, plainly: the first thing your computer runs is then a small program this project did not write and cannot withdraw, and the choice is remembered in your computer's own memory until you delete it (Delete MOK, in the same menu). Route A has neither property, which is why it is first.
Always available, nothing to enrol, and it gives up one specific protection: with Secure Boot off, nothing checks that the stick still holds what you put on it. So take that job back by hand.
THE SETUP KEY, BY MAKE
| Dell | F2 / F12 |
| Lenovo | F1 / F2 (or Fn+F2) |
| HP | F10 / Esc |
| ASUS | F2 / Del |
| Acer | F2 |
| MSI | Del — boot menu is F11 |
// On HP machines, permission to start from a USB stick is a separate setting from Secure Boot, and both have to allow it. On MSI, if the stick does not appear in the boot menu at all, turn Fast Boot off — it skips USB entirely. And SignerOS needs a computer made in roughly the last decade.
The key menu usually offers Clear All Secure Boot Keys right next to Enroll, and it does exactly what it says: it throws away the trust your own Windows or Linux installation depends on, and the machine stops starting up normally. Add yours to the list; do not replace the list. If you do press the wrong thing, Restore Factory Keys is in the same menu and undoes it — nothing here can permanently break a computer.
Everything from here happens on the screen in front of you, on a machine with no network and no way to get one. There are three things it can do, and the next page walks through each of them the way they actually appear.