en-us https://www.intensedebate.com/users/4665944 Comments by fail0verflow http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment781255831 AFAIK it's mostly so they can run the homescreen and let people use the browser at the same time as games. They could allow developers to disable the browser and use more RAM, I guess. Wed, 8 Jan 2014 13:30:50 +0000 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment781255831 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment780139814 You're looking at it backwards. The PS2, the GC, the DS, and everything before them didn't *have* an OS you could use. They were also simple enough that bare metal software made sense. They also didn't have enough RAM or CPU oomph to make Linux usable, so people built bare-metal libraries for them. The Wii is the middle step. It got lucky, because we had libogc from the GC days, and it still didn't have enough RAM to run Linux comfortably, though popular homebrew based on Linux does exist. It also didn't really have an OS either, just a built-in launcher. The Wii U changes that. It uses bog standard hardware that *already* has Linux drivers. It has a truckload of RAM. And its native apps already use an OS that qualifies as a modern multitasking, protected memory OS. Running Linux on it will actually improve things (e.g. you get access to more RAM, since normally the system reserves half!) Think of Linux as a homebrew SDK, nothing more. Just one that happens to have APIs that make porting existing games and apps way easier than it ever has been on any other console. Nobody's suggesting that we throw Ubuntu on people's consoles, just that the Homebrew Channel for Wii U might as well run a Linux kernel behind the scenes. Homebrew developers don't *actually* want to learn yet another proprietary graphics API when they can just use OpenGL. Make it easier to write homebrew without needing to use specific skills and undocumented APIs, and you'll get better homebrew. Mon, 6 Jan 2014 12:09:17 +0000 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment780139814 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment779444539 The dynamic linking in Cafe OS makes writing homebrew easier since you don't need an SDK, but, for example, the Cafe OS NX enforcement would make a homebrew channel impossible (without a kernel exploit) since it wouldn't be able to boot other code. Personally, I think ignoring Cafe OS entirely and rolling our own Linux thing would be more productive, though higher initial effort. We haven't looked into non-browser exploits. There probably are quite a few around though, subject to possible entry points (i.e. things the Wii U will do with storage - which seem to be fewer than the Wii!). Sun, 5 Jan 2014 03:21:26 +0000 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment779444539 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment779432528 They can't fix the Espresso exploits, as those are in ROM code (and in hardware, for the HRESET hack). They probably could've avoided the SRESET race conditions (I won't detail how to avoid giving them any ideas, just in case they really think this is worth fixing), but they'd need to spin new silicon for that, which is extremely unlikely - they'll only do it if they're doing a new silicon revision for some other reason. Sun, 5 Jan 2014 02:49:20 +0000 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment779432528 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment779413828 1) Nintendo can fix all the bugs. Realistically, they never will, given the quality of the software. If the history of the Wii is any indication, we'll always be able to find new bugs. The cat is out of the bag (the software is accessible), so now all it takes is white-box reverse engineering, which makes it reasonably easy to find bugs. They don't have good mitigations; a bug in Cafe OS userspace, a bit of ROP (or not even that, for the browser), a kernel bug, an IOS bug, and you're in. 2) Meh, it was mostly an evolution of the Wii's. The Wii had a pretty decent (but simplistic) security design and a crappy/buggy implementation. The Wii U seems to be more of the same, though with some nonsense thrown in (the Espresso bootrom) and some obvious features added (verification on launch and hash trees for NAND titles). On the other hand, they finally have drive to console authentication, which was sorely needed (otherwise there would've been drive emulator piracy a month after the console's release). I suspect that bit was high priority for them. 3) Inkscape. Sun, 5 Jan 2014 01:57:00 +0000 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment779413828 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment779411652 Sure, but to do that you need keys which are different for each console, which means you need a full Wii U mode exploit running on every console (you can't just dump the keys once and use them on other consoles). Sun, 5 Jan 2014 01:51:09 +0000 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment779411652 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment779411420 Only for the System Menu and the NANDloaders. Sun, 5 Jan 2014 01:50:31 +0000 http://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#IDComment779411420 http://fail0verflow.com/blog/2013/espresso.html#IDComment640763449 Have you tried coding Wii homebrew (or most other console homebrew)? You get to deal with a buggy, incomplete, mostly undocumented set of libraries. It's fun from a hacker perspective (which is why I found the Wii interesting), but for actually developing apps? No, sorry - HBC, as polished and stable as it may look, has been a constant source of headaches and we've discovered (and fixed) dozens of framework bugs while developing it. Since there's no native GUI library, it evolved using a hacked up custom widged toolkit which is bizarre and confusing. The threading used for application uploading and loading triggered bugs in the libogc scheduler (which is a horrible turd). Memory management was a pain - I ended up having to write a custom MEM2 allocator to make it able to load large themes and apps, and whenever we had a buffer overflow bug, tracking it down was a horrid exercise in using gdb over usbgecko and staring at memory hex dumps, trying to guess what the garbage that had scribbled all over your data structure was (I ended up staring at -and reading!- hex dumps of grayscale font data until I figured out what set of circumstances broke the new font code). It's cool that we can do these things, and messing with and reverse engineering the system is fun, but as an application development platform? No, sorry, console homebrew SDKs are a joke compared to something like Android (or Linux + the usual libraries, or OSX, or Windows + DirectX), as much as you may dislike it. Console homebrew is a niche market with niche tools. OTOH, this is why, if there's interest, I still think the obvious direction for Wii U homebrew is to use Linux. At least then you'll get a mature set of development tools and a sane graphics API (OpenGL) plus all the usual libraries like libSDL. It'll still take a lot of effort to port, but at least it won't take as much effort to actually write apps once it's done. Now, you may argue that the Android ecosystem is more annoying for users, but there are plenty of free, ad-free, useful Android apps. It's just that, because it's a much more successful platform, and it has legitimacy that console homebrew doesn't have, they're buried under all of the ad-supported crap. On the other hand, I personally have absolutely *no* problem paying a couple bucks for a polished, functional Android app that doesn't go overboard requesting permissions. I want to support application authors like that. As for device locking, I've never bought an Android device that required an exploit. Oh, sure, there are plenty of locked devices out there, but there are many unlocked ones too. Pretty much all of the Chinese sticks come pre-rooted. All my portable Android devices are from the Nexus line with unlocked bootloaders. Ouya comes with an unlocked bootloader. Even on locked devices, the development effort is typically minimal compared to console homebrew: just find an exploit that lets you run code as root, throw /bin/su on there, and you're set. Yesterday I fixed the Japanese fonts on my phone and tablet by editing an .xml file - how is that not an open platform? As a hacker, I find reverse engineering security systems interesting, but when it comes to app development, I stick to what makes sense. The last two big application projects that I've worked on have been developed to run on Linux systems (though mostly portable to OSX). One of them is designed to run as set-top-box type appliance. Could I have used a Wii U? Sure, it's actually an almost ideal system from a hardware perspective - I needed a touchscreen remote. But I went with a hacked chromebox running Ubuntu and a <$100 chinese android tablet as a remote. The development effort required to get all of this to run smoothly on a Wii U (i.e. porting Linux including all of the reverse engineering required) would've been astronomical compared to the ~4000 lines of application code involved. Total price - $450 compared to $300 for a Wii U. Well worth the extra $150 for having an open system (nevermind that the Chromebox CPU is quite a bit faster). With a bit of effort it could be optimized to run on something cheaper like the Ouya. As I said, 31 people (many of them experienced homebrewers from the Wii community) have the info so far, yet nobody has started working on this. In order for homebrew to be successful on a console, there needs to be a critical mass of interested, experienced developers to bootstrap it. I don't see that critical mass being there for the Wii U. I don't care about whether piracy happens - if the WiiKeyU guys work it out, so be it, that's for Nintendo to deal with. I care whether it happens in association with my work. Honestly, most of the time I hear from random people using HBC, it's to run some warez launcher, and that's depressing. I don't want to end up in the situation where we have warez kiddies running pirated games using a Wii U mode exploit a year before a homebrew SDK finally becomes useful. Sun, 12 May 2013 16:18:49 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment640763449 http://fail0verflow.com/blog/2013/espresso.html#IDComment640715674 This is pretty much what we're doing here, isn't it? Sun, 12 May 2013 14:27:28 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment640715674 http://fail0verflow.com/blog/2013/espresso.html#IDComment639090424 There have been several exploits on e.g. the banner parser of the Wii System Menu. Attempting to integrate Wii channels into the Wii U menu would greatly increase the attack surface for Wii U mode. Doing it as a totally separate sandbox is kind of annoying for users, but from a security standpoint, it makes perfect sense. Fri, 10 May 2013 03:09:47 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment639090424 http://fail0verflow.com/blog/2013/espresso.html#IDComment639089599 The Espresso is a nice scalar CPU but it has primitive SIMD compared to the PS3 (SPUs) and the Xenon (the extended AltiVec). Games that make heavy use of CPU-based SIMD (e.g. physics, certain types of stream processing, etc) will plausibly have more trouble running at full speed on a WIi U than on a PS3/360. Fri, 10 May 2013 03:08:02 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment639089599 http://fail0verflow.com/blog/2013/espresso.html#IDComment639087324 Can you read? I think I stated pretty clearly that we DO have a Wii U mode exploit (we just aren't releasing it at this time). The pseudocode I posted is derived from the initialization code of Cafe OS. We have the decrypted binaries for the entire OS, which, by the way, includes most of the entire SDK since the SDK libraries are dynamically linked on the Wii U. I've checked. There is no clock switching. It's not a triple-core 750FX, it's a triple-core 750CL with a new L2/bus/coherency subsystem and a wider bus. The cores are laid out from scratch, but the core features up to the L1 caches are basically identical to the 750CL. You can speculate all you want about power consumption figures (which, by the way, Nintendo often overstates), but I've seen the software, I've seen how the PLL change to Wii mode is implemented, I've seen the SPR list of the Espresso, I've disassembled its boot ROM, I've poked HID1, and I haven't seen a single shred of evidence pointing towards any kind of clock switching going on. The Espresso that you get from the above hack is exactly the same as the WIi U mode espresso, except the bus config is different and the PLL is different, as those are determined via hardware strapping (controlled from the Starbuck). No other features are disabled because the entire CPU is reset and nothing has a chance to disable anything (the NANDloader is what normally would put it into 750CL compat mode). Please stop acting like I don't know what I'm talking about. Fri, 10 May 2013 03:03:12 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment639087324 http://fail0verflow.com/blog/2013/espresso.html#IDComment638344243 The 360's Xenos still has much better SIMD performance than the Espresso. Where it screws up is in scalar performance and branchy code, since it is in-order and has a deep pipeline - that's where the Wii U's otherwise old CPU design shines. While the Cortex-A9 probably isn't quite as beautiful at branchy scalar code as the venerable 750, it's still pretty decent and does have a clockspeed and extra core of advantage over the Espresso, so I do think it manages to beat it at scalar integer performance (and definitely beats it at SIMD - heck, the Espresso doesn't do integer SIMD at all, which is actually pretty critical for things like video decoding!) Thu, 9 May 2013 04:09:53 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment638344243 http://fail0verflow.com/blog/2013/espresso.html#IDComment638338110 Either is fine, though there's probably no point in discussing the coherency bug until someone writes the code to get the other cores spun up first :) And IRC is faster anyway. Thu, 9 May 2013 03:58:25 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment638338110 http://fail0verflow.com/blog/2013/espresso.html#IDComment638336836 1. No. It will never be possible to render Wii games in higher resolution, not even in Wii U mode. It's a different GPU and the Wii GPU does not have any free framebuffer memory for that. The GPU architectures are totally different. Short of emulating the WIi GPU in software on top of the Wii U GPU, it's not going to happen. 2. It's much easier to do this by using the Wii U gamepad together with a PC, which should be possible soon. It's almost certainly impossible to use the gamepad in vWii mode, although I'm not quite confident enough to claim it with 100% certainty. It would be possible in Wii U mode, of course. 3. see 2). For interesting things to happen in Wii U mode, someone has to write the frameworks, libraries, and drivers first. Regardless of whether we release the exploit, someone has to do that. If nobody does, then there's no point in releasing the exploit. The point isn't to completely avoid piracy in Wii U mode, it's to at least have a healthy homebrew ecosystem *before* the warezors manage to get what they want. What I definitely don't want to end up with is piracy after the first month with little to no homebrew development for years due to lack of interest. Thu, 9 May 2013 03:56:05 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment638336836 http://fail0verflow.com/blog/2013/espresso.html#IDComment638332942 There's a crucial difference between emulators/media players and warezloaders. You can play emulated games and watch media on any other platform, but you can't pirate Wii U games on anything but a Wii U. Not having homebrew isn't going to stop anyone who wants to pirate movies or retro games from doing so; however, not having a Wii U warezloader will. Nevermind that media players are used for legal media playback a vastly larger percentage of the time than warezloaders. Personally, I have nothing against emulators (as long as they don't come with some kind of sketchy ROM library) and I *definitely* don't have any problem with media players. Both enable things that _were not possible_ on the platform before, involve quite a bit of software engineering (dynamic recompilers and GPU-accelerated video decoding are cool), and are unlikely to get anyone in legal trouble. Warezloaders are boring pieces of software (really just patches) usually written by people with only barely enough of a clue to get the job done and whose sole purpose is essentially piracy. Furthermore, the main drive has always been (ever since the Xbox 1 and the GC) homebrew. Just because that homebrew may have ended up being used for piracy by a majority of people afterwards doesn't change the fact that the original development happened without piracy in mind. Go visit the list of homebrew software on Wiibrew sometime. Warezloaders are not allowed, and yet I see over 300 homebrew apps listed. Thu, 9 May 2013 03:48:50 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment638332942 http://fail0verflow.com/blog/2013/espresso.html#IDComment638320497 ... and on page 18, you'll see that the maximum clock speed for the 750CL is 900MHz. Just because the PLL can do 10x doesn't mean you can run it at 10x without lowering the bus clock first. The reason why you need two PLLs is for *clock switching*, because you can't change the configuration of a PLL while the CPU is running on it (you have to wait for it to lock). With one PLL you have to reset the entire PPC when switching clocks (which is what happens when you go into Wii mode). Nintendo have never been ones to push the envelope on clock speeds and run their parts maxed out. It's possible that the Espresso might be stable at, say, 1.5GHz, but Nintendo chose 1.24GHz and that's what we get. Sorry, but neither the Espresso nor Cafe OS can switch clocks at runtime. Please don't become that guy who pestered us for months claiming that the Wii had a secret Radeon HD GPU that nobody knew nothing about when all evidence was to the contrary, citing some dubious die area and process node calculations. Thu, 9 May 2013 03:25:55 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment638320497 http://fail0verflow.com/blog/2013/espresso.html#IDComment638315123 Power consumption changes don't mean they're switching clocks. The Espresso does not have dynamic frequency switching, but like every other CPU has had for years, it does have low-power halt states. They probably have one or two mostly idle cores while in the menu (heck, they may even put them into explicit full sleep mode - that much it probably does support). The GPU may have frequency switching or (more likely) some other kind of power saving states. Thu, 9 May 2013 03:16:19 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment638315123 http://fail0verflow.com/blog/2013/espresso.html#IDComment637414011 "PPC" doesn't have a software programmable clock, because PowerPC is an architecture, not a chip. Some PowerPC-compliant chips, like the PPC750FX, have two programmable PLLs and the ability to switch between them to implement clock switching. Some, like the PPC750CL (and the Broadway) only have one PLL and its configuration can only be changed at hard reset time (externally). Initially, we thought/hoped that the Espresso would borrow the 750FX's dual PLLs, but that turned out not to be the case. The CPU die shot also does not show two symmetrical PLLs. The HID1 bits that control the PLLs in the 750FX are not present in the Espresso. The Starbuck sets the bus frequency (the Latte's SYSPLL) and configures Espresso's multiplier (via configuration pins) and it's stuck there. The bus clock is ~248MHz (almost the same as the Wii, which used a ~243MHz system bus), but the processor bus is wider. In Wii U mode, the multiplier is 5, while in Wii mode it is 3 (and with SYSPLL set to ~243MHz instead of ~248MHz). The code that sets the Espresso clock multiplier pins in the Cafe2Wii compatibility bootstrap (C2W_SetEspressoPLLConfigGPIO, part of the Wii U mode Starbuck code) sets both a GPIO labeled "ESP10Workaround" and an unknown bit in another register. Unfortunately, toggling the former myself (which is possible in Wii mode) doesn't seem to cause the Espresso to come up with 5x multiplier, and the latter is locked and cannot be changed in Wii mode as far as I can tell (the locking mechanism is unknown, but it might just lock itself when that bit is flipped). Also, sorry, but a 750 at 2-2.5GHz is insane. You don't get to just stick an old microarchitecture into a newer process and triple the clockspeed. 729MHz to 1.24GHz is the kind of sensible clockspeed bump that we expected. I can guarantee that the Espresso isn't going to switch to a higher clockspeed while in Wii U mode; you guys need to just accept the fact that it runs at 1.24GHz already. Wed, 8 May 2013 02:08:51 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment637414011 http://fail0verflow.com/blog/2013/espresso.html#IDComment637353245 Yes, a 1.6GHz quad-core Cortex-A9 with NEON from ~2010 beats a 1.2GHz tri-core PowerPC 750 with paired singles from ~1997 or 2001 (depending on whether you count the PS or not). The PPC750 is a nice core and has lasted long (and beats crap like the Cell PPU and the 360's cores clock-per-clock on integer workloads), but sorry, contemporary mobile architectures have caught up, and the lack of modern SIMD is significant. Performance varies by workload, but I'm willing to bet that they're similar at integer workloads and the Cortex-A9 definitely has more SIMD oomph thanks to NEON. Wed, 8 May 2013 00:08:52 +0000 http://fail0verflow.com/blog/2013/espresso.html#IDComment637353245