VirtuProbe Studio
VirtuProbe Studio
Blog
Protocol write-ups, why the tool is built the way it is, and the things that turn out to behave differently than we assumed.
A webhook sender calls back on its own schedule, after the request that triggered the event has already returned, so a test has to receive the callback and know which run it belongs to. This one gives each test run its own callback URL, waits for the callbacks with a deadline and stops waiting the moment they arrive, and asserts on the payload, down to which event came first and whether the same one was sent twice. It also covers running the same suite from a CI/CD pipeline, where the callbacks are caught inside the execution server container, and a run whose listener could not start exits with its own code and names the reason, so it never reads as a sender that did not deliver.
Read more →An agent decides what a tool does by reading the description the server sends with it, and nothing in the protocol signs that text. This one reads those descriptions through a proxy as they arrive, shows what a hostile one carries and how a whole sentence hides in a block of characters no renderer draws, and then rewrites one in transit. It also covers adding a tool the server never advertised, the emoji flag that a careless exemption would hand straight back to an attacker, and writing the interception test so that a finding on a clean tool can only have come from the rule.
Read more →The checks that catch what unit tests cannot cross services and protocols, so none of them belongs to a single repository and none appears in the test stage of a single build. This one places an order over HTTP, reads the row it leaves in the database and finds the confirmation it sends to a mailbox, composed in an editor and then handed to a pipeline that gates on the result. It also covers what a green run is allowed to mean, where a secret goes so it does not end up in the artifacts a pipeline archives, and the three ways to reach a test environment from CI.
Read more →Comprehension used to arrive free, as a byproduct of writing the code, which is why no lifecycle model ever named it as a deliverable and why nothing in a process reports its absence. Build and verification now sit inside a loop that a person supervises instead of working through, so review is the only stage left where a system still enters a human head. What that changes is different at each stage, from what a ticket has to contain before it is ready to why a missing check is visible only in the set of tests and never in any one of them.
Read more →A library is built to stop its caller sending anything the spec calls invalid, which is the wrong instinct in a penetration testing tool, so the SMB client is written by hand with no runtime dependencies. What that buys is pass-the-hash, SAMR enumeration and a real DCSync against a domain controller. What it cost was an afternoon on two stacked bugs, where the same request bytes returned every share from Samba and an empty list from a Windows server, and the test fleet had been reporting the feature as working the whole time.
Read more →A container ends a connection with a TCP reset. Reached on 127.0.0.1 the client sees an ordinary close instead, and reached on the host's own LAN address, through the very same published port, it sees the reset. The relay in the way is docker-proxy, the line that decides which path you get is one iptables rule, and only the abnormal close disappears, so a suite that tests for a hanging server stays perfectly green while the one thing under test is quietly wrong.
Read more →A friend who runs engineering at an AI-first company installs an agent on a fresh server before anything else, and no longer writes instrumentation at all. That is a fair question to put to a testing tool. The answer I arrived at: determinism, repeatability and evidence are properties of the artifact, not of the actor. An agent authors, a person supervises through a glass box, and the frozen artifact runs with evidence. Plus the part I had backwards, and what is still not built.
Read more →VirtuProbe's power was letting you hand-drive the protocol conversation: the exact EHLO, the malformed MAIL FROM. That's exactly what most people testing an integration don't want to do. Action Mode lets you state the outcome, send an email or find a message or check a login, and keeps the raw commands one click away. Plus why "find the latest message" had to be a small program.
Read more →MCP looks like a whole new protocol to support. It isn't. It's JSON-RPC over HTTP with a session header and an optional event stream. The design story of teaching the HTTP probe to test Model Context Protocol servers: a body mode instead of a module, a session that's just a chain, and the one piece we genuinely had to build, streaming a response into the panel live.
Read more →MySQL is the ninth protocol and the only one not hand-written against the protocol. It is a thin layer over MariaDB Connector/J and HikariCP. The design decisions behind it: why an integration test should end in the row not the response, pooling by connection signature, treating a rejected statement as data rather than a crash, stringifying every cell, and why the auth escape-hatches ship off by default.
Read more →A practical walkthrough of AS-REP Roasting and Kerberoasting: talk straight to the KDC with a hand-rolled RFC 4120 stack, pull a crackable hash in hashcat format, and chain the whole thing off an LDAP lookup. For authorised testing, labs and CTF boxes.
Read more →Request smuggling is one of the highest-impact web bugs and one of the most dangerous to confirm, because the textbook proof traps a real user's request. How VirtuProbe finds CL.TE and TE.CL desync by timing instead, on a client that sends raw bytes, without poisoning a victim.
Read more →Most real tests aren't one request. They're a sequence where each step depends on the last. How the value gets from one step to the next: extractors, {{variables}} and control-flow steps, across HTTP, DNS, SMTP and LDAP in one runnable chain.
Read more →When a model can ship an integration in an afternoon, "write the code" stops being the bottleneck. Knowing it actually works, under load and against malformed input and on the protocol that doesn't quite follow the spec, becomes the whole job. Why the running system is the only source of truth left.
Read more →A friend called VirtuProbe a "nice, semi-serious project". He meant it kindly; it stung, and it was right. The distance between a semi-serious tool and one an engineer trusts with their day isn't the feature list. It's the focus ring, the missing keyboard shortcut, the dialog that won't take your cursor. Notes on the thousand small frictions nobody screenshots.
Read more →VirtuProbe started as a plugin to patch the seams of a web-security proxy that fought me the moment work spanned more than one target and more than one protocol. Here's how a nightly side project on Hack The Box turned into a standalone tool with eight hand-rolled protocol stacks, and why I stopped patching someone else's foundation.
Read more →