No offense, but that's a really stupid idea. Once there is a Wii U exploit, we can use the official SDK legally. It's possible since it's just there on the filesystem, with full symbols visible.
No offense, but that's a really stupid idea. Once there is a Wii U exploit, we can use the official SDK legally. It's possible since it's just there on the filesystem, with full symbols visible.
I'm impressed on how Marionumber1's statement regarding the SDK being actually inside the Wii U's filesystem seems to be consistently ignored...
This release is mostly a "we're touching the tip of the iceberg" thing. An official SDK leak, specially an old one, means very little to developers or hackers.
This release is mostly a "we're touching the tip of the iceberg" thing. An official SDK leak, specially an old one, means very little to developers or hackers.
Yes, it's perfectly legal. You would need to produce an ELF file (slightly modified, since the Wii U's ELF format is non-standard) that dynamically links with the SDK libraries, and of course, find a way to run it on your Wii U.
Oh, external use of its libraries, that's for sure a legal use.
And what happen if Nintendo delete the SDK with an update?
Would it be available in their servers to download and install it, would that be legal?
Or is used by all the software on the WiiU?
Is it like the resources of a S.O. then?
And what happen if Nintendo delete the SDK with an update?
Would it be available in their servers to download and install it, would that be legal?
Or is used by all the software on the WiiU?
Is it like the resources of a S.O. then?
It basically works like .dlls on the PC.
The OS loads them to memory when your program is loaded and you can simply call all functions.
To create an SDK you would basically just have to create all the header files.
The OS loads them to memory when your program is loaded and you can simply call all functions.
To create an SDK you would basically just have to create all the header files.
The SDK is used by all Wii U software, including disc-based games and applications, so deleting the SDK would make all of those no longer work. It is possible to get the SDK off Nintendo's update server, but it's encrypted (and there's no way to decrypt it without the common key).
Sorry, but if someone has the SDK, creates all the needed links,make everything he want doesn't it need to get some nintendo's signature to run on a legacy wii U ?
That is very interesting, the legal use of the Nintendo's SDK will be pretty sure a great boost for the Hombrew in the WiiU. Thanks guys for your explanations.
---------------------------------------------------------------------
---------------------------------------------------------------------
Run unsigned code in the WiiU need a exploit in the first place.
Well, if the SDK is for a game dev purpose, there would be nothing related to the native OS...
You wand to run games, you're only in an applicative matters... Basis of IOS won't be delivered there...
If you hacked it you will be stuck in the OS...
The Wii was created on the barre metal, the Wii U as some OS to catch errors...
But maybe if you are able to create you own OS to flush the Wii U one and manage the disable bit and go through all securities... Well may append in the future...
I think you will need some rop to get it work... Remember the 3ds ...
You wand to run games, you're only in an applicative matters... Basis of IOS won't be delivered there...
If you hacked it you will be stuck in the OS...
The Wii was created on the barre metal, the Wii U as some OS to catch errors...
But maybe if you are able to create you own OS to flush the Wii U one and manage the disable bit and go through all securities... Well may append in the future...
I think you will need some rop to get it work... Remember the 3ds ...
The Wii U actually runs two operating systems: it still runs IOS on the ARM CPU like it did on the Wii, but now there's also an OS running on the PowerPC called Cafe OS. The SDK is an interface that lets game developers access resources, like graphics, sound, controller input, and filesystems. Cafe OS sits between the games and the hardware, giving the games access to these resources. It may delegate some of that work to IOS as well.
What this means is that there are 3 levels to exploit on the Wii U: userspace, Cafe OS kernel, and IOS. Userspace exploits are the very first step, and can likely only be done through the browser. A browser exploit would require ROP, like on the 3DS, since Cafe OS enforces non-executable memory. Once you have code running in userspace, you get access to the Cafe OS SDK. This is pretty much all you need for homebrew. However, in userspace, you're just another consumer of Cafe OS, like all other Wii U applications. With a Cafe OS exploit, you could get direct access to most of the system. As you mentioned, you could also replace Cafe OS with something else (like Linux, which was fail0verflow's plan). But even with control over Cafe OS, some hardware is still managed by IOS, so to completely own the system, IOS needs to be exploited as well.
Technically, there are actually 4 levels, since IOS is a microkernel and runs most drivers in userspace on the ARM. Meaning that even if you exploited a specific device driver in IOS, you'd only get the privileges of the driver and would still need to exploit the IOS kernel.
Well not only the OS, it's the processor himself who won't allow to run stuff it's some kind of AHBPROT (2nd level but harder to break) that requires the ROP to break...
I thought my suggestion on the webkit some month ago felt in a hole
If you get access to IOS there still will be a game verifications !?
Well not only the OS, it's the processor himself who won't allow to run stuff it's some kind of AHBPROT (2nd level but harder to break) that requires the ROP to break...
I thought my suggestion on the webkit some month ago felt in a hole
AHBPROT is simply what prevents the PowerPC from accessing peripherals on the Hollywood/Latte that the ARM normally gets exclusive access to. It doesn't prevent unsigned code from running. A vulnerability in WebKit will still give us userspace code execution on the PowerPC. However, we need to use ROP in order to run a WebKit exploit because Cafe OS marks all data memory (which we would control from Javascript) as non-executable. As for the WebKit idea, it was used by fail0verflow back in 2012 and I'm currently attempting to do something similar...
If by game verifications, you mean checking the game's signature, then it is possible to bypass them if you get code running in the IOS kernel. Of course, these hacks would only exist in memory (since no part of the Wii U's security system can be modified) and would be lost upon system shutdown/reset.
That's why I said "some kind of" I know it's on a different layer !
No I thought there was some cheched from te game on "who" called "him" If He checked the signature of "his' caller...
My point is that you seemed to say AHBPROT prevented unsigned code, which is untrue.
IOS will refuse to boot any code that is unsigned.
- Joined
- Nov 26, 2012
- Messages
- 2,568
- Trophies
- 2
- Location
- United States
- Website
- sites.google.com
- XP
- 3,895
- Country
So basically the SDK is just to run natively on the development hardware, and if you want to use retail Wii U, you must use the APIs provided by Cafe OS/IOS? No SDK required (all you would need are API names)?
I hope API names don't result in ... (google vs oracle)
Anyway... if you want native access to the hardware, without Cafe OS (like Wii and Gamecube), you would need an SDK (or something that interfaces with your program/hardware) (libogc), and disable AHBPROT/whatever protection there is, correct?
I hope API names don't result in ... (google vs oracle)
Anyway... if you want native access to the hardware, without Cafe OS (like Wii and Gamecube), you would need an SDK (or something that interfaces with your program/hardware) (libogc), and disable AHBPROT/whatever protection there is, correct?
The APIs provided by Cafe OS are exposed to games as the SDK. The SDK literally is just a set of libraries that makes calls to Cafe OS to manage the hardware. You have the Cafe OS kernel running in privileged mode on the PowerPC, the SDK to communicate with the Cafe OS kernel, and games running in user mode on the PowerPC that talk to Cafe OS through the SDK. Cafe OS itself delegates some hardware access to IOS. If you wanted direct access to the hardware, you'd need a way to run code on the PowerPC in privileged mode and a way to disable AHBPROT, as you said.
Similar threads
-
- Article
-
-
@
Psionic Roshambo:
It's great if you have something anyone else wants, otherwise it's annoying and potentially bad if you lose your keys -
-
-
@
SylverReZ:
@Xdqwerty, Its good if you have any important documents for say a business that you don't want leaking in the wild.+1 -
-
-
@
SylverReZ:
Bad news is that BitLocker was cracked, so somebody could use a Pi Pico and probe the LPC pads on the motherboard to grab the key.+1
-
-
-
-
-
-
-
@
BigOnYa:
My wife's doctor prescribed her a ointment for neck and knee pain, that cost $30. We just read the ingredients, and active ingredient is CBD, found exact ingredients in another off brand ointment online, for only $8. Our healthcare system at its finest. -
-
@
Psionic Roshambo:
I always suggest kneepads with wheels to help with knee pain, then I get slapped
-
-
-
-
-
-
-
-
@ HiradeGirl:
https://www.youtube.com/watch?v=ntjkwIXWtrc&ab_channel=Apple
I feel uncomfortable from watching this.
@
HiradeGirl:
https://www.youtube.com/watch?v=ntjkwIXWtrc&ab_channel=Apple
I feel uncomfortable from watching...