Booting & verification

The engine boots into a hard lock and stays there until it has verified its license online. This page walks through writing the ISO to USB, what the lock allows, the exact unlock sequence, and what every deny message means.

Writing the ISO to USB

The ISO is a hybrid image, so any dd-style writer works: Rufus in DD mode, balenaEtcher, or plain dd on macOS/Linux. Write the whole image to the raw device — do not extract it or copy files onto a formatted stick.

Ventoy is also supported. You can drop the ISO onto a Ventoy stick alongside other images; the engine reads its license token from the ISO file itself wherever it is mounted, so the embedded credentials survive.

Boot the target machine from the stick using its one-time boot menu (typically F12, F10, or Esc during power-on). There is no boot menu on the stick itself — the engine starts directly.

Frozen drives unfreeze automatically

Many machines boot with their ATA drives in a firmware-frozen security state, which blocks the erase commands the engine relies on. The engine handles this at boot: when a frozen disk is detected, a boot-time unfreeze routine performs a brief suspend/resume cycle before the kiosk starts. You may see the machine blink through a sleep transition during boot — that is expected, and no operator action is needed.

The boot lock

The kiosk boots locked. Until the license is verified online, the interface is a hard lock screen, and only three things work:

• Wi-Fi — open the network popup, scan, and join a network.
• Worker — open the license-status popup and refresh the connection.
• Power — power off or reboot.

Everything else is blocked: navigation between screens, drive enumeration and refresh, hardware tests, notes, and — above all — starting a wipe. There is no offline unlock: no bypass code, no cached approval from a previous boot, no grace period. Each boot verifies fresh.

The lock screen itself is deliberately quiet; the reason the device is locked — and everything else about its license state — is shown in the Worker popup.

The unlock sequence

Once the engine is running, unlocking is automatic. Step by step:

1. Connectivity poll. The engine checks for a working network route every 3 seconds. If the device is offline, the Wi-Fi popup opens automatically so the operator can join a network. (A wired connection with DHCP needs no interaction at all.)
2. Health check. As soon as a default route exists, the engine calls GET /api/health on the licensing service, presenting its embedded device token. It tries up to 3 times, 4 seconds apart, with a 5-second connect and 20-second request timeout. Success moves the Worker indicator to Connected.
3. Verification. The engine sends POST /api/verify. This applies the full license decision — status, quota, account standing — but is unmetered: verifying at boot never consumes wipe quota, so repeated boots cost nothing. It is also idempotent — you can boot the same stick as many times as you like.
4. Verified. On an affirmative allow, the UI unlocks for this boot, and the once-per-boot asset report is released.

Any other outcome — a deny, or any failure to reach the server — leaves the device locked, with the reason shown in the Worker popup.

The Wi-Fi popup

The Network button in the sidebar opens the Wi-Fi popup. Its status line reads one of:

• Wired connection active
• Connected
• Not connected — join a network

Below that, a Rescan button and the list of networks — each row showing a signal-strength glyph, the SSID, and a lock icon for secured networks. While scanning the list shows Scanning…; if nothing is found, No networks found.

Selecting a secured network reveals an inline password field and a Connect button; while joining, the row shows Connecting…. Once connected, the popup switches to a connected view showing Network, Signal ({n}%), and IP address, with a Disconnect button.

While the device is offline, the Wi-Fi icon in the sidebar flashes red and amber to draw the operator's attention.

The Worker popup

The Worker button opens the license and connection status popup (titled Worker), with the current status, a Refresh button, and these rows:

Row	Value
Worker	The licensing service URL baked into the stick
Engine	The engine version (e.g. 1.0.0)
Boot record	This boot's record id, e.g. CW-20260623-221305
Licence	Verified — {account}, or LOCKED — not verified in red
Wipes remaining	A number, or unlimited
Account	The account id from the token (acct_…)
License	The license token id
Token expires	An ISO timestamp, never, or EXPIRED {when} in red

On an unprovisioned stick the popup instead reads: Not provisioned — no Worker URL or device token on this stick. Wipes are blocked until check-in succeeds. If the last request failed, a Last error: {err} line shows the failure.

The token claims shown here (account, license, expiry) are decoded for display only — they are not what grants access. The server re-verifies the token on every call.

Worker status colors

Status	Color
Connected	Green
Connecting	Amber
Disconnected	Red

Deny messages

When verification (or a later check-in) is denied, the engine translates the server's reason into a plain operator message. All of them, verbatim:

Server reason	Message shown
disabled	This ISO has been disabled by MAESON support. Contact support — your account admin cannot re-enable it.
revoked	This device's licence was revoked by an account admin. Download a fresh ISO.
suspended	This device's licence is suspended. An account admin can reinstate it.
quota_exceeded	This device has used its entire wipe quota. Contact your account admin.
account_inactive	The AVERASE subscription for this account is not active. Renew it to keep wiping.
not_found / invalid_token	This stick's licence token is not recognised. Download a fresh ISO.
validation_unavailable	The licence server is unreachable right now. Check the network and try again.
(any other reason)	Licence check denied ({reason}).
(network failure)	Could not reach the licence server. Check the network and try again. ({error})

Note that validation_unavailable and a transport failure both leave the device locked — the engine fails closed rather than trusting a stick it cannot verify. See Downloads for how admins revoke, suspend, and reinstate ISOs.

Unprovisioned sticks

An ISO that was never issued through your account — or was copied without its embedded token — has an empty key slot, and the engine treats it as unlicensed end to end:

1. At boot, no token is found, so the engine has no license to present. The device is permanently locked for that boot: Wi-Fi, the Worker popup, and power still work, but nothing can unlock it.
2. The Worker popup shows: Not provisioned — no Worker URL or device token on this stick. Wipes are blocked until check-in succeeds.
3. Even if the lock were somehow bypassed, the pre-wipe check-in independently blocks every wipe: Device not provisioned: no backend token configured. Wipe blocked.

The only fix is to download a fresh ISO from your AVERASE account.

The once-per-boot asset report

Once the device is Verified and Connected, and hardware collection has finished and the storage inventory has settled, the engine sends its asset report — once per boot — with POST /api/record. The report contains:

• record_id — this boot's identifier, format CW-YYYYMMDD-HHMMSS (UTC, generated at engine startup). This is the same id shown in the Worker popup's Boot record row.
• engine_version — the engine version.
• fingerprint — the complete hardware fingerprint, verbatim: every section the Device fingerprint dashboard collects, with the storage list limited to internal drives. Nothing is summarized on-device — the server receives exactly what was collected.

The engine retries a failed send up to 3 times with 2-second and 4-second backoff; if all attempts fail, the report is re-armed and sent again once connectivity returns, so a flaky network never loses the audit. Hardware test results and operator notes are held back until the report is acknowledged, because both attach to the machine's record by record_id.

In the web app, the report appears (or updates the existing record for that machine) in Inventory.

Where to next