SignalLab — Source library
Public documentation snapshot: 2026-09-08
Prove what you were allowed to transmit.
Signed, bounded authorization for lab-only RF and Wi-Fi testing, plus a monitor-mode bench kit for your own workstation.
Prove what you were allowed to transmit.
Built for: Product security and RF test labs validating garage, gate, vehicle-keyless, and sub-GHz controller fixtures on a bench · Red teams and assessment firms that need a defensible authorization envelope for every RF or Wi-Fi engagement · Independent RF and 802.11 researchers working on their own spectrum who want a repeatable, recorded workflow · Engineering teams trying to get a working monitor-mode Wi-Fi bench running on a Windows workstation
SignalLab exists because of this.
You are about to put energy into the air, and the only thing standing between authorized work and a serious problem is a piece of paper. Not paperwork in the bad sense — a specific, dated permission that names the fixture, the frequency range, the maximum output, the required containment, the person who approved it, and the moment it stops being valid. Most teams keep that in an email thread, a signed PDF, or a shared document. None of those can tell you six months later whether the copy in the engagement folder is the copy that was actually approved, or whether someone widened the frequency range afterwards. Then there is the bench itself. Was the dummy load actually on the transmit port? Was the antenna off? Did anyone watch the spectrum before the first active step? Was the fixture on an isolated supply rather than a live installation? Those facts are true for about ninety seconds while somebody is standing at the bench, and after that they live only in memory. When a client's counsel asks what was permitted on the fourteenth and what was actually done, you have a folder of PDFs, a capture file with no context, and a recollection. And before any of it, you have to get a real monitor-mode radio working on a Windows workstation. That is a two-day detour through stale forum posts, adapters that half work, and write-ups that tell you what worked once on somebody else's machine and go quiet about the part where the adapter drops off the bus. You end up with a radio you do not trust, and nothing that records what the radio actually did.
SignalLab exists because of this.
The rule stated in the interface and the rule enforced in the code are held together by a test, so the app cannot quietly issue an authorization its own policy forbids.
SignalLab exists because of this.
There is no transmit control in the public app at all, and that boundary is enforced by tests rather than by convention or by a setting somebody could flip.
SignalLab exists because of this.
Withdrawal is kept on a separate list rather than written into the record, so a withdrawn authorization can never be mistaken for a tampered one.
SignalLab exists because of this.
Capability claims come from dated acceptance runs with retained capture evidence and checksums, and the failures — an adapter that drops off after about eleven minutes, an environment that could not take sustained monitor traffic — are published beside the passes on the same page.
SignalLab exists because of this.
Fixtures whose real-world analogue opens something require a second named approver, recorded inside the record so its fingerprint covers the countersignature.
SignalLab exists because of this.
An imported bundle is treated as untrusted: every fingerprint is recomputed rather than believed, and a record whose content no longer matches its stored digest is rejected by name.
SignalLab exists because of this.
The bench preflight is recorded inside the authorization at the moment it is true, not reconstructed from memory when the report is written.
How SignalLab works, start to finish.
SignalLab turns an RF or Wi-Fi test into a record that survives the engagement. You build an engagement authorization that pins the exact frequency range, a maximum output ceiling, the fixed attenuation in the path, the containment method, the fixture class and its asset id, the organization that authorized the work, and an expiration date. The app checks that combination before it will issue anything. Output above +10 dBm is refused outright, and there is no uncontained option to pick — the form does not offer one. If you choose a garage, gate, or vehicle-keyless fixture, a shield enclosure is required and a second named approver has to be recorded, because a fixture whose real-world analogue opens something is not a one-person decision. Before the authorization is issued you work a five-step bench preflight: the load is connected, the antenna is off the transmit path, the range was observed clear, the fixture is on an isolated supply, and the power cutoff is within reach. Those confirmations are written inside the authorization itself and covered by its integrity fingerprint, so a later reader sees exactly what was confirmed and when — not a checklist someone filled in from memory afterwards. If only some were confirmed, that is recorded honestly rather than rounded up. Once issued, the authorization can be checked by anyone who holds it. Eleven checks run: recognised format, the identity and fixture fields actually filled in, all four authorizations affirmed, still inside its window, not withdrawn, the frequency and power envelope still inside limits, containment still adequate for that fixture class, the second approver present where the class demands one, every prohibited-action flag still false, and a SHA-256 fingerprint that proves the content has not been edited since it was generated. Withdrawal is deliberately kept on a separate list keyed by that fingerprint rather than written into the record, because editing a record to mark it withdrawn would break its own fingerprint and make a withdrawn authorization indistinguishable from a forged one. The authorization says what was permitted. Test sessions record what was done — start and end times tied to that specific authorization, with an outcome and notes, and a session left open past its expiry is flagged rather than shown as neutral. You can compare two authorizations to see exactly what changed when one supersedes another, calculate the power actually arriving at the fixture rather than the number on the transceiver, and print one page that combines the authorization, the preflight as actually confirmed, and every session run against it. That page is the thing that goes in the engagement folder. The public app never transmits, and it never will — there is no transmit control anywhere in it, and a test enforces that. Anything that touches a radio happens on the separate bench executor you stand up on your own workstation with your own adapter. What the downloadable kit does today is passive: monitor-mode capture, monitor start and stop, and channel-hopping scans that inventory the access points and client stations on a dedicated lab network, driven from a local browser dashboard. A one-shot installer, that dashboard, a printable setup guide, and the exact validated system packages with per-component checksums are all downloadable from the site, and a separate hosted guide covers the two-adapter command-line setup that the dashboard does not drive. Active transmission is the part to be precise about, because it is where products usually oversell. The rules for it are written and enforced rather than assumed: a wireless plan is refused unless it carries an equipment allowlist, an isolated-range or shielded-bench environment, a frame budget, a pacing floor, a bounded execution window, an emergency-stop acknowledgement, and seven named prohibitions; and in an open-air isolated range the runner has to sweep the air first and abort before a single frame if any station outside the declared inventory is present. That gate and that runner are built and unit-tested, they ship inside the phone client, and they run against a simulated radio by default — no transmitting agent is included in the downloadable kit, and the acceptance run made no executor connection at all. The transmission actually proven on hardware so far is a bounded engineering test between two lab adapters: eight synthetic frames in each direction, all eight received both ways with zero drops, capture files retained and checksummed.
Everything in the current release.
Each of these is built and working today. Nothing on this list is a roadmap item.
Authorization that refuses to be vague
Build an engagement authorization that pins the frequency range, the maximum output, the attenuation in the path, the containment method, the fixture class and asset id, the authorizing organization, and an expiration. Output above +10 dBm is rejected and there is no uncontained option to select. The result is a bounded envelope rather than a sentence saying testing is approved.
The stated rule is the enforced rule
The hardware section says a shield enclosure is required for garage, gate, and vehicle-keyless fixtures. That exact sentence is what the app enforces, at issue time and again at verification, and a test asserts the wording and the enforcement agree. Before this was wired up you could authorize a garage fixture with a dummy load and get a record that read as approval — a stated policy the app does not apply is worse than no policy.
Two approvers for anything that opens something
Garage, gate, and vehicle-keyless fixtures require a second named approver with their role recorded inside the authorization, so the integrity fingerprint covers it. The rule of thumb is whether the real-world analogue of the fixture opens something. If it does, one person does not authorize it alone.
Bench preflight recorded at the bench
Five physical checks — load connected, antenna removed, range observed clear, isolated supply, cutoff reachable — are confirmed before the authorization is issued and stored inside it. Partial confirmation is recorded as partial, not quietly rounded up. Months later a reader sees what was actually confirmed rather than what the process says should have been.
Eleven-point verification anyone can run
Paste or load an authorization and run the same checks the bench will run: format, identity, fixture, all four confirmations, expiry, withdrawal, envelope bounds, containment against the fixture class, second approver, prohibited-action flags, and the content fingerprint. A failing fingerprint alongside another failure is normal — editing a record to weaken it changes the content, so the fingerprint stops matching too.
Withdrawal that cannot be confused with forgery
Withdrawing an authorization records its fingerprint on a separate list with a reason and a timestamp. The record itself is left untouched on purpose, because writing a withdrawn flag into it would change the content and break its own fingerprint. That would make a withdrawn authorization look identical to a tampered one.
Sessions: permitted versus done
The authorization records what was permitted; a session records what was done. Start and end times are keyed to that specific authorization, with an outcome and notes, and a session can only be started against an authorization that is currently valid and not withdrawn. A session still open after its authorization expired is flagged as such rather than shown as neutral.
Compare, supersede, and print the engagement artifact
Compare two authorizations to see exactly what changed when one replaces another, with the fields that always differ excluded so they do not bury the real change. A new authorization can declare the one it supersedes, so an amendment is traceable instead of a silent swap. One printable page combines the authorization, the preflight as confirmed, and every session run against it.
Link budget so the envelope is reasoned, not guessed
Transmit power minus attenuation minus cable loss gives you the level actually arriving at the fixture, in dBm and mW. It exists because containment has to hold the power that arrives, not the number printed on the transceiver. It writes only the two fields it computes and never touches your confirmations.
A transceiver identity check that refuses the wrong device
The app can confirm which bench transceiver is plugged into the workstation before you build the authorization. Two devices are in the registry: the HackRF One, the only transceiver approved here for contained active work, and a receive-only dongle that is recognised by name and then explicitly rejected as invalid for an active session. It is an identity check only — the app does not claim the device, tune it, or move any samples.
A monitor-mode bench kit you install once
The bench executor is the separate local piece that actually touches a radio: a small dedicated environment you stand up on your own workstation so a supported Alfa adapter comes up in real 802.11 monitor mode. A local browser dashboard shows adapter and monitor status, starts and stops monitor mode, and runs channel-hopping scans across 2.4 and 5 GHz that inventory the access points and client stations on a dedicated lab network — the raw material for rogue-access-point and evil-twin review. Everything the dashboard does is passive: it observes, it does not interfere.
The rules for active work are written down and enforced
Active resilience testing is governed by a signed wireless plan, and the gate that validates one is built and unit-tested. A plan is refused unless it carries an allowlist of equipment you own, an isolated-range or shielded-bench environment, a frame budget, a pacing floor, an execution window, an emergency-stop acknowledgement, and seven prohibitions named explicitly. In an open-air isolated range the runner must sweep first and abort before a single frame if any station outside your declared inventory is on the air — which turns there is no other traffic here from an assertion into a checked precondition. Be clear about where this lives: the gate and runner ship in the phone client and run against a simulated radio by default, and the downloadable bench kit includes no transmitting agent.
Two setup paths, both written up, with the failures published
The bench kit carries its own one-shot installer and printable guide for the single-adapter setup that the dashboard drives. A separate hosted guide, also downloadable as a PDF, covers the command-line setup for one supported Alfa adapter, the other, or both attached at once — verifying the download, installing the validated packages, binding and attaching, identifying each radio by driver rather than by a name that changes, putting every radio on the same test channel, stopping cleanly, and recovering after a disconnect. The validated package sets are published with per-component checksums, and the stability boundary is stated on the same page as the successes.
Nothing is uploaded, and there is no account
Authorizations, the audit trail, and withdrawals live in your browser on that device. The audit trail records that an action happened with a timestamp and engagement id, never the content of a record. There is no server-side copy, no account to create, and no telemetry, and the whole tool works offline once installed. The one thing that leaves your machine is a contact message, if you choose to send one.
A phone app for capture review and plan building
A native Android client analyses capture data on the device and reports evil-twin, privacy-downgrade, channel-drift, deauthentication-flood, preferred-network-list exposure, and handshake-capture findings without any radio attached. It also builds a bounded wireless engagement plan with declared inventory, environment, frame limits, pacing, capture window, and emergency-stop acknowledgement, and it starts in passive mode with the simulated radio selected by default. It is signed and has passed an acceptance run, but it is not published on any store and is not downloadable from the site.
Numbers we can stand behind.
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
Numbers we can stand behind.
The governance layer and the bench radio are the same product, connected by the signed authorization, so the proof travels with the work.
Surfaces and status.
Status as of 2026-09-02. Re-checked 2026-09-02: the homepage, the public setup guide, the privacy policy, the guide PDF, the sitemap, and the executor kit download all returned HTTP 200 with no login, and the served homepage matches the repository copy. The repository's own status line reads 'Live and working', with dated release entries through 2026-09-01 covering the homepage funnel rework and the working contact form. The site is indexable and lists three URLs in its sitemap. The Android client is signed and acceptance-tested at 1.0.2 but has no published store listing and no physical-device acceptance, so that surface alone is marked In development.
Worth more together.
Products on this platform share one sign-in, one support queue, and one engineering standard. These pair naturally with SignalLab.
BandSight
SignalLab covers contained bench work and the governance around it. BandSight is the receive-only side: field discovery and survey with a phone or a receive-only dongle, for when you are walking a site rather than sitting at a bench. SignalLab actively recognises that receive-only dongle and refuses it for an active session, because it is BandSight's device.
Network Sentinel
Once the RF and Wi-Fi layer is characterised, Sentinel is where the network side of the same environment is watched. SignalLab was originally part of its console before becoming its own product in August 2026.
ASL Scan
Teams running authorized RF engagements usually run authorized application and infrastructure assessments too. Scan applies the same signed-scope discipline to that side of the work.
ASL Vault
Engagement artifacts, capture evidence, and approver records need somewhere durable to live once the session report is printed. Vault covers the storage side that a device-local tool deliberately does not.
Recent progress.
This product ships often. The most recent verified changes, newest first.
Recent progress.
2026-09-01 the homepage was reworked from a tool-only page into a full funnel while keeping every existing capability, download, and safety boundary intact: new sections covering who uses it, what the bench has actually been validated to do, and a working contact form whose delivery was proven end to end. The site was made indexable for the first time and a hosted privacy policy was published, effective the same day. Also on.
Recent progress.
2026-09-01 the Android client was rebuilt as 1.0.2 (version code 3) with its store application id in place — that is the most recent commit in the repository.
Recent progress.
2026-08-27 the biggest technical release of the period: both supported Alfa adapters were attached simultaneously and passed firmware initialization, monitor mode, and concurrent passive scans with zero drops, followed by a bounded bidirectional frame injection acceptance in which all eight unique synthetic frames were received in each direction with zero receiver drops and retained capture evidence. The long-duration boundary that did not pass was published alongside it. The public adapter setup guide was expanded to cover one or both adapters and made properly discoverable, and the validated system package sets were published as downloads with per-component checksums.
Recent progress.
2026-08-24 the Android client passed an emulator acceptance run with 26 of 26 core tests green and fourteen screenshots retained as evidence.
Recent progress.
Pricing for SignalLab is quoted after a short conversation about your situation, because the right scope differs from one team to the next. There is no charge for that conversation.
What does it cost?
Pricing is per engagement rather than a published subscription, because the scope varies enormously between a single fixture review and a multi-week Wi-Fi assessment. Tell us the fixtures, bands, containment, and the authorization you already hold, and you get a number. The public app, the setup guide, and the bench kit are on the site now with nothing to sign up for.
We already track authorizations in a shared document. Why change?
A shared document cannot tell you whether the copy in the engagement folder is the copy that was approved. SignalLab gives each authorization a content fingerprint, so anyone holding it can check in seconds that nobody widened the frequency range or raised the power ceiling after approval. It also refuses to issue an authorization that its own containment rules would not allow, which a document cannot do.
Where does our data go?
Nowhere. Authorizations, the audit trail, and withdrawals are held in your browser on that device. There is no account, no server-side copy, and no telemetry, and the tool works offline once installed. The only thing that leaves your machine is a contact message if you choose to send one, and that is separate from the tool.
What happens if we stop paying?
Your records are already on your own machine, not in an account we can switch off. You can export a bundle at any time and the printable session report is just a page you print. Verification of an existing authorization is arithmetic over the file you hold, so a record you generated stays checkable regardless of any commercial relationship.
Is it actually ready, or is this early work?
The site, the authorization workflow, the verifier, the setup guide, and the bench kit download are live today, and the app is covered by 45 automated tests across two suites. The two-adapter capability claims come from a dated August 2026 acceptance run with retained capture evidence and checksums. Two things are deliberately not claimed: unattended long-duration operation on one of the two adapters, and turnkey active transmission — the rules for active work are built and tested, but the downloadable kit ships no transmitting agent. Both limits are published on the same page as the successes.
Does it transmit? Can it open a garage door or clone a fob?
The public app does not transmit and never will. It has no transmit control anywhere in it and tests enforce that. It will not provide a workflow for opening garages, gates, or vehicles, cloning or replaying remotes, Wi-Fi deauthentication of third parties, jamming, credential capture, or transmitting arbitrary captured recordings. That is a product decision, not a gap waiting to be filled.
So what can the bench side actually do today?
It gives you a genuine 802.11 monitor-mode radio on your own workstation and passive work on top of it: monitor start and stop, and channel-hopping scans that inventory the access points and client stations on a dedicated lab network, from a local browser dashboard. Active resilience testing is governed by a signed plan whose gate and runner are built and unit-tested and run against a simulated radio by default; making them drive a real radio needs an executor endpoint that is not part of this product today. If active testing is what you are buying, that is a scoping conversation, not a download.
What hardware do we need?
For the authorization side, nothing — it runs in a browser. For contained active RF work the recommended transceiver is a HackRF One used with a dummy load, fixed attenuation, or a verified shield enclosure. For Wi-Fi work you need a supported Alfa adapter (AWUS036ACM or AWUS036AXML, or both) and a Windows workstation for the bench executor, plus a dedicated lab access point and client, because a wideband receiver is not a substitute for a normal 802.11 test interface.
How much work is it to get started?
The authorization side is immediate — open the site and build your first record in a few minutes, with nothing to install and nothing to migrate. The bench executor is the real setup: the installer does most of the workstation side in one pass but budgets twenty to thirty minutes of mostly unattended install, and the hosted guide walks through the validated packages, attaching one or both adapters, identifying each radio by driver, entering monitor mode, stopping cleanly, and recovering after a disconnect. Budget an afternoon for the bench the first time.
What should I know before I rely on it?
We would rather you hear this from us than discover it later. As of 2026-09-02:
What should I know before I rely on it?
Authorizations, the audit trail, and withdrawals live in one browser on one device. A private window, cleared site data, a different browser, or a different machine all start empty — export a bundle if you need them elsewhere.
What should I know before I rely on it?
The browser keeps the 25 most recent authorizations. It warns you before you reach the cap and tells you how many records an import displaced, but it is still a cap.
What should I know before I rely on it?
Withdrawing an authorization does not reach a copy someone already downloaded. That is a real limit of a device-local record, and it is the reason expirations should be kept short.
What should I know before I rely on it?
The public app never transmits. Any radio work needs the separate bench executor on your own workstation, and standing that up is a setup job measured in hours, not minutes — the installer alone budgets roughly twenty to thirty minutes of mostly unattended install, and the dashboard needs two extra tools present on the workstation.
What should I know before I rely on it?
What the downloadable bench kit does today is passive: monitor-mode control and channel-hopping scans that inventory access points and client stations. It ships no transmitting agent and no active-plan endpoint.
What should I know before I rely on it?
The signed-plan gate and runner for active resilience testing — allowlist, isolated-range sweep, frame budget, pacing, stop control, read-back — are built and unit-tested inside the phone client, and they run against a simulated radio by default. Driving a real radio through them requires an executor endpoint that is not part of this product, and no such connection has been exercised in any acceptance run.
What should I know before I rely on it?
The only transmission proven on hardware so far is a bounded engineering test between two lab adapters using synthetic frames. It is not a customer-facing feature and it added nothing to the public app.
What should I know before I rely on it?
The kit's browser dashboard drives the single-adapter setup only. The two-adapter setup covered by the hosted guide is command-line work and is not driven by that dashboard.
What should I know before I rely on it?
The AWUS036ACM is not accepted for unattended or long-duration sessions on the two-adapter path. In the August 2026 acceptance run it dropped off after roughly eleven minutes of repeated capture work and was recovered without unplugging anything. Short sessions pass; long ones are not claimed.
What should I know before I rely on it?
In the kit's own single-adapter environment the AWUS036AXML is not approved as the dependable bench radio — sustained monitor traffic crashed that environment. It is kept there for bounded, manually attached work only, and the AWUS036ACM is the dependable radio for that path.
Prove what you were allowed to transmit.
Prefer email? contact@autosecurelogin.com