How I Hacked Liar’s Bar: GamePwn Reverse Engineering Exposes Critical Multiplayer Security Flaws + Video

By /

Listen to this Post

Featured Image

Introduction:

Runtime instrumentation and reverse engineering of multiplayer game clients reveal dangerous trust assumptions in network synchronization. By analyzing GameAssembly components, RPCs (Remote Procedure Calls), and SyncVars, attackers can manipulate gameplay logic, health values, and session data—turning a casual game into a live penetration testing lab.

Learning Objectives:

  • Master runtime analysis of Unity-based game clients using memory inspection and network monitoring tools.
  • Identify and exploit insecure client-server trust boundaries, including RPC spoofing and SyncVar manipulation.
  • Apply reverse engineering techniques to map internal object relationships and state synchronization vulnerabilities.

You Should Know

  1. Setting Up Your GamePwn Lab for Unity Client Analysis

A proper lab environment allows you to monitor, debug, and manipulate game clients without disrupting other players (ideally in an isolated test server). Below is a step‑by‑step guide for both Windows and Linux.

Step‑by‑step guide:

1. Install monitoring tools:

  • Windows: Cheat Engine (memory scanning), Wireshark (network capture), Process Hacker (process inspection), dnSpy/ILSpy (C decompilation).
  • Linux: tcpdump, strace, gdb, and Frida (cross‑platform instrumentation).

2. Run the game and attach a debugger:

  • On Windows: Open Cheat Engine, select the game process (e.g., Liar’s Bar.exe), and scan for known values (health, ammo, score).
  • On Linux: `sudo strace -p $(pidof LiarsBar) -e trace=network` to observe live socket calls.

3. Decompile managed assemblies:

  • Unity games store logic in `GameAssembly.dll` (often obfuscated) and managed DLLs in `Managed/` folder.
  • Use `ILSpy` to load `Assembly-CSharp.dll` and browse classes like NetworkManager, PlayerController, SyncListHealth.
  • Command (Windows): `ilspycmd Assembly-CSharp.dll -o decompiled_output/`

Why this matters: Understanding how the game serializes state and calls RPCs is the first step to breaking client‑side trust.

2. Mapping RPCs, SyncVars, and Object Lifecycles

Multiplayer Unity games use `

` (client→server), `[bash]` (server→clients), and `[bash]` (automated state sync). Monitoring their calls reveals attack surfaces.

<h2 style="color: yellow;">Step‑by‑step guide:</h2>

<h2 style="color: yellow;">1. Hook network methods with Frida:</h2>

[bash]
// Frida script to trace Unity RPCs
Interceptor.attach(Module.findExportByName("GameAssembly.dll", "UnityEngine.Networking.NetworkBehaviour::SendCommandInternal"), {
onEnter: function(args) {
console.log("[bash] Command called: " + args[bash].readCString());
}
});

2. Start Frida:

  • Linux/macOS: `frida -n “Liar’s Bar” -l rpc_trace.js`
  • Windows (with Frida server): `frida -n LiarsBar.exe -l rpc_trace.js`

3. Observe console logs:

  • Each time you perform an action (shoot, change rank, ready up), the script prints the RPC name and parameters.
  • Look for `CmdRequestHealthChange` or `CmdSetReady` – these are often unprotected.

4. Find SyncVars in memory:

  • Use Cheat Engine to search for a known value (e.g., health = 100).
  • Change the value in‑game, then rescan for changed addresses.
  • Right‑click the address → “Find out what writes to this address” – often you’ll see a `SyncVar` hook updating the client’s copy.

Pro tip: Many games forget to validate `

` methods on the server. If a command executes locally without server‑side checks, it’s a direct vulnerability.
</blockquote>

<h2 style="color: yellow;">3. Runtime Analysis of GameAssembly Components</h2>

GameAssembly.dll contains native compiled C++ code from Unity’s IL2CPP backend. Reversing it requires different tools.

<h2 style="color: yellow;">Step‑by‑step guide:</h2>

<h2 style="color: yellow;">1. Extract and identify key functions:</h2>

