I just ran a script through the Wiimmfi database to grab all the existing serial number prefixes that ever connected to Wiimmfi, and it looks like the letters R and S can also exist as second char in the serial number. R is Argentina (NTSC-U). I don't know what country S is. From the logs it looks a lot like NTSC-U, but I'm not 100% sure.

I've added those two as NTSC-U.

For curiosity's sake, I checked the setting.txt file of my Middle Eastern Wii, and it has the following:

AREA=USA
MODEL=RVL-001(UAE)
DVD=0
MPCH=0x7FFE
CODE=LMH
SERNO=[redacted]
VIDEO=NTSC
GAME=US

So the text in parentheses in MODEL isn't necessarily the same as AREA. Interesting...

Yeah, it looks like "UAE" wouldn't be a valid value for AREA. Or the tool I'm using doesn't know that UAE would be valid. The "SettingEdit" I used to look at the settings.txt file only has JPN, USA, EUR, AUS, BRA, TWN, ROC, KOR, HKG, ASI, LTN and SAF in the dropdown for AREA. The "Model" value is a free text field. Maybe Nintendo decided on the UAE model region after they've already finalized the list of valid / possible AREAs?

Although it could just be that UAE is missing from the tool by accident, but then why would an UAE wii not have UAE as AREA ...

I just tested this PR, but there is still a bug somewhere.

After importing the NAND backup, the settings are looking correct. Printing "decoded" to the console results in an output like this (assume my real serial number being LEH123456789):

AREA=EUR
MODEL=RVL-001(EUR)
DVD=0
MPCH=0x7FFE
CODE=LEH

SERNO=123456789
VIDEO=PAL
GAME=EU

Then, when I quit the game and start it again, it prints this instead:

AREA=EUR
MODEL=RVL-001(EUR)
DVD=0
MPCH=0x7FFE
CODE=LEH
SERNO=12345

Then, in any subsequent runs, it prints this:

AREA=EUR
MODEL=RVL-001(EUR)
DVD=0
MPCH=0x7FFE
CODE=LEH
SERNO=1234
VIDEO=
GAME=

So the last part of the serial number, and the VIDEO and GAME entries, are just gone.

Is it running into a size limit somewhere? Some part of Dolphin seems to corrupt the setting.txt again, and I haven't (yet?) been able to figure out where that happens. Do you have any idea?

@JosJuice Okay, either I am reading this piece of code wrong (I don't think that's the case), or there is a fairly stupid bug in the SettingsHandler::Decrypt function.

Take a look at this code block that does the decryption:

const u8* str = m_buffer.data();
while (*str != 0)
{
  if (m_position >= m_buffer.size()) {
    return;  
  }
    
  decoded.push_back((u8)(m_buffer[m_position] ^ m_key));
  m_position++;
  str++;
  m_key = (m_key >> 31) | (m_key << 1);
}

Am I understanding this correctly that "str" is a pointer to the encoded / obfuscated data? This means that "str" is pointing to binary data, not to a string.
In turn, this means that when the encoded binary data contains a NULL byte, the code stops and thinks it's done.

When I replace the while (*str != 0) loop with a while (1) loop and only rely on the if condition to return at some point, everything is working just fine. A better solution would probably be to decrypt the char, and if it decrypts to a NULL byte, stop. But I don't know if Nintendo always ends their decrypted content with a NULL byte.

That would mean that currently, while decrypting a setting.txt, there is a 1/256 chance for each byte in the file, that the decryption just randomly stops because the encrypted value is a 0. That wouldn't just break the Wiimmfi console identification, but would break everything that relies on reading correct console data from the setting.txt and should (in my opinion) be fixed ASAP.

I'll open a new bug report for that because that doesn't really have anything to do with this PR. Please wait with merging this PR until this bug is fixed.

I just opened issue 12019 for this decryption bug.

Thanks for merging #8680 and thus fixing issue 12019, now this (#8673) should be the last PR that needs to be merged to make NAND import work properly, at least for all the serial numbers and other identifiers.