Yakit: the Electron client for the Yaklang security engine

What Yakit is for, and who it is aimed at

Yakit is the graphical client for Yaklang, a domain-specific language for security work. The README describes the split plainly: the team wrote a gRPC server for Yaklang, then built Yakit as a client that drives that server. The GUI is the product; the language is the engine.

The stated goal is consolidation. Security teams run a proxy here, a fuzzer there, a reverse-shell listener somewhere else, and glue them together by hand. Yakit's answer is to expose every engine capability through one interface, and to let users who do not want to write code still reach the underlying primitives. The README frames this as giving all Yaklang capabilities a GUI, with the interface maturing over releases.

That makes the target user a penetration tester or security engineer who works interactively. Someone who needs a scheduled, unattended scan across thousands of hosts is not the audience the README describes. The tool assumes a human at the keyboard, editing a request, deciding what to send next.

The gRPC engine split and what it buys you

The architecture is client and server. Yakit is an Electron application (package.json sets main to app/main/index.js and describes the package as the "yaklang.io Electron GUI Entry"). The Yaklang engine runs as a gRPC server. The README says this server can be deployed remotely or started locally on the host.

That separation is the most consequential design decision in the project. A remote engine means the GUI can run on a laptop while the engine sits on a machine with network reach into the target environment. It also means the GUI is not where the scanning logic lives. If the engine is down, or the gRPC channel is blocked, the client has nothing to drive.

The README states the engine's HTTP library is hand-written rather than borrowed. That is what allows malformed request and response packets to be constructed deliberately, which the documentation presents as useful for exploit work in special cases. The same choice is why the Web Fuzzer can repair CRLF, complete Content-Type, handle chunked transfer, fill in multipart boundaries and fix Content-Length on the user's behalf, so the operator only edits the parts of the request that matter.

MITM interception in Yakit, and where it stops

The MITM module starts an HTTP proxy and forwards traffic. When manual hijacking is switched on, automatic forwarding stops, the request is blocked and pushed to the interface after Gzip decompression, chunk handling and decoding, so the operator sees something readable and can edit or replay it. On replay, the backend repairs the constructed packet so it stays valid.

The README claims the MITM console can replace BurpSuite for all operations, including certificate installation, request and response hijacking, and packet editing, and describes a workflow of hijack, then History, then Repeater or Intruder via the Web Fuzzer. Treat the replacement claim as the vendor's position, not a measured result. The realistic question is whether the extensions and integrations your team already depends on exist here. Yakit's answer is Yaklang plugins and hot-loading, not Burp's Java extension API.

One practical boundary: because the engine implements HTTP itself and the client talks to it over gRPC, the interception path involves more moving parts than a single-process proxy. The repository carries dedicated performance scripts (perf:mitm, perf:mitm:electron:compare, perf:mitm:electron:matrix-compare in package.json), which suggests the maintainers treat MITM throughput as something worth measuring. The README does not publish numbers.

Fuzztag: the feature that actually differentiates Yakit

Fuzztag is the part of Yakit with no clean equivalent in the tools it is compared against. Instead of selecting an attack type and importing a wordlist, the operator writes tags into the request itself. The README gives {{int(1-10)}} for generating a range of user IDs, and {{file(/tmp/username.txt)}} for pulling values from an external dictionary. Multiple tags combine as a Cartesian product.

For cases a dictionary cannot cover, a hot-load tag can execute a Yaklang script inline to generate payloads. The README's example is generating regional ID card numbers during a fuzz run. In BurpSuite's Intruder, that scenario means writing a generator, producing a file, and importing it. The difference is where the logic lives: in the request, or in a preprocessing step.

The syntax is also the learning cost. Tags are a small language embedded in a larger one, and a malformed tag produces a malformed request rather than a clear error. The README links to a Fuzztag overview page for more detail, which is an admission that the inline syntax needs its own documentation beyond the main README.

Reverse connections: one port, many protocols

The reverse-connection module rests on port protocol multiplexing. The README contrasts it with the traditional approach, where an LDAP exploit needs an HTTP listener and an LDAP listener on separate ports before the attack request is sent. Yaklang listens on one port, identifies the protocol from the request, and responds accordingly.

