From a proxy plugin
to a standalone workbench.

01How it started

VirtuProbe began as a plugin for a popular web-security proxy. The problem was familiar: that proxy is excellent for a single engagement, in one window, against one target. The moment your work spans projects, with different clients, different scopes and different protocol sets, its model starts to fight you. Workspaces don't share. Project switching is heavy. Anything that isn't HTTP lives outside the tool entirely.

I started writing a plugin to compensate. It grew. Then I sat down, looked at what I had, and realised the frame was wrong. I was trying to bolt a different product onto someone else's foundation.

And the more I looked at it, the more familiar the gap felt. Wherever I'd worked, a greenfield core-banking platform one year and a pixel taking hundreds of millions of hits a day the next, I kept hitting the same wall: the testing tools the market handed me were never quite enough, and I'd end up coding around them, sometimes for weeks at a stretch. The proxy plugin was just the latest patch over the same hole. So on those nights at the keyboard I decided to stop patching and close the gap properly.

So I started again, this time as a standalone. The internal codename was beer-request-manager (don't ask). The plan was deliberately small: get the cross-project bits out of the way and ship a no-nonsense workbench for the protocols I actually used.

Then I kept going, mostly during sleepless nights on Hack The Box. The protocol list grew: HTTP, then SMTP, IMAP, LDAP, DNS, SMB, Kerberos, SpamAssassin scoring. Hand-rolled stacks against the RFCs, because every library I'd reached for "helpfully" fixed my malformed input before it ever went out. Chains, so I could stitch the protocols together. A MITM proxy, because once you have probes, the natural next step is "catch a real request and turn it into one."

What started as a plugin to patch one tool's seams turned into its own thing, VirtuProbe Studio.

02The companion plugin still exists

I haven't abandoned the original. The companion plugin lives on, scoped down to two operations that are genuinely useful when that proxy is already your home:

• Send any HTTP request from the proxy into VirtuProbe as a probe, which helps when you've shaped a request in its repeater and want to chain it across other protocols.
• Expose a small endpoint inside the proxy that VirtuProbe can post to, dropping the probe straight into its target list for further work.

If that proxy is your daily driver, VirtuProbe is a side door, not a replacement.

03Who's behind this

VirtuProbe started as a one-person project. It isn't one anymore. A small team now builds and maintains it together, and a proper company around it is taking shape. For now it runs as an independent business.

04How to reach me

VirtuProbe is a small operation, deliberately. There is no support queue routed through three SaaS layers. It goes to my inbox.

If you find a bug or a security issue, write to security@. I'd rather hear it from you than read about it elsewhere.

05About the binaries

macOS builds are signed with an Apple Developer ID and notarized by Apple, so they open with no Gatekeeper warning. Windows builds are not yet code-signed (Authenticode is next), so SmartScreen warns on first launch. Every download carries a published SHA-256 checksum. If you're cautious about installing software from a small vendor, and you should be, verify the SHA-256 before opening and write to security@ if anything looks off.

Installation is local. The application stores your work on your own disk. The only servers the application contacts on its own are the license validator and the update channel; everything else only happens when you point a probe at it.