Hacking Wii U Hacking & Homebrew Discussion

[the_randomizer]

Uh, it's not like we have no way to do a kernel exploit now. It was one idea that Relys and I were trying.

I stand corrected, my apologies.

 

[TheLoneWolfe]

Each button value is a power of 2, and the value given to you by VPADRead() is a bitwise-or of each present value, so you can use two bitmasks, one for each button.

Thanks, that helps a lot. I will return here with any further stupid questions.

 

[Bug_Checker_]

Thanks, that helps a lot. I will return here with any further stupid questions.

The only stupid question is the unasked one.

 

[Relys]

.

 

[WulfyStylez]

.

Is the DMA engine documented in the SDK? Or are you guys simultaneously trying to figure out both what it lets you do and if you can use it to exploit the kernel?
(also it's probably good i didn't reply till after you edited your post lolololol)

 

[Bug_Checker_]

Is the DMA engine documented in the SDK? Or are you guys simultaneously trying to figure out both what it lets you do and if you can use it to exploit the kernel?
(also it's probably good i didn't reply till after you edited your post lolololol)

I feel like I've missed out on something important. Ohhh that edit must have been telling. Otherwise it would have been left.

 

[Ryanrocks462]

Is the DMA engine documented in the SDK? Or are you guys simultaneously trying to figure out both what it lets you do and if you can use it to exploit the kernel?
(also it's probably good i didn't reply till after you edited your post lolololol)

it describes something about the kernel. do u want me to PM u a link to the sdk download?

 

[TheLoneWolfe]

.

Can the newly-leaked more-recent SDK shed any light on the matter?

Edit: I'm not being sarcastic, I actually did read your post pre-edit, lol.

 

[Relys]

heh, yeah someone mentioned to me it is probably a bad idea to be posting this on a public forum since Nintendo can read things and we wouldn't want it getting patched even if we just have theories right now lol.

 

[Bug_Checker_]

heh, yeah someone mentioned to me it is probably a bad idea to be posting this on a public forum since Nintendo can read things and we wouldn't want it getting patched even if we just have theories right now lol.

It's risky to release an exploit that you have in your hand when you do not have another to fall back on.
But it is even riskier to talk about an exploit that is yet to be working. Good catch.

 

[celcodioc]

Not sure if this has been documented anywhere, but it seems like the (4 as far as I can tell) framebuffers start just after 0xE0D3F9A0 and end about 0x2BA40E bytes after that (at ~0xE0FF9DAE). There is a bit of padding(?) between them. No exact values, if nobody else does it I can get them later.

Edit: Now that I think about it, maybe those are just saved frames for Miiverse screencaps etc.? I don't see why there would be more than 2 framebuffers, and on top of that one of the pairs doesn't even show the current frame.

I'm not a very good hacker though, lol...

 

[Relys]

Not sure if this has been documented anywhere, but it seems like the (4 as far as I can tell) framebuffers start just after 0xE0D3F9A0 and end about 0x2BA40E bytes after that (at ~0xE0FF9DAE). There is a bit of padding(?) between them. No exact values, if nobody else does it I can get them later.

Edit: Now that I think about it, maybe those are just saved frames for Miiverse screencaps etc.? I don't see why there would be more than 2 framebuffers, and on top of that one of the pairs doesn't even show the current frame.

I'm not a very good hacker though, lol...

Chadderz mentioned he saw them in that range, but you're the first one to look into narrowing down the addresses. You should try to find the exact values, and then overwrite the memory to see if it is the framebuffer the GPU uses (as opposed to your Miiverse screencap hypothesis).

I will try poking around when I get home later tonight. If it is the framebuffer the GPU uses, we can work on starting a simple little graphics lib to get an interactive menu going instead of printing out text with OSFatal.

Good work.

 

[WulfyStylez]

