Trackmania (PPSA02195)

[simnJS]

Setup

Title	Trackmania, PPSA02195, contentVersion 01.026.000, masterVersion 01.00
Host	Windows 11 Pro 26200, Ryzen 9 7950X3D, RTX 4080 SUPER, 64 GB
Relinker	main at 813496001e, WinLibs GCC 15.2.0 r7, Release
Target	Windows PE

The app ships one executable and five ELF modules: libaegir.prx (48 MB, the engine) at the app root, anzu/anzu.prx, and sce_module/{libc,libScePfs,libSceNpCppWebApi}.prx. fakelib/ holds SELF stubs for libSceAgc, libSceAgcDriver, libSceAmpr, libScePlayGo and libScePsml; they were left out of the module directories, since AnyPS5 provides those libraries itself. All six were unwrapped with tools/unwrap_self.py, then converted with:

relinker --windows --registry --trace-imports --module-dir . --module-dir anzu eboot.elf app.exe

The executable needs 48 system libraries, all of them declared under core/libs/prx. libaegir.prx additionally needs libSceRazorCpu.prx and GbxGame, which is the executable's own module name.

Status

Conversion fails on main. With the two changes below it converts fully (5 modules, 2558 external prx references), and the runtime then stops in the module loader. No frame has been rendered yet.

1. First stop: a segment prefix with no memory operand

FAIL: Unsupported Windows guest TLS instruction (bytes: 64 22 d0) (offset 0x1854935)

64 22 d0 is fs and dl, al: ModRM d0 is register-direct, so the FS prefix has no memory operand and selects nothing. WindowsTlsBuilder classifies it anyway and refuses the image.

This refusal is deliberate, and I first read it as an oversight. UNSUPPORTED_TLS in test_sce_code_extent.py is 64 2d 65 6c 66 2e c3, an fs sub eax, imm32 whose immediate spells elf., and several fixtures there require that the conversion fail on it. segment-prefix-at-eof in test_tls_function_coverage.py uses 64 90. So an inert segment prefix is the project's canary for code taken from data: the refusal is what surfaces a misclassification instead of silently miscompiling. Skipping it would hide the cause rather than fix it, and section 2 is that cause.

Those bytes are not code. They sit in an OpenSSL CRYPTOGAMS AES constant block at va 0x1850680-0x1850710, which a function at va 0x1850620 addresses with lea r10, [rip+0x79] and reads with seven movdqa. None of these modules carry symbols for this code, so the attribution to CRYPTOGAMS rests on the instruction shape and on the copyright string in section 2, not on a symbol name.

2. The cause: embedded constants followed as code in an image without PT_SCE_DYNLIBDATA

After the first stop, the next one is:

FAIL: Unsupported Windows guest TLS instruction (bytes: 64 20 73 71) (offset 0x1874715)

64 20 73 71 is not an instruction either. It is the ASCII d sq of

Keccak-1600 absorb and squeeze for x86_64, CRYPTOGAMS by <appro@openssl.org>

which the eboot stores at va 0x18706fe, right after the 24 Keccak iota round constants at va 0x1870640. Two lea r15, [rip+...] at va 0x187040d and 0x1870495 take that constant block's address.

The code analysis has a code/data test for exactly this, but it never ran: sceFunctions is filled only in the if (sceBase) branch of CodeInstructionCollector::Collect, and no module of this title has a PT_SCE_DYNLIBDATA segment, while all six do have PT_GNU_EH_FRAME. With the list empty, addPointerRoot takes the sceFunctions.empty() short circuit and makes every RIP-relative lea target in an executable segment a code root, and BuildControlFlowGraph is told to follow code addresses. dataTargets stays empty, so nothing is reported.

The eboot does carry what the test needs: PT_GNU_EH_FRAME with 80625 FDEs covering 31.4 MB of the 32.1 MB executable segment, 98.0 %. Both failing addresses fall in inter-function gaps, 0.65 MB in total across 76503 gaps.

Reading the unwind table in that branch too makes the conversion complete and report Took 55 pointer target(s) outside the unwind functions as data, the first at 0x1850770.

3. Runtime stops on the executable's own module name

With the conversion through, the title gets as far as the module loader:

[time] scheduler tick raised to 0.5 ms
[HostCpu.cpp:220] host CPU AMD Ryzen 9 7950X3D: ... lacks none
Failed to load module: libs\GbxGame
GetLastError: 126 - The specified module could not be found.

