My TV says the resolution of the input source when I hit "info". It doesn't say framerate or anything like that, but maybe you can check if your TV will at least tell you that much.How do I know what resolution each game supports?
My TV says the resolution of the input source when I hit "info". It doesn't say framerate or anything like that, but maybe you can check if your TV will at least tell you that much.How do I know what resolution each game supports?
But the Wii U outputs 720p as 1080p signal, doesn't it?My TV says the resolution of the input source when I hit "info". It doesn't say framerate or anything like that, but maybe you can check if your TV will at least tell you that much.
Yeah, the Wii U render games at custom resolutions (WATCH_DOGS runs at 648p, while Splatoon for example 720p).But the Wii U outputs 720p as 1080p signal, doesn't it?
i doubt there could even exist a tutorial since each games probably has the resolution in completely diferent places or even functions.Yeah, the Wii U render games at custom resolutions (WATCH_DOGS runs at 648p, while Splatoon for example 720p).
To know approximately what is the native resolution of a game, I try to get the closer I can to my TV and see the pixels, in 720p I can see it's more jagged than a 1080p one, I compared SSBFW and Scribblenauts and I know Scriblenauts approximately resolution is/is close to 720p.
For the frame rate is another story, you need to see if it runs smooth or you fell it choppy, there still no way to know exact frame rate and resolution, I hope someday someone makes a tutorial to know this and even change graphical settings...
BTW, in Scribblenauts Unmasked I found a graphic configuration ini (But it doesn't change resolution, it lets me to access debug or change the Anti-aliasing FXAA)
Nope, NWPlayer said that the resolution thing and frame rate is all in the .RPX .i doubt there could even exist a tutorial since each games probably has the resolution in completely diferent places or even functions.
@feyas You can use kern_write() if you don't want to change the mapping.
kern_read() and kern_write() force the kernel to read from and set the values at 32-bit pointers. They let you bypass kernel-only page protections, and write kernel data, but if you try to break other protections (like read-only) if will crash.
In the program i'm currently writing i need to patch some code which seems to be on physical memory location 0x8ee3ac88. But it seems the remapping of the kernel exploit doesn't go that far.
Has someone an idea how i could patch the location without actually changing the whole mapping? I want to keep it compatible with the different mappings that are already used....
@Marionumber1
I read the post about the OSDriver exploit and there you explained the kernel address table.
Wouldn't it be possible with this table to remap the actual memory area to RWX instead of remapping the memory area. Or isn't that possible for some reason?
Thanks for telling me this AFTER WEEKS where everyone already updated their Wii u to 5.3.2 to get spoofed 5.5.0 and eShop access again, gg, 10/10This is true? @MN1 @FIX94 @NWPlayer123 @Hykem
naehrwert @naehrwert 3h3 hours ago
If your Wii U is still on firmware version < 5.2.0 and you want 'easy' IOSU hax in the future: don't update.
https://twitter.com/naehrwert
Yes it is. It's a flaw that naehrwert is attempting to exploit. We've been discussing it for the past few hours.
Nonetheless, it's a IOSU userland flaw only at the moment. It should be more relevant if it's possible to attack the kernel with it.
The flaw itself was patched after 5.2.0, so, the general rule applies, if you're on a low firmware already, don't update.
It's not like information was withheld until that day.. They probably just discovered it that day and then told everyone as soon as possible. You made your decision weeks ago, so enjoy what you have and stop complaining. Hykem's goal is to port any exploit up to 5.5.0 anyways.Thanks for telling me this AFTER WEEKS where everyone already updated their Wii u to 5.3.2 to get spoofed 5.5.0 and eShop access again, gg, 10/10
Thanks for telling me this AFTER WEEKS where everyone already updated their Wii u to 5.3.2 to get spoofed 5.5.0 and eShop access again, gg, 10/10
@Hykem Do you see a firmware downgrade possible potentially with what you guys currently have ? or even with the help of the leaked SDK ?
Thanks for telling me this AFTER WEEKS where everyone already updated their Wii u to 5.3.2 to get spoofed 5.5.0 and eShop access again, gg, 10/10
@Hykem, is this flaw firmware dependent?
You think it will be released only for firmwares that have already a userspace/kexploit developed or it will be available also for firmwares where an userspace/kexploit is possible, but has not yet been developed (5.1.1 - 5.2.0)?
I'm asking this because I'm stuck on 5.2.0
The leaked SDK is not useful for hacking retail units. It's a good source of documentation for developers, but don't expect anything related to hacking to show up thanks to the official SDK.
Regarding a firmware downgrade, absolutely. Aside from running custom code at boot (which would require exploiting the earlier stages of the boot chain; boot0 and/or boot1) and turning your WiiU into a toaster, the IOSU kernel access level can pretty much accomplish anything you can imagine.
Instead of going into full on rage mode, you could have read my post a few pages ago.
TL;DR, you're not missing out anything.
Like I've mentioned before, this flaw in particular should only work on firmwares lower than 5.2.0. What I'm working on will work on any firmware version.
@soniczx123
Yes it is! You can find files for basically any VGM here!
Just use pyGecko or TCPGecko to insert them!