Not sure if this has been documented anywhere, but it seems like the (4 as far as I can tell) framebuffers start just after 0xE0D3F9A0 and end about 0x2BA40E bytes after that (at ~0xE0FF9DAE). There is a bit of padding(?) between them. No exact values, if nobody else does it I can get them later.

Edit: Now that I think about it, maybe those are just saved frames for Miiverse screencaps etc.? I don't see why there would be more than 2 framebuffers, and on top of that one of the pairs doesn't even show the current frame.

I'm not a very good hacker though, lol...

Two framebuffers are used for vsync. That's what "Double-buffered" and "Triple-buffered" vsync are, if you're a PC gamer. This is how it's been done since at least PSX days.

 

[Duo8]

So the update blocked the browser exploit?

 

[uyjulian]

So the update blocked the browser exploit?

correct

 

[celcodioc]

I was a bit off when I posted the addresses 'cause I forgot to multiply by 4. Anyway...

Image #1: 1280x720 RGB32 image, starts at 0xE3500000, ends at 0xE3884000 (length 0x384000).

Image #2: ?x? (can't get it to render properly with my guessed widths) RGB32 image, starts at 0xE38C0000, ends at 0xE3A63F58 (length 0x1A3F58). Same as #1 but smaller, probably gamepad.

Image #3: 1280x720 RGB32 image, starts at 0xE3A80000, ends at 0xE3884000 (length 0x384000).

Image #4: ?x? (again, not much luck figuring out the resolution) RGB32 image, starts at 0xE3E40000, ends at 0xE3FE3F58 (length 0x1A3F58). Same as #3 but smaller, probably gamepad.



Now, there are several reasons I don't think these are framebuffers. I'm a very novice hacker so this might sound dumb but:

a) This isn't double/triple buffering. #1/#2 and #3/#4 aren't even from the same app.
b) #3/#4 should show the current frame from the web browser (the exploit page), which they are not.
c) My Wii U is set to 1920x1080, and if I recall correctly SM3DW also renders at 1080p. Yet what I'm pretty sure are the TV images (#1 and #3) are 1280x720.


I haven't tried writing to those areas yet. I still think they're related to Miiverse though... I wish I could post modified pics there without getting banned if I was right

 

[Duo8]

IIRC SM3DW is 720p.

 

[celcodioc]

I didn't scanned the entire 0xE0000000 - 0xE4000000 area this time, but and Rayman Legends, which does output at 1080p, is also represented as a 720p image. http://i.imgur.com/LVktccB.jpg

Also, I'm having trouble writing to the memory. This is my first time with Python, and while I've been able to read and save RAM to my computer fairly easily, I'm pretty much stumped here. When I paste this into the interactive shell, the Wii U crashes to "Invalid RPC command" for some reason. I haven't modified rpc.py, it sends the right command byte (1).

import datetime
 
adr = 0xE3500000 #address
btw = 0x00384000 #bytes to write
curb = 0        #current byte
 
thefile = open("scrsht.bin", "rb") #raw rgba file
 
while btw - curb > 0:
    if btw - curb >= 500:
        numbytes = 500
    else:
        numbytes = btw - curb
   
    outdata = thefile.read(numbytes)
   
    while len(outdata) % 4:
        outdata += b"\x00" #4-byte alignment if needed for the last pack of bytes
   
    rpc.write32(adr + curb, struct.unpack(">{}I".format(numbytes // 4), outdata))
   
    curb += numbytes
   
    if curb % 100000 == 0:
        print(str(curb) + " / " + str(btw) + " (" + str(round(curb / btw * 10000) / 100) + "%)") #progress report
 
thefile.close()

 

[pelago]

Image #2: ?x? (can't get it to render properly with my guessed widths) RGB32 image, starts at 0xE38C0000, ends at 0xE3A63F58 (length 0x1A3F58). Same as #1 but smaller, probably gamepad.

GamePad resolution is 854x480.

 

[celcodioc]

GamePad resolution is 854x480.

I've tried that, and it's not the correct resolution.