Guide Metin2 Reversing — Locating PacketSend & Bypassing Encryption

[byte_corvus]

Most public "packet senders" for Metin2 or generic MMORPGs are just low-tier pastes. If you want to actually build something custom—maybe a clientless bot or a unique exploit—you need to know how the game actually talks to the server. We aren't going the easy route using leaked sources; we're doing this the real way with a debugger and some brainpower.

The Foundation
In Windows, almost every game uses the WS2_32.dll library for TCP communication. The specific function we need is WS2_32.send(). This function is the final gatekeeper before data leaves the client.

Spoiler: The send function signature

int send(
  __in  SOCKET s,
  __in  const char *buf,
  __in  int len,
  __in  int flags
);

We don't care about the socket or the flags. What matters is char *buf (the payload) and int len (the size). By tracing these, we can work our way back to the game's internal logic.

Phase 1: Finding the Entry Point
Attach Cheat Engine to your game process. Open the Memory Viewer and go to View -> Enumerate DLL's and Symbols. Look for WS2_32.dll and find the send export. Double-click it to jump to the assembly.

Phase 2: Tracing the Buffer
Set a breakpoint on the function start. When it hits (use skills, move, or equip items to trigger it), look at the stack. You'll see the parameters pushed. The second parameter is your buffer pointer.

1. Add this pointer to your Cheat Engine table as an Array of Bytes.
2. Right-click the address and select "Find out what writes to this address".
3. Trigger an in-game action. You will see instructions moving data into this buffer.

Phase 3: Bypassing Encryption
In modern games, data isn't sitting in the buffer as plain text. It goes through an encryption loop (XOR, AES, or custom shit) before hitting WS2_32.send.

To find the unencrypted data, trace back the EAX/ESI registers from the encryption loop. Usually, there is a "Pack" or "Encrypt" function that takes the raw packet and copies it into the final send buffer. You want to set your breakpoint before that encryption happens.

Phase 4: Packet Analysis Case Study
Let's look at the "Use Item" action. By monitoring the unencrypted buffer, we find a 4-byte structure:

0B 01 02 00

1. 0x0B: The Header (Server identifies this as "Use Item").
2. 01: Static padding/Unknown.
3. 02: The Inventory Slot (Slot 3, zero-indexed).
4. 00: Null terminator or padding.

Phase 5: Implementing an Internal Packet Sender
Once you have the internal function address and the class pointer (ECX), you can define a C++ struct and call it directly.

Spoiler: C++ Internal Implementation

struct ItemUsePacket {
    BYTE header;
    BYTE unknown;
    BYTE slot;
    BYTE unknown2;
};

typedef void(__thiscall *tSendPacket)(DWORD thisPTR, unsigned int* pStruct, unsigned int size);
tSendPacket SendPacket = (tSendPacket)0x006E0250; // Use your discovered offset
DWORD classPTR = 0x03BA0878; // Example static pointer

void SendUseItem(BYTE slot) {
    ItemUsePacket iup;
    iup.header = 0x0B;
    iup.unknown = 0x01;
    iup.slot = slot;
    iup.unknown2 = 0x00;
   
    SendPacket(classPTR, (unsigned int*)&iup, sizeof(iup));
}

Final Warnings
Hardcoding addresses like 0x006E0250 is fine for testing, but for a real internal project, you need to find these dynamically using signatures (AOB) or you'll be fixing your code every update. Also, remember that calling network functions out of sync can cause desync or kicks—try to hook the main game loop and dispatch from there.

Anyone tested this on the latest patch or ran into custom VM protectors?