Ayewo ISO — FAQ

Everything you need to deploy an Ayewo scanner node on your own hardware.

What is the Ayewo ISO?

A pre-registered Ayewo scanner node delivered as a single .iso file you flash directly to a disk with Balena Etcher, Rufus, dd, or Raspberry Pi Imager. Once flashed and booted, the target hardware becomes a full Ayewo scanner — identical to the Virtual product, on hardware you own and control.

Price: $579/month per node ($5,790/year prepay — 2 months free). x86-64 and ARM64 available.

How does it work?

Order an ISO from your Hudson Infosec portal (/order). Pick x86-64 or ARM64.
We build, sign, and boot-verify your ISO on our side before delivery — takes ~45–60 minutes.
You receive an email with a 7-day download link for three files:
- {customerID}.{arch}.{orderID}.iso — the disk image
- .iso.minisig — cryptographic signature (ed25519)
- .iso.sha256 — integrity checksum
Verify the signature (see below), then flash to your target disk.
Boot. The node self-registers with AWS IoT, receives its certificate, and starts scanning.

Supported platforms

Every target falls into one of three tiers. Pick accordingly — the Unsupported list is the one we'll cite when closing tickets.

x86-64

Tier	Examples
Supported	Intel NUC (7th gen+), Dell Optiplex Micro (7th gen+), HP EliteDesk Mini (G3+), ProtectLi Vault line, MikroTik CHR, generic UEFI mini-PCs with Intel/AMD 4+ core CPUs
Best Effort	ESXi and Proxmox VMs meeting minimums (USB passthrough for wireless is customer-dependent), Dell R-series / HP DL-series, IPMI-managed bare-metal servers
Unsupported	Hyper-V (no reliable USB passthrough for wireless), Legacy BIOS-only systems, Atom/Celeron below 4 cores, anything below 8 GB RAM

ARM64

Tier	Examples
Supported	Raspberry Pi 5 (8 GB), Raspberry Pi CM5 on official carrier boards
Best Effort	Orange Pi 5 Plus (8 GB+), Radxa ROCK 5B+, Pi 4 8 GB variant
Unsupported	Pi 4 4 GB variant, Pi 3 and older, Pi Zero series, any 32-bit ARM board, SD card as primary storage for production workloads

Minimum hardware

Component	Minimum	Notes
CPU	4 cores (x86-64 or ARM64)	Below 4 cores the node will run but deep scans throttle heavily
RAM	8 GB	Encrypted RAM disk + Nuclei Java heap peak around 5 GB; below 8 GB the node OOMs on deep scans
Storage	10 GB internal (SSD/NVMe strongly recommended)	HDD works but scan performance drops; SD card only recommended for SBC best-effort targets
Firmware	UEFI (x86); UEFI or U-Boot (ARM)	Legacy BIOS not supported — image uses GPT
Network	Wired Ethernet for initial boot	Wi-Fi only supported via USB adapter once booted

The node runs a hardware-precheck service at boot. If your hardware is under-spec it will still boot and scan, but the admin panel flags the node and we'll decline related support tickets citing this policy.

Known unsupported

Hyper-V (Windows Server and Pro): lacks reliable USB passthrough for wireless adapters. ISO boots, wireless scanning doesn't.
32-bit ARM (Pi 3, Pi Zero, older SBCs): we ship 64-bit only.
Legacy BIOS-only systems.
Under-spec hardware (below 8 GB RAM, below 4 cores, below 10 GB storage).
Jailbroken or modified hypervisor environments: out of scope for support.

Writing the ISO to disk

Writing the ISO wipes the target disk. Double-check the target device before you confirm. Using the wrong target can destroy your system drive.

Your OS	Recommended Tool	Command / Path
macOS / Linux	`dd` (built-in)	sudo dd if=ayewo.iso of=/dev/sdX bs=4M status=progress conv=fsync
Windows	Rufus (GPT + UEFI mode)	Open Rufus → select ISO → select target disk → "Start" → keep default (DD mode works fine)
Any OS	Balena Etcher	GUI, cross-platform, built-in validation. Recommended for most users.
Raspberry Pi / ARM SBC	Raspberry Pi Imager	"Use custom image" → select ISO → choose SD/NVMe target → write

First boot

Write the ISO to your target disk with one of the tools above.
Disconnect the flashing drive and insert/attach the written disk to your target hardware.
Set boot order: target disk first. Legacy BIOS must be disabled — ISO requires UEFI.
Connect wired Ethernet (required for initial boot — the node contacts AWS IoT to complete registration).
Power on. Boot takes 2–4 minutes. The node will run P1 + P2 initialization, request its signed certificate, and begin heartbeat.
Watch your Hudson Infosec portal. The node appears under Node Monitoring within ~5 minutes of successful boot.

No operator interaction required. No installer prompts. No passwords to enter.

Verify the ISO (signature check)

Optional but recommended — especially for MSPs redistributing the ISO to sub-clients. Every ISO is signed with our ed25519 signing key; verifying proves you received an unmodified image from Hudson Infosec.

Install minisign

macOS:   brew install minisign
Linux:   sudo apt-get install minisign   # Debian / Ubuntu
         sudo dnf install minisign       # Fedora
Windows: winget install jedisct1.Minisign

Download our public key

Our signing public key lives at https://www.hudsoninfosec.com/trust/ayewo-iso-signing-key-v1.pub. Download it once and cache it locally.

Verify

minisign -Vm customer-id.x86.order-id.iso -p ayewo-iso-signing-key-v1.pub
# Expected output:
# Signature and comment signature verified
# Trusted comment: Ayewo ISO | key_id=v1 | sha256=<hash>

