V10lator / NUSspli

NUS simple packet loader/installer

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Not yet documented data structure found in vWii system titles (credits to @Xpl0itU and Wii U Downloader users)

V10lator opened this issue · comments

This is more for devs, not for users.

Xpl0itU/WiiUDownloader#91 - which looked easy when Wii U Downloader devs tried to understand. It revealed a small error in our database. This little mistake returned wrong title IDs and as a result neither Wii U Downloader nor NUSspli where able to download thede titles.

NUSspli devs startet to investigate as the database is maintained by us. We found and fixed the mistake, informed Wii U Downloader devs and all was good - or so we thought. Shorty after this I tried to download Wii Shop Channel, just to make sure the bug is really gone. This gave a new error:
image

I also didn't pay much attention first, then I wanted to know why NUSspli thinks this title.tmd file is invalid. It turned out the file was too small for what https://wiiubrew.org/wiki/Title_metadata defines as minimum filesize. This made other devs and me curious, so we started to open this invalid title.tmd file as well as a known good one in hex editors, comparing them byte by byte.

Our findings so far are that multiple values at the main header differ, i.E. the type value. Also some byte wiiubrew defines as padding differs, so we don't think this is just padding anymore.
What differs the most through is what starts at offset 0x204 - It should be be a content metadata array of size 64 but it's something completely different.

This is when we realised there must be some yet completely undocumented title.tmd type.

TODO:

  • Look if this unknown data structure is maybe just the TmdView structure (as wiiubrew calls it, we call it dynamic sized TMD_CONTENT array) so if this type of title.tmd is just missing the content metadata array (as wiiubrew calls it, we call it fixed size TMD_CONTENT_INFO array).
  • Look for any kind of patters / repeating data / counters / repeating offsets and so on.
  • Write a ttitle.dmd downloader and parser checking all title.tmd files on the NUS, esp the type value and if the fixed size TMD_CONTENT_INFO array is at offset 0x204 (maybe Wii U Downloaders codebase could help a lot here?).

Credits to @Xpl0itU and the users of Wii U Downloader who participated at Xpl0itU/WiiUDownloader#91

I decided to do the byte-by-byte comparision of the invalid and the good title.tmd file one more time, this time with the web browser open, writing everything I find directly into this comment. I'm doing this so we won't forget anything in the private chats but have a place to look everything up and organise. This bug report here is also for developers of other tools/projects who are interrested in helping to have a place they can look anything up and talk to us.

So here are the findings now, obvious things like title ID / title version / group I skipped. Also nothing compared after 0x204 as that doesn't make sense:

Offset Name Value valid Value invalid
0x000 sig_type 0x00010004 0x00010001
0x140 issuer Root-CA00000003-CP0000000b Root-CA00000001-CP00000004
0x180 version 0x01 0x00
0x183 WUT_UNKNOWN_BYTES padding 0x00
0x184 sys_version 0x000500101000400A 0x0000000100000038
0x194 title_type 0x00000100 0x00000001
0x1AA reserverd 0x80000000 0x00000000 0x05510000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x0000 0x00000003 0x00038000 0x03030403 0x00808080 0x80808080 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x0000
0x1E0 boot_index 0x0000 0x000D

In the invalid file the hash at 0x1E4 starts with something looking like a pattern, not some hash value, to me: 0x0000000000000001000000000006

When comparing offset 0x204 of the invalid file with offset 0xB04 in the valid file on a quick look the unknown structure might indeed be the dynamic sized TMD_CONTENT array / I think I see similar patterns in the bytes... This needs more research through.

On a bit deeper look it looks like the new type is missing the hash, too, so maybe the dynamic sized TMD_CONTENT array starts at offset 0x1E4 there. If this is true this would be the first array entry:
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x06 0xA6 0xC0 0x16 0x83 0xA8 0x8F 0x72 0x82 0x7F 0xD2 0xD7 0x5E 0xF6 0x46 0x27 0xC3

Which would parse to:
CID (.app file name without .app extension) : 00000000
Index: 0
type: 0x0001 (encrypted)
size (of .app file) : 0x6A6C0 (435904 bytes aka 425.6875 KB)
Hash: 0x1683A88F72827FD2D75EF64627C3

Which looks very good to me. Still needs more research through.

Looks like it might actually just use the Wii’s TMD format, due to the bit at offset 0x183 changing, which resembles the Wii’s format https://wiibrew.org/wiki/Title_metadata

@Xpl0itU Good catch! So maybe TMD version (offset 0x180) is 0x00 for Wii and 0x01 for Wii U stuff?
And with a title having version 0x00 we should check that bit at 0x183, too, to see if it's vWii compatible or the user wants to brick?

Also we could read out region and stuff from the .tmd for Wii titles it seems... Love what you found there!
Offsets seem to match on first glance... So yea, you might be completely right!

Turns out this might be more complicated than first thought but maybe it might bring many new informations to the scene...

Like what if I tell you that title IDs are no IDs but bitmasks? Just look at this: 0005001010000100 - that's the title ID of boot1. Now let's assume this would be 4 16 bit wide bitmasks, so this:

0x0005
0x0010
0x1000
0x0100

This start to look bitmasky, doesn't it?

Now let's just look into the first of this bitmasks, what could it mean?
0x0001 = Not a Wii system title
0x0002 = Wii title
0x0004 = Wii U title (never seen alone?)
All other bits are probably reserved... So out 0x0005 would mean "Not a Wii system title / Wii U title" (the 0x0001 is probably for the Wii parsing this bitmask as yea, Wii and Wii U use the same bitmasks here).

Let's look at a Wii title instead: 0007000248414241 (Wii Shop Channel), there the 0x0007 would mean "Not a Wii system title / Wii title / Wii U title". Doesn't make sense? Of course it does as a vWii title is somehow a Wii and a Wii U title. But not only this, if we actually open the title.tmd file of this Wii Shop Channel the title ID Nintendo wrote in there is 0001000248414241. So it's different! The 0x0001 would mean "Not a Wii System title" which matches as system titles are things like IOS (starting with Wii title ID 0000) but it's also not a game/title for (v)Wii.

Ofc. this also needs a lot more research, this is basically just an unconfirmed thought in my head, but it would explain a lot. For example why title IDs tend to look similiar or why it's so hard for forwarder or channel creators to find a working title ID.

And yes, you just heard that right: There are titles with two title IDs! Nintendo doesn't make it easy for us...