[Skyforge] Looking for Reverse Devs

[JujutakJR]

As i cant say goodbye to my Favorite MMORPG "Skyforge" i started the process of reversing a server for this game .
We do have a propriatory c++ engine without documentation and with anti tamper by starforce mmog v6.02.....
We do have a pretty effective anti debugging layer and no network traffic at all from before the shutdown (which would help greatly if u have any).

what we need :
reverse engineers willing to sink their time into this project
if u are willing to help with this project pls let me know .

gonna do it solo if i needed . cant say bye to this game ...
As of now : client listens for local server after several bypasses, server sends first 9 packets right, commands phase entered , client waits for avatarlist
Pre Ascension Atlas is a long term target too .
Generally speaking when we are at a playable point im gonna address all the issues players had with the game after the ascension update and make it great again .

Skyforge Revival Project Discord
The Project is open-source but not public atm so if u wanna join reviving skyforge pls hit me up

 

[TheLittlePeach]

I'm interested, send me more information via DM.

 

[JujutakJR]

Status (as of 2026-09-24)
The full login + Frontend handshake works end to end, reproducibly and — new this session — a realnative game entity can now be created from scratch and functionscorrectly, though it does not yet render on screen. Since the project has moved through several major phases:
1. The project's oldest blocker is solved : real kernel-level breakpoint/single-step debugging of `Skyforge.exe` is now available — a VirtualBox VM (`Skyforge-RE`) with `bcdedit /debug on` plus a remote WinDbg kernel session over a serial pipe, using `.process /i /p /r` to invasively switch into Skyforge's process context **without ever calling `DebugActiveProcess`** (the exact mechanism `docs/54` identified as the original transceiver-timeout blocker back in 2026-08-16). Confirmed live: a real breakpoint hits and the game keeps running normally afterward — no more slow hook-and-infer inference needed for native mysteries going forward.
2. The kind-1 `ReplicaMsg` wire format is fully reversed and live-confirmed : `AbsolutePositionReplicator`'s multi-field body (3 position floats + 1 scalar, each independently wrapper-varint-encoded) matched the static derivation exactly on the first live attempt — both an all-zero test and a **real non-zero position** (x=1.0/y=2.0/z=3.0), zero `FE_CS_*` errors, no crash.
3. Entity/component creation via the two NETWORK-DRIVEN paths is conclusively blocked, from four independent angles : the `ReplicaMsg` apply path's "entity identity" key is hardcoded to a `-1` "no entity" sentinel by a single instruction, always, independent of wire content ; an exhaustive reflection-class search plus a five-level-deep native trace (`GM::Entity → GM::Creature → GM::Avatar`/`GM::Mob`, a master descriptor-driven factory, spawn-table predicate evaluators) finds a real, actively-used native entity system — but it needs `NDb::` spawn-table template data that provably does not exist anywhere in the client's shipped content . **A THIRD path — call the native factory directly, bypassing both — works, see point 6.**
4. The `NDb::` spawn-table classes' byte layouts are now fully reversed : `NDb: PlayerSpawnPlace` (216 bytes, a real runtime content class registered as `"gameMechanics.map.zone.PlayerSpawnPlace"`) and `NDb::SpawnTableTemplate`'s complete field offsets, defaults and "unset" sentinel values are known, including the likely x/y/z/radius/facing position fields and an `NDb::IntArrayResource` reference (presumably the spawnable mob-template-id list).
5. Concluded, definitively negative : a real kernel- debugger breakpoint armed on the per-map `.inplace` container-parser entry point, BEFORE connecting, watching an otherwise completely undisturbed full login run all the way to the deepest-ever reached state ("LOADING CHARACTER...", `docs/247` #18) — the parser is **never called, not once**. Combined with point 3's data-absence finding, this closes the character-generation-screen question with certainty: it is not just missing data or an unfound caller, a real breakpoint confirms the call itself never happens anywhere in the currently-reachable flow. The practical ceiling stays `docs/247-250`'s milestone; reaching an actual playable screen needs either a real packet capture (none exist) or a from-scratch synthetic entity-graph effort (not started, high effort/uncertain payoff).
6. NEW : native entity creation, solved. Fully decompiled the native `CreateAvatar` factory chain and found its exact one crash-risk dependency (a "zone context" object's vtable slot 5) — then, instead of needing REAL spawn-table data (point 3's wall), fabricated a minimal dummy object (an 8-slot vtable of harmless `xor eax,eax; ret` stubs, the same "harmless dummy vtable" trick `docs/262` had already proven safe for a different purpose) and called `CreateAvatar` directly via `CreateRemoteThread`. **It worked on the first attempt**: Skyforge survived, no crash, and a live memory scan confirmed a real, correctly-vtabled `GM::Avatar` object. A follow-up call to the object's own `SetOrientation`-style method also worked exactly as predicted (byte-for-byte). This overturns `docs/329`'s "large, speculative undertaking, no guarantee" verdict — native entities can be created and are functionally real, bypassing both point 3's dead ends at once. **Not yet solved:** getting such an entity to actually render — `GM::Avatar`'s own vtable has no render method, so a separate presentation-layer bridge (candidate: `UI::MainAvatarCreatedEvent`, its firing site not yet found) is the next concrete target.
7. Two `ROADMAP.md` tracks moved since `docs/335`: Track C (`MsgDebugDraw*`, the hoped-for lower-risk rendering path) is now **closed, negative** — its wire format is fully solved and live-confirmed , but a *valid* DebugDraw message still faults on a null scene/render object right after deserializing — it doesn't sidestep the presentation-layer wall after all. Track D (the `Cmd*` server-handler backlog) got its **first real entry**: `Replica::CmdSendChatMessage`'s wire format is reversed and decoded server-side — not yet live-testable, since nothing reachable today can make the client send a real gameplay command.
8. Track D scaled from one class at a time to the whole catalog : two more classes hand-reversed (`CmdMuteUser`/`CmdUnmuteUser`, `CmdTeleportMap`), then a batch IDA pipeline + a generic schema-driven decode engine auto-extracted and decoded 267 of the full 555 `Cmd*` classes — `server/cmd_schemas.json` + `server/cmd_schema.py`, all cross-validated against the hand-reversed classes. The remaining classes keep their extracted field names as a documented backlog for whoever continues. Same caveat as everything in Track D: not live-tested against the real client yet.
9. Track D continued class-by-class : two new reader primitives (a second wrapper-varint slot, a string array), a general leading-`chatRequestId` fix, two real parser correctness bugs found and fixed (`MapPath` field over-collapsing; cc620-resolution ordering, a recursive `optional:<type>` decode-engine capability , six more field-name verifications (`ItemSlot`×3/`Vector3`×2), a new `byte_array` primitive solving the `roles` inline-array-loop case via a `CLASS_FIELD_OVERRIDE` , and a new `orientation_info` 7-field composite solving `CmdOrientedTeleportMap` — **267 → 351 of the full 555 `Cmd*` classes (63%)** now auto-decodable. Also confirmed: the `target`/`address`/`interlocutor` runtime-conditional class is shared by at least 10 field/array contexts and fully characterized end to end — still needs live testing, not guessed at.