If verification fails, do not flash the ISO. Contact support.

Cross-check the SHA-256

Separately, the .sha256 file contains the full SHA-256 hash. Verify with:

sha256sum -c customer-id.x86.order-id.iso.sha256

Wireless scanning

ARM and x86 ISO nodes both support 802.11 wireless scanning via a USB Wi-Fi adapter passed through from your hardware. The node automatically detects the adapter and puts it in monitor mode during a wireless scan command dispatched from the portal.

Known-good adapters

Alfa AWUS036ACH (Realtek RTL8812AU, dual-band)
Alfa AWUS036ACSM (MediaTek MT7612U)
Panda PAU09 (Ralink RT5572)
TP-Link Archer T3U Plus (Realtek RTL8812BU — needs DKMS driver, included in image)

USB device policy

The ISO image ships with a strict USBGuard policy:

Allowed: HID (keyboards / mice), Wireless adapters (class e0), USB hubs, USB-Ethernet adapters (CDC).
Blocked: USB mass-storage (flash drives, external HDDs, SD readers, card readers), Imaging devices (PTP/MTP cameras / phones), Vendor-specific devices (class ff).

This prevents a bad actor with physical access from plugging in a USB stick to exfiltrate scan data or boot unauthorized code. Plugged-in storage devices simply don't appear — dmesg will show them blocked by USBGuard.

Network requirements

The node needs outbound internet. No inbound ports required.

Port	Protocol	Destination	Purpose
8883	MQTT / TLS	`*.iot.us-east-1.amazonaws.com`	Scan commands + heartbeat
443	HTTPS	AWS S3 + IoT credential provider + portal API	Config, cert fetch + validation, scan result upload

If your firewall policy is allow-list, whitelist the two hosts above.

License + multi-instance protection

Each ISO is keyed to one node — the deviceId baked into the image during boot verification. Flashing the same ISO to multiple machines results in all of them being suspended.

Our backend detects dupes in two ways:

IP-difference check: two machines with the same deviceId heartbeating from different public IPs within a 5-minute window → immediate suspend of all instances.
Hardware fingerprint check: every 4-hour cert validation also sends a 5-signal hardware fingerprint (BIOS UUID, system serial, CPU identity, primary NIC MAC, primary disk serial). If the received fingerprint doesn't match the one bound on first boot, the node is suspended.

Legitimate hardware upgrades (NIC swap, disk replaced) are tolerated via a similarity check — 3 of 5 signals matching is treated as a drift and silently rebound. Migration between entirely different machines is treated as a clone attempt. If you need to move the node to new hardware, contact support and we'll rebind the cert manually.

Support tiers

Tier	What we support	SLA
Supported	Tested hardware targets (see platforms table). Full troubleshooting from initial boot through scanning + pentest operation.	Per your customer agreement
Best Effort	Hardware that meets minimums but isn't on the tested list. We'll help where we can; hardware-specific issues are your responsibility.	No guarantee
Unsupported	Known-incompatible platforms or under-spec hardware. We'll decline tickets and refer to this policy.	N/A

Preflight check (strongly recommended)

Before writing the ISO to disk, run our 30-second preflight script on your current OS. It verifies UEFI mode, Secure Boot, RAM, CPU, disk size, and outbound network reachability — catching the 5 issues that cause ~90% of boot failures.

curl -sL https://www.hudsoninfosec.com/ayewo-preflight.sh | bash

Full details: ISO Preflight. Runs on any Linux live USB, WSL on Windows, or macOS. Exits 0 if you're good to go, 1 if there's a blocker.

Refund & swap policy

If your hardware genuinely can't boot the ISO after ruling out Secure Boot and UEFI misconfiguration, you have two options within 7 days of purchase:

Swap to a virtual-node order at the same subscription price — works in any major hypervisor (VMware, Hyper-V, Proxmox, KVM, Parallels, UTM, XCP-NG). Your remaining subscription period transfers over.
Full refund of the first month's charge. Email support_tickets@hudsoninfosec.com with your order ID.

Running the preflight script and attaching its output to the ticket speeds up the swap/refund process — it shows us exactly what blocked the boot. Refunds are declined if the hardware was below the published minimums.

Troubleshooting

ISO won't boot

Confirm UEFI is enabled and Legacy BIOS is disabled in your firmware.
Confirm Secure Boot is disabled — our image isn't signed for MS Secure Boot chains.
Try a different flashing tool (Etcher is most forgiving).
On some motherboards, the first USB port / lowest-numbered SATA port is the only one that appears in the boot picker.

Node doesn't register with the portal after boot

Confirm wired Ethernet with DHCP and outbound 443 + 8883 to AWS.
Some corporate firewalls intercept TLS — Ayewo's cert validation pins AWS IoT certs and will fail on such firewalls. Add an exception for *.iot.us-east-1.amazonaws.com and *.amazonaws.com.
Check the portal under Node Monitoring after ~5 minutes. If absent, contact support with your order ID.

Wireless scan reports "No adapter detected"

Confirm the adapter is on the known-good list (see Wireless scanning).
Plug the adapter in before initiating the scan — hot-plug during scan isn't guaranteed.
Run iw dev via emergency SSH (see below) to confirm the adapter is visible to the kernel.

Emergency SSH access

SSH is disabled by default. From your portal, send enable_ssh via Node Monitoring → your node → Enable SSH. SSH is enabled for 30 minutes and auto-disables. Your default hsecworker password is visible on the device detail page when SSH is enabled.