Hacking Wii U Hacking & Homebrew Discussion

  • Thread starter Thread starter filfat
  • Start date Start date
  • Views Views 5,120,667
  • Replies Replies 21,104
  • Likes Likes 29
Oh, no, it lets me play offline, but every freaking time I open ANYTHING, even boot up the menu, it tells me to update. SO ANNOYING. I may as well just delete all my internet connections at this rate :P


Ah, good. I was about to say...

So do things like YouTube and Netflix still work? (I can't get on my Wii U because I'm out of town).
 
About some weeks i had open a topic about update or not. And i choose not update. My WiiU remains 4.1. Nintendo is smart is closing the circle of updates. I question myself how many consoles was ben catch by the silent update and what will be the next step. Maybe a automatic wifi search and check? Well maybe i´m over reacting. But i still safe.
 
Oh, And also as a follow up to my comment/question/hint about GX2Invalidate():
Unless things have change with GX2SetDRCBuffer, it appears fail0verflow maybe have been on a debug unit (or things have changed) because the BufferingMode that is used in their example(I believe) is invalid on retail units.
BufferingMode =1 appears to only be valid on debug.
It appears you may need to use double or triple bufferingmode with GX2SetDRCBuffer.

looking at 1 of the gx2.py examples from earlier in the thread is
GX2SetDRCBuffer(self.startingaddress, self.inputlen, 1, 0x41A, 0)
is bufferingmode = 0 even valid?
 
Oh, And also as a follow up to my comment/question/hint about GX2Invalidate():
Unless things have change with GX2SetDRCBuffer, it appears fail0verflow maybe have been on a debug unit (or things have changed) because the BufferingMode that is used in their example(I believe) is invalid on retail units.
BufferingMode =1 appears to only be valid on debug.
It appears you may need to use double or triple bufferingmode with GX2SetDRCBuffer.

looking at 1 of the gx2.py examples from earlier in the thread is
GX2SetDRCBuffer(self.startingaddress, self.inputlen, 1, 0x41A, 0)
is bufferingmode = 0 even valid?

Uh. Go look at the list of buffering modes. 0 is single-buffered. 1 is double, 2 is triple. Assuming you wanna write one static image to screen, your buffer is single-buffered.
 
Uh. Go look at the list of buffering modes. 0 is single-buffered. 1 is double, 2 is triple. Assuming you wanna write one static image to screen, your buffer is single-buffered.

Are you absolutely sure about your numbering because I believe it to be different than yours?
I believe it to be:
0 = invalid
1 = single buffer and only valid for debug
2 = double buffer and valid for retail DRC
3 = triple buffer and invalid for retail DRC
4 = quad buffer
 
Are you absolutely sure about your numbering because I believe it to be different than yours?
I believe it to be:
0 = invalid
1 = single buffer and only valid for debug
2 = double buffer only valid for retail DRC
3 = triple buffer invalid for retail DRC

Derp yeah i was reading into things wrong. I don't think there's anything explicitly stopping single-buffered from working on retail, I think they just want developers to use modes that will reduce screen tearing.
 
well as for homebrew
game-over-man-game-over.jpg
 
well as for homebrew
No. Quit your memeing and check out literally this entire thread. Just b/c something got patched and some little kids can't stand to not be able to play online doesn't mean homebrew isn't actively being worked on literally right now.
/sass
 
It seems like i must update.... I want my free game and the code is about to expire. Plus my Sister wants to play online and my dad is forcing me to update.... well i might aswell forget a new tablet, becuase im going to need to buy another Wii U :/
 
WulfyStylez and Bug_Checker_, I got my GamePad to display some random flickering pixels in random areas by setting the buffer to the start of MEM1. Not what I had expected it to render, and probably useless since MEM1 is too small to hold even a DRC framebuffer in its free space, at least when used by the internet browser.

Code:
GX2SetDRCBuffer(0xF4000000, 854*480*4, 1, 0x41A, 1)

It seems like i must update.... I want my free game and the code is about to expire. Plus my Sister wants to play online and my dad is forcing me to update.... well i might aswell forget a new tablet, becuase im going to need to buy another Wii U :/

That sucks. :( But aren't you supposed to get the free game code on Monday?
 
Uh, I pointed it to the frames we found for the applications a few pages back, and managed to turn the gamepad screen slightly whiter, but only in certain spots (the left arrow and the door at the top right are the right color but the rest is whiter).
GX2SetDRCBuffer(0xE38C0000, 896*480*4*2, 1, 0x41A, 1). Then again, I didn't load up another program before switching, so it might be white normally.
 
Uh, I pointed it to the frames we found for the applications a few pages back, and managed to turn the gamepad screen slightly whiter, but only in certain spots (the left arrow and the door at the top right are the right color but the rest is whiter).
GX2SetDRCBuffer(0xE38C0000, 896*480*4*2, 1, 0x41A, 1). Then again, I didn't load up another program before switching, so it might be white normally.

Same thing happened to me when I tested pointing the buffer to random memory regions, but it seems to have effect when pointed to an area inside MEM1 (0xF4000000 - 0xF6000000).
 
I'm pretty sure f0f only worked on retail units.


Either way, in the latest SDK leak the exploits while made on debug, some of them seem to be able to be ported across. I think the browser exploit brings you up to roughly an average dev anyway in terms of memory access, you can't just do whatever you like on those units. In the SDK the files have been hacked on the PC along with the console files themselves (bit like that PSvita thing that was not that useful).

And there's a ton of extra stuff to be documented on there, nobody seems to have noticed for some reason that loads of new files are added/modified, there's at least 1 specific public new exploit detailed in there, as well as other things i don't quite understand yet and asking for people to help look at it properly (the exploit is related to mainly meta.xml's and the fact they are loaded so soon in the bootchain makes them able to actually, with some tricks, take over the Wii-U boot and therefore control over it all.

# sed
#
# Wrapper function for /usr/bin/sed. Needed because of a sed bug: when using
# some non-UTF-8 encoding formats (ex: Shift-JIS), executing on a file with
# multibyte characters, sed can hang. This function forces sed to use the UTF-8
# encoding format, then restores to previous format.

which helps with functions like this used by whoever the hackers were;

#Create a new version of $CAFE_META_DIR, this one with an edited meta.xml,
#Which will force the disabling of background daemons

There's loads of meta.xml's and even tools to deliberately flood the NAND or USB with them completely so theres nothing left to fall back on i presume? They seem to make a chain error reaction killing everything in normal memory and eventually rebuilding it.
 
  • Like
Reactions: youreed

Site & Scene News

Popular threads in this forum