Hacking Wii U support in Dolphin

[CarlKenner]

Too bad it can't read the fst of the game partition, yet (I am really curious about if there are all these beta levels in the WW remake or even new test stages).
But nice job anyways
Are there any screenshots or is there a demonstration video of it?
(i dont have any Wii U game rip so i can'T try it out on myself)

Yes, the game partition is the interesting one, and extracting the game files would enable some cool mods for other games (although I'm hoping files in the update partition might be useful for exploits and enabling homebrew). Unfortunately, there is probably a different encryption on the game partition, because I can't get any meaningful information from it. Maybe the SI partition has the needed information to decrypt the game partition, or maybe we need the Wii common key, or maybe there's some trick to it.

In case you are wondering, I couldn't find the game names in the disc images anywhere, which is why the screenshot shows the WUP- codes instead.

Screenshot

 

[Bug_Checker_]

Spoiler

Well, that explains OpenSSL. However, as far as I was aware, I was decrypting each cluster individually (with an IV initialized to zero). But since that would explain my bug, and why it was affecting three filenames rather than one, it must be the problem.

Clusters appear to be 0x8000, not 0x10000, so I'm (trying to) decrypt each 0x8000 individually. Is that the problem? Should I be using 0x10000 blocks for decryption? FST blocks usually seem to start on a 0x8000 boundary after an unecrypted cluster, so I'm not sure how I could decrypt in 0x10000 blocks anyway.

I didn't look at empty decrypted sectors except in the bugged OpenSSL decrypted file.

Here's my code (and yes, I know the read current block part would be more efficient inside the next if):

bool CVolumeWiiUCrypted::Read(u64 _ReadOffset, u64 _Length, u8* _pBuffer) const
{
    if (m_pReader == nullptr)
    {
        return(false);
    }
 
    // The first cluster of a partition is unencrypted
    if (_ReadOffset < 0x8000)
        return RAWRead(_ReadOffset + m_VolumeOffset + dataOffset, _Length, _pBuffer);
 
    while (_Length > 0)
    {
 
        // math block offset
        u64 Block  = _ReadOffset / 0x8000;
        u64 Offset = _ReadOffset % 0x8000;
 
        // read current block
        if (!m_pReader->Read(m_VolumeOffset + dataOffset + Block * 0x8000, 0x8000, m_pBuffer))
        {
            return(false);
        }
 
        if (m_LastDecryptedBlockOffset != Block)
        {
            u8 IV[16] = { 0 };
            aes_crypt_cbc(m_AES_ctx, AES_DECRYPT, 0x8000, IV, m_pBuffer, m_LastDecryptedBlock);
 
            m_LastDecryptedBlockOffset = Block;
        }
 
        // copy the encrypted data
        u64 MaxSizeToCopy = 0x8000 - Offset;
        u64 CopySize = (_Length > MaxSizeToCopy) ? MaxSizeToCopy : _Length;
        memcpy(_pBuffer, &m_LastDecryptedBlock[Offset], (size_t)CopySize);
 
        // increase buffers
        _Length -= CopySize;
        _pBuffer    += CopySize;
        _ReadOffset += CopySize;
    }
 
    return(true);
}

Actually... those 3 filenames were correct in the OpenSSL decrypted file. It's just my code they were wrong in.

I'm gonna stick with 0x10000 for cluster size since Nintendo seems to number them so nicely for us.(until I see evidence oherwise) But to each his own.

 

[NWPlayer123]

Yep, this works as expected.

 

[CarlKenner]

I'm gonna stick with 0x10000 for cluster size since Nintendo seems to number them so nicely for us.(until I see evidence oherwise) But to each his own.

Well, the obvious evidence for 0x8000 is:

• The partition table uses the number of 0x8000 clusters as the offset for the partition.
• The sub-partition headers at the top of each FST table use the number of 0x8000 clusters as the offset for that sub-partition.
• The sub-partition headers at the top of each FST table use the number of 0x8000 clusters as the size for that sub-partition.
• The unencrypted sections are usually 0x8000 bytes long.
• The encrypted FST tables are usually at an offset of 0x?8000.

That doesn't mean you are wrong about the encryption, because it appears I am doing something ever so slightly wrong, but I'm not clear on how to do decryption in blocks of 0x10000 when the encrypted blocks don't even start on multiples of 0x10000. How do you do it?

BTW, technically what I am calling a cluster isn't really a cluster in the FAT sense, since files begin on multiples of 0x20.

 

[spotanjo3]

yeah i read this. but in future i think early in 2-4 years.

Yeah, maybe less but it doesnt mean you want it to run in 30 days or 6 months.

 

[Fishaman P]

I would have suggested that this be merged into the main project when it's working properly, but then all the noobs would be complaining that they can't load WiiU games.
Definitely bring this to the attention of the main devs, though! I would suggest Delroth first.

 

[NWPlayer123]

I would have suggested that this be merged into the main project when it's working properly, but then all the noobs would be complaining that they can't load WiiU games.
Definitely bring this to the attention of the main devs, though! I would suggest Delroth first.

Not really any use if we don't even have the keys to decrypt it all. Maybe once we have that they can consider it

 

[WulfyStylez]

So we can extract stuff from the update partition - but I imagine all that's there is a package/packages that we'd need the common keys to do anything with?

 

[CarlKenner]

I would have suggested that this be merged into the main project when it's working properly, but then all the noobs would be complaining that they can't load WiiU games.
Definitely bring this to the attention of the main devs, though! I would suggest Delroth first.

It's still a bit buggy though, and they haven't seemed keen on emulating the Wii U before. And I have a bunch of other branches that they didn't seem to like.

 

[the_randomizer]

I would have suggested that this be merged into the main project when it's working properly, but then all the noobs would be complaining that they can't load WiiU games.
Definitely bring this to the attention of the main devs, though! I would suggest Delroth first.

He can be a tough cookie to work with and convince

Edit: Yep, he just intervened, and shot it down, he's just full of surprises.

 

[grossaffe]

It's still a bit buggy though, and they haven't seemed keen on emulating the Wii U before. And I have a bunch of other branches that they didn't seem to like.

Yeah, I seem to remember reading the Dolphin devs saying they had no interest in having it support Wii U.

 

[CarlKenner]

So we can extract stuff from the update partition - but I imagine all that's there is a package/packages that we'd need the common keys to do anything with?

Probably, I couldn't make much sense of the update files besides the app.xml and the update.inf.USA, and the title files. The .app files don't look like U8 archives.

 

[Marionumber1]

Send them to me, I'd be interested in taking a look.

 

[Bug_Checker_]

Not really any use if we don't even have the keys to decrypt it all. Maybe once we have that they can consider it

That is why I didn't explain what was going on with encrypt/decrypt sectors earlier. Btw credit goes to Venom and crediar(and maybe nintendo) who if they hadn't begun this a year ago my understanding would not be as far as it is.
Can anyone say WiiUfuse?

 

[delroth]

It makes no sense to bring that into Dolphin because it is not emulating anything. We don't want Dolphin to be a GC/Wii emulator and a Wii U file explorer (that also doesn't work since it cannot open encrypted game partitions - so it's virtually useless at this point). This could have been just as much a standalone application, or something added into WIT and other disc management kind of tools.

 

[CarlKenner]

Wii U support has to start somewhere though, and recognizing Wii U discs and executables seemed like a good enough place to start.

 

[the_randomizer]

Wii U support has to start somewhere though, and recognizing Wii U discs and executables seemed like a good enough place to start.

And no one can fault you for having the desire/the drive for wanting to start somewhere

 

[delroth]

Wii U support has to start somewhere though, and recognizing Wii U discs and executables seemed like a good enough place to start.

No, this is a terrible place to start because it is completely irrelevant to Wii U emulation. If you had started anywhere else you would have noticed that Wii U emulation is a completely different beast than GC/Wii and would have abandoned the idea of integrating that into Dolphin.

There is no way to introduce Wii U support in Dolphin that wouldn't require rewriting half of our codebase and compromising on GC/Wii emulation speed. You're talking about changing from a kernel mode system emulation to a user mode system that runs under a kernel, from a single core system to a multi core system, from a fixed pipeline GPU to a complex programmable GPU, and that's not including the doubling in processing speed, the new hardware support, etc.

There is no compelling reason to even try it - Dolphin is a fairly terrible codebase (though we're working on making that better), composed of a lot of old and hacky parts, and not up to modern programming standards.

 

[uyjulian]

No, this is a terrible place to start because it is completely irrelevant to Wii U emulation. If you had started anywhere else you would have noticed that Wii U emulation is a completely different beast than GC/Wii and would have abandoned the idea of integrating that into Dolphin.

There is no way to introduce Wii U support in Dolphin that wouldn't require rewriting half of our codebase and compromising on GC/Wii emulation speed. You're talking about changing from a kernel mode system emulation to a user mode system that runs under a kernel, from a single core system to a multi core system, from a fixed pipeline GPU to a complex programmable GPU, and that's not including the doubling in processing speed, the new hardware support, etc.

There is no compelling reason to even try it - Dolphin is a fairly terrible codebase (though we're working on making that better), composed of a lot of old and hacky parts, and not up to modern programming standards.

well at least some parts of dolphín may be uséful for wii u emulation.

 

[delroth]

Like?