EN
v2.1.7
WPE_CORE_OS // QUICK_START

WINSOCK PACKET EDITOR

WPE x64 is an open-source Winsock packet interceptor and editor. It adapts to 32- and 64-bit targets and can modify and forward the network packets of any client program.

Requirements

Check your environment before you start:

ItemRequirement
OSWindows 10 / 11 · Server 2019 / 2022 · x64
Runtime.NET Framework 4.8 (checked on launch)
PrivilegesAdministrator (checked on launch)
Target program32-bit and 64-bit both supported; the matching hook module is selected automatically

Download and install

Portable single-file build — unzip and run. The archive holds one exe: no installer, no registry writes, no entry in Add or Remove Programs.

  1. Go to Downloads and grab the latest archive from Lanzou or Baidu Pan.
  2. Right-click the archive → Properties → Unblock → Apply. Do this before extracting.
  3. Extract anywhere. You get WinsockPacketEditor.exe.
  4. Double-click it and accept the UAC prompt to run as administrator.
// Two things people get wrong

① Unblock first, then extract. The other way round leaves the Zone.Identifier mark on the exe and injection fails with Code 15.
② Administrator is mandatory. Injecting, loading the driver and installing the root certificate all need elevation; WPE restarts itself to ask for it.

// About updates

WPE never checks for or downloads updates. To upgrade, take the new archive from Downloads and run the new exe; keeping or deleting the old one is up to you.
Note that the config database is stored per version, so settings do not carry over automatically — export them from the old build first. See Upgrading to a new version.

Two capture modes

WPE x64 offers two ways to intercept traffic — pick by scenario:

Proxy Mode

Capture at a built-in SOCKS proxy server. Handles HTTP/HTTPS/WS/WSS/TCP/TLS-TCP/UDP, with port mapping and a Web API for licensing integrations.

Inject Mode

Hook the target process directly and capture everything from launch. Works with emulators; the 32- or 64-bit module is chosen to match the process.

Capture your first packet

Four steps, using Inject Mode as the example:

  1. Start WPE, choose Inject Mode, pick the target in the process list and click Inject.
  2. Once capture starts, packets stream into the Packet List. Red rows were intercepted; amber rows were modified by a filter.
  3. Select any packet and right-click to view, compare or edit it — several encodings are one click apart.
  4. Set up an advanced Filter or a Robot to make the edits and replays run by themselves.

Proxy Mode setup

With Proxy Mode on, point the target program's traffic at the local proxy port:

yaml — config
proxy: mode: socks5 listen: 127.0.0.1:1080 protocols: [http, https, ws, tcp, udp] webapi: true # licensing integration

Highlights

Two capture paths

SOCKS proxy and process injection, so Winsock packets can be reached in almost any setup.

Message queue

Packets are queued and rendered as they arrive instead of waiting for a buffer to fill — stays responsive under million-packet load.

Advanced filters

Change packet length and repeat count, substitute random values, and chain several filters together.

Robots

When a trigger condition is met, a predefined instruction set runs — edit, resend, toggle things on and off.

Compare / search

Straightforward packet diffing, quick switching between data formats and search-to-locate.

Emulator friendly

Inject emulators directly and read the traffic of the apps running inside them.

  • Proxy Mode speaks the common proxy and SSL protocols, with port mapping and breakpoint debugging.
  • The injector and the packet editor are independent, so several programs can be injected at once and read separately.
  • Packets can be sent in batches with a custom order and repeat count, and imported / exported with notes.
  • Settings are saved as you go and restored on the next launch; the runtime log is recorded live and can be exported.
  • The .NET assemblies need no GAC registration, which keeps both usage and further development simple; resources are released on exit.

Typical use cases

The same capture-and-edit toolkit takes different routes depending on the job. These four are what WPE x64 gets used for most; each notes which mode to use and where to start reading:

Protocol debugging

When your own client and server disagree, or a third-party SDK behaves differently from its docs, reading the real bytes on the wire beats adding logs at both ends.

Security testing and API review

With authorization in place, craft odd lengths, out-of-range values and malformed fields to see how the target handles bad input — or check whether sensitive data leaves in the clear.

Protocol study and reverse engineering

Given an undocumented private protocol, work out its structure one field at a time through controlled experiments — the classic WPE workflow.

Emulators and mobile apps

An Android emulator is just a local process, so inject it directly. For a real device, make WPE the proxy server on your LAN.

Limitations · what it cannot do

