Request: core info should check the hash of bios files when a hash is available

[kcin2001]

First and foremost consider this:

• Only RetroArch bugs should be filed here. Not core bugs or game bugs
• This is not a forum or a help section, this is strictly developer oriented

Description

To make verifying bios files easier for the user it should hash the bios file to verify that it is the correct bios file

Expected behavior

bios file hashing if the file is there but it doesnt match the hash it should say "Wrong hash" or similar instead of missing or present

Actual behavior

just name checking

Bisect Results

[Try to bisect and tell us when this started happening]

Version/Commit

You can find this information under Information/System Information

• RetroArch: [version/commit]

Environment information

• OS: [The operating system you're running]
• Compiler: [In case you are running local builds]

[orbea]

With some cores the user's working bios files will not match the hashes for working bios files which other users have.

[ghost]

The fact that we would have to scrape the freeform description field is also a problem, unless the core info format was modified.

[i30817]

You mean it doesn't already? Filename check only? Uh. I guess it's understandable because some bios have writable memory areas and settings like the clock make use of that.

[ghost]

why stop there? i think its better after checksum the files, especially those not marked option can be loaded ahead and passed to core (similarly to loading content/rom),

[ghost]

Filename check only

Yes.

I didn't think about cores modifying their "bios" files... not sure what to do in that case.

[i30817]

This could be done by really digging into the bioses and seeing which ones have that peculiarity and eliminating that range from the 'required' checksum (also show the 'whole' checksum as the required one for users).

It shouldn't be extremely difficult, because there shouldn't be that many platforms doing it (because it's a terrible idea).

However, some things will continue to be filename checks (rather, folder name checks), like the dolphin Sys dir; so things will be slightly inconsistent anyway, and the code complexity price might not be worth the usability improvements of catching mistakes (well, until the first 'bios virus' hits retroarch i guess, which is a good counter argument).

[orbea]

A better approach to a bios or content virus would be to harden RetroArch and every core against hostile input.

[andres-asm]

I'll be coming up with a BIOS API call later on. A lot of the problems with RA are that that the API was pretty much unidirectional, so we have to rely on info files and assumptions. This was the case because RA was mostly CLI driven.

But now it's not the case, and the GUI can show what is required for content to work and more, the API just needs to communicate these things more effectively.

The idea I have is that there will be a GET_BIOS env callback that will publish the required BIOS files for a system, with the supported CRCs and the lookup locations

Like....

GPGX woud report (this is all made up

megadrive.bin, md|gen, CRC1|CRC2, RETRO_SYSTEM_DIR|RETRO_SYSTEM_DIR/Sega Megadrive|RETRO_SYSTEM_DIR/Sega Genesis|RETRO_CONTENT_DIR|RETRO_CONTENT_DIR/Sega Megadrive|RETRO_CONTENT_DIR/Sega Genesis
gamegear.bios, gg, CRC1|CRC2, RETRO_SYSTEM_DIR|RETRO_SYSTEM_DIR/Sega Game Gear|RETRO_SYSTEM_DIR/Sega Game Gear|RETRO_CONTENT_DIR|RETRO_CONTENT_DIR/Sega Game Gear|RETRO_CONTENT_DIR/Sega Game Gear

This is the gist of the idea it wouldn't be exactly like that So when loading content RA would check this callback, would check the content extensions and look for the files in the indicated lookup locations and present error messages accordingly BEFORE attempting to load content, would allow to load anyway if the BIOS is optional and would remember the response (hopefully)

[i30817]

A better approach to a bios or content virus would be to harden RetroArch and every core against hostile input.

But bios are executable code, you'd have to run a sandbox against a crafted attack if the 'bios' can just execute some code in the emulator and break out.

Hardening against 'hostile input' in something you have to run as executable is checksumming, and even that is not really sufficient with a crafted collision (from a insecure checksum).

I agree this is unlikely in this vector though. Like, extremely unless there is a 'whitehat' asshole trying to make a imaginary point with a terrible low impact propagation mode (i guess i don't think it's such a good counter argument after all).