How it Works

Web overlay is made up of three layers that work together: a C++ application that reads game memory and renders the overlay, a Tauri/Rust bridge that handles the UI process and communication, and a React frontend that renders the menu the user interacts with.

The Three Layers

C++ Backend

The C++ process is the core of everything. It attaches to the target process, runs the DirectX 11 overlay window, and owns all the config state. It also runs a TCP server on 127.0.0.1:14242 that the UI connects to, and pushes events to the UI when the overlay needs to be shown or hidden (e.g. when the target window loses focus).

Tauri / Rust Bridge

The Tauri app is the UI process. It runs a TCP client that connects to the C++ server on startup and immediately sends a register_app message containing its own PID — this is how the C++ side knows which process the UI belongs to so it can manage z-ordering correctly. The Rust layer exposes Tauri commands to the React frontend, which it fulfills by sending requests over TCP to the C++ backend and waiting for a response.

React Frontend

The React app talks exclusively through Tauri commands via invoke(). It never touches the TCP connection directly — that's all handled by Rust. The useConfigKey hook is the main way pages interact with config: it pings the C++ backend to check connectivity, fetches the config for a given key, and provides a set function that sends updates back. The UI rebuilds optimistically on every change.

Communication Flow

Here's what happens when a user changes a setting in the menu:

React (useConfigKey.set)
  → invoke("set_config", { name, data })          [Tauri command]
    → IpcConnection::request_async("set_config")   [Rust over TCP]
      → C++ Server receives JSON message
        → config handler updates g_config
          → sends back set_config_response
        → Rust resolves the promise via request_id channel
      → Tauri command returns Ok
    → React updates local state

Every request is matched to its response using a request_id field injected into the message. The Rust side keeps a map of pending requests keyed by this ID, and when the response comes back from C++ the correct channel is resolved.

Config System

Config is owned entirely by the C++ side. The Tauri/React layer has no persistent state of its own — it always fetches from C++ and pushes changes back. The supported operations are:

• get_config — fetch a single named config (e.g. "visuals", "aimbot")
• set_config — update a single named config
• set_all_configs — bulk update all configs at once
• config_file_list — list saved config files on disk
• config_file_load — load a config file, returns all configs
• config_file_save — save current config to a named file
• config_file_delete — delete a saved config file

Config files are stored in %LOCALAPPDATA%\<cheat_name>\configs.

Overlay Visibility

The C++ backend controls when the UI is visible. When the target window loses focus or is minimized, the backend sends a hide_window event over TCP. When focus returns, it sends show_window. The Rust layer handles these events by calling window.hide() or window.show() on the Tauri webview — the React app is never involved in this at all.

The menu can also be toggled manually with the keybind (default: Insert), which the C++ side handles by toggling WS_EX_TRANSPARENT on the overlay window and sending the appropriate show/hide event to the UI.

Window Constraint

The UI window is kept within the bounds of the target process window at all times. The Rust side polls every 200ms, finds the target window by its title (received from C++ via the register_app response), and clamps the UI position and size to stay within those bounds. This means if you move the UI it cannot escape outside the target window.

Connection State

The React frontend polls connectivity via ipcPing on page load. If the C++ process is not running or the TCP connection is lost, the UI shows a "lost connection" screen and stops rendering page content. There is no automatic reconnect on the React side — the Rust layer handles reconnection transparently in the background, so once the C++ process is back up the next ping will succeed and the UI recovers automatically.