We only need Matieluh (or how he is spelled) to make it more pathetic and disasterific.
Looks like you got your wish From mathieulh (who gets his info from the AU cracker xorloser aka CitizenX of Paradox that he trades SDK stuff for lmao! - via gbatemp.net/threads/super-mario-3d-world-usa-wiiu-powerup.366269/page-8#post-5004085):
"My guess is this wiikeyU uses a software exploit that is probably going around in private circles and that some of these "release groups" use to dump the game.
That's just a wild guess though
As far as I am concerned, I am just interested in getting rid of the stupid region lock so I can play Japanese games on my European unit."
Conclusion: Anyone clueless enough to donate to these dinks or blow money on an unnecessary hardware mods deserves to be left in the dark as to what really goes on behind the scenes.
To quote (via wiiubrew.org/wiki/Ancast_Image#Keys): Ancast images are encrypted and signed binaries for the Espresso processor to execute. The Espresso contains a secure Boot ROM that runs upon a PowerPC hard reset, which will only boot signed code.
This code comes in the form of an ancast image. Before resetting the Espresso, the currently running Starbuck code (either IOSU or vWii IOS) must load the ancast image to 0x1330000 for the Boot ROM to verify and decrypt. The Cafe OS kernel, vWii System Menu, and vWii NANDLoader are all in the form of ancast images.
Let’s look at the Espresso. Why a PPC750? Well, first of all, the Espresso has to be fully compatible with the Broadway to run Wii software. Several people have pointed out that many PowerPC cores are essentially fully backwards compatible for user software. However, Wii games run on the bare metal, without any OS. This means that the CPU needs to be 100% compatible at the system/OS level too, down to the smallest detail of the highly model-specific special-purpose registers.
Wii software regularly messes with registers such as HID0-HID4, which are Hardware-Implementation Dependent registers. Additionally, the PPC750 line is the only range of PowerPC processors that implement Paired Singles, an (outdated) SIMD implementation that was introduced with the Gekko on the GameCube and which is not compatible with modern PowerPC SIMD, such as AltiVec.
These processors also implement other GameCube/Wii-specific features, such as the Write-Gather Pipe (used to send commands to the GX) and the locked L1 cache and DMA that were discussed in the talk. On top of that, because the Espresso runs at the clock rate of the Wii in vWii mode (and no faster), instruction timings must be identical (or possibly better) in all cases, lest some Wii games run slower on vWii mode than on a real Wii.
Now, it is true that the Espresso implements some new features - most obviously, it is a multi-core, and thus SMP, system. I am not aware of any other SMP PPC750 implementation (although that is possible with vanilla PPC750 - https://www-01.ibm.com/chips/techlib...B72005C745C#10, but inefficient).
However, the Espresso was clearly commissioned by Nintendo specifically for the Wii U, and they had the freedom to make significant changes to the design. Most importantly, although the individual Espresso cores are almost identical to the standard PPC750CL core, the L2 cache subsystem and bus-interface subsystem have been significantly redesigned.
The design philosophy seems to have been to keep the 750 core as untouched as possible, but graft in support for efficient SMP around it. As a result, they’ve tacked MERSI support onto the cores and the new L2 subsystem fully supports cache coherency between cores (and cache intervention). Incidentally, the 60x bus seems to have been upgraded as well (they call it 60xe now, and judging by the die shots, it looks wider).
In fact, the SMPization of the 750 in the Espresso is not perfect. There appears to be a bug that affects load-exclusive and store-exclusive instructions (an explicit cache flush is required), which means that using SMP Linux with them will require patching the kernel and libpthread to work around it (and possibly other software that directly uses these instructions to e.g. implement atomics). They would’ve never shipped such a blatant bug on a general-purpose CPU, but I guess they called it good enough for a game console since they can just work around it in the SDK (which they do: the Cafe OS locking primitives have the workaround).
Since I mentioned MERSI and cache coherency, you may be wondering about the point in the talk where I said that the Wii U is not a cache-coherent system. In fact, the Espresso fully supports cache coherency, and there is coherency between cores. However, as far as I can tell, the Latte does not implement this, and memory is not coherent with regards to the Starbuck and other hardware peripherals when performing DMA (although I have not verified that there really is absolutely no support - but it’s at least certainly true of memory during bootrom execution, and since the Wii didn’t implement coherency either, it sounds like the kind of thing Nintendo wouldn’t care about).
Recently, an anonymous contributor e-mailed me what appears to be a screenshot of the introduction page of the Espresso User Manual, which seems to confirm most of what we had deduced. Please don’t ask where it came from; I was only sent the screenshot and the sender used an anonymous e-mail service.
Oh, and that whole out-of-order execution debate? The confusion arose due to the myth that the PPC750 is in-order. It’s a superscalar core: it does dispatch up to 3 instructions per cycle and they can complete independently (and the results are placed in a completion queue). That qualifies as out-of-order. It’s not particularly wide and definitely isn’t nearly as aggressively out-of-order as modern Intel and POWER cores are, though. The Espresso is just as out-of-order as the Broadway and previous members of the 750 family. There’s no upgrade there: it’s a (simple) out-of-order core and it always was.
Go read thePPC750CL User’s Manual (fail0verflow.com/media/files/ppc_750cl.pdf) if you want all the gory details (it also has information on the formerly-Nintendo-proprietary stuff like Paired Singles, DMA, Locked L1, Write-Gather Pipe, etc.).
From last year's CCC convention: Console Hacking 2013 - WiiU
About a year ago Nintendo released their latest video gaming console, the Wii U. Since 2006, the Wii has led to one of the most active homebrew scenes after its security system was completely bypassed. This talk will discuss the improvements made in Wii U's architecture and explain how it was broken in less than 31 days. The talk is targeted at those who hack (or design) embedded system security, but gamers might also find it interesting.
The talk will consist of several parts. First, we will discuss the Wii U: what it is, what makes it tick, and how it compares to its predecessor, the Wii.
Next, we will cover two different approaches that we used to attack the Wii U system. The focus will be on how our results were achieved instead of on what those results are, so you can reproduce the attacks at home. Along the way we'll describe the Wii U's security architecture.
The third and final part of the talk will cover where to go from here: What is broken, what is yet to be broken, things that still have to be done to create a viable homebrew ecosystem, the balance between the effort required and the reward for users and hackers, and the potential upsides and downsides of different approaches.
Basic knowledge of embedded systems and CPU architectures is recommended for attendees, although we will try to explain required concepts as we go along. Before and after the talk we will also be available in the hackcenter for those who would like to discuss further details or embedded security in general.
Speaker: sven marcan Nicholas Allegra (comex)
Event: 30th Chaos Communication Congress [30c3] by the Chaos Computer Club [CCC]
Location: Congress Centrum Hamburg (CCH); Am Dammtor; Marseiller StraBe; 20355 Hamburg; Germany
Begin: Fri, 12/27/2013 20:30:00 +01:00
From nevik: From my understanding the Ancast Image is the WiiU bootrom and there is a package out there to dump it. Here are a few links that may help explain what is happening.
(feel free to correct me I am not a 100% sure about this it is just what I have gathered from some reading)
[Leaked] Method For Dumping BootROM/boot0.bin/OTP Key for Wii U
[Leaked] Method For Dumping BootROM/boot0.bin/OTP Key for Wii U by BobbyBangin
This is the exploit/method to get the Espresso Wii U/vWii Ancast keys from the Wii U. This method was leaked.
A few people have asked why PS3 Hax was so heavily involved in the Wii U hacking scene. The reason is that the work has been continued by a dedicated PS3 hacker (at this point should just be known as hacker extraordinaire), who wishes to remain anonymous.
He hasn't asked for a thing and would only like 1) to see the scene prosper and 2) because he was bored. We should all be thankful for his work, because without it, we wouldn't be this far. The same debt of gratitude goes to Maxternal and f0f for their thankless contributions.
Apply the gbadev.diff to it, in order to make it dump the OTP's.
You will need an SD card. It will write a file to the SD card named otp_ppc.bin, boot0.bin and bootrom.bin.
The exploit works using SRESET. As fail0verflow stated, they enable SRESET at the end of bootrom execution, after it invalidates the L2 cache and reenables it and before the bootrom is disabled.
The SRESET trick should be done at the begining of the bootrom execution, just after it enables the L2 cache and before it overwrites the reset interrupt vector. And it works! We run before bootrom is executed and before the OTP is disabled. Voila!
From credair: People go apeshit about the smallest things as usual.
The vWii ancast key is useless all the things it can decrypt you already could decrypt by loading them into memory and letting the PPC decrypt them for you and then just dump the memory.
The Wii U ancast key is useless until you also have the Wii U common key BUT even then all you could do is decrypt stuff it doesn't magically give you any exploits, though it will certainly make it easier to find them since you can look at the code that is running.
While this is certainly a great achievement from a hacking point of view this doesn't mean much for the common user. So no piracy or homebrew will happen due this anytime soon.
Also from what've seen so far a Homebrew only hack might actually happen this time.
Finally, from zecoxao: I'm going to take a gamble here but...
Finally the secret 'Wii U Browser Exploit' is now out in the wild for everyone to enjoy on their Nintendo Wii U Console, if you lucky enough to still be at v4.10 firmware.
There been a lot of action in the Wii U scene recently, and now the exploit that allows you to do various things, one of them being able to dump key information has been leaked that works on the webkit-based Wii U browser for those still lucky enough on v4.10 firmware.
This exploit has been partly blocked on the recently released v5.10 firmware by Nintendo, but with little exploring it should be possible to find the new vectors to get in.
There is also rumors that this exploit might even work on the PS Vita or PS4 as they used a similar setup, all tho on the Wii U team fail0verflow mentioned before this is only possible because the NX protection bit is disabled on the Wii U browser system setup.
From BobbyBangin: I was offered the Wii U Web Browser Exploit to leak. I chose not to. Now somebody else has leaked it. The exploit only works for those on firmware 4.1.0.
As we knew before, the exploit was partially blocked in update 5.10. Devs remain confident that they can find alternate access to the exploit in current and future updates, while others think there's a chance it might be patched. Either way, this is a huge release. This is only a partial exploit.