Why A1-One exists
Commercial obfuscators are expensive, locked per-machine, and rarely cover more than one ecosystem. Eazfuscator handles .NET well — and only .NET. Dotfuscator is enterprise-priced. JavaScript-obfuscator is fine for JS — but if you also ship a Go service, you're back to writing your own pipeline.
We shipped a .NET ERP, a check-printing WPF, a real-estate WPF, a data-migrator WPF, an SSL manager, and 57 Go microservices for A1Firewall — across .NET Framework 4.x, .NET 8/9, React/Vite, and Go 1.26. None of the off-the-shelf options spoke all four languages and produced a single watermark we could verify in one place.
So we wrote A1-One: a fork of ConfuserEx 2 with our own watermark patch, an npm wrapper around javascript-obfuscator, a garble + Ed25519 wrapper for Go, and a small shell-script protector. One key. One watermark. One verifier per runtime. The same workflow whether you're shipping a WPF installer or a FreeBSD service binary.
How we think about the product
Same key across every engine
The watermark on a .NET DLL, a React bundle, and a Go binary all share a1one.key. One key to rotate, one key to vault. A1Verify, a1verify-js and a1verify-go all answer the same question — was this binary tampered with after we shipped it?
Local-first, no phone-home for protection
The protector runs on your machine. The engine never sends bytes anywhere. License activation is the only network call, and that's deferred until the trial expires.
Honest fallbacks
The product subdomain (protector.a1-soft.com) is the canonical buy URL, but the protector probes it live. When it's down, the trial banner and "Buy" page link fall back to the central a1-soft.com hub automatically — customers always have a working path to pay.
We use it ourselves
Every A1-Soft product that we sell to a customer was protected by A1-One first: A1Realty, A1CheckPrinter, A1-DataMigrator, SSLCertManager, and the A1Firewall fleet. If it breaks, it breaks us first.
Roadmap highlights
2026 Q2
Shell engine reaches feature parity with the other three engines
2026 Q3
Python engine (pyarmor wrapper + HMAC sidecar) — opt-in beta
2026 Q4
Hardware-bound license tokens (TPM 2.0 sealing) for enterprise tier
2027 Q1
VS Code extension matching the Visual Studio 2022 VSIX
2027 Q2
Cloud-based key escrow + signed transparency log for verifier checks
What we won't do
We will not phone home from your protected binaries. We will not gate features behind subscriptions you can't audit. We will not add telemetry to the verifier. The whole pipeline is transparent — the engine source is open (BSD-2 base, our patch on top), and any organisation can reproduce a protected build byte-for-byte given the same key.