WowPacketParser reads World of Warcraft sniff files and writes SQL diffs

What the tool does with a sniff file

WowPacketParser, abbreviated WPP, is the TrinityCore project's World of Warcraft packet parser. The README's usage section is short, and the shape of it tells you what the tool is for. You compile it with Visual Studio 2026 and the .NET 10.0 SDK, or download compiled binaries from the nightly builds, then edit WowPacketParser.dll.config to fit your needs, then drag one or more .pkt or .bin files onto WowPacketParser.exe. The command line form is given as a bracketed option list followed by the files to parse. The output is text, and with the right configuration it is SQL as well. The important detail is that it does not merely dump packets. It produces readable text with named entities resolved, and with the database feature enabled it produces SQL statements describing what would have to change in your server database to match what the client did.

Two databases with two different jobs

The databases section explains the distinction that makes WPP useful. It can connect to two kinds of MySQL databases, the world database from TrinityCore and its own database, WPP, and the switch is the DBEnabled key in the config file. The world database is used when creating SQL files after parsing, to produce the minimum number of changes needed to update the database. The example the README gives is the clearest illustration of the value: if only the faction of a creature that appears in the sniff needs to be updated, the produced SQL files contain an UPDATE query instead of a full INSERT into the creature_template table. WPP does not modify this database directly, all the tentative changes are written to the output SQL files. That constraint is what makes the tool safe to point at a live server database, and it is also what makes the output reviewable, because you get a diff rather than a mutation. The WPP database has a different role, feeding additional data that WPP may use while parsing, so that the text output can show a spell name next to a spell id rather than a bare numeric id, and the same applies to achievements, creatures and quests.

The output text, and what the WPP database adds to it

The README shows a snippet of the text output, and it is a good picture of what you get. A line identifies the direction and opcode, ServerToClient with SMSG_SPELL_START at 0x2BB8, with its length, connection index, timestamp and sequence number, followed by indented cast details such as the caster GUID with its player and map information, the spell id with its name in parentheses, and the cast flags. Without the WPP database that line would carry only the numeric spell id, and the name in parentheses is what the auxiliary data supplies. The same mechanism is said to be available for a lot of other named entities, and the SQL needed to set up that database lives in the SQL directory, where create_WPP.sql creates the database and wpp_data_objectnames.sql holds the data to fill it. So the setup cost for the readable output is one extra database and two SQL files, which is a reasonable trade for output that a human can audit.

One parser module per client build

The repository layout is the clearest evidence of what this problem costs. Alongside the main WowPacketParser directory, the Substructures module and the BattleNet module, there is one WowPacketParserModule directory per client build: V2_4_3_8606, V2_5_1_38707, V3_4_0_45166, V4_3_4_15595, V4_4_0_54481, V5_3_0_16981, V5_4_0_17359 through V5_5_0_61735, V6_0_2_19033, V7_0_3_22248, V8_0_1_27101, V9_0_1_36216, V10_0_0_46181, V11_0_0_55666, V12_0_0_65390, V1_13_2_31446, V1_60_1_69876 and 1_60_1. Each build changes the protocol, so each build needs its own opcode table and structure definitions, and the module naming convention encodes the build number. That is a lot of directories, and it tells you that supporting a new client build is a recurring task rather than a one-off. There is also a Proto directory, and the solution file is a .slnx rather than the older .sln format, and the project is written in C# for .NET 10 with the repository not archived and the last push on 2026-10-17.

Running it in Docker

There is an experimental Docker path using the trinitycore/wpp image, and it is documented in three steps. Building the image needs BuildKit enabled.

DOCKER_BUILDKIT=1 docker build . -t trinitycore/wpp

Configuring it means copying WowPacketParser/App.config as a template and editing it as needed. Running it mounts your sniffs directory and your config file.

docker run -it --rm -v /place/where/sniffs/are/kept:/sniffs -v /full/path/App.config:/app/WowPacketParser.dll.config trinitycore/wpp /sniffs/sniffname.pkt

The placeholders in that command are the local directory containing the .pkt file and the name of the file to be parsed, and the output, both .txt and .sql, is written back into the sniffs directory. The Dockerfile at the repository root is a two-stage build on the .NET 10 SDK image followed by the .NET 10 runtime image, with the entry point set to a docker-entrypoint.sh script copied in with mode 755. The compile command in the build stage is a plain dotnet build at Release configuration.

Where WowPacketParser is the wrong choice

Three limits. The first is that this is a TrinityCore tool, and the SQL output is written against a TrinityCore world schema. Point it at a retail server database and the generated statements will not apply, because the table names and columns the parser emits are the core's own, and the README's mention of TargetedDatabase having to be set in accordance with the targeted version of the core makes the version coupling explicit. The second is the maintenance cost of a new client build. Every patch that changes the protocol needs a new parser module with its own opcode table and structure definitions, and those directories have to be written by someone who understands the packet layout. A project that only needs to read a sniff once for a support ticket does not need that machinery, and a commercial sniff-analyser tool with a maintained opcode database is the better fit for occasional use. The third is the licence. GPLv3 is fine for TrinityCore server work, and the README points at the COPYING file for the terms, but it is a strong copyleft, and the parser is a library rather than a separate process in most integrations, so linking it into a closed-source tool has obligations. The third-party position is also worth noting: NuGet dependencies carry their own authorship terms, and the provided DBFileReaderLib comes from wowdev with its own copyright, 2019 to 2026.

Editorial conclusion

Adopt WowPacketParser if you run a TrinityCore server and need to reproduce what a client sent over the wire, or want SQL that updates your database with the smallest possible change set. Skip it if you are not working with TrinityCore or with WoW packet captures at all. Before you rely on the output, set TargetedDatabase to match the core version you run, and read the Nginx-style config in WowPacketParser.dll.config since that is where the behaviour lives.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. TrinityCore/WowPacketParser on GitHub