The README lists three parts: Reverse Shell, reverse-connection exploitation, and reverse-connection detection. Reverse Shell acts as the receiving end of a rebound shell and, per the documentation, aims for an experience closer to native ssh than the nc listener it replaces, where backspace and arrow keys tend to produce garbled output. The exploitation part lets you set payloads for different protocols behind a single listener and have the right one returned automatically. Detection covers TCP, DNSLog and ICMP callbacks, which the README presents as useful for confirming command execution.

Because the protocol handling is implemented by hand rather than delegated to standard libraries, the documentation notes that malformed protocol packets can be constructed, and that data can be carried over DNS or ICMP. That is a genuine capability for restricted network conditions. It is also the kind of feature that requires authorization you can point to.

Installing Yakit and sending a first fuzzed request

The README does not give package-manager install steps. It says to download and install from the official site at yaklang.com, and to use the official documentation at yaklang.io for learning and usage. There is no npm install for the application itself: package.json describes an Electron app with a postinstall step of electron-builder install-app-deps, which is a build-time concern for contributors, not an end-user install path.

If you are working from the repository rather than a release build, the cli entry point is exposed as a script. The CLI is used by the project's own e2e pipeline to produce builds:

node ./cli/cli.mjs build --link -v yakit

That command comes from the test:e2e:build-link script in package.json and produces a linked build rather than a packaged release. Expect a development-oriented result, not a distributable installer.

Once the client is running, the Web Fuzzer accepts raw HTTP. The README's own example of a fuzz tag is a numeric range:

{{int(1-10)}}

Placed where a user ID would go, that tag expands to ten requests, one per integer, without any dictionary file. A dictionary-based tag looks like this:

{{file(/tmp/username.txt)}}

What you should see is the request count grow with the tag's expansion, and the History view holding each exchange. If the engine is not reachable, the request will not leave the client at all.

Licence, upgrade cadence and what that costs a team

Yakit is licensed AGPL-3.0. For internal security testing that is usually workable, but the network-copyleft clause matters here more than in a typical desktop tool, because the architecture is explicitly a client talking to a server over gRPC. If you modify the engine and let others interact with it over a network, the licence's obligations are the question to put to your legal team. The README also states that commercial use requires official authorization and that the project reserves the right to pursue unauthorized commercial use. That is a separate restriction from the licence text and should be read on its own terms. Nothing here is legal advice.

On cadence, the last push to the repository was on 2026-08-28, and the most recent releases listed are v1.4.8-0828 and v1.4.8-0825, both dated 2026-08-28 and 2026-08-25 respectively. The version string in package.json reads 1.4.8-0911, which suggests the working tree runs ahead of the tagged releases. Release tags follow a date-stamped pattern, so upgrades arrive frequently and are not semantic-versioned in a way you can plan around.

That cadence is the upgrade cost. There is no documented migration or rollback procedure in the README, so pinning a known-good build and testing the next one before rollout is the only safe pattern. A team that needs a frozen, long-support release should look elsewhere.

Where Yakit is the wrong tool

The clearest failure mode is the headless case. Yakit is an Electron GUI driving a gRPC engine. If your pipeline is a CI job that scans a staging environment and fails the build on findings, you want the engine and its Yaklang scripts, not the client. The GUI adds a window, a display dependency and a human.

Second, the replacement claim needs reading carefully. The README says the MITM console can replace BurpSuite entirely. What it does not claim is compatibility with Burp's extension ecosystem, and the substitute offered is Yaklang plugins. If your team's workflow is built on third-party Burp extensions, migrating means rewriting that tooling in a language you may not know.

Third, the documentation is thin on operational specifics. The README covers capabilities and links out to the official docs and a technical white paper, but it does not document rollback, does not publish MITM throughput figures, and does not describe failure handling when the gRPC engine drops mid-session. For a tool that blocks and re-sends live traffic, that last gap is the one worth testing yourself before you rely on it during an engagement.

Editorial conclusion

Adopt Yakit if you already write Yaklang scripts or want MITM interception and Web Fuzzer in one desktop client, and you accept AGPL-3.0 plus a separate engine process. Do not adopt it if you need a headless CLI scanner, a pure BurpSuite replacement with the same extension ecosystem, or a permissively licensed component. Before committing, verify that the gRPC server can reach your targets and that your legal team accepts AGPL-3.0 for the deployment model you have in mind.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes