Auth (Part 3) gets the client a sessionKey and a game-server host. Now the central question: what does that server speak, and how does it travel on the wire? This part leans on the message catalog (985 messages with opcodes, names, and types) as a given — reconstructing it on next part. Here it's the transport: framing first, then the cipher, which looked like a ten-minute job and became the hardest part of the project.

The framing and the server

Port 17701 is the game server — raw TCP, the framing came from an offline self-test: serialize a known C2S_Login under the client's own serializer and hexdump it —

42 00 | 6e 30 19 2d | 0d 00 00 00 | 55 00 53 00 45 00 ...   ("USER_...", UTF-16LE)
 len       opcode        strlen

Frame  = [u16 length] [u32 opcode] [fields...]      little-endian
String = [u32 charCount] [UTF-16LE]

The leading u16 is the total length (its own 2 bytes included), sent in the clear. A pcap of a real session confirms it: the length matches each packet, but the body (opcode + fields) comes out encrypted.

The gift: the key travels in the clear

One packet isn't encrypted — the server's first, S2C_CheckConnection. Its six Int64 fields are a giveaway:

S2C_CheckConnection { socketUID, connectionKey,
                      clientSendIV, serverSendIV,      ← per-direction IVs
                      encryptionKeyLow, encryptionKeyHigh }   ← the key

The server hands over key and IVs in plaintext in the first frame (48 bytes = its whole body). Everything after is encrypted with a cipher derived from them. Great for an emulator — we'll be the server, so we pick the key. We just needed to know which cipher.

The cipher hunt (the long part)

• Act 1 — "It's AES" (wrong). 128-bit key, non-block-aligned bodies → a stream mode. Brute-forced 2000+ AES combos (CTR/CFB/OFB, both key orderings, every IV variation). Zero hits.

• Act 2 — "Not AES" (wrong). RC4, Salsa20, ChaCha20 (all shipped in the client). Nothing. Brute-force exhausted — time to read the code.