<ul>
<li>Use `ida64` or `Ghidra` with the `IL2CppDumper` tool. </li>
<li>Command (Linux): 
[bash]
./IL2CppDumper GameAssembly.dll global-metadata.dat dumped/
  • This produces `script.json` and `il2cpp.h` with function names and addresses.

    • 2. Trace object lifecycles:

    • Look for methods like PlayerController::Update, GameManager::OnPlayerReady, NetworkBehaviour::OnDeserialize.
    • Hook them with Frida or a debugger to see when objects are created/destroyed.

    3. Set conditional breakpoints on sensitive writes:

    • In gdb: 
      break 0x7f4a2c401234 if ((int)$rdi == 0)  break when health becomes 0
    • This reveals if the client decides when a player dies (bad) or if the server enforces it (good).

    Real‑world finding: The original Liar’s Bar analysis uncovered that the client could set its own `rank` and `readiness` without server validation – leading to instant lobby starts and rank manipulation.

    4. Manipulating State Changes via Memory Editing

    Once you identify critical variables (health, score, rank), you can change them live and observe server reactions.

    Step‑by‑step guide:

    1. Locate dynamic addresses using Cheat Engine:

    • Perform an “Unknown initial value” scan → change value → “Changed value” scan → repeat.
    • Add found addresses to the address list.

    2. Freeze or modify values:

    • Set health to a very high number (e.g., 9999) and freeze it.
    • If the server accepts this and you become invincible, you’ve found a client‑authoritative bug.
    1. Write a simple trainer (Python + pymem on Windows): 
      import pymem
pm = pymem.Pymem("LiarsBar.exe")
health_addr = 0x1A2B3C4D  from Cheat Engine pointer scan
pm.write_int(health_addr, 9999)

    4. Test state synchronization:

    • After changing a value, check if other players see the change.
    • If they do, the game uses a ` 
      ` without sanitization – you can force global state corruption.</li>
</ul>

<blockquote>
  Mitigation: Servers must recalc health and critical stats from authoritative sources, never blindly trust client‑sent `SyncVar` values.
</blockquote>

<h2 style="color: yellow;">5. Exploiting Client/Server Trust Boundaries</h2>

The most dangerous vulnerabilities arise when clients can send arbitrary RPCs or manipulate network packets.

<h2 style="color: yellow;">Step‑by‑step guide:</h2>

<h2 style="color: yellow;">1. Capture network traffic with Wireshark:</h2>

<ul>
<li>Filter for the game’s port (use netstat to find it). </li>
<li>Look for protobuf, JSON, or custom binary packets. </li>
</ul>

<h2 style="color: yellow;">2. Identify RPC packet structure:</h2>

<ul>
<li>Many Unity games use `LLAPI` or `Mirror` with simple serialization. </li>
<li>A packet might contain: an opcode (e.g., 0x01 for <code>CmdShoot</code>), a network ID, and parameters. </li>
</ul>

<ol>
<li>Craft and replay malicious packets (Python + scapy): 
[bash]
from scapy.all import 
payload = b'\x01\x00\x00\x00' + b'\x64\x00'  example: opcode 1, param 100
send(IP(dst="game_server_ip")/UDP(sport=12345, dport=7777)/payload)

      • 4. Test for privilege escalation:

      • Try calling an admin RPC (e.g., CmdKickPlayer) from a non‑admin client.
      • If the server processes it without checking identity, you have a critical bug.

      Case in point: The Liar’s Bar “victims” didn’t realize that Ramez could trigger all deaths or change ranks because the server accepted every `CmdRequestStateChange` without verifying the client’s authority.

      6. Hardening Multiplayer Games – Detection & Mitigation

      Based on the findings, developers must adopt server‑authoritative patterns and runtime integrity checks.

      Step‑by‑step guide to defensive implementation:

      1. Server‑authoritative state:

      • Never mark health, score, or rank as ` 
        ` that clients can write. </li>
<li>Send only inputs from clients to server; compute all state changes server‑side. </li>
</ul>

<h2 style="color: yellow;">2. Encrypt and authenticate RPCs:</h2>

