OurNuts / OurNuts Modules

🌰 OurNuts - Modular Possibilities

The OurNuts ecosystem is highly flexible. Instead of using it as one giant launcher application, we can break it down into simple, small, modular components. You can mix, match, or deploy these individually based on your needs.

Here are the modular possibilities we have extracted from the OurNuts project:

1. 🔑 The Auth Node (Microservice)

What it is: A standalone C# service that handles just the Ourpalm authentication bypass. How it works:

  • Accepts simple username/password.
  • Performs the MD5 payload signing.
  • Talks to Ourpalm (or our custom server) and returns a raw session token and uid. Why it's useful: You can use this in your own scripts, bots, or web dashboards without needing a UI.

2. 🎭 The Identity Spoofer (Library)

What it is: A small .dll library that manages the Statistics_Info_v1.db. How it works:

  • Generates realistic @@@@... Device IDs.
  • Opens the SQLite DB and forcefully injects the Device ID before the game boots. Why it's useful: Prevents hardware bans. You can integrate this into a Python bot or a simple batch script to rotate HWIDs before every game launch.

3. 🚀 The Headless Injector (CLI Tool)

What it is: A command-line executable (OurNuts.CLI.exe). How it works:

  • Takes arguments: OurNuts.CLI.exe --uid 123 --token XYZ --server 1
  • Injects the MU3_DEVICE_ID environment variable.
  • Launches MU3-Win64-Shipping.exe directly, completely bypassing the official launcher UI. Why it's useful: Perfect for automating bots, launching multiple instances at once, or quickly testing server changes without clicking through a UI.

4. 📦 The Delta Patcher (Microservice)

What it is: A standalone file verification engine. How it works:

  • Downloads index.xml from your CDN.
  • Hashes your local .pak files using SHA256.
  • Downloads and patches only the missing or outdated files. Why it's useful: You can package this with your client distributions. It ensures players always have your latest custom textures and XML tables before they can click "Play".

5. 🛠️ The GM Local API (Background Service)

What it is: A lightweight local webserver running on port 9090. How it works:

  • Exposes endpoints like POST /api/kill to close the game.
  • Exposes POST /api/query to read local client DBs. Why it's useful: You can build a web-based GM dashboard that sends commands to player clients (e.g., force-closing a bugged client, or retrieving crash logs remotely).

6. 🎨 The UI Shell (Frontend)

What it is: The Avalonia UI frontend. How it works:

  • Provides the beautiful dark theme, server status pings, and news feed. Why it's useful: If you already have the other modules running in the background, this is just the "pretty face" that players see. It is completely decoupled from the heavy lifting.

How to use this?

Because the code is cleanly separated in Src/Core and Src/UI, we can easily compile any of these modules independently. For example, if you just want the Headless Injector for your bots, we can compile a tiny 5MB .exe that does exactly that and nothing else.