GPL Violation & Obfuscation: "MiSTer x64" is hiding Libretro API usage inside a closed-source executable

[shmupsbr]

Hello team,I am reporting a blatant GPL violation by a project called "MiSTer x64" (https://misterx64.com).

They are distributing a closed-source software emulator disguised as an "FPGA port for PC", and they are using the Libretro architecture without publishing their source code. A forensic analysis of their binary (MiSTer-x64-1.28.5.exe) reveals the following: The executable contains a locked, high-entropy block of ~112 MB.

The visible Windows PE executable (~3.7 MB) is a frontend/wrapper that uses SDL 3.4.14 and Vulkan/Direct3D/OpenGL. To hide the GPL violation, they obfuscated the Libretro API calls using a basic Caesar cipher (shifting each character by +3).

By subtracting 3 from each byte, 21 Libretro functions are clearly exposed.

Some examples include:

uhwurblqlw -> retro_init (Hex: 0x0029DAC8) uhwurbuxq -> retro_run (Hex: 0x0029DB30) uhwurbordgbjdph -> retro_load_game (Hex: 0x0029DB40) uhwurbvhwbylghrbuhiuhvk -> retro_set_video_refresh (Hex: 0x0029DA48)

They organize their directories with cores//core.json files, acting as plugin recipes. They refuse to provide a GitHub repository or source code for their wrapper, directly violating the GPL.

Given the deliberate obfuscation to hide the Libretro API, this seems like grounds for a DMCA Takedown.

[hizzlekizzle]

Just using the API calls is actually okay, even in a closed source codebase, as the libretro API itself is MIT-licensed (though they should still mention it to be totally license-compliant). RetroArch is GPLv3, but as long as they're not directly using it, there probably isn't / may not be any violation at all.

[shmupsbr]

Thanks for the clarification! That makes sense regarding the libretro API itself being MIT. I was wrong to frame "using the API in a closed frontend" as an automatic GPLv3 / RetroArch violation.

The stronger issue is different, and I wanted to update the report:

Static analysis of MiSTer-x64-1.28.5.exe (SHA-256 410afeacc8cdb84b0862208935056d91254b820f786f32bd4370a24b8733f8a1) shows a ~3.7 MB PE frontend plus a ~112 MB overlay. The overlay is not AES; it is XOR'd with a predictable xorshift32 keystream seeded from each entry name (trailer magic MX64). After unpacking, the embedded cores are third-party libretro DLLs, not original engines:

NES → nes.dll → Mesen
PCE → pce.dll → Beetle PCE (Mednafen)
Genesis / Mega CD → genesis.dll → Genesis Plus GX
SNES → snes.dll → bsnes
Master System → sms.dll → Gearsystem
Neo Geo → neogeo.dll → Geolith
Atari 2600 → atari2600.dll → Stella
PlayStation → psx.dll → Beetle PSX
Saturn → saturn.dll → Beetle Saturn (modified)
Dreamcast → dreamcast.dll → Flycast
GameCube → gamecube.dll → Dolphin
3DO → 3do.dll → Opera
N64 → n64.dll → gopher64 (after a short-lived mupen64plus build)

Several of these upstream projects are GPL. The MiSTer x64 distribution is closed-source, has no public repository for the wrapper or for modified cores (e.g. Saturn / N64), and still markets itself as an "FPGA port" while linking the official MiSTer repo as if that were its source.

So: not "calling retro_* = GPL violation by itself." The concern is redistributing GPL libretro cores (some modified) inside a closed binary without corresponding source, plus deliberate obfuscation of the retro_* symbol names (Caesar +3 in .rdata) and of the core pack.

Happy to attach hashes / unpack notes if useful. Site: https://misterx64.com/

[hizzlekizzle]

oof, yeah, not too surprising.

I would say the next step would be, as a binary holder, to request source code from them.

Gopher64 doesn't have an existing, publicly available libretro core yet, so I'd personally be interested in seeing such a thing, though I assume it's all just slopified.

[shmupsbr]

Still about this:

MiSTer-devel/Main_MiSTer#1301 (comment)

[luizaoooobr]

Ainda sobre isto:

MiSTer-devel/Main_MiSTer#1301 (comentário)

Man, you're really envious. Leave the MisterX64 guys alone and mind your own business; the project is really cool and non-profit, and what you're doing hurts the retrogaming community.

[hizzlekizzle]

They're free to use these other projects as long as they comply with the terms of the licenses, which they currently are not. That's easy enough to fix, though.

If you value their work, and are a native speaker (to better avoid tone confusion and miscommunication), you can help by politely encouraging them to provide access to their modified source code where applicable as stipulated by those license terms.

That's all that needs to happen here. I/we don't have any desire to put a stop to anyone's work, etc., but it is important that developers are able to trust that the few stipulations of their licenses will be followed, or else they're likely to stop releasing their code at all (i.e., which prevents these sorts of downstream projects from existing in the first place).

[shmupsbr]

To @luizaoooobr: This isn’t about envy or hurting the retrogaming community; it’s entirely about basic accountability and respect for the open-source licenses that make projects like this possible in the first place. Nobody is trying to stop cool software, but pretending a packaged collection of GPL/MIT emulators (like Mesen, Flycast, and Gopher64) is an "FPGA port" while hiding the modified binaries behind an XOR overlay (MX64) and omitting source code isn't just misleading—it's a direct license violation.

To @hizzlekizzle: Completely agree with your perspective. Keeping downstream projects honest and compliant is the only way upstream developers can trust that their work won't be silently swallowed into closed-source binaries. If the project is non-profit and well-meaning, complying with the GPL by publishing the modified source code (especially for cores like N64/Gopher64) should be a straightforward fix. Providing that access is all it takes to clear up the concerns and keep everyone legally safe.

[KingDuckZ]

Not going to lie and pretend I know anything about this, I'm just a casual observer. I just wanted to say tho, if someone goes through the trouble of renaming functions using a cipher, that's dodgy af. It's not just to fit their code convention. I use plenty of libraries in my own projects myself, I respect their terms to the best of my knowledge and never once I felt like I should rename an init function to lqlw. That's a long winded way to say please don't dismiss this as "yeah whatever". Reach out to the FSF or any other entity that might offer help in enforcing licensing terms. If said project is so cool and cares about the community so much, they will have no problems publishing its source code for everyone's benefit, no need to shut down at all.

[shmupsbr]

They have already addressed this, stating that the source code will not be provided and that "anyone who wants to use it does so at their own risk"—in other words, they are completely ignoring GPL rules and the potential security risks entailed by such a violation. They mistakenly claim to have "the right not to publish their code"—which would be true, were they not appropriating Libretro-compatible cores (both intact and modified) that are subject to specific licensing requirements.