Hacking Wii U audio dumping research thread

[loco365]

So with the 5.X exploit being released by Marionumber1 and Chadderz, I can now execute arbitrary code on my Wii U (As well as anyone else with an up-to-date console). What I'd like to start doing is finding a way to dump all of the system's RAM using a ROP Chain once it's possible (From what I'm hearing, there's some kind of PPC hack that will allow this, feel free to correct me on this), and analyse them for audio formats, then create a branch of my own 3DS Audio Music Dumper, and get it to dump Wii U formats (I assume most of which would be streamed formats).

However, I'd like to start with looking for public documents similar to what you find on [system]brew sites and start using that documentation to create a preliminary ripper for when memory dumping can be done by the average end-user. I'm currently looking into it, so that I can begin to extract formats, as well, get these file formats to the authors of vgmstream so that support for Wii U formats can begin to be added.

I'm hoping that someone on GBAtemp has some kind of information on these formats, and if so, be able to share perhaps a sample file or sample files so that I can start working on this.

 

[NWPlayer123]

We can't do anything yet without a kernel exploit or access to all the keys.

 

[loco365]

We can't do anything yet without a kernel exploit or access to all the keys.

You don't necessarily need keys. Files are decrypted before being loaded to the RAM, similar to a 3DS. If you can dump the memory of a system, you can get the unencrypted assets that are currently being used.

 

[iNFiNiTY]

If you are looking for filetypes possibly vulnerable to exploits, well i think Nintendo deliberately uses their own sound format(s) and they use mobiclip who they bought out for video related things, both are private and going to be a lot harder to find exploits in as a newbie than looking for some existing exploit that affects a library Nintendo have used or something along those lines (ie: webkit browser exploit, tiff and other image exploits dependant on libtiff and other standardized libraries that they have used.. there's a list in another thread of some that have been found). But their own propitiatory formats will be more difficult and they tend to try and use them a lot.

If you just want to look for music to rip out of games its a bit early for it yet but they probably use similar formats to the ones listed on 3dbrew.org. Eventually you'll be able to search in memory and probably pull some of them out but the tools are not there yet.

 

[loco365]

If you just want to look for music to rip out of games its a bit early for it yet but they probably use similar formats to the ones listed on 3dbrew.org. Eventually you'll be able to search in memory and probably pull some of them out but the tools are not there yet.

Well, this is pretty much it. But instead of the system finding the formats, it'd be a program. I already have the shell for it, I'd just need the formats and the binary dump.

 

[iNFiNiTY]

If you got some other audio file, from a 3DS game prehaps, lets assume its maybe the same format for now, try searching for the 4 specific bytes at the start of the file in memory to work out the locations.. a binary dump of a whole game won't happen all the music isn't even likely to all be in memory, just need to know its loaded, find the location, then work out the format to tell how big the file is... then tell the shell to dump memory from x to x location to file. Easier said than done though right.

http://3dbrew.org/wiki/BCWAV
http://3dbrew.org/wiki/CSTRM
http://3dbrew.org/wiki/BCSAR

And '.CGRP - CTR GRouP - Used to package several formats like (CWAR, CWAV, CWSD, CBNK, CSEQ, ect...) sort of like the Wii's MRG format. (they aren't the same structures but both package together several formats)' suggests they might be packed together too, although in memory surely unpacked.. i'm not sure about music being in basically pure WAV files but they got the space on disc for it... still it's possible to do though if you want! I would have thought dumping a game executable would be more interesting or something though.

 

[loco365]

If you got some other audio file, from a 3DS game prehaps, lets assume its maybe the same format for now, try searching for the 4 specific bytes at the start of the file in memory to work out the locations.. a binary dump of a whole game won't happen all the music isn't even likely to all be in memory, just need to know its loaded, find the location, then work out the format to tell how big the file is... then tell the shell to dump memory from x to x location to file. Easier said than done though right.

http://3dbrew.org/wiki/BCWAV
http://3dbrew.org/wiki/CSTRM
http://3dbrew.org/wiki/BCSAR

And '.CGRP - CTR GRouP - Used to package several formats like (CWAR, CWAV, CWSD, CBNK, CSEQ, ect...) sort of like the Wii's MRG format. (they aren't the same structures but both package together several formats)' suggests they might be packed together too, although in memory surely unpacked.. i'm not sure about music being in basically pure WAV files but they got the space on disc for it... still it's possible to do though if you want! I would have thought dumping a game executable would be more interesting or something though.

Yeah, I already have all the 3DS audio formats in my audio dumper (Check the OP for a link to that), all that I really need is the header format, so I can rewrite the program to find those formats on a hexadecimal level.

 

[iNFiNiTY]

Have you looked in the leaked SDK? Bad i know. But probably a hint in there even though it's old.

 

[loco365]

Have you looked in the leaked SDK? Bad i know. But probably a hint in there even though it's old.

I'm looking, but the applications aren't working nicely for me, and the documentation is all tentative, so I probably won't find any information on standardized files.

 

[FusionGamer]

Well, we know BFSTM is the audio format for Mario Kart 8.

 

[Chadderz]

You won't be able to access the files on the game disks without a PPC Kernel exploit (or similar), because the Wii U's OS is set up to segregate the game form the browser, from the menu, etc. This means that although the game may be loaded in memory, the OS is smart enough to stop the browser accessing the disk, or indeed the game's memory, which means even though the files are in RAM, you cannot access them. MrBean35000vr and I have a PPC Kernel exploit, and he has successfully created a converter for the main audio format (BFSTM). We're planning to document all the file formats that we've found on an MK8 modding wiki similar to the MKWii modding wiki.

All that said I did notice something interesting. There is an area of the RAM (0xE0000000-0xE4000000) that is shared between all programs and appears to be used for communication with hardware devices such as the graphics card. I noticed that while the game is running, an RGBA32 copy of the screen buffer existed in this area (plus a separate copy for the gamepad). I also noticed that 16bit PCM audio data existed in this area, which when I decoded was the opening sound effects of MK8 (at 0xE2C00000). This is not the file format used on the disk, this is clearly the decoded data that is being sent to the audio interface and out to the speakers. I have no idea if this is always true, or if all the games sound is stored there, but I suspect so. If all you want to do is rip the audio, then this may be a good line of investigation.

 

[Relys]

You won't be able to access the files on the game disks without a PPC Kernel exploit (or similar), because the Wii U's OS is set up to segregate the game form the browser, from the menu, etc. This means that although the game may be loaded in memory, the OS is smart enough to stop the browser accessing the disk, or indeed the game's memory, which means even though the files are in RAM, you cannot access them. MrBean35000vr and I have a PPC Kernel exploit, and he has successfully created a converter for the main audio format (BFSTM). We're planning to document all the file formats that we've found on an MK8 modding wiki similar to the MKWii modding wiki.

All that said I did notice something interesting. There is an area of the RAM (0xE0000000-0xE4000000) that is shared between all programs and appears to be used for communication with hardware devices such as the graphics card. I noticed that while the game is running, an RGBA32 copy of the screen buffer existed in this area (plus a separate copy for the gamepad). I also noticed that 16bit PCM audio data existed in this area, which when I decoded was the opening sound effects of MK8 (at 0xE2C00000). This is not the file format used on the disk, this is clearly the decoded data that is being s

Awesome. What are the address ranges for the screen buffers? It would be great to write a simple little graphics lib.

 

[Chadderz]

Awesome. What are the address ranges for the screen buffers? It would be great to write a simple little graphics lib.

No idea, never actually figured it out I just rendered that whole area of RAM as RGBA32 and saw the images in amongst the data.

 

[Oxybelis]

I would prefer sound rips from files. Decoded stream could be used for gamepad and has some preprocessing (aka "surround" sound and normalization). Donkey Kong Country: Tropical Freeze rip must be done

 

[Bug_Checker_]

You won't be able to access the files on the game disks without a PPC Kernel exploit (or similar), because the Wii U's OS is set up to segregate the game form the browser, from the menu, etc. This means that although the game may be loaded in memory, the OS is smart enough to stop the browser accessing the disk, or indeed the game's memory, which means even though the files are in RAM, you cannot access them. MrBean35000vr and I have a PPC Kernel exploit, and he has successfully created a converter for the main audio format (BFSTM). We're planning to document all the file formats that we've found on an MK8 modding wiki similar to the MKWii modding wiki.

All that said I did notice something interesting. There is an area of the RAM (0xE0000000-0xE4000000) that is shared between all programs and appears to be used for communication with hardware devices such as the graphics card. I noticed that while the game is running, an RGBA32 copy of the screen buffer existed in this area (plus a separate copy for the gamepad). I also noticed that 16bit PCM audio data existed in this area, which when I decoded was the opening sound effects of MK8 (at 0xE2C00000). This is not the file format used on the disk, this is clearly the decoded data that is being sent to the audio interface and out to the speakers. I have no idea if this is always true, or if all the games sound is stored there, but I suspect so. If all you want to do is rip the audio, then this may be a good line of investigation.

Can you not just use something like _ProcessFixedId to elevate the browser's permissions?

 

[Chadderz]

Can you not just use something like _ProcessFixedId to elevate the browser's permissions?

I think if it were that simple everyone would've done that You need a Kernel exploit or similar to access the game's files or memory, there's really no way round that.

Also, I remember seeing a BFSAR (sound archive) file in the browser's files so it's possible to get hold of those for research purposes without needing an exploit.

 

[uyjulian]

All that said I did notice something interesting. There is an area of the RAM (0xE0000000-0xE4000000) that is shared between all programs and appears to be used for communication with hardware devices such as the graphics card. I noticed that while the game is running, an RGBA32 copy of the screen buffer existed in this area (plus a separate copy for the gamepad). I also noticed that 16bit PCM audio data existed in this area, which when I decoded was the opening sound effects of MK8 (at 0xE2C00000). This is not the file format used on the disk, this is clearly the decoded data that is being sent to the audio interface and out to the speakers. I have no idea if this is always true, or if all the games sound is stored there, but I suspect so. If all you want to do is rip the audio, then this may be a good line of investigation.

Data for what would usually be a black screen? (the loading between applications)

 

[JaapDaniels]

i've read on nu.nl (news site) that it's likely the usb ports will not be strongly secured... but it needs a hardware mod... the firmware of a usb drive was the key to tell the system for example it's a save keyboard while in fact it's executeing system code for an exploit at a point the system is reading just key inputs. is this tested/legit?

 

[loco365]

I think if it were that simple everyone would've done that You need a Kernel exploit or similar to access the game's files or memory, there's really no way round that.

Also, I remember seeing a BFSAR (sound archive) file in the browser's files so it's possible to get hold of those for research purposes without needing an exploit.

Well, I can tell you that I've found FSAR formats and FSEQ formats in a ram dump I was given anonymously. I presume they're the proprietary formats Nintendo use, so I'm going to document on their header formats and start working on either a branch of my 3DS application, or combine them all into one program and have separate tabs for the Wii U formats. I might just branch it off though.

Edit: Also found the FWAV format as well. Once I can find the filesize bytes, I'll begin working on the ripping of the files. I also found (What I think is) a WAV file stored in memory, but I'm not sure yet.

Edit 2: Yeah, it's a .wav file, however, the file is, for some odd reason, 0 bytes in size. Only the WAV header exists.

Edit 3: Does anyone have any clue with what the F stands for? I know that on the 3DS, everything had C (CWAV, CSEQ) and it meant CTR, and the Wii had R (RSTM) and it meant RVL, but I'm not sure what the F means at all.

Edit 4: File sizes are stored in Big Endian, I should be able to begin coding in the scanner to reflect this and get Wii U RAM file ripping working soon.

 

[Ben12066]

Is this a probably incomplete BFSAR like it was with 3D Land's BCSAR? (I know it's likely early, but you should be able to answer once the FWAVs are rippable I hope)