GbxGame is the eboot's module name, the title's equivalent of MainProg. libaegir.prx imports GvGnMOCTRXA from it, and the eboot exports exactly that symbol (value=0xc27f20, size=8, GLOBAL, FUNC). The converted libaegir.prx.guest.prx instead declares GbxGame among its host dependencies, and the executable's own .needed.json lists it as well, so the loader looks for a libs/GbxGame that cannot exist. The relinker prints no warning; tools/import_audit.py does flag it.

I tested #11432 on top of the section 2 change, merged cleanly at 77cb5f907c. It gives the executable what it was missing: app.exe now carries an export directory and objdump -p shows [ 0] +base[ 1] 0000 GvGnMOCTRXA. The title still stops at the same place:

Failed to load module: libs\GbxGame
GetLastError: 126 - The specified module could not be found.

The entry stub loads every needed library from libs/ by name before it resolves any import, so the executable's new export table is never reached. The chain is:

1. libaegir.prx has DT_NEEDED GbxGame. The executable's own DT_NEEDED has 48 entries and GbxGame is not among them.
2. The executable's .needed.json companion lists GbxGame all the same, since it aggregates the host dependencies of the bundled modules, as USAGE.md describes.
3. WindowsEntryStubBuilder turns that list into a load of libs/<name> for each entry. A missing library is tolerated only when nothing is imported from it, and GvGnMOCTRXA is imported, so this one is fatal.

So #11432 is necessary here but not sufficient: something also has to recognise that a needed name is the title's own executable. One rule that would not need the module name to be recoverable from the image, which it does not look to be here (no DT_SONAME, no module info the unwrapped ELF kept): a needed library with no file in libs/ or the module directories, whose imported symbols are all exported by the converted executable, resolves to the executable. With #11432 those exports exist, so the check is possible.

I tried that rule locally, on top of #11432: the entry stub takes the handle of the process image with GetModuleHandleW(NULL) for a needed library that has no module suffix and whose every import the converted executable exports, and stores it in the same handle slot, so the existing GetProcAddress resolution is unchanged. libs/GbxGame is no longer looked for and the title starts.

4. Where it stops now

With sections 2 and 3 in place the title reaches its own engine and runs until the audio setup:

[Sys]  BuildInfo   : date=2025-06-19_21_00 git=127527-9def2ceea10 GameVersion=3.3.0
[Sys]  Defines     : ConsoleMode TrackmaniaStandalone .
[memory] configured flexible memory: 0x1c000000 bytes (448 MiB)
[GameDataPacks] installed pack: Maniaplanet.pak (176 299 784 bytes)
[GameDataPacks] installed pack: Maniaplanet_Core.pak (54 003 464 bytes)
[GameDataPacks] installed pack: Maniaplanet_ModelsSport-001.pak (4 048 669 960 bytes)
[Sys] Windows GDI resolution = 1 920x1 080x32b
[Sys] Shaders binary link success. using ':data:\Packs\GpuCache_Ps5.zip'.
Starting Trackmania date=2025-06-19_21_00 git=127527-9def2ceea10 GameVersion=3.3.0...
[libc] unhandled exception 'St13runtime_error'
  what():  NGS2: voice param 0x30000002 is not implemented
FATAL: abort() (SIGABRT) on thread 493632

So it mounts every data pack, checks their hashes, links its shader cache from GpuCache_Ps5.zip and starts, then stops on one NGS2 voice parameter. 0x30000002 is not among the identifiers libSceNgs2.native handles. No frame has been presented yet, and nothing beyond this point has been exercised.

Library status

tools/import_audit.py over the executable and the five converted modules, against a main build of libs:

3537 references, 1969 unique imports
  implemented   1235 imports    1495 references
  partial         25 imports      27 references
  stub             2 imports       2 references
  absent           1 imports       1 references
  module         706 imports    2012 references

The only absent import is GvGnMOCTRXA [GbxGame] from section 3. The two stubs that would throw when called are libSceHttp2.prx: sceHttp2WaitAsync and sceHttp2ReadDataAsync. Of the 25 partials, 18 are also libSceHttp2, so HTTP/2 is where this title will land next once it boots.

Patches

One change, on section 2, with a fixture that fails without it: a non-SCE image whose function takes the address of an fs instruction past the end of its unwind function. It clears both stops, since the constants are no longer followed as code, and it leaves the canary of section 1 in place: #13716.