<ul>
<li>Use a session‑based HMAC on every `[bash]` call. </li>
<li>Example server‑side pseudo‑code: 
[bash]
[bash]
void CmdUpdateHealth(int newHealth, byte[] hmac)
{
if (!ValidateHMAC(connection, newHealth, hmac)) return;
// ... update health only after validation
}

      3. Deploy integrity checks on the client:

      • Use tools like `UnityGuard` or custom DLL integrity verification (checksums of GameAssembly.dll).
      • On Windows, check for known debugger or memory scanner processes.
      • Command to list suspicious processes (PowerShell): 
        Get-Process | Where-Object {$_.ProcessName -match "cheat|wireshark|frida"}

      4. Runtime anomaly detection:

      • Monitor for impossible state changes (e.g., health increasing after death).
      • Log and kick clients that send `CmdSetHealth` from 0 to 100 in one frame.

      Key takeaway: No client‑side check is sufficient – all security must be enforced on the server with defense‑in‑depth.

      1. Hands‑on Tutorial: Reversing SyncVar Updates in Real Time

      This practical walkthrough combines memory editing and network spoofing to demonstrate a complete exploit chain.

      Step‑by‑step guide:

      1. Find the SyncVar update function:

      • Use `IL2CppDumper` to locate UnityEngine.Networking.SyncVarAttribute::Hook.
      • In the decompiled Assembly-CSharp.dll, search for ` 
        ` fields and their `Hook` methods (e.g., <code>OnHealthChanged</code>). </li>
</ul>

<h2 style="color: yellow;">2. Hook the SyncVar setter with Frida:</h2>

[bash]
var onHealthChanged = Module.findExportByName("GameAssembly.dll", "PlayerController_OnHealthChanged");
Interceptor.attach(onHealthChanged, {
onEnter: function(args) {
console.log("Health changed to " + args[bash].toInt32());
}
});

        3. Manually trigger the sync:

        • Write a new value to the health address (from step 4 in section 4).
        • Watch the console – if the hook logs the change, the client is actively sending updates to the server.

        4. Block outbound SyncVar updates:

        • Use a firewall rule to drop packets from your client to the server (iptables -A OUTPUT -d server_ip -j DROP on Linux).
        • Change health to 9999, then remove the rule. If the server reverts to the old value, it’s authoritative – if it stays at 9999, the client overwrites server state.

        Result: In poorly secured games, the client overwrites server state, enabling permanent cheating.

        What Undercode Say

        • Client trust is the 1 vulnerability in multiplayer games. The Liar’s Bar analysis proves that without server‑authoritative validation, every SyncVar and RPC becomes an exploit vector.
        • Reverse engineering is not just for hackers; it’s a core defensive skill. The same tools (Frida, ILSpy, Wireshark) used to find bugs can also be used to build integrity checks and runtime detection.

        Analysis:

        Modern multiplayer games often prioritize latency over security, leading to catastrophic trust assumptions. The 3‑day GamePwn project described by Ramez Saber highlights a common pattern: developers treat the client as a “thin renderer” but still allow it to dictate game state. From health to rank to readiness, each unprotected network call hands an attacker the keys to the kingdom. The industry must adopt Zero Trust principles even inside a “friendly” game session – every packet must be validated, every state change recomputed, and every RPC authenticated. Tools like Unity’s Netcode for GameObjects provide built‑in server‑authoritative patterns, yet many studios disable them for “simplicity.” This laziness creates a generation of insecure games that become live training grounds for penetration testers. The victims in Liar’s Bar never knew they were part of a research exercise – but the next time, it could be a real‑world cheat sold to thousands of players.

        Prediction

        Within two years, AI‑powered runtime anomaly detection will become standard in AAA multiplayer games. Machine learning models trained on legitimate player behavior will automatically flag impossible state changes (e.g., health jumping from 0 to 100 without healing events) and kick or ban offenders in real time. Simultaneously, we will see a rise in “GamePwn” bug bounty programs, where developers reward reverse engineers for finding client‑side trust flaws before cheat developers weaponize them. The cat‑and‑mouse game between reverse engineers and game developers is only accelerating – and the side that embraces transparency and proactive testing will build the most resilient ecosystems.

        ▶️ Related Video (82% Match):

        🎯Let’s Practice For Free:

        IT/Security Reporter URL:

        Reported By: Https: – Hackers Feeds
        Extra Hub: Undercode MoN
        Basic Verification: Pass ✅

        🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

        💬 Whatsapp | 💬 Telegram

        📢 Follow UndercodeTesting & Stay Tuned:

        𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

    Related Posts: