VirtuProbe Studio
FAQ
Everything about VirtuProbe Studio — what it does, how it works, which tier you need, and how to get started.
VirtuProbe Studio is a multi-protocol request workbench for engineers and security professionals. It lets you send raw requests over HTTP, SMTP, IMAP, LDAP, DNS, SMB, Kerberos, and SpamAssassin from the same interface, chain them together, and script them with Groovy.
The core idea: your real-world integrations don't stop at HTTP. VirtuProbe doesn't either.
Two main audiences:
If a single-purpose HTTP proxy is your daily driver and you keep reaching for other tools the moment something isn't HTTP — VirtuProbe is the side door you were missing.
Most request tools stop at HTTP. VirtuProbe covers eight protocols in a single interface. The other key differences:
§payload§ and run a wordlist against it. Works across all protocols.No. VirtuProbe is a desktop application that runs entirely on your machine. The execution server can also be deployed inside a target network (or a Docker container) for probes that need to fire from within the perimeter — but there is no VirtuProbe cloud service that handles your requests.
Your probes and data never leave your machine unless you point a probe at an external target yourself.
Yes. Pre-built installers are available for:
.dmg.exe installerAppImageThe application bundles its own JVM — no Java installation required.
VirtuProbe currently supports eight protocols, each with a hand-written client stack:
A SOCKS5 MITM proxy is also included for traffic interception and replay.
Standard libraries "help" by fixing things — they normalise headers, reject invalid method names, refuse to send malformed packets. That is exactly what you don't want when you're testing protocol edge cases or fuzzing.
VirtuProbe's stacks are written directly against the RFCs. This means you can send whatever you want on the wire, including things that should fail — which is the point when you're finding bugs or testing server resilience.
Yes — that's the core value of chains. A chain is a sequence of steps that can mix protocols freely. A typical example: send an HTTP login request, extract the session token from the JSON response, then use it in an LDAP search. Each step's output feeds the next via variable extraction.
Supported chain steps: HTTP, SMTP, IMAP, LDAP, DNS, SMB, Kerberos, SpamAssassin, plus control flow steps (ITERATE, CONDITION, PARALLEL, ASSERT, CHAIN_REF).
SMB is available as a probe and in the library, but it cannot be used as a chain step today — it's the only protocol without a chain executor. This is a known gap and is on the roadmap.
SMB support requires the Security tier. It includes file read/write/delete, directory operations, share enumeration, ACL reads and writes, plus pass-the-hash authentication.
A chain is a named sequence of steps. Each step can be a protocol probe or a control-flow instruction. Steps share a variable context: an earlier step can extract a value (e.g. HTTP_JSON_PATH $.token) and later steps reference it with {{token}}.
Control-flow step types:
Extractors pull values from step responses and store them as chain variables. Available extractors:
HTTP_STATUS — HTTP response status codeHTTP_JSON_PATH — JSONPath expression against the response bodyHTTP_BODY_RAW — entire response body as a stringHTTP_HEADER — a specific response header value (case-insensitive)LDAP_SUCCESS — whether the LDAP operation succeededLDAP_EXCHANGE_RESULT_CODE — result code for a specific LDAP operationDNS_SUCCESS — whether the DNS query resolvedDNS_ANSWER_VALUE — the first answer record's valueREGEX — arbitrary regular expression against any textCONSTANT — a literal value (useful for seeding variables)Scripts are Groovy programs that run in a sandboxed GroovyShell. They have access to a vp binding that exposes the VirtuProbe API. You can send probes programmatically and process their responses:
def result = vp.send("My Bundle", "Login probe", [username: "alice"])
println result.extract("HTTP_JSON_PATH", "$.token")
Use println — output captured via the out binding appears in the UI. System.out.println is not captured.
Scripts belong to a Project and share that project's environment variables.
Fuzzing lets you run a probe repeatedly, substituting different payloads into marked fields on each run. Mark a field with §payload§ (section-sign markers) and supply a payload list — VirtuProbe substitutes the payload and collects the results.
Works in any probe field across any protocol. Results are not saved to history — they appear in the fuzz results panel only. Fuzzing requires the Security tier in the UI; the backend engine is protocol-agnostic.
Each Project can have multiple named environments (e.g. "Dev", "Staging", "Prod"). Each environment is a key-value map. Switching the active environment instantly changes which values are injected into probe fields and chains that reference {{varName}}.
Variable priority: values set during chain execution override environment variables (chain wins on collision). Probe inline variables override environment variables too.
The free tier gives you a fully working workbench with no time limit — and a lot of things other tools charge for:
No account. No cloud. No credit card. No "free trial" countdown. The free tier is permanently free.
Engineering tier is for shipping and debugging integrations:
Engineering Pro adds service virtualization (mock rules in the proxy), the infrastructure library, self-hosted API server and team collaboration.
Security tier is aimed at penetration testers and security researchers — it inherits everything in Engineering (including the MITM proxy) and adds the offensive kit:
§payload§ markers in any probe fieldSecurity Pro additionally inherits Engineering Pro's service virtualization, plus custom protocol modules and an audit log.
Yes — the Academic License gives verified students and academics full Security tier access at no cost. It's available to:
When you subscribe via Paddle, you receive an access key (UUID). Enter your email and that key in the License panel inside VirtuProbe Studio. The app validates against the license server and caches your tier locally — it re-validates every 12 hours in the background.
Your license is tied to the email you used at checkout, and it activates on up to three of your own devices. The app works offline for up to 12 hours without a license server connection.
Yes — one license covers one person on up to three devices (laptop, desktop, a VM — whatever you work on). To cover more people, each person needs their own license; for teams and organisations, reach out — team and Enterprise arrangements are handled on request.
No. The installer bundles a complete JVM (Temurin 21). You do not need to install Java, and the bundled JVM does not conflict with any existing Java installation on your system.
Current builds are unsigned. macOS Gatekeeper will warn you because the binary doesn't carry an Apple notarisation certificate yet. Signed builds are coming in a near iteration.
In the meantime: verify the SHA-256 checksum published on the download page before opening. If anything looks off, write to security@virtuprobe.studio.
To open an unsigned app: right-click → Open → Open anyway (macOS will remember the exception for this file).
VirtuProbe stores probes, bundles, chains, scripts, and settings in a platform-appropriate directory:
%APPDATA%\VirtuProbe~/Library/Application Support/VirtuProbe Studio~/.local/share/virtuprobeEverything is stored locally in a Nitrite embedded database. No cloud sync. To back up your data, copy this directory.
Yes. The execution server is a standalone Spring Boot JAR that can be deployed inside a Docker container or on a server inside your target network. The UI connects to it remotely over HTTP/WebSocket. This is the recommended architecture for corporate or on-prem setups where you need probes to fire from within a specific network segment.
A fully air-gapped, self-hosted deployment — detached licensing, no phone-home — is on the roadmap for later in 2026 as an Enterprise option.
Two external calls happen automatically:
license.virtuprobe.studio — only when a license key is configured; checks your subscription status. Never transmits probe content.dl.virtuprobe.studio/latest-version.json — a single JSON file fetch at startup. Used to show the "new version available" notice. No telemetry.All other network activity is initiated by you when you send a probe to a target you configure.
Write to security@virtuprobe.studio. Please include a description of the issue, steps to reproduce, and any proof-of-concept you have. We aim to respond within one business day and to ship a fix within 14 days for confirmed vulnerabilities.
We'd rather hear it from you than read about it elsewhere.
The SOCKS5 proxy binds to localhost by default and is not exposed on the network. It generates a self-signed CA certificate on first use — you install this CA in your browser or system trust store to intercept TLS traffic. The CA private key stays on your machine and is stored in the VirtuProbe data directory.
Only route traffic through the proxy that you own or have explicit permission to intercept.
The docs cover everything in detail. Or just ask directly — it goes straight to my inbox.