[Feature Request] Visible information based on the loaded ROM on hard reset

[JP-Xinnam]

Background

Speedrunning GBA games can be very difficult to police on emulator. There exists a possibility of modified ROMs being used on emulator that are passed as the real thing to leaderboard moderators. This can lead to cheating, and can be very hard to detect, especially if the person with the modified ROM knows what they're doing.

To combat this for GB/GBC games, the Pokemon Speedrun Community implemented in Gambatte-Speedrun (Fork of Gambatte) a visible crc32 hash of the ROM as well as the emulator version information in the on-screen display after hard resets. This allows the leaderboard moderators to be able to accurately determine that the ROM is legitimate, and that the correct emulator is being used. (See screenshot)

Request

I would like to see a toggle-able hash of some sort (doesn't have to be crc32) and version information on hard reset implemented in mGBA so that we can validate ROMs for leaderboard purposes. It can also assist users in determining if the ROM they are using is a correct ROM, and not a modified ROM. Having it visible on hard reset will also assist runners with not having to worry about full window capture of the emulator for verification purposes.

[RetroEdit]

@JP-Xinnam This is an interesting concept, but what if the user modifies the source code to display the inaccurate information? Definitely requires a bit more work and sophistication so may prevent the average would-be cheater, but it also allows a false sense of security for those with more knowledge to potentially slide under the radar.

I wouldn't necessary disagree with this being added, but I also don't think it's a panacea for preventing cheating.

[JP-Xinnam]

Yes, it certainly isn't an end-all be-all for cheating prevention. Adding the barrier can discourage people from attempting to cheat, however. As a moderator on the FireRed/LeafGreen leaderboard, we've been discussing making emulator visible on it, and the challenges behind this. The most straightforward way to help pave that way is ROM integrity, which is why I placed the feature request. We moderators also know the game fairly well, so we can look for other signs of improper gameplay, but this is a good way to hard-check potential cheaters.

[Poliwrath]

For what it's worth, all it takes is one person to distribute a modified emulator that displays fake information for this to break...

[CasualPokePlayer]

Not sure if a new issue should be made, but this mostly relates to this so I'm putting this here.

I would like to request for this feature to be part of a togglable "Speedrun Mode". Such a mode would force settings specific for speedrunning, a list of such settings:

1. Force Native framerate
2. Force the real BIOS to be used (and probably check the hash to boot, no pun intended, assuming that isn't done already).
3. Indicators speedrun mode is on in the top of the window
4. Show ROM checksum/emu version on hard reset (preferably crc32; ie original request; this doubles as an indicator speedrun mode is on)
5. Have some sort of good rom indicator forced on top of the window (that or force the setting for the good rom name, which seems to togglable now: Setting to show filename in title bar instead of ROM name. #1807)
6. Hard reset fadeout like a GBP (this can probably be something togglable, this is rarely actually relevant)
7. Speedup/debugger/memory viewer/save states/changing the time/etc are disabled (essentially anything that has no legitimate purpose in a speedrun would be disabled, ie not possible on console -> not allowed)
8. Invalid opcodes hang like on console (as opposed to throwing an error and closing the ROM)

Also for the comment this request is to prevent cheating, this isn't really true. Gambatte-Speedrun did not implement this to prevent cheating, rather this is just to prevent people from accidentally submitting runs done on bad dumps. There isn't really a way to full on stop cheating on the emu side without severe impedance on a user's privacy and an absurd level of permission on a user's computer, so it's really best for leaderboard mods to be up to that task.

[endrift]

That mostly sounds like a good list of things to add in one go. Not sure what the point of the fadeout is, but the rest seems reasonable.

[CasualPokePlayer]

The fadeout would be meant for timing parity with the Gameboy Player, which is the most common console used for GBA runs (mostly due to the capture situation, also because the next best platform, the DS, suffers from a lower framerate in GBA mode than a normal GBA). Although some communities might not care for the hard reset fadeout (so probably best make it togglable?), and even for Pokemon there is rarely a case where the hard reset fadeout actually matters (the "invalid opcode" part would be the most likely case if anything, but that would only be applicable for 1 category and it's still niche with that single category).

[profi200]

Sounds like the 3DS could become the next Game Boy Player then since it uses original GBA hardware and on top of that you get ARM9 and ARM11 cores running so you could run whatever you need directly on the 3DS alongside the game.

[CasualPokePlayer]

Again, the fadeout thing would vary on community (in reality, Pokemon would be the only one which would maybe care, and even then, only applicable in a niche case in 1 category). And 3DS can't really be "the next Gameboy Player" considering that the cartridge part still has to be emulated, and there were what, only 11 games officially released? And Virtual Console injection is generally banned by speedrun communities, so that's moot.

[profi200]

Why so offensive? Btw you missed something. The gamecart is not emulated in the way you think and it behaves 1:1 like a real one with the exception being out of bounds reads.

[endrift]

That exception is important, since so many games fuck that up.

[CasualPokePlayer]

In general, not official release = banned or allowed with limited capacity. Hence, in general, flash carts and repro carts are banned from the leaderboards (again, in general; this can vary). Like flash carts and repro carts, Virtual Console injection is not an offical release, so it is generally banned.

Of course in cases it is allowed, it would likely be with limited capacity and treated like an emulator for purposes of comparison. Or possibly it is considered the same as an official release; it really depends on the community.

EDIT: Also, by 1:1, do you mean the write speed of say Flash is (nearly) identical to an official cart? Just curious if this is the case, considering this can matter for speedruns that might use Save+Quit.

[profi200]

Timings for all but SRAM can be adjusted in cycles. Not sure how close the timings set in the header of official ambassador games are. It seems to be matching nicely compared with real hardware.

The problem with out of bounds reads is that it doesn't have variale cart sizes. It only has 16 or 32 MiB depending on the save type. I recently added fake cart open bus padding on the other branch to get this as accurate as possible. It will work fine for non-sequential out of bounds accesses (edge case of an edge case).

[CasualPokePlayer]

Adding onto this, it might be best to also just show the checksum on soft reset along with hard reset (detected with swi #0?)

[Amaroq-Clearwater]

Another issue with mGBA and Speedrunning is that the ROM isn't preloaded into memory by default (there's an option which enables this, of course), which means that you could theoretically replace the ROM of a game while it's running. As such, a Speedrun mode needs to also enable this option.

---

As for preventing the code itself from being tampered with, I'd suggest obfuscating the code in some fashion, as well as including redundant bits of said code (obfuscated in a separate pass so that it's less obviously the same code), and maybe even relying on self-modifying code.

In fact, a tamper-proof, speedrunning-compliant version of mGBA would probably need to be a separate closed-source build altogether, with lots of things in the code changed outright.

[endrift]

Closed or obfuscated source are out of the question. This is an open source project and cheating can and will happen regardless of how difficult it is to alter the program. I won't reduce the integrity of the project for one feature that would be circumvented eventually if people tried hard enough anyway.

Also I just straight up cannot make a closed source version that also can encode H.264 or HEVC due to licensing restrictions on the libraries used, so that makes it impossible even if I weren't opposed to doing that in the first place.

[CasualPokePlayer]

As for preventing the code itself from being tampered with, I'd suggest obfuscating the code in some fashion, as well as including redundant bits of said code (obfuscated in a separate pass so that it's less obviously the same code), and maybe even relying on self-modifying code.

In fact, a tamper-proof, speedrunning-compliant version of mGBA would probably need to be a separate closed-source build altogether, with lots of things in the code changed outright.

Did you miss my reply?

Also for the comment this request is to prevent cheating, this isn't really true. Gambatte-Speedrun did not implement this to prevent cheating, rather this is just to prevent people from accidentally submitting runs done on bad dumps. There isn't really a way to full on stop cheating on the emu side without severe impedance on a user's privacy and an absurd level of permission on a user's computer, so it's really best for leaderboard mods to be up to that task.

[CasualPokePlayer]

endrift — Today at 12:24 AM
ohh yeah
does the game not use HALT properly
mGBA has a thing where it's supposed to optimize those out
I know AREE doesn't
though I think the detection broke in AREE at some point
but: that optimization is intentionally disabled in bizhawk
because it's not proven to be deterministic
(and I'm pretty sure there are some timing issues with it oops)

Another minor thing a speedrun mode, it should probably disable this like BizHawk does.

[endrift]

Please file a separate issue for speedrunning mode, as I'm making this visible info a separate feature (at least for now).