Engine-Based Porting: Rehosting on the Original Engine Instead of Recompiling

Companion docs: ps3-recomp.md, ps2-recomp.md, psx-recomp.md, amiga-recomp.md, ps4-recomp.md.

Unlike those docs, this is not a platform survey — it’s a technique survey that cuts across platforms. Static/binary recompilation (the subject of the companion docs) treats a game as an opaque blob of compiled machine code and lifts it instruction-by-instruction. That framing quietly assumes the entire game was compiled machine code in the first place. For titles built on a well-known, still-actively-developed third-party engine — practically, Unreal Engine or Unity — that assumption is often wrong for a meaningful fraction of “the game,” which opens up a structurally different porting strategy: get a legitimate, matching build of the engine itself running natively on the target platform, and feed it the original title’s recovered assets and script content, rather than translating any compiled code at all. This document surveys how real that strategy is today, using our own in-progress subject — Drakengard 3, a PS3-exclusive title confirmed to run on Unreal Engine 3 (internal codename SQEX03GAME) — as a running illustrative example throughout.

The core insight: not everything shipped as machine code

UE3. A large share of UE3-era gameplay logic was written in UnrealScript, a bytecode language compiled to a portable .u/package format and executed by the engine’s own bytecode interpreter at runtime, not by the host CPU directly. Epic’s own documentation describes it as effectively a VM in the Java/.NET sense — “platform-neutral,” designed so the same compiled script content runs unmodified across PC, Xbox, and PS2/PS3 with “very little binary changes” (UnrealScript Language Reference, UnrealWiki: Advanced Technical Issues). Tooling to decompile that bytecode back to readable UnrealScript is mature and UDK-era community-built: UE Explorer and its underlying UELib decompile .upk/.u packages across UE1–UE3 with high fidelity, there’s a smaller independent effort in unhood, and the modding scene has forked UELib per-title for engines with extra obfuscation (e.g. Unreal-Library-Arkham for the Batman: Arkham series, whose modders have an established UE Explorer/UDK-cooker decompile-edit-recompile workflow). Drakengard 3’s disc assets are plaintext, unencrypted .XXX-renamed UPK packages — a community .xxx importer already exists — and package names like GAMEFRAMEWORK.XXX strongly suggest UnrealScript class packages rather than plain data, meaning some non-trivial slice of Drakengard 3’s actual gameplay logic is likely recoverable, portable bytecode rather than PPU machine code.

UE4/UE5. The analogous mechanism is Blueprints, visual scripts compiled to their own VM bytecode form (Discovering the Blueprint VM). But the split shifted: UE4/5-era teams generally lean more on native C++ for core/performance-critical systems and use Blueprints for the higher-level, more game-specific glue — Epic’s own guidance frames it as a deliberate mix rather than either extreme (Balancing Blueprint and C++), and industry commentary generally agrees Blueprint-only shipped titles are the exception, not norm, for AAA scope (Blueprints vs. C++). Practically: a UE4/5 title’s script layer is still recoverable the same way, but it covers a smaller fraction of “the game” than a UE3 title’s UnrealScript typically did, so this technique’s leverage shrinks somewhat as the engine generation advances.

Unity. Gameplay code is C#, shipped either as Mono IL — interpreted/JIT’d at runtime, and decompiling back to near-original readable C# with mature tools like dnSpy and ILSpy is close to a solved problem — or IL2CPP, which Unity transpiles ahead of time to generated C++ and compiles natively. IL2CPP is not merely common on consoles, it’s close to mandatory: it’s the only backend supported anywhere JIT compilation is disallowed, which is every major console platform (Unity IL2CPP Overview). The good news is that reversing IL2CPP output, while harder than reading Mono IL directly, is a fundamentally different and more tractable problem than reversing hand-written, compiler-optimized native game code: the generated C++ is mechanical and heavily patterned, and tooling exploits that directly — Il2CppDumper reconstructs metadata (classes, methods, fields) back into loadable dummy assemblies; Il2CppInspector (now continued as Il2CppInspectorRedux) automates scaffolding for IDA/Ghidra; and Cpp2IL works toward IL reconstruction from the generated C++ itself. Separately, AssetRipper reconstructs an openable Unity project (not just individual assets) from a built game, though it’s explicit that reconstructed scripts and some features won’t work perfectly out of the box.

The actual technique: rehost, don’t recompile

The move this document is named for: instead of lifting compiled code, get a working PC (or otherwise cross-platform) build of the same engine version running, then hand it the game’s recovered assets plus its UnrealScript/Blueprint/C# content — re-hosting the original content on a legitimate build of its own engine, rather than translating compiled code function-by-function.

