SniffCraft: a Minecraft proxy that puts every packet in front of you

A proxy in the middle, forwarding everything it sees

SniffCraft is a cross-platform C++ proxy that lets you inspect the content of each packet sent between a Minecraft client and a server. It can run with a GUI or in headless mode.

The mechanism is a man-in-the-middle, and the README describes it plainly. Instead of connecting directly to the server, you point your client at SniffCraft, which is connected to the server. All packets are transmitted to their original recipient and are simultaneously logged on the fly. Nothing is swallowed or delayed by the inspection itself.

That property is what makes the tool usable for real work. A proxy that changes what it sees is a tool for building things; a proxy that forwards everything and writes a copy down is a tool for understanding things. For protocol development, mod authors trying to match a server's behaviour, or an operator debugging why a client misbehaves, the copy is the point.

The audience follows from that. This is for people who need to read the Minecraft protocol as it actually appears on the wire, which usually means mod and plugin developers, server operators and anyone writing tooling around the game.

The topics listed for the repository match, with minecraft, packets, protocol and proxy as the tags, and the source tree is organised as sniffcraft/ for the code, 3rdparty/ for vendored dependencies, conf/ for configuration, plus a CMakeLists.txt, cmake/ and a .gitmodules file.

Version coverage from 1.8 to 26.3, including the new transfer packets

The feature list opens with the fact that decides whether the tool is usable for you: supported Minecraft versions are all official releases from 1.8 to 26.3.

That range covers the modern protocol era back to the last generation before the major protocol rewrite, and the release named latest is built for the newest game version. The README also notes separately that 1.20.5+ transfer packets are now supported, which is a change in how the game moves chunks of data around and would otherwise leave a hole in the capture.

Maintaining that many protocol versions is a real ongoing cost, and it is the cost you inherit if you pick this tool. Each version has its own packet set and login sequence, and the project's own release automation is reflected in the build status badge for the automatic_release workflow.

The practical consequence for a user is that the tool is not stuck on one game version, which matters when you are supporting a server that spans several, and also that a very old or very new client might hit an edge case. The README points to a community Discord server for the Sniffcraft and Botcraft community, which is where such edge cases get discussed.

For reference, the source of protocol knowledge is botcraft, a separate project by the same author, which is listed among the build dependencies and linked from the README.

Encryption is terminated at the proxy, which is what makes the log readable

The most technically interesting feature is how SniffCraft handles encryption, and it is not what a first reading suggests.

The README says encryption is supported by moving the authentication step from the client to SniffCraft. The consequence is asymmetric and important: all the traffic from the client to SniffCraft is not encrypted, while the traffic between SniffCraft and the server is.

So the proxy is the one that authenticates, and it does so in plain view. That is what allows the tool to show you packet contents in a session where the client and server would otherwise be talking over an encrypted channel.

There are two options in the configuration file regarding authentication, and Online must be true to connect to a server with authentication activated. SniffCraft then prints instructions on the console to log in with a Microsoft account, only the first time, after which cached credentials are reused. Multiple Microsoft accounts can be cached using different MicrosoftAccountCacheKey values.

Version specific restrictions follow, and they are worth reading carefully. For versions up to 1.18.2 and 1.19.3 and later, you can use any client you want, cracked or regular with any account, as long as SniffCraft itself is authenticated with a valid account. For versions 1.19 to 1.19.2 there are two subcases. If the server sets enforce-secure-profile to false, the same applies. If the server sets it to true, you must use a client authenticated with the same account you are using in SniffCraft, or you will be kicked out for signing key mismatch as soon as you try to send a chat message.

If you want the latest certificates for your account on 1.19 and later, the README explains that setting the expires_date value for the cached credentials to 0 makes SniffCraft retrieve the latest ones from the Mojang server.

Three logging levels, and a mode where nothing is logged at all

The logging options are configurable, and the granularity goes down to the byte.

Packet logging supports different levels of detail, described as ignoring the packet, logging the packet name only, or logging the full packet content. On top of that, byte level packet inspection is supported, as is logging of raw packets at byte level. Compression is supported, so a compressed session does not defeat the capture.

Configuration is live. Which packet to log or ignore can be changed on the fly without restarting, which is what makes the tool usable for exploration rather than just for a fixed capture script. A session file is created automatically to log information, and logging to the console at the same time is optional.

The session can be saved to a binary file and reopened later in the GUI, and the full session can also be exported as a Replay Mod capture, which is a neat bridge to the existing Minecraft replay tooling: the same session can then be watched as video rather than read as a log.

