VirtuProbe Studio
Get the app

FAQ

Questions we actually
get asked.

Everything about VirtuProbe Studio — what it does, how it works, which tier you need, and how to get started.

01General

What is VirtuProbe Studio?

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.

Who is it for?

Two main audiences:

  • Integration engineers — building or testing systems that talk SMTP, LDAP, DNS, or similar. VirtuProbe replaces ad-hoc tooling and telnet sessions with a structured, repeatable interface.
  • Security professionals — penetration testers and bug bounty hunters who need wire-level access to protocols, the ability to send malformed packets (fuzzing), and a MITM proxy that gives you full protocol visibility.

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.

What makes it different from other request tools?

Most request tools stop at HTTP. VirtuProbe covers eight protocols in a single interface. The other key differences:

  • Custom protocol stacks — hand-written against the RFCs, not wrapping a library. This means you can send malformed packets, arbitrary commands, and raw payloads that a standard library would silently sanitise.
  • Cross-protocol chaining — a single chain can send an HTTP probe, extract a token, use it in an LDAP bind, then check the result with a DNS lookup.
  • Fuzzing — mark any field with §payload§ and run a wordlist against it. Works across all protocols.
  • MITM proxy — intercept and replay traffic at the wire level, not just HTTP.
Is there a hosted / cloud version?

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.

Does it work on Windows, macOS, and Linux?

Yes. Pre-built installers are available for:

  • macOS — Apple Silicon (ARM) and Intel (x64), distributed as a .dmg
  • Windows — x64, distributed as an .exe installer
  • Linux — x64 and ARM, distributed as an AppImage

The application bundles its own JVM — no Java installation required.

02Protocols

Which protocols are supported?

VirtuProbe currently supports eight protocols, each with a hand-written client stack:

  • HTTP/HTTPS — arbitrary methods, raw headers, body, cookies, redirects, TLS
  • SMTP — full command sequence, STARTTLS, AUTH, DATA, fuzzing per-command
  • IMAP — login, list, select, fetch, search, STARTTLS
  • LDAP — bind, search, compare, add, modify, delete; custom filters
  • DNS — A, AAAA, MX, TXT, CNAME, SRV, PTR; UDP and TCP; custom resolvers
  • SpamAssassin — SPAMC/SPAMD protocol for message scoring and analysis
  • SMB — file operations, share enumeration, ACL reads; NTLM auth and pass-the-hash (Security tier)
  • Kerberos — AS-REQ credential validation, AS-REP Roasting, Kerberoasting (Security tier)

A SOCKS5 MITM proxy is also included for traffic interception and replay.

Why are the protocol stacks hand-written instead of using libraries?

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.

Can I use multiple protocols in a single test?

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).

Is SMB different from the other protocols?

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.

03Chaining & Scripting

How does request chaining work?

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:

  • ITERATE — runs child steps once per item in a list; last iteration's variables bubble up
  • CONDITION — evaluates a Groovy expression; skips children if false
  • PARALLEL — forks child steps into concurrent workers, merges results
  • ASSERT — fails the chain if a variable doesn't match an expected value or pattern
  • CHAIN_REF — calls another chain as a sub-routine, passing and receiving variables
What extractors are available?

Extractors pull values from step responses and store them as chain variables. Available extractors:

  • HTTP_STATUS — HTTP response status code
  • HTTP_JSON_PATH — JSONPath expression against the response body
  • HTTP_BODY_RAW — entire response body as a string
  • HTTP_HEADER — a specific response header value (case-insensitive)
  • LDAP_SUCCESS — whether the LDAP operation succeeded
  • LDAP_EXCHANGE_RESULT_CODE — result code for a specific LDAP operation
  • DNS_SUCCESS — whether the DNS query resolved
  • DNS_ANSWER_VALUE — the first answer record's value
  • REGEX — arbitrary regular expression against any text
  • CONSTANT — a literal value (useful for seeding variables)
How does Groovy scripting work?

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.

What is fuzzing and how do I use it?

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.

How do environment variables work?

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.

04Pricing & Licensing

What's included in the free tier?

The free tier gives you a fully working workbench with no time limit — and a lot of things other tools charge for:

  • HTTP, DNS, and SMTP probes + chaining (ITERATE, CONDITION, PARALLEL, ASSERT, CHAIN_REF)
  • Unlimited probes, bundles & chains
  • AI assistant — bring your own key; we never charge for tokens
  • API auth — OAuth2 (every flow), Basic, Bearer, API key, Digest
  • GraphQL requests
  • Import OpenAPI / Postman / Bruno / HAR / Insomnia / cURL
  • Directory-backed, git-native workspaces
  • Run history, diff & JSON evidence export
  • Community library access (78 probes across protocols)

No account. No cloud. No credit card. No "free trial" countdown. The free tier is permanently free.

What does Engineering tier add?

Engineering tier is for shipping and debugging integrations:

  • Stateful protocols: IMAP, LDAP
  • Groovy scripting (with a real code editor — autocomplete & linting)
  • MITM proxy & interception (TLS termination)
  • Enterprise & Windows auth — NTLM, Pass-the-Hash, SPNEGO/Kerberos, AWS SigV4, mTLS
  • Integrations library (Slack, Jira, GitHub, AWS, Azure, GCP, and 130+ more)

Engineering Pro adds service virtualization (mock rules in the proxy), the infrastructure library, self-hosted API server and team collaboration.

What does Security tier add on top of Engineering?

Security tier is aimed at penetration testers and security researchers — it inherits everything in Engineering (including the MITM proxy) and adds the offensive kit:

  • Fuzzing§payload§ markers in any probe field
  • SMB probe — file ops, share enum, ACL, NTLM, pass-the-hash
  • Kerberos probe — AS-REP Roasting, Kerberoasting
  • SpamAssassin scoring
  • Full pentest library (HTTP, SMTP, IMAP, DNS, Active Directory, API security — 202 probes)

Security Pro additionally inherits Engineering Pro's service virtualization, plus custom protocol modules and an audit log.

Is there free access for students or academics?

Yes — the Academic License gives verified students and academics full Security tier access at no cost. It's available to:

  • Students currently enrolled in a degree programme (any field)
  • Researchers and faculty — PhD candidates, postdocs, lecturers, professors
  • Instructors licensing for a course, and university security/CS societies or CTF teams

Apply for the Academic License →

How does licensing work technically?

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.

Can I use it on more than one machine?

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.

05Installation

Does it require Java to be installed?

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.

The macOS installer says it's from an unidentified developer — is it safe?

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).

Where does VirtuProbe store its data?

VirtuProbe stores probes, bundles, chains, scripts, and settings in a platform-appropriate directory:

  • Windows%APPDATA%\VirtuProbe
  • macOS~/Library/Application Support/VirtuProbe Studio
  • Linux~/.local/share/virtuprobe

Everything is stored locally in a Nitrite embedded database. No cloud sync. To back up your data, copy this directory.

Can I run just the execution server without the desktop UI?

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.

06Security

Does VirtuProbe send any data to external servers?

Two external calls happen automatically:

  • License validationlicense.virtuprobe.studio — only when a license key is configured; checks your subscription status. Never transmits probe content.
  • Version checkdl.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.

I found a security issue — how do I report it?

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.

Is the MITM proxy safe to use on a shared network?

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.

Still have questions?

The docs cover everything in detail. Or just ask directly — it goes straight to my inbox.

Join our Discord