Hosting Rōblox Servers by Deconstructing Post-v463 Studio Binaries

[Windows81]

Should we add other versions of Rōblox to the RFD project? As for earlier versions, the answer is very likely to be negative.

RFD's goal is to allow people like us to host our own games outside of Rōblox.

The RCC for v463 can run games with a footprint as low as 150 MiB.

Let's see how we can use modern versions of Studio to run servers without needing to interface with Qt at all. I might know the answer in 3 years. Who knows.

You can learn x86 assembly and find out. Difficult stuff.

---

As for what I know:

• I use and study the PDB symbols for Studio v548. Useful for taking apart the individual components of the game engine.

• The now-defunct Rsblox project provides guidance.

📖 Explanation

There are four steps to make a team test compatible with Player:
setting a fast flag,
blocking an unhandled item,
compiling compatible bytecode,
and replicating the bytecode.

DebugLocalRccServerConnection

Overriding the fast flag, DebugLocalRccServerConnection, on both Player and
Studio will allow a connection to be made between the client and the server.
It also will force the client to connect to localhost|53640.

With this alone, you can already join a Studio team test from Player - however,
it is not playable yet.

ClientQoSItem

Shortly after Player joins the team test server, it will be kicked after
sending a ClientQoSItem - which is unhandled by Studio. This can be resolved
by refusing to deserialize the item if a ClientQoSItem is passed to
RBX::Network::Replicator::deserializeItem.

BytecodeEncoderClient

Opening the developer console in Player after connecting to the team test
server shows some strange errors with the path of LocalScript instances that
are replicated to Player and none of them are executed. This is partly due to
how Studio populates the contents of the server's legalScripts vector. A
LegalScript is a 'whitelisted' script for replication, containing source and
bytecode. The function RBX::Network::Server::registerLegalSharedScript is
used to register and compile these scripts.

Studio already calls this function and even invokes LuaVM::compile - however,
on Studio it just returns an empty std::string. This can be fixed by hooking
LuaVM::compile and compiling source with LuaVM::BytecodeEncoderClient.

NetworkSchema

Even after compiling scripts correctly and populating each LegalScript with
bytecode, the same error appears in the developer console. When a server is
started, a NetworkSchema is generated, which contains info for every class in
the reflection database. This includes info on how to send properties, like
Script.Source, which is determined by their NetworkValueFormat. By default,
Studio selects the type for Script.Source to be ProtectedStringSource, and
sends the source code of scripts to other Studio clients for them to compile
themselves.

This can be fixed by forcing the server to use ProtectedStringBytecode, which
will make it get the stored bytecode from the legalScripts vector and send it
over when serializing the property. The generation of the NetworkSchema
occurs in RBX::Network::NetworkSchema::generateSchemaDefinitionPacket, and
the portion of interest is when it chooses the corresponding
NetworkValueFormat for the reflection type ProtectedString.

[TheGuyWhoIsIdiot]

Great explanation by the way, there are still more things you could've added like the capacity of connecting to an actual server outside the localhost domain.

[Windows81]

RFD does that and has been doing that since 2023L.

[frostyyyy1]

you could've added like the capacity of connecting to an actual server outside the localhost domain.

Uhm what? i expose my RFD Server to the outside on a diffrent port then 2005, and everyone that has the domain, port and allowed usercode, can access my RFD Server aslong as its turned on

[SANS3R66]

yes