Real precedent exists but is modest, not polished. On the UE3 side, UDK Ultimate merged leaked console (PS3/Xbox 360) UE3 engine source into Epic’s free public UDK distribution, letting UDK content build for console targets — the mirror image of what this document is after (console→PC rather than PC→console), but it demonstrates the same underlying fact: community actors can and have merged console-side UE3 engine internals with a legitimate free UDK build. It’s also a useful cautionary note: the project was hit with a DMCA takedown and its official downloads pulled, now surviving only via Internet Archive mirrors (RetroReversing writeup, Internet Archive). On the asset side, the Batman: Arkham modding community routinely decompiles, edits, and re-cooks UPK content through UDK’s own cooker (ModDB UDK config tutorial) — real, working, but scoped to mods of an already-PC-native game, not a console-exclusive title moved wholesale to a new host. On the Unity side, AssetRipper-based project reconstruction has been used to revive individually abandoned/lost Unity titles for preservation, but these are one-off community efforts, not a demonstrated pipeline for moving a console-exclusive Unity game to a new platform. Bluntly: this is a real, technically-grounded strategy with real supporting tooling, but the search here turned up isolated, partial community efforts and adjacent capability demonstrations — not a single polished “console-exclusive AAA title now runs on PC via its own rehosted engine” success story to point to.

What still has to be solved

Even with recovered script/bytecode and a matching engine build, real work remains:

Fork drift. A AAA studio’s in-house UE3/UE4 branch typically carries custom native C++ engine modifications beyond stock Epic code — rendering tweaks, custom subsystems, gameplay framework extensions. That surface still needs genuine reverse engineering, just a much smaller one than the whole game (the studio’s engine diff, not the whole title).
Cooked asset re-conversion. Console-cooked content usually can’t be dropped straight into a PC build. For UE3 specifically, PS3 shaders were precompiled ahead-of-time into RSX-native binary via Sony’s Cgc compiler with no runtime compile/link step (Introduction to GCM), which is a fundamentally different pipeline than a PC UE3 build’s D3D9/HLSL cooked shaders — those shader binaries generally need re-cooking from source material (or shader source recovery) rather than reuse. UE3’s own cooker documentation confirms cooking is platform-specific, including byte-swapping for big-endian console targets (UDK Content Cooking).
Middleware. Bundled audio middleware, video codecs, and physics SDKs need PC-compatible equivalents or reimplementation — real work, but usually smaller and more bounded than the engine/logic question, since middleware is more likely to already have PC-side builds or open replacements.
Licensing and norms. UDK itself is free for non-commercial/educational use but requires a paid commercial license for any revenue-generating use, and forbids releasing any UDK application using certain bundled Epic assets (UDK license terms). More broadly, fan preservation/recompilation projects in this space (including the binary-recompilation projects in the companion docs) converge on the same informal norm: distribute only tooling/source, never the original copyrighted assets, and require end users to supply their own legally-owned copy of the game. This is not legal advice, just an observed convention — and one the UDK Ultimate DMCA episode shows isn’t a guarantee against takedown.

Comparative framing

Against the binary-recompilation landscape the companion docs survey, engine-based porting is generally more promising, not less — for the specific case where a title’s engine is identified as Unreal or Unity, decompiling script/bytecode content back to source is dramatically more tractable than lifting arbitrary compiled PPU/MIPS/68k machine code, and the pre-built tooling (UE Explorer, Il2CppDumper, AssetRipper, dnSpy) is more mature than any general-purpose static recompiler surveyed elsewhere in this project. It’s roughly the PS3-generation-and-later part of the landscape where this applies at all — Unreal and Unity weren’t dominant third-party engine choices earlier, and pre-Unreal/Unity titles, or titles on heavily-modified in-house engines with no public engine lineage to rehost against, are stuck with exactly the binary-recompilation-or-nothing situation ps3-recomp.md, ps2-recomp.md, and psx-recomp.md describe. For Drakengard 3 specifically, that means the UE3/UnrealScript angle is worth pursuing in parallel with (or ahead of) any PS3 binary-recompilation stretch goal — it targets a different, likely-larger fraction of the game’s actual logic, with better tooling, for a fundamentally smaller reverse-engineering surface.

Engine-Based Porting: Rehosting on the Original Engine Instead of Recompiling

The core insight: not everything shipped as machine code

The actual technique: rehost, don’t recompile

What still has to be solved

Comparative framing

Sources