Test benches & product security
Signed session manifests and hardware preflight for fixture-based validation — garage/gate controllers, keyless bench harnesses, Wi-Fi labs.
Authorized RF & Wi-Fi security testing
Prove RF security, safely.
Signed authorization, contained by design.
SignalLab is the RF & Wi-Fi security-testing platform for labs, red teams, and researchers doing written-authorized work. Build a signed engagement manifest, run hardware preflight, and drive a monitor-mode & gated-active executor — with an audit trail and honest boundaries. The public app never transmits; it prepares and verifies the authorization.
Validated Aug 2026: dual Alfa radios (MT7612U + MT7921U) in one WSL2 instance, monitor mode + concurrent scans, and bidirectional frame injection on channel 1 — with the long-duration stability limit stated plainly.
Hard boundary: SignalLab is for isolated fixtures and written client-authorized lab work. It will not provide a workflow for opening garages, gates, or vehicles; cloning or replaying fobs/remotes; Wi-Fi deauthentication; jamming; credential capture; or transmitting arbitrary captured IQ recordings.
Who uses SignalLab
Built for authorized RF work.
If you run contained, written-authorized RF or Wi-Fi security testing, SignalLab gives you a repeatable, auditable authorization workflow and a real executor.
Pentest & assessment firms
An auditable authorization envelope per engagement: scope, fixtures, frequency and power allowlists, expiration, and a session report for the engagement folder.
RF & 802.11 research
Monitor-mode capture and gated active tests on your own spectrum, with the stability and recovery boundaries documented instead of hidden.
Validated
What the bench has actually done.
Capabilities are stated from real acceptance runs with evidence — and the boundaries are stated just as plainly. That honesty is the point.
Proven on hardware
- Dual Alfa radios (MT7612U + MT7921U) attached simultaneously in one WSL2 instance — firmware init, monitor mode, concurrent passive scans, zero kernel drops.
- Short-session bidirectional raw-frame injection on channel 1 — eight frames each way, all captured, zero drops, with PCAP evidence.
- Signed authorization manifests with SHA-256 integrity, revocation, verification, and a printable session report.
What we do not claim
- Long-duration / unattended MT7612U USB/IP stability — it disconnects at about 11 minutes and recovers by software reattach. Short-session work only.
- The public app never transmits. Active work is executor-only, behind a signed plan with an isolated-range gate.
- No deauthentication, jamming, replay, credential capture, or real-world actuation — ever.
Platform hardware
Bench transceiver, not a universal key.
The recommended active hardware is a genuine HackRF One used with RF containment. Wi-Fi security checks use a separate dedicated lab access point and client because a wideband SDR is not a substitute for a normal 802.11 test interface.
Great Scott Gadgets HackRF One
Half-duplex SDR for controlled transmit-or-receive research. SignalLab only performs a WebUSB identity check in this release; it does not claim the interface or send samples.
Dummy load + fixed attenuationDefault transmit path; no antenna during initial validation.
RF shield enclosureRequired for garage, gate, vehicle-keyless, and sub-GHz controller fixtures.
Dedicated Wi-Fi lab AP + clientFor WPA/WPS/PMF configuration checks without deauthentication or interference.
WebUSB has not been checked.
Transmission stays behind interlocks
- Signed engagement manifest with owner, scope, fixtures, expiration, and permitted test modes.
- Hardware interlock proving a dummy load, cabled attenuator, or shield enclosure is present.
- Frequency and output-power allowlists; no arbitrary waveform or captured-IQ upload.
- Per-session audit log and automatic expiration.
- Desktop or Raspberry Pi bridge; the public phone PWA never exposes a transmit button.
Local RF executor
The bench radio that runs the session.
The public PWA prepares and verifies the authorization; it never touches a radio. The RF executor is the separate, local bridge that does — a small headless Linux VM on your own workstation that gives SignalLab a real 802.11 monitor-mode radio over native USB passthrough. It captures for detection, and runs active Wi‑Fi tests only inside a signed plan with an isolated-range gate. This is the desktop bridge the hardware section describes, now built.
Monitor mode, and contained active tests
- Monitor-mode capture on a MediaTek MT7612U adapter (Alfa AWUS036ACM or equivalent): rogue-AP / evil-twin visibility and a beacon/probe inventory on a dedicated lab network. Passive — detection, not attack.
- Injection-capable for authorized resilience tests, gated behind a signed wireless plan: MAC/BSSID allowlist, isolated-range environment, pacing, a stop-file, and monitor-mode read-back.
- Native USB passthrough in a VirtualBox VM — reliable where WSL / usbip is not. The adapter runs entirely inside the VM; the host only carries it.
- Windows dashboard — drive the radio from a browser: adapter and monitor-mode status, start/stop, and live channel-hopping scans of nearby access points and client devices.
Active work stays behind the plan
- Capture is passive and always allowed on a lab network; it observes, it does not interfere.
- Active transmission requires a signed plan whose scope is the isolation — an allowlisted target on an isolated range, never open air.
- No deauthentication of third parties, no evil-twin credential capture, no jamming. The executor enforces the allowlist and the stop-file.
- Every session is bounded and logged, and the radio reads back its own state so a later reader sees what actually happened.
Downloads
Stand up the executor.
Everything needed to build the RF executor on a Windows workstation: the installer, dashboard, setup guide, and the exact validated Linux kernel package set. Authorized lab use only.
VirtualBox config + dashboard
A one-shot PowerShell setup that installs VirtualBox and its Extension Pack, builds the Ubuntu RF-executor VM, wires up USB passthrough and SSH, and ships the browser dashboard. Re-runnable and idempotent.
Contains setup-rf-executor.ps1, the alfa-dashboard bridge and launcher, and the README. Needs Windows with VirtualBox, Node.js, and PuTTY.
One or two Alfa adapters
Set up the ACM, the AXML, or both together through the tested WSL2 and USB/IP path, with exact kernel, module, attach, interface-mapping, monitor-mode, recovery, and VirtualBox fallback steps. Read it here or take the PDF.
The guide is hosted on this site as a page for reference.
Linux 6.17.0-42 + MT7921U firmware
The exact unmodified Ubuntu kernel, modules, headers, and firmware packages used to validate the AWUS036AXML. The archive is approximately 795 MiB and includes per-package SHA-256 checksums.
The AXML passed bounded feature tests on this kernel but remains experimental under VirtualBox: sustained monitor traffic reproduced an xHCI kernel panic. Keep the previous kernel available for rollback.
WSL 6.18.33.2 dual-Alfa driver build
A custom WSL2 kernel image, complete matching module tree, build configuration, and embedded firmware for both the MT7612U and MT7921U Alfa adapters. The archive is approximately 669 MiB and includes byte-level provenance.
Both the AXML and ACM passed simultaneous USBIP attach and initialization, passive scans, and bounded bidirectional synthetic-frame injection. No disruptive frames or real-network targets were used. The MT7612U later disconnected after about 11 minutes of repeated monitor/capture work and recovered by software reattach, so short-session injection passes while long-duration USBIP stability does not.
Permitted test families
Safe, fixture-based validation
- Known benign test carrier into a dummy load or cabled attenuator.
- Receiver sensitivity, filter response, and frequency-offset measurement.
- Garage/gate controller resilience review using spare controller fixtures and manufacturer logs.
- Vehicle keyless design review using an OEM bench harness with no live vehicle actuation.
- Wi-Fi WPA mode, WPS state, PMF support, channel use, and rogue-AP visibility on a dedicated lab network.
Permanently blocked
No bypass, replay, or interference
- Replaying captured garage, gate, alarm, or vehicle signals.
- Attempting to unlock, start, open, or actuate a real target.
- Rolling-code prediction, key extraction, relay attacks, or immobilizer bypass.
- Wi-Fi deauthentication, jamming, evil-twin credential capture, or forced roaming.
- Transmitting arbitrary captured IQ, private communications, or unknown payloads.
Authorization manifest
Create a lab session.
The PWA stores manifests locally. A future signed bridge will accept only unexpired manifests whose fixture, mode, frequency, power, and containment rules match the connected hardware.
Local output
Review before export
No manifest generated.
No manifest is uploaded automatically. Hardware transmission remains disabled in this public release.
Manifest library
Review what you have authorized.
Every manifest is held in this browser only, capped at the 25 most recent. Status is recomputed from the expiry timestamp, so a session that lapses while this page is open changes state on its own.
Verification
Check a manifest before you trust it.
Runs the same checks the signed bridge will: schema, authorizations, expiry, RF envelope bounds, prohibited-action flags, and the SHA-256 integrity hash. A mismatched hash means the content was edited after it was generated.
Input
Paste a manifest
Result
Eight checks
Local audit trail
What happened on this device.
Records that an action occurred — created, verified, downloaded, cloned, deleted, preflighted — with a timestamp and engagement id. It deliberately stores no manifest content, and never leaves this browser.
Link budget
Work out the power at the fixture.
Arithmetic only — no hardware is involved. It exists so the envelope is set from a computed figure instead of a guess: what containment has to hold is the power arriving at the fixture, not the number on the transceiver.
Inputs
Path
Result
At the fixture
A sanity rail, not a safety certification. The real limits are the fixture’s damage threshold and the enclosure’s isolation, neither of which this page knows.
Test sessions
What actually happened.
The manifest records what was permitted. This records what was done — start and end times keyed to the manifest hash, with an outcome and notes. A session can only be started against an authorization that is currently valid and unrevoked.
Start and End are on each manifest in the library. Fill the outcome and notes fields there before ending a session — they are captured at the moment you end it.
Import
Restore a bundle.
An exported bundle is a file, and a file can be edited between export and import. Every manifest is re-validated and its hash recomputed here — the stored digest is treated as a claim, never as proof. Import merges and dedupes; it never replaces what you already hold.
Use Import bundle in the library toolbar to load a file.
Compare
What changed between two manifests.
The review question that actually gets asked when one authorization supersedes another. Timestamps and the hash are excluded, because those always differ and would bury the fields that matter.
Engagement artifact
The session report.
One printable page combining the authorization, the bench preflight as actually confirmed, and every session recorded against it. This is the thing that goes in the engagement folder — not the raw JSON.
View or generate a manifest, then use Session report above.
Engagements
Talk to us about authorized RF testing.
Pricing is per engagement. Tell us your scope and we’ll follow up. This form opens your own email client — nothing is uploaded from this page.
What happens next
From enquiry to signed session
- Scope call. We confirm the fixtures, bands, containment, and authorization in writing.
- Manifest. You (or we) build the signed engagement manifest right here in the app.
- Execute. Monitor-mode capture and any gated active test run behind the signed plan, with read-back and a session report.
- Deliverable. You get the printable engagement artifact — authorization, preflight, and everything that actually happened.
SignalLab is only for isolated fixtures and written client-authorized lab work. We do not take engagements against live access-control targets.
Help
How to use SignalLab.
Everything here happens in your browser. No manifest, note or audit entry is ever uploaded, and there is no account to create.
Start here
Running a session, end to end
- Preflight the hardware. Connect the dummy load or attenuator first, then use Check HackRF over USB. This is an identity check only — SignalLab never claims the interface or moves samples.
- Describe the work. Engagement id, authorized organization, fixture class and asset id. These are what make the manifest auditable months later.
- Declare the RF envelope. Frequency range, maximum output, attenuation and containment method. A band preset fills the range in for you; confirm it matches your fixture.
- Work the bench preflight. Five physical checks. They are stored inside the manifest and covered by its hash.
- Confirm the four authorizations and set an expiration, then generate. The manifest is hashed and stored locally.
- Verify before you rely on it. Paste or load it into the Verify panel — that is the same set of checks the signed bridge will run.
Field reference
What each field means
- Engagement id
- Your work-order reference. Reusing one across a multi-session engagement is fine — you get a note, not a refusal.
- Fixture class
- What kind of bench target this is. A live installation is never a valid answer.
- Permitted test mode
- The one family of work this manifest authorizes. A different mode needs a different manifest.
- Start / end frequency
- The allowlist the bridge will enforce. Keep it as narrow as the work allows.
- Max output (dBm)
- Ceiling for the session. Above +10 dBm is rejected outright for contained bench work.
- Attenuation (dB)
- Fixed attenuation in the path, so a reader can reconstruct the power actually reaching the fixture.
- Containment
- Dummy load, cabled attenuator, or a verified shield enclosure. There is no uncontained option.
- Expiration
- When the authorization lapses. Status recalculates on its own, including while this page is open.
Verification
What the nine checks mean
- Schema — recognised manifest version.
- Identity and fixture — the audit fields are actually filled in.
- Confirmations — all four authorizations were affirmed.
- Not expired — the window is still open.
- Not revoked — the hash is not on this device’s revocation list.
- Envelope — frequency order, power ceiling and containment still within limits.
- Policy flags — replay, actuation, deauthentication and jamming all still false.
- Integrity hash — the content has not been edited since generation.
A failing integrity check alongside another failure is normal: editing a manifest to weaken it changes the content, so the hash stops matching too. That is the mechanism working, not a second fault.
Revocation
Withdrawing an authorization
Revoking records the manifest’s hash on a local revocation list with a reason and a timestamp. The manifest file itself is deliberately left untouched — writing a revoked flag into it would change its content and break its hash, which would make a withdrawn authorization indistinguishable from a forged one.
That list lives in this browser only. Revoking here does not reach a copy someone already downloaded — a real limit of a local-only tool, and the reason expirations should be short.
Troubleshooting
When something does not work
- The USB check does nothing
- WebUSB needs a secure context and a Chromium-based browser. Safari and Firefox do not expose it. On a phone, use current Android Chrome.
- My device is not offered
- The picker only lists devices in the supported registry. An RTL-SDR is recognised but rejected for active work — that is BandSight’s device.
- Copy JSON does nothing
- Clipboard access is permission-gated and unavailable on insecure origins. Use Download instead.
- No integrity hash appeared
- WebCrypto is unavailable in that context, usually because the page was opened over plain HTTP or from a file. Load it over HTTPS.
- My manifests vanished
- They live in this browser’s local storage. Clearing site data, a private window, or a different browser or device all start empty. Export a bundle if you need them elsewhere.
Data and boundaries
What this app will not do
SignalLab prepares and verifies authorizations. It does not transmit, replay captured signals, jam, deauthenticate, unlock, or actuate anything, and it will not gain those abilities. Transmission, if it is ever built, lives behind a signed local bridge with a hardware interlock — never in this page.
- Nothing is uploaded. No account, no server, no telemetry.
- Manifests, the audit trail and revocations are stored locally, capped at 25 manifests and 200 audit entries.
- The audit trail records that an action happened, never manifest content.
- Receive-only field discovery belongs in BandSight.