Unimplemented FS service command 0x08750180

[NVriezen]

A couple Yokai Watch games produce the error: Unknown FS service command with header 0x08750180
The games which this definitely happens for:

• Yokai Watch Blasters
• Yokai Watch 2 Psychic Specters
  (Yokai Watch 3 possibly produces this error as well, but it crashes before that point)

[neobrain]

This is documented as anti savegame restore. IIUC FS-HLE should write the values set by the game to the FS system save data, and then later return it. I don't think there's more to it, since the actual value checks are probably handled by the game itself?

For future compatibility with FS-LLE, it would be interesting to know what exactly the FS system save data for this looks like. Does FS create one file per game in its system save data, or does it use an internal format instead? Perhaps @ZeroSkill1 knows more?

[ZeroSkill1]

@neobrain I noticed some weird implementations on the FS side for secure values a while back, but I got busy so I left it unexplored until just now.

• 0x865/0x866 require special permissions to use (or if the caller doesn't have them, at least the save ID set in the exheader) and read/write secure values only from the FS system save.

• 0x86B/0x86C also require special permissions (save ID in the exheader does not suffice here) and read/write secure values directly to/from the save data DISA header and not the FS system save (the DISA header containing secure values [or hell, even gamecards being able to use secure values] is something that was previously completely unknown to my knowledge). (though you can force these two commands to read/write to/from the system save by setting the media type to 100, very strange)

• 0x86E/0x86F read and write secure values:

  • to/from the FS module system save data for media types SD & NAND
  • to/from the DISA header for gamecards

• 0x875/0x876 are identical to 0x86E/0x86F, except that instead of taking a media type and title ID, those are resolved through internal state using the given archive handle (which of course only works if the handle corresponds to a DISA).

I've added the storage format for values in the DISA header to 3dbrew already.
As for the structure of the FS system save for secure values, this is the structure (which I will also add to 3dbrew soon):

typedef union secval_key {
    u64 title_id;
    struct {
        u32 slot;
        u32 unique_id;
    } key_with_slot;
} secval_key;

typedef struct secure_save {
    u8 version;
    u8 pads[3];
    u32 count;
    u32 unused[1022];
    secval_key keys[0x3800];
    u64 secure_values[0x3800];
} secure_save;

System savedata ID 0x10011 is used (one of two FS module system saves, the other being SEEDDB), in which a file named just DB is created, consisting entirely of just the secure_save struct.

[neobrain]

Interesting findings, thanks so much for looking into it!

I also cross-checked the azahar sources and it looks like they just return stub-implement these functions. Apparently this works because if you always report that no secure value has been saved yet, the game will happily initialize it and won't mind if you immediately forget it.

So to get the games running in Mikage, stubbing seems like a reasonable way forward as well. FS-LLE will eventually take care of proper emulation.