Knowing what it cannot do saves more time than the feature list. None of the following is a misconfiguration — the mechanism simply does not reach that far:

CannotWhyWhat to do instead
Traffic that bypasses WinsockInject Mode hooks the user-mode send / receive functions in ws2_32.dll and friends. A kernel driver sending packets itself, or a program with its own network stack, never passes through that layerUse Proxy Mode, or pull it in with Force Proxy at the driver level
ICMP · Ping · raw socketsNone of it goes through the WinSock send / recv family, and the proxy protocols have no channel for it eitherOut of scope for WPE; use a link-layer capture method
HTTPS in the clear under Inject ModeThe hooks sit on send / recv, where the data is already TLS-encryptedSwitch to Proxy Mode and let the built-in CA decrypt it
Editing HTTP(S) or WebSocket with a FilterFilters expose 12 packet-type switches, and those three are not among them — such packets never enter matchingUse Map Settings to rewrite the response body or the target
Breaking HTTPS when the app pins its certificateSSL Pinning only trusts the certificate baked into the app, regardless of what the system trustsObserve it as TCP traffic, or find a way in from inside the process
QUIC / HTTP3 in the clearIt rides on UDP, so WPE sees the bytes — but QUIC encrypts the payload itselfMake the target fall back to TCP + TLS, then decrypt in Proxy Mode
Running on macOS or LinuxThe whole implementation depends on the Windows WinSock API, .NET Framework 4.8 and Windows kernel driversRun it inside a Windows VM
Working without administrator rightsInjecting other processes, loading drivers and writing to the system certificate store all require elevationNo workaround; WPE requests elevation itself

What the internet says, and what is actually true

Search for "what is WPE" and you will find plenty of overviews — many describing the 1.x release from twenty years ago, or simply repeating each other. For the record:

Common claimFor WPE x64
"TCP only, weak UDP support"False. Inject Mode hooks sendto / recvfrom / WSASendTo / WSARecvFrom; Proxy Mode implements a full SOCKS5 UDP relay, and UDP request / response are separate packet types in the filter
"Intercepts at the network or driver layer"Inaccurate. Both modes work at the application layer — injection hooks WinSock functions, the proxy runs its own SOCKS5 / HTTP service. Only Force Proxy uses a kernel driver, and its job is to steer traffic into the proxy, not to read packets directly
"IPv4 only"False. The SOCKS5 address types cover IPv4, IPv6 and domain names, for both TCP and UDP
"Capturing slows down or crashes the target"Depends on the mode. Proxy Mode never touches the target process. Inject Mode does load an assembly into it and replace function entry points, so programs with anti-injection protection may misbehave — pressing Stop removes every hook. See the FAQ
"WPE is a cheat tool"That is a use, not a property of the tool. The same capability is protocol debugging on your own software and a violation — possibly a crime — on someone else's server without authorization. See below

Responsible use

// Statement

This is an open-source tool intended for personal study and research in network programming. It is not for commercial use, and must not be used for anything unlawful.

Capturing and editing packets is a neutral engineering technique; whether it is legitimate depends on whether you are authorized to touch the target. Run through this list first:

  • Scope of authorization: use it only on software you wrote, servers you own, test environments, or targets you hold written permission for. Capturing or editing a third party's live service — even "just looking" — may already cross the line.
  • Games and anti-cheat: using any capture or packet-editing tool in an online game can be flagged and get the account banned, whether or not the tool is open source. This project does not support that use.
  • Data handling: captured traffic may contain accounts, tokens, identity data and payment details. Do not retain, share or repurpose it beyond the debugging task at hand, and clear samples when you are done.
  • Not an attack tool: tampering with other people's communications, forging transactions or bypassing authentication is well past debugging, and the legal responsibility is yours.
  • License: released under MIT. The author accepts no liability for how it is used; keep the license notice when redistributing.

About and credits

Winsock Packet Editor has been published and maintained by X-NAS since 2021, moved from the 52pojie forum to GitHub and Gitee in 2022, and is released under the MIT license.

Thanks to EasyHook and SunnyNet. The project is listed in DotNet Guide and is part of the dotNET China organisation.

Next steps

  • Read the full 2.1.8 tutorial — installation, injection capture, the proxy server, filters, robots and the warehouse, step by step. All eight chapters are available in English; the legacy 1.0.0.36 PDF is archived as well.
  • Browse Downloads for past releases and the changelog.
  • Open an issue or contribute on GitHub.