• Act 3 — Disassembly at runtime. Themida unpacks in memory, so frida-il2cpp-bridge

  • an address → name map made the disassembly readable. The handler shows the key is transformed before use (that's why raw-key AES failed) and that two cipher objects are created, one per direction.

• Act 4 — The key derivation. The transform is RijndaelManaged (CBC, zero IV, one block ⇒ ECB) with an embedded ASCII key. Hooking set_Key caught it — c5i0u+e(1EHvE[l7 — and it matched on decrypt: derivedKey = AES-128-ECB-decrypt("c5i0u+e(1EHvE[l7", rawKey16).

• Act 5 — The cipher. The class signature (128-bit key, 64-bit IV, state in 32-bit words, counter with carry) is Rabbit (RFC 4503). Confirmed by matching its keystream against the pcap.

• Act 6 — Block alignment. The keystream is consumed in 16-byte-aligned blocks per frame (ceil(len/16)*16, discarding the remainder), so each frame starts on a 16-byte boundary. The first S2C frame (CheckConnection) is plaintext and consumes no keystream.

The recipe

Handshake: S2C_CheckConnection (PLAINTEXT) → socketUID, connectionKey,
           clientSendIV, serverSendIV, encryptionKeyLow, encryptionKeyHigh

rawKey16   = LE(encryptionKeyLow) || LE(encryptionKeyHigh)
derivedKey = AES-128-ECB-decrypt("c5i0u+e(1EHvE[l7", rawKey16)

Frame = [u16 length LE, plaintext] [body]
Body: Rabbit(key=derivedKey, iv=LE(sendIV)), 16-byte block-aligned per frame
  C2S iv = LE(clientSendIV)  — all frames encrypted
  S2C iv = LE(serverSendIV)  — 1st frame (CheckConnection) plaintext

Result: the pcap decrypts 100% (C2S 48/48, S2C 122/122) — the whole VersionCheck → SessionAuthLogin → EnterWorld → walk → Logout session readable, and reproducible in any language.

Lessons: brute-force has a ceiling; the indirection was in the key, not the algorithm; runtime tools beat static protections (Themida); validate every hypothesis against real data.

Next part: how that message catalog was built — 985 messages straight from the IL2CPP metadata, without unpacking the binary.

The screen lies about your options

Launch the client and the login screen offers Google and Apple. That's it. But the identity layer — redlabgames' own SDK, RedlabSDK — knows more than the screen shows. Its identity-provider enum spells out the real menu:

ERLIDPCode:
  NONE = 0,
  EMAIL = 1,
  GOOGLE = 2,
  APPLE = 4,
  GUEST = 99

Guest and email exist in the code; the build just never renders their buttons (a region/build gate). We confirmed this at runtime with frida-il2cpp-bridge: the "Choose a login method" popup (CUIIDPLoginPopup) has an m_btnGuest field sitting right there in the prefab, deactivated.

Let's observe the traffic captured on data-proxy to check what a login actually does.

The identity step, captured live:

POST /v1/auth/pc/google/start        -> { result, state, authUrl }
POST /v1/auth/guest/authorize        -> { result, state, userCode }   (guest: authToken="")
POST /v1/auth/pc/<provider>/auth     -> { result, state, userCode }   (carries the IDP token)

The userCode is a 28-character handle (Firebase-UID shape) — the stable account identity. But a userCode is not what the game socket wants. That comes from the regional API:

POST /api/worldList        -> the world/server list (points the game socket somewhere)
POST /api/authLogin        -> { userCode, sessionKey (Int32), accountId, worldListData }
POST /api/worldList:cross  -> a light cross-region list

And that closes the loop back to the protocol.

So the chain is: identity issues who you are (userCode); the region issues a short-lived ticket (sessionKey); the game socket checks the ticket. Two auth APIs, not one — a general identity service and a per-region game service — plus the CDN that bootstraps which region host to even talk to.

The Google button never needed Google

The most useful discovery was how the OAuth webview finishes. The authUrl from /start opens a webview; when the provider sign-in completes, the page calls back into a local HTTP listener the client is running — CodeListenerPC on localhost:7077 — handing over the auth code:

http://localhost:7077/auth?isSuccess=true&state=<state>&authToken=<token>&error=0

Read that again: the webview's only hard requirement is to reach localhost:7077. It does not have to be accounts.google.com. If our /start returns an authUrl that points at our own /authorize page, and that page just does the localhost:7077 callback itself, the whole Google round-trip disappears. Google login becomes offline-capable — no real Google, no secrets, no network beyond our own server.

Rebuilding it as a server

A single path-routing script proved the flow, but the real backend wants the three concerns split. Because the client talks to fixed hostnames on :443, the split is by hostname (a reverse proxy up front, later), not by port:

• CDN — static: domaindata.json + patch files. Stays a plain file server.

• Identity (auth) — /v1/auth/..., owns accounts, issues userCode.

• Regional (region) — /api/..., issues sessionKey/accountId, owns the world list.

The identity and regional services became two small Node/TypeScript (Express + SQLite) apps. The interesting decisions:

Accounts and registration. Guest and social logins auto-provision on first sight (keyed on device/identity). We also un-hid the email path the client's enum promised: email + password, hashed with scrypt (Node built-in — no dependency), stored in SQLite. The login/register UI is the very webview page the client already opens; it just shows a real form now instead of auto-completing.

A single-use token in the middle. The form doesn't hand the client a userCode directly. On success it mints a short-lived (5-minute), single-use authToken; the client's existing /v1/auth/<provider>/auth call then trades that token for the account's userCode. Register does not sign you in — it creates the account and sends you back to the sign-in form, so account creation and authentication stay distinct.

The region validates against auth. /api/authLogin doesn't trust a userCode blindly — it calls the auth service to confirm the account exists and fails closed if it doesn't. Then it mints a sessionKey, stored with a 1-day TTL.

The game server validates against the region. This is the last link, and it's the one the raw socket needs. The region exposes an internal endpoint the game server calls on connect, in one of two flavours:

GET  /internal/sessions/<sessionKey>          -> reusable until it expires
POST /internal/sessions/<sessionKey>/consume  -> single-use (second call fails)

Either way it returns { accountId, userCode, worldId, expiresAt }, and the game server must check the returned userCode matches the accountCode the client sent on the socket — otherwise a valid ticket could be paired with someone else's account. consume makes the ticket one-time, so a replayed sessionKey is rejected atomically.

That is the full trust chain, each link checking the one before it:

form login -> userCode      (auth owns identity)
userCode   -> sessionKey    (region validates userCode with auth, fails closed)
sessionKey -> game entry     (game server validates sessionKey with region)

The Api

Now with this info we can create a simple api to simulate those endpoints, it's hosted on rom-api.

It's two independent services, deliberately split by responsibility:

• auth (identity) — owns the accounts. Handles email + password login/registration (scrypt-hashed), plus guest and the social providers. Issues the userCode, the stable account identifier. The login/register form is served inside the very OAuth webview the client already opens.

• region (regional game API) — issues the game session (sessionKey/accountId) and the world list. Before issuing, it validates the userCode against auth and fails closed if the account doesn't exist.

Outside rom-api sit the CDN (static files and domaindata.json) and the game socket (raw TCP with its own cipher) — the latter validates the issued session by calling an internal region endpoint.

The trust chain is the heart of the design: each link checks the one before it.

login form  -> userCode      (auth: identity)
userCode    -> sessionKey    (region validates against auth, fails closed)
sessionKey  -> world entry   (game server validates against region)

A session is valid for 1 day and can be checked in single-use mode (replay protection for the same ticket). A short-lived (5-minute), single-use intermediate authToken bridges the form to the userCode exchange.

Stack: Node.js + TypeScript (Express 5), one SQLite database per service, no heavy dependencies — hashing and IDs use only Node's built-in crypto. Each service runs standalone; TLS and hostname routing are handled by a reverse proxy in front (a later step).

Status: both ends (auth and region) are implemented, tested, and committed. What remains is the game-server integration (validating the session at socket login) and hardening the /internal/* endpoints.

Now when the client clicks on google login, it shows a simple login/register form.

And after a successful login we can see our server list on the client.

In Part 1 the launcher handed us the CDN hosts, the patch manifest, and the exact -env=Real command to start the game. Now we turn to the game client itself — the Unity binary that ultimately speaks the network protocol we need to reconstruct. Before anything else, figure out what it's made of.

First reconnaissance

You need to know what you're dealing with. A glance at the client folder already tells a lot of the story:

• GameAssembly.dll (~45 MB) and UnityPlayer.dll → it's Unity, and the game code is compiled with IL2CPP (C# → C++ → native), not Mono. That matters: with IL2CPP the original C# isn't there "for free," but there is a file that reconstructs almost all of it.

• ROMGoldenAge_Data/il2cpp_data/Metadata/global-metadata.dat (~34 MB) → the most important file in the project. It's where IL2CPP keeps type names, fields, methods, strings, and constants. If it's clean, you can recover the game's entire type structure — including the network protocol.

• client/GameGuard/ + NPGameDLL64.dll → nProtect GameGuard, an anti-cheat with a kernel driver. It'll be an obstacle down the road. Worth flagging early: at startup GameGuard also makes its own network calls, to *.gameguard.co.kr (nProtect's anti-cheat update/live-check). Those aren't part of the game's bootstrap and don't come from anything we can patch — the packed GameGuard modules hold the host, so it never shows up in the metadata or assets. Our stance for now: ignore it and let it reach its real destination — we neither redirect nor block gameguard.co.kr. That matches how the whole project treats GameGuard: tolerated, not touched (the server never sends the one anti-cheat protocol message, so the client never runs the GG network handshake). It stays a live external dependency to revisit for full offline preservation.

• lua5.3.dll → part of the game logic is Lua script.

• The Unity version, extractable from the metadata: 2022.3.62f2.

We confirmed that global-metadata.dat is unencrypted from the header: dumping the first bytes with a hex editor (xxd on the command line; HxD on Windows) shows AF 1B B1 FA 1F 00 00 00 — the magic 0xFAB11BAF and version 31. A clean metadata = half the battle already won.

Tools in this section: the OS file explorer / ls to survey the folder, and a hex editor (xxd, HxD) to read the metadata header.

Watching the client talk: a MITM proxy

The static survey tells you what's in the folder; it doesn't tell you what the client fetches. Part 1 pulled the CDN base and the patch manifest.json out of the launcher config — but the game client asks for more than that manifest lists, and some of the endpoints it uses aren't hardcoded anywhere on disk: they arrive at runtime in a domaindata.json the client downloads on boot. To see the whole picture you have to watch the wire.

So we stood up a small man-in-the-middle proxy — data-proxy, a Node/TypeScript tool — and pointed the retail client through it:

• A TLS-terminating HTTPS proxy on :443. For every incoming SNI name it mints a leaf certificate on the fly, signed by a local CA (via node-forge) that we install as a trusted root on the Windows box. The client's HTTPS calls (patch/CDN, auth, launching) don't pin certificates, so once the CA is trusted the proxy reads every request and response in the clear.

• Its own upstream resolver. The proxy resolves the real server IPs through public DNS (8.8.8.8) to forward traffic on — even though the client's own DNS is being redirected (next point).

• An observe-only handler. For ROM it logs every request/response (and decodes WebSocket text frames) and rewrites nothing. Its only filter is an ignoreRequest pattern that drops the noise irrelevant to host discovery: UnCheater and gameguard (the anti-cheat's own traffic — flagged above) and the bulk .dat/.mp4 asset and movie downloads.

To get the client's traffic into the proxy without touching the client, we redirect DNS. The machine points at dns-proxy as its resolver, which answers the game's domains with the proxy's address and forwards everything else upstream. No hosts-file edits, no client patching — just "resolve patch.romgoldenage.com (and friends) to us." Here's a sample config

{
    "host": "192.168.10.2",
    "nameservers": [
        "8.8.8.8"
    ],
    "domains": {
        "romgoldenage.com":"192.168.10.2"
    }
}

Tools in this section: data-proxy (our Node/TypeScript MITM proxy — per-SNI leaf certs from a local CA, TLS termination, request/response + WebSocket logging) and dns-proxy to redirect the client's DNS at the proxy.

What the proxy revealed

With the client booting through the proxy, the log is the client's shopping list. Beyond the launcher/patch manifests from Part 1, it pulls a set of standalone files the manifest never mentions: domaindata.json (the runtime endpoint table), maintenances.json, ROMGoldenAge_WemixPay_Crypto.json, and a batch of packed game-data blobs under patch/Windows/ (table.dat, AssetBundlesVersion.txt, bundlegamedata.dat, lobby.dat, tablecrypto.dat, defult.dat) — plus two indices that fan out into hundreds more downloads: MovieFile.json (the cutscene list) and BundleInfo.dat (the asset-bundle catalog).

That runtime-fetched domaindata.json is the payoff for bothering with a proxy at all: the regional auth/billing/translate hosts and the game-server endpoint aren't strings in the binary — they exist only in that JSON, so pure static string-scanning would miss them. Cross-referenced with the hosts we did find hardcoded (scraped from three places in the shipped client — the IL2CPP dump, global-metadata.dat's string literals, and resources.assets), it gives the complete infrastructure map, catalogued in rom-tools' client/DOMAINS.md. Check the domaindata.json content.

{
  "result": 0,
  "domainData": [
    {
      "region": "ASIA",
      "domainData": [
        {
          "domain_name": "AUTH",
          "domain": "live-auth-region-ap.romgoldenage.com"
        },
        {
          "domain_name": "BILLING",
          "domain": "billing-ap.romgoldenage.com"
        },
        {
          "domain_name": "TRANSLATE",
          "domain": "translation-ap.romgoldenage.com"
        }
      ]
    },
    {
      "region": "NA/SA/EU",
      "domainData": [
        {
          "domain_name": "AUTH",
          "domain": "live-auth-region-sa.romgoldenage.com"
        },
        {
          "domain_name": "BILLING",
          "domain": "billing-sa.romgoldenage.com"
        },
        {
          "domain_name": "TRANSLATE",
          "domain": "translation-sa.romgoldenage.com"
        }
      ]
    }
  ]
}

Mirroring it before it's gone

Discovery only matters if we keep the bytes. Everything the proxy showed the client fetching, we wired into rom-tools' patch mirror, patcher/patch_downloader.py. It walks the launcher and patch component manifests and downloads every per-file zip (verified against ArchiveSize, kept compressed), then mirrors the standalone files, the movie index and every movie, and the bundle index and every bundle — each verified against the size in its index and skipped if already present, so the mirror is idempotent and resumable across the ~3.7 GB. Standard library only; point it at a release and let it run. The whole reason it exists: when the servers go dark on 2026-10-15, the patch CDN goes with them.

The wall: Themida

The obvious plan is to run a ready-made tool like Il2CppDumper or Il2CppInspector: you feed it GameAssembly.dll + global-metadata.dat and it spits out the reconstructed C# project. Except here that fails.

The reason: GameAssembly.dll is packed with Themida/WinLicense (Oreans), a commercial protector. Detect It Easy (DIE) flags the packer on sight, and a look at the section table (with DIE, CFF Explorer, or the pefile Python module) confirms it: the telltale sections (.winlice, .vm_sec, .boot) have a huge virtual size and zero bytes on disk — the real code (including the Il2CppCodeRegistration/MetadataRegistration tables the tools need) is only unpacked in memory, at runtime. On disk, the targets of the il2cpp exports point to zeroed bytes.

In other words: static analysis of the binary is a dead end. That sets the strategy for the rest of the series:

1. You can still pull a LOT out of the clean metadata alone, without touching the packed binary (Part 3).

2. For what only exists in the binary (the field types), we'll need a runtime approach.

Tools in this section: Il2CppDumper / Il2CppInspector (the ready-made dumpers that failed), Detect It Easy (DIE) to identify the packer, and a PE inspector (DIE, CFF Explorer, or pefile) to read the section table.

Rewriting the client's URLs

Knowing which hosts the client calls has an obvious sequel: being able to change them. Repoint the client's CDN host at a server of our own and the retail client boots against our infrastructure with no proxy and no hosts-file hack — the redirect lives in the client's own files. Standing up the server that answers on the other end is a later thread; what belongs here is the client-side half: where those URLs live, and how to patch them without breaking the file.

The client resolves its CDN host from two baked-in strings, and every bootstrap URL is built as String.Format("{0}/{1}", base, path) from one of them:

Both point at the same host, in different files and formats — so redirecting the client means editing both. And because everything derives from these two bases, one host swap cascades through the whole bootstrap: base B's domaindata.json is where the regional auth and the game-server endpoint come from — the runtime-only hosts the proxy surfaced above — so patching the host pulls patch, auth, and game along with it.

Two small rom-tools scripts do the edits, and the interesting part is that each file format forces a different in-place trick:

• client/metadata_host.py (base A). An IL2CPP string literal is { u32 length; i32 dataIndex } plus a raw data blob, each carrying its own explicit length. So the edit is simply: overwrite the bytes and rewrite the length field — no offset rebuild — as long as the new string is <= the original (a host→IP swap shrinks it; https→http shrinks it further). The /NewPCwemix/ path suffix is preserved.

• client/resources_host.py (base B). resources.assets is a Unity SerializedFile, where a [u32 length][UTF-8] string's length feeds every later byte offset — change the length and the whole file corrupts downstream. So this edit keeps the exact byte count: no padding, and the tool refuses if the chosen host yields a different length (over https that means a 22-character host for the /real/ patch string, 21 for auth) rather than silently corrupt the file. A redirect webserver is then expected to strip everything before /real/.

Both run analyse-only by default — locate the string, confirm it's unique, change nothing — and neither ever overwrites the source: they emit a patched copy you swap in, keeping the original as a backup.

Tools in this section: rom-tools' client/metadata_host.py (base A — global-metadata.dat literal) and client/resources_host.py (base B — resources.assets host strings), both standard-library Python that edit in place and emit a patched copy.

Where we stand

We have the lay of the land: a Unity/IL2CPP client with open metadata, a binary armored by Themida, and a kernel anti-cheat to deal with later. We also watched the client on the wire — mapping every host and file it fetches (including the runtime-only endpoints no static scan would find) and mirroring the whole ~3.7 GB before the CDN disappears. None of it is a show-stopper — it just decides where to get in. And it points straight at the richest target that doesn't require defeating Themida: the clean metadata. Now we are able to modify domaindata.json and point to custom domains.

Next part: verifiy the auth options to replicate.

Tools used in this part: xxd/HxD (hex inspection), data-proxy (our Node/TypeScript MITM proxy) + dns-proxy (DNS redirect) to observe the client's traffic, rom-tools' patch_downloader.py (CDN mirror), Il2CppDumper / Il2CppInspector (the dumpers that failed), Detect It Easy + pefile/CFF Explorer (packer + PE sections).

ROM: Golden Age https://romgoldenage.com/ (a version of ROM: Remember Of Majesty, developed by redlabgames) is going to EOS(End of Service) on October 15, 2026 and the goal of this series is to preserve it: understand the client well enough to reconstruct a private server, in the same tradition as other mmorpgs.

Legal / ethics note. All of this work is done on a client I installed legally, with the goal of preserving a game that is being discontinued. Nothing here is for cheating on live servers, pirating content, or commercial repackaging.

One more thing about how this gets done: I lean on AI throughout to speed things up. To be clear about what that means — the AI isn't doing anything a skilled human reverse-engineer couldn't do; it's doing the same work faster. Parsing a binary format, sifting 30,000 string literals, writing a throwaway decryptor, cross-checking a hypothesis against a capture — all of it is well-trodden ground for a human, just slow and tedious by hand. And time is exactly what this project doesn't have: the servers are on a clock. So AI is the accelerator, not a shortcut past understanding — every result in this series is one I checked and can explain.

The launcher: the easy way in

The game binary is armored; the launcher, on the other hand, is the weak link: a .NET executable. And .NET decompiles very well. This is the base folder after the setup installation.

ROMGoldenAge_Launcher.exe is a .NET 8 single-file bundle (WPF). "Single file" means the assemblies are embedded and compressed inside the exe. We unpacked the bundle into its DLLs with single-file-extractor (the sinbad/SingleFileExtractor tool for the .NET bundle format), then ran ilspycmd (ILSpy on the command line) to reconstruct the C#:

Launcher.dll (26.8 MB), Launcher.Core.dll, Launcher.Shared.dll  →  readable C#

Tools in this section: single-file-extractor to split the .NET single-file bundle, and ILSpy (ilspycmd) to decompile the DLLs back to C#.

The encrypted appsettings.json

The launcher config ships with values in the form ENC: <base64>. Searching through the decompiled code, the crypto routine shows up in full in Settings.cs. It's AES-256-CBC with a homegrown key derivation from four embedded phrases (p1..p4):

private static (byte[] Key, byte[] Iv) GetCryptoKeys()
{
    string s = p1 + p4 + p2 + p3;                       // specific concat order
    using SHA256 sha = SHA256.Create();
    byte[] key = sha.ComputeHash(Encoding.UTF8.GetBytes(s)); // 32 bytes -> AES-256
    byte[] iv  = new byte[16];
    Array.Copy(key, 0, iv, 0, 16);                      // iv = first 16 bytes of the hash
    return (key, iv);
}

public static string Decrypt(string cipherText)
{
    if (string.IsNullOrEmpty(cipherText) || !cipherText.StartsWith("ENC: "))
        return cipherText;                              // plaintext passthrough

    var (key, iv) = GetCryptoKeys();
    string b64 = cipherText.Substring(5).Trim();        // strip "ENC: "

    using Aes aes = Aes.Create();                       // default: CBC + PKCS7
    aes.Key = key; aes.IV = iv;
    using var ms = new MemoryStream(Convert.FromBase64String(b64));
    using var cs = new CryptoStream(ms, aes.CreateDecryptor(), CryptoStreamMode.Read);
    using var sr = new StreamReader(cs);
    return sr.ReadToEnd();
}

s   = p1 + p4 + p2 + p3          # concatenation in a specific order
key = SHA256(s)                  # 32 bytes → AES-256
iv  = key[:16]                   # the first 16 bytes of the hash
# value = "ENC: " + base64(AES-CBC(plaintext)), PKCS7

With the four phrases (which are in the code) we reproduce the decryption in a short Python script (using pycryptodome for the AES) and read the config in the clear. What it reveals:

• Production CDN (AWS S3/CloudFront): patch.romgoldenage.com, with the path NewPCwemix/Real/{launcher|patch|web}. ("wemix" = the edition with the WEMIX blockchain SDK; "Real" = production.)

• The game's patch manifest: .../Real/patch/manifest.json — version 1.4.0, 123 files, ~3.74 GB uncompressed. Each file downloads from <base>/<file>.zip.

{
  "Launcher": {
    "Version": "ver 1.4.0.5 (Crypto)",
    "HomepageUrl": "https://patch.romgoldenage.com/NewPCwemix/Real/web/{0}/index.html"
  },
  "SelfUpdate": {
    "Enabled": true,
    "RequireSignature": false,
    "ManifestUrl": "https://patch.romgoldenage.com/NewPCwemix/Real/launcher/manifest.json",
    "BaseUrl": "https://patch.romgoldenage.com/NewPCwemix/Real/launcher",
    "PublicKeyPem": "manifest_pub.pem",
    "UpdaterExe": "Updater.exe",
    "LocalManifestName": "launcher_local_manifest.json"
  },
  "GameUpdate": {
    "ManifestUrl": "https://patch.romgoldenage.com/NewPCwemix/Real/patch/manifest.json",
    "BaseUrl": "https://patch.romgoldenage.com/NewPCwemix/Real/patch",
    "InstallRoot": "client",
    "GameName": "ROMGoldenAge.exe",
    "TempRoot": "tmp"
  }
}

Preservation note: these manifests and binaries should be mirrored before the shutdown.

"NewPCwemix" and the Cross build

The NewPCwemix in the path is literally the internal build name (New PC, WEMIX edition). There's a second build, Cross (NewPCcross/...), with its own web3 stack and cross-server plumbing. We downloaded its metadata too and compared the protocol: identical — same 985 messages, same IDs, same fields. A single emulator serves both. The builds only differ in the account/wallet/store shell.

How to start the game without the launcher

Practical question: to instrument the game (and later point it at our server), I need to be able to run it directly. What does the launcher do when you click "play"? In the decompiled GameUpdateClient.LaunchGame(), the answer is disappointingly simple: it runs the client passing only one argument:

client\ROMGoldenAge.exe -env=Real

No token, no environment variable, no parent-process check. The game only has a single-instance mutex. In other words, -env=Real is a complete launch. That'll be gold in the future, when we instrument the process with Frida.

Where we stand

From the launcher alone we've already pulled: how the game updates, from where (CDN + versions), and the exact command to start the game without the launcher — all without touching the protected game binary.

Next part: the game client itself — Unity/IL2CPP, its clean metadata, and the Themida wall that makes the main binary a hard target. It's where the reverse engineering really begins.

Postscript: our own tooling — rom-tools

Everything the launcher gave us — the CDN hosts, the patch manifest, the -env=Real launch — is also what we need to eventually point the client at our server instead of production. We collected that work into a companion repository, rom-tools, with the tooling we built to redirect the launcher and the patcher away from the official CDN stand up a local server that answers the bootstrap/patch requests, so the retail client boots against our infrastructure with no proxy or hosts-file hacks. It's hosted on https://github.com/octrys/rom-tools/

Tools used in this part: xxd/HxD (hex inspection), Il2CppDumper / Il2CppInspector (the dumpers that failed), Detect It Easy + pefile/CFF Explorer (packer + PE sections), single-file-extractor (.NET bundle), ILSpy/ilspycmd (decompilation), Python + pycryptodome (config decryption).