The last feature in the list is the one to think about carefully. No log at all is possible, in which case SniffCraft becomes a pure proxy that you can adapt to block or modify any packet you want. The inspection machinery is the same code path as the logging machinery, which is also why a project that only wants to see the traffic ships a tool that can rewrite it. Treat that mode as a development feature, and be deliberate about which packets a live session allows you to touch.

Headless for long captures, GUI for reading them back

The GUI is optional at build time and switchable at run time, and the split is about memory rather than features.

If the project is compiled with the cmake option SNIFFCRAFT_WITH_GUI, a GUI appears when SniffCraft starts, and that can be disabled by launching it with the --headless command line argument. In GUI mode, packet data are kept in memory while the session is displayed. The README calls that usually not a real issue for regular use, but recommends --headless, or a build without GUI support, for multi-hour capture sessions or many concurrent sessions, because in that mode all data is only stored in files and not in RAM.

That is a sensible engineering trade-off, and the reason it matters is that the log format is binary, not text. SniffCraft binary files can be reimported later in the GUI by dragging them onto the SniffCraft window, so a capture taken headless on a busy machine is still reviewable afterwards on a workstation.

The runtime story is simple: you start the executable, by default found in the bin folder next to the source code, either by double clicking it or from the command line, and then point your Minecraft client at it.

There is also a detailed network usage recap in the feature list, which is the kind of summary that turns a raw capture into something you can put in a bug report.

Building with CMake, and the options that define the feature set

Precompiled binaries for the latest game version with encryption and GUI support are published under the latest release tag, and the README documents the source build for anyone who needs different options.

git clone https://github.com/adepierre/SniffCraft.git
cd SniffCraft
mkdir build
cd build
cmake -DGAME_VERSION=latest -DSNIFFCRAFT_WITH_ENCRYPTION=ON -DSNIFFCRAFT_WITH_GUI=ON ..
cmake --build . --config Release

Three CMake variables steer that build. GAME_VERSION selects the protocol version, SNIFFCRAFT_WITH_ENCRYPTION turns on the OpenSSL backed encryption support, and SNIFFCRAFT_WITH_GUI turns on the graphical interface. Setting the first to latest tracks the newest game version, which is also what the published binaries use.

The dependency story is unusually friendly. The README states that you do not have to install any dependency to build SniffCraft, since everything that is not already on the system is downloaded and built locally during the build process. The dependencies that get pulled in are asio for the network layer, zlib for the compressed packets, openssl when encryption is enabled, and botcraft for the protocol knowledge. The GUI adds glad, glfw and Dear ImGui.

The two flags are therefore the entire configuration surface for most users, which is a low bar for a tool that ends up seeing your session traffic.

Modded environments work, but only in the cases people have tried

The README is straightforward about the limits of the modding support. SniffCraft has been confirmed to work with heavily modded client and server using Forge. It is however not regularly tested against all possible modded environments, and some adjustments might be required in some cases. If you hit such a case, the project asks you to open an issue or join the community Discord server and describe the use case with as much detail as possible, naming the Minecraft version, the server IP and the client and server mods.

The reason a modded session can be hard to read is protocol knowledge. Mods add their own packets, carried inside Custom Payload packets, and the proxy does not know what they mean by default. To print the content of those packets, you need protocolCraft plugins that extend the protocol knowledge with mod-specific packets, and the README points to the protocolcraft-plugin repository for how that works.

So the honest summary is that SniffCraft handles the standard protocol thoroughly, and modded traffic needs either a plugin or an issue thread. The project maintains a Discord for both the Sniffcraft and Botcraft community, and a YouTube tutorial is linked from the badges at the top of the README.

The maintenance picture is stable rather than fast moving. There is a single release named latest, dated 2026-10-02, and the last push to the repository was on 2026-10-02, so the published binary and the source head are in step.

Editorial conclusion

SniffCraft suits Minecraft protocol developers, mod authors and server operators who need to see the actual packet exchange rather than guess at it, especially when a modded or custom client behaves in a way the documentation does not explain. It does not suit players looking for a way to alter a live session to their advantage, and it does not suit anyone unwilling to route their client through a proxy that sits between it and the server. Check three things before you rely on it: which Minecraft version your server runs, whether that version imposes the account matching rule described for 1.19 to 1.19.2, and whether your capture will be long enough that you should build with the GUI disabled and log to files. The last push to the repository was on 2026-10-02 and precompiled binaries are published under the latest release tag.

Frequently asked questions

Official sources

1. adepierre/SniffCraft on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases