Hacking Wii U audio dumping research thread

[WulfyStylez]

So, I've set up the RPC client and whatnot, and am working on software RAM dumping within the shared area between devices (0xE0000000 to 0xE4000000), although at least it's a start, but I'm not having the success that I was hoping for. It only dumps around 0x7AA bytes (1962 bytes, or 0.00187110900878906 MB) of data out of the almost 16MB that the dumps actually create. I'm not sure what's going on there, but I hope to rectify it soon.

(All of that was mentioned in this post)

We're not sure how much of that area actually has information you'd find useful, to be fair. AFAIK, the only useful data there might just be the screenshots the browser uses. At the same time, you should be able to dump the browser's data and get some sorta audio from that. Browser data sits at 0x10000000 and goes to about 0x27800000ish.

 

[loco365]

We're not sure how much of that area actually has information you'd find useful, to be fair. AFAIK, the only useful data there might just be the screenshots the browser uses. At the same time, you should be able to dump the browser's data and get some sorta audio from that. Browser data sits at 0x10000000 and goes to about 0x27800000ish.

Well, I have a question then. Within the scope of this current exploit, and given what we have now, what memory ranges can I access? I'll try dumping all that I can and analyse it for the time being.

 

[WulfyStylez]

Well, I have a question then. Within the scope of this current exploit, and given what we have now, what memory ranges can I access? I'll try dumping all that I can and analyse it for the time being.

Within the scope of stuff that could have media stored in it, or the entire range of nitty gritty including boring system stuff?

 

[loco365]

Within the scope of stuff that could have media stored in it, or the entire range of nitty gritty including boring system stuff?

Let's go all-out and say nitty-gritty including boring system stuff. Might as well.

 

[WulfyStylez]

Let's go all-out and say nitty-gritty including boring system stuff. Might as well.

First of all, this image is actually surprisingly accurate:

Marionumber1 gave me most of this info, but here we go: somewhere low in memory (not sure, mn1 said 0x01000000 but I wasn't sure if I was finding them here), you can find the RPL loader and some system libraries (coreinit, gx2, vpad rpls). The 0x2000000-byte long JIT area for the browser sits at 0x01800000.
After that (0x02000000) sit private RPLs, such as the browser's webkit library. As I said before, the browser goes from 0x10000000 to about 0x27800000. That's where all the resources you'd want from the browser probably are.
What I mention beyond here needs OSWriteLog() to read. Right at 0xF6000000 sits the only RPL I've been able to dump so far, called nsyshid.rpl. The locked L1 cache sits at 0xFFE40CD0, I'm pretty sure from playing around with it.
Finally, 0xFFEE0000-0xFFF20000 is the range of the kernel's data (NOT the code).
Once again, thanks to MN1 for most of what I just paraphrased.

I'm not sure if graphics memory is protected beyond what OSConsoleWrite() can read. I haven't tested. It's kinda likely.

 

[loco365]

Well, I'll be sure to look at it. In the meantime, I took my old command that I used, and made one minor addition to it to dump what I think is the proper amount of data:

rpc.dump_img(0xE0000000, 0x4000000, "TestDump-WWHD-01.bin")

Now it should dump the correct range I'm looking for. It's roughly 14% done dumping, so it's going to be a while. Once it's done, I'll scan it and post what I find. That is, if there's anything more than a ton of 00s.

 

[uyjulian]

~~Snip~~!

Newer version of image...

 

[WulfyStylez]

Newer version of image...

They're probably both accurate, but neat thanks. Hadn't found this one yet.

 

[iNFiNiTY]

Isn't there enough tools in the SDK that info is from to just take the music out of the wumad... get it in the pure bcpcm or however they call it. Do master2part, then unpackfile? Don't need to pull out of ram. I was going to try and have a look at MK8 if it wasn't 50GB and didn't like me partially trying to do it. Maybe extract file too, all in the /bin/tool/mastering dir, if its compressed and in the wumad format. Btw nice job jumping the rpl still; right on the system limitation? handles usb devices, never know if these things could be useful. PS3 had an issue with it only took uh 6 years or something for someone to find it.

For the guy interested in 3D modelling there seemed to be a basic view you could have a play around with called Spark in the SDK, /system/bin/

 

[WulfyStylez]

Isn't there enough tools in the SDK that info is from to just take the music out of the wumad... get it in the pure bcpcm or however they call it. Do master2part, then unpackfile? Don't need to pull out of ram. I was going to try and have a look at MK8 if it wasn't 50GB and didn't like me partially trying to do it. Maybe extract file too, all in the /bin/tool/mastering dir, if its compressed and in the wumad format. Btw nice job jumping the rpl still; right on the system limitation? handles usb devices, never know if these things could be useful. PS3 had an issue with it only took uh 6 years or something for someone to find it.

For the guy interested in 3D modelling there seemed to be a basic view you could have a play around with called Spark in the SDK, /system/bin/

The SDK isn't legal. Also how do you propose you access MK8's data?

 

[loco365]

So, my dump finished, but my Wii U crashed in the process somehow. Not sure what caused it. Anyways, in the (what seems to be a partial) dump, I did not find any formats, so I'm going to see what exactly I can dump using the documentation above, combined with the knowledge that I'm locked to within the browser's range for now, and try dumping the entire area that I can access.

 

[WulfyStylez]

So, my dump finished, but my Wii U crashed in the process somehow. Not sure what caused it. Anyways, in the (what seems to be a partial) dump, I did not find any formats, so I'm going to see what exactly I can dump using the documentation above, combined with the knowledge that I'm locked to within the browser's range for now, and try dumping the entire area that I can access.

I wonder how far yours got... anyways I'm dumping the whole of 0x010 to 0x278 to see if there are any potentially crashy addresses in there. I'll tell you if I see any headers for your formats in there.

 

[Ryanrocks462]

Isn't there enough tools in the SDK that info is from to just take the music out of the wumad... get it in the pure bcpcm or however they call it. Do master2part, then unpackfile? Don't need to pull out of ram. I was going to try and have a look at MK8 if it wasn't 50GB and didn't like me partially trying to do it. Maybe extract file too, all in the /bin/tool/mastering dir, if its compressed and in the wumad format. Btw nice job jumping the rpl still; right on the system limitation? handles usb devices, never know if these things could be useful. PS3 had an issue with it only took uh 6 years or something for someone to find it.

For the guy interested in 3D modelling there seemed to be a basic view you could have a play around with called Spark in the SDK, /system/bin/

yes it seems it would be a lot easier to master2part and unpack the file from the sdk. /System/bin/tool/mastering

 

[WulfyStylez]

yes it seems it would be a lot easier to master2part and unpack the file from the sdk. /System/bin/tool/mastering

Once again, better to do stuff cleanroom if at all possible.

Also I had a crash at 0x03800000ish, did you get past there?

 

[iNFiNiTY]

The SDK isn't legal. Also how do you propose you access MK8's data?

Why are you concerned about that, what legal use do you have for the files? This is gbatemp there's ads for flashcarts, the sponsors, sure if you want to do it for fun and learning ok but you seem to want the files. So just go ahead, people use them every console. It's not your fault Marcan and whoever else decided a homebrew SDK would not be worth doing. I'm sure you'll get crashes but at least use some of the legal docs in there to hel, although the guy worked for Nintendo i don't know if all of his work is by default property of Nintendo.

 

[celcodioc]

So, my dump finished, but my Wii U crashed in the process somehow. Not sure what caused it. Anyways, in the (what seems to be a partial) dump, I did not find any formats, so I'm going to see what exactly I can dump using the documentation above, combined with the knowledge that I'm locked to within the browser's range for now, and try dumping the entire area that I can access.

There's a PCM starting at 0xE2C00000. I've dumped some parts of in-game music (edit: game/app startup music) from there.

 

[Marionumber1]

Finally, 0xFFEE0000-0xFFF20000 is the range of the kernel's data (NOT the code).

There's a small mistake here. Kernel data is all throughout the 0xFFExxxxx range until 0xFFEE0000. 0xFFEE0000-0xFFF20000 is the location of the kernel's code.

 

[loco365]

Once again, better to do stuff cleanroom if at all possible.

Also I had a crash at 0x03800000ish, did you get past there?

I went from 0xE0000000 to 0xE4000000, so no.

celcodioc I didn't get anything there, but I'll try dumping from that area on with a game running one more time. I'm quite sure WWHD uses streams, but idk why nothing dumped there.

 

[starerik]

I haven't played TWWHD, but when I've seen gameplay of it it sounded like the cutscene music (which was streamed) is exactly the same as the original. But I do believe the in-game music are the same MIDI files but with new sample sets. Don't take my word for it, though. It's just, from what I've heard the music still sounds sequenced.

 

[loco365]

Alright, so I attempted another dump, however, there's a problem. Using NWPlayer123's code (See this post), it can dump, from time to time. However, the Wii U crashes are caused for some unknown reason. As soon as the "dumping" finished (It made a 0-byte sized BIN file), the Python console spit out this:

Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    rpc.dump_img(0xE2C00000, 0x1400000, "TestDump-WWHD-02-Move.bin")
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host
>>> rpc.exit()
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    rpc.exit()
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host

The first one with the img_dump, that occurred just after finishing the dump and hitting 100%. All in all, nothing was actually dumped for some odd reason. rpc.exit() just fails because the Wii U has crashed by this point and has become completely unresponsive.