prosper-together: Prosper Together: How a PS4 and PS5 Save File Becomes a LuaJIT Escape Hatch
A game-specific exploit for Don’t Starve Together turns save-data injection, sandbox leakage, and bytecode trickery into a reusable userland control surface.
- Prosper Together turns a save file into an execution path, which makes the exploit feel like content delivery rather than a classic console jailbreak.
- Its novelty is not just the entry point, but the ladder from Lua sandbox leakage to memory primitives, ROP, and syscall access.
- The repo reads like a userland research harness, with TCP script loading and payload tooling that make exploitation repeatable.
- Compared with WebKit or BD-J entry points, its power comes from precision and game-specific trust, not from breadth.
The save file is the weapon
Prosper Together starts where most console exploits do not: inside a game save. A Python tool rewrites Don’t Starve Together save data, injects Lua, and repacks the container so the game happily loads the payload as if it belonged there.
That is the trick. The exploit does not need a browser, a network service, or a firmware bug to get started. It rides a normal game workflow, which makes the delivery path look boring right up until it isn’t.
Why Lua makes this possible
The game embeds LuaJIT, and that choice creates the surface area. Scripts are supposed to be flexible, which means they also sit close to valuable game objects, helper APIs, and runtime state.
The repository’s README and payload code frame the boundary as RunInSandbox. That sounds protective, but the exploit uses that boundary as a foothold, not a wall.
Here, the game’s mod-friendly design is the risk. If a scripting environment is trusted enough to touch gameplay, it is trusted enough to become an attack surface.
The first break: escaping the sandbox
The first meaningful pivot is not memory corruption. It is a context break. Once the injected code reaches the global environment, it can access objects such as TheSim and TheNet, which is the point where save-loaded content stops being inert data and starts behaving like code with reach.
That matters because it changes the blast radius. The payload is no longer trapped inside the narrow sandbox intended for loaded content. It can now interact with the broader runtime and prepare the conditions for the real abuse.
Don't Starve Together userland exploit by earthonion. Does not work with NetCtrl since it's a normal game, it does not have dup. https://t.co/IlvItz7pYi
The real trick: making Lua lie about memory
This is where addrof and fakeobj matter. The exploit bends LuaJIT’s assumptions so that a value can be treated as an address, or an address can be treated like a value. Once that boundary is blurred, the VM stops being a safe interpreter and starts being a very elaborate memory oracle.
| Normal Lua object | Forged object |
|---|---|
| Lives behind the VM’s type rules | Pretends raw memory is a legitimate runtime value |
| Can be inspected only through sanctioned APIs | Can be shaped into a read or write primitive |
| Is opaque to the attacker | Becomes a handle on nearby memory |
| Stays inside the language model | Leaks control into the machine model |
The important part is the shape of the escalation, not the byte-level trick. First comes a type confusion. Then comes control over memory. The exploit works because each step unlocks the next.
From memory access to syscalls
With arbitrary read and write in hand, the payload can locate module bases, scan for executable regions, and assemble a ROP-backed bridge into syscall territory. The article should be read as a ladder: save file, sandbox escape, memory primitives, runtime control, syscall capability.
That ladder is why the project feels more like a research harness than a one-shot proof of concept. The repo includes TCP-based script loading, utility payloads such as an FTP server, and enough scaffolding to make the exploit useful after the first code execution lands.
-- Conceptual shape only
-- file load -> runtime control -> memory primitives -> syscall bridge
local payload = loadstring(remote_script)
payload()
| Axis | Prosper Together | WebKit or BD-J entry points | Full jailbreak or kernel path |
|---|---|---|---|
| Entry point | Game save and Lua payload | Browser or media stack bug | Usually a userland step plus kernel exploit |
| Dependency | Requires <em>Don’t Starve Together</em> | No specific game required | No specific game required |
| Repeatability | High once the crafted save exists | Depends on exploit stability and firmware | Depends on the whole chain |
| Depth of access | Userland control surface | Often userland first, then more | Kernel and system-level control |
| Audience | Exploit researchers and homebrew builders | Broader console hacking community | Advanced jailbreak users |
The comparison is the point: Prosper Together is not trying to be universal. Its strength is precision. It gives researchers a narrow, repeatable route into userland on two consoles, and then hands them tools to experiment.
What the repo reveals about modern console attack surfaces
The repo’s real lesson is not that games are weak. It is that trusted scripting layers, save-file parsers, and convenience APIs can form a surprisingly rich attack surface when they all sit inside the same execution flow.
That combination matters because it is practical. File-based delivery lowers friction. Lua lowers the barrier to payload development. TCP script loading turns a local exploit into a remotely driven lab. Put together, those choices make the project feel engineered, not improvised.
That limitation is also the design virtue. Prosper Together does not pretend to replace a full jailbreak. It demonstrates something narrower and, in a research context, more interesting: how far a game-specific userland foothold can be pushed when the scripting layer and the save pipeline are both trusted too much.
