#M4: polymorphism, launchers, platforms and Steam

M4 covers per-build divergence, cross-platform launch and Steam. Under the project's own open-core split, the polymorphism engine and the native launcher are the closed component, and Steam, Proton, Windows and Linux each need their own hardware to exercise. This page states precisely what the open baseline delivers and verifies here, and what is closed or pending hardware.

#Per-build divergence (baseline, working)

The property that "a break of one game does not port to the next" starts in the baseline: every protect run produces a cryptographically independent build.

• A random 16-byte container_id salts all key derivation (HKDF), in addition to random per-file IDs and keys and per-chunk nonces
• As a result, the same game protected twice yields a different container_id, different per-file keys and a different container, and one build's keys cannot read another's; this is proven in tests/test_cli.py::test_two_builds_are_cryptographically_independent
• The script key is independent of the container key (see Script layer and engine lockdown)

What the baseline does not randomize: the container's byte layout and field order, and the script AST class names, which are left standard (only re-encrypted).

#Closed upgrade: the polymorphism engine

The closed binary plugin randomizes the structure per build, namely the container layout and the compiled-script encoding, so that no universal reader or decompiler can be written even with the keys in hand. It plugs into renmori protect over the stable, documented process interface (see Architecture and Plugin interface); the open CLI is the integration point and runs the baseline when the plugin is absent. The mechanism and implementation are proprietary and live in the private MewBaka/RenMori-core repository.

#Launchers and platforms

The baseline loads through Ren'Py's extension mechanism (game/renmori.rpe), which runs inside Ren'Py's own bundled Python during normal startup. It is platform-agnostic: the same .rpe works on Windows, macOS, Linux and Steam Deck, because it relies only on Ren'Py's Python and ctypes, not on a per-OS launcher binary.

AES-GCM backend per platform (one interface, container/crypto.py):

The library is located beside the Python executable (runtime_lib_candidates, unit-tested), never via CDLL(None).

#Native launcher (closed, later)

A native per-platform launcher that boots the embedded Python from the container and performs runtime key derivation (so that no key sits in autorun.py) is the closed hardening, not an open deliverable. On macOS it is ad-hoc signed automatically at build time (free, and required on Apple Silicon) and remains re-signable with a Developer ID. The baseline ships no new executable, so it adds no signing burden over the original Ren'Py build.

#Steam

• The Steam overlay is safe by construction: the overlay injects a DLL into the game process, while RenMori only hooks Ren'Py's file loading and never performs process or DLL injection or anti-tamper on the hot path, so it cannot block the overlay
• Files read outside renpy.loader stay on disk: the Steam SDK reads steam_appid.txt directly (not through the loader), so it is kept unencrypted by default (DEFAULT_KEEP_ON_DISK); other such files can be added via keep_on_disk in renmori.toml; this is proven in tests/test_cli.py::test_steam_appid_kept_on_disk
• Achievements and Cloud save data go through Ren'Py's Python API, which is untouched; .rmc is a static file, so Steam's file verification and updates work normally
• Do not double-wrap with Steam DRM: it edits the executable, can conflict with a native launcher's self-check, and is weak in any case

Full Steam, Proton and Steam Deck runs are pending the corresponding hardware; the properties above are structural (based on hooks and file placement) and have not been run-tested here.

For the developer-facing release flow (build, protect, SteamPipe upload, which files go to which depot, and launch options), see Releasing to Steam.

#Also in M4

• renpy.exists() (previously disk-only) now also consults the container, so games that probe files with it see packed files (_install_exists_fallback)

#Current status

Open baseline, verified on macOS with Ren'Py 8.5.2: per-build divergence, the cross-platform .rpe path, Steam file placement and overlay safety by construction, and the renpy.exists fallback. Closed or pending hardware: the polymorphism engine, the native key-deriving launcher, and live Windows, Linux and Steam runs.