You're confusing homebrew with warez. Homebrew usually works pretty well, and HBC has a near zero chance of bricking your console. Applicaions vary in functionality and robustness, but they're safe since they're just applications that won't modify your console.
Loaders, on the other hand, besides typically illegal (they like to ship around chunks of IOS), are very dodgy and unreliable. System modification is required to install loaders, so it's an inherently risky activity. About 50% of the reports of permanent bricks I get from people are due to using Waninkoko's stuff. Stay far away, he never learned what that 'int' thing before function prototypes is for.
They just reauthorize those games online on your new console (via the serial numbers). When the system is totally bricked you lose your saves. They only notice homebrew or warez when they get "bricked" consoles that display an error message (which indicates System Menu operation), which they can usually fix by reinstalling stuff with their rescue mode DVDs and a small "flag" tool inserted into a memory card slot to put the menu into recovery mode.
I don't know about their hardware engineers, but my opinion of their software engineers has been steadily decreasing. Call me a dickhead if they want, but they fail at almost everything they do as far as system programming. Their system architecture is archaic and they've locked themselves out of many of the features and improvements that their compatitors are able to add. They tried twice to stop a certain savegame exploit and failed disastrously - yes, there were critical bugs in the anti-exploti code, as small as it is. I've disassembled a lot of their code and the list of WTFs would span hundreds of pages. Their "secure" IOS security is dismal. They implemented a homebrew crypto layer and completely screwed up the very core of RSA verification, resulting in the very first exploit to run homebrew. They appear to have never heard of things called "code reviews". They're using a scheme of forking IOS for each minor addition that makes it very difficult to maintain security fixes in the future, nevermind that older games will never get new features or improvements. Then there's the hugely botched boot2 update that this article is all about, and which they clearly didn't test well enough (I mean, come on, we can find it with a handful of Wiis and some minor testing and they can't?). They have to resort to stupid hacks like copying SD channels to NAND to play them because they never even attempted to develop an even slightly sane storage layer for IOS - access to everything goes through different APIs. The division of functionality between ARM and PPC code is chaotic: the USB stack is in IOS, the Bluetooth USB device driver is in the PPC but the Keyboard/mouse drivers are in IOS, the Bluetooth stack is in the PPC while the TCP/IP stack is in IOS, half of the SD driver is in IOS and the other half in the PPC, the NAND filesystem driver is in IOS but the FAT filesystem driver for SD is in the PPC, etc. The WiFi drivers are notoriously unreliable (Broadcom is probably to blame for that). They left in DVD-Video mode code and functionality that is what enables softmods - and when we tried to report it to them them before Wii piracy via homebrew existed, they harassed us and refused to let us speak with an engineer! Softmods, predictably, came later, when other people discovered that code.
As for their hardware engineers, they at least have horrible power management inside the Hollywood to blame for the WC24 heat issues causing GPU failures. The software guys also helped, though, by making IOS have a busy-wait idle thread. IOS uses 100% of the Starlet CPU during idle mode, while the fans are off and the system is slowly getting cooked.
Again, feel free to look for a flashing mechanism too, but our experiences and attempts, evidence from people who send in their Wiis for repair, and our generally bad opinion of Nintendo's engineers all point towards there not being one.
I didn't use a single tag in that post. I'm not sure what you're talking about. I think you're confusing a bad Slashdot/D2 vs. Safari interaction with people messing with fonts.
I'd test it but my iPhone's screen is currently cracked.
And what you're trying to say is...? Do you see a socket anywhere? I don't know about you, but we've never seen a repaired Wii with obvious signs of SMT reworking. Using a chip clip to program in-system is problematic and deinitely not the way the system was designed; see above reply.
Their system doesn't appear to be designed to accept external driving of the flash. The Hollywood boots and tries to talk to it as soon as you power it on. External NAND flashers need to overdrive the Wii's outputs very hard to properly do their jobs. As far as we can tell, the control outputs to the NAND Flash do not have tristate capability (they always drive hard high or low, even when the system is uninitialized or idle). The NAND power rail is also the 3.3V Hollywood power rail, so it is impossible to power the NAND Flash without powering up the Hollywood.
USB loading or any kind of "backup loading" is not supported by the Wiibrew community because 90% of its users are massive pirates. If you want to legitimately use games you own from USB, you're on your own. Fair warning: most of the software involved is crappy, unstable, and/or dangerous.
For what it's worth, I've yet to hear any report of a Wii being bricked by the HackMii installer (or any other prior versions, including the old standalone Homebrew Channel installer). So far, as far as we know, 100% of the Wiis bricked via "homebrew" have in fact been bricked via either dodgy piracy tools (the people behind them seem to go for insta-releasing to become famous, instead of actually doing that old thing called QA and Testing and doing things like checking error codes) or by people doing stupid silly things like modding their System Menu.
FWIW, 4.2 is reported to completely kill modchip region-free functionality. If they've done what I think they've done (started to check the region on the TMD, which is cryptographically signed), region-free via modchip is dead and won't be coming back.
Oh, it's going to work fine for [b]most[/b] people, but the bricking rate is still going to be much higher than normal. The boot2 flashing code isn't completely borked (I've successfully used it to flash early versions of BootMii 10-20 times), but the fact of the matter is sometimes it'll botch. I'd expect a sizable number of bricks, much higher than for "normal" system updates.
If Nintendo aren't idiots, they'll ditch the idea of putting boot2v4 on discs. They can still throw the rest of the 4.2 update on them with no ill consequences to unmodified consoles.
Because they fail at securing internet protocols. At this stage they probably just can't do anything for older games. Remember, their software architecture does not allow for [b]any[/b] kind of updates to already released games, and that includes the internet protocol stack.
Everyone need to keep in mind that software architecture-wise, the PS3 and Xbox 360 are light years ahead of the Wii. It's not that Nintendo doesn't do anything, it's that they can't because their architecture is very limited and they clearly didn't have much foresight when designing it.
You tell me how they do that. Not software - the ROM bits have no recovery functionality. Hardware? Massive props for you if you can find any kind of JTAG or similar port on the board, because quite a few people have wasted lots of time trying and failing to do so. As far as we can tell, they preflash the NAND chips before soldering, and I'm not aware of anyone who hasn't just had their motherboard replaced after this kind of unrecoverable brick.
Here's a pinout diagram of the Hollywood with everything that's definitely not a recovery port marked. Let me know if you find any flashing/recovery functionality on the remaining pins;)
won't work, because you actually need to be a server (i.e. you need a domain with SRV records and open ports and a reasonably static IP and whatnot).
The open client protocol problem is simply a problem that hasn't been solved yet. I'm sure a solution will arrive. As long as the server-to-server federation protocol is open, you're golden.
He is. But seriously, this is a 4kB dump of an 11-year-old boot ROM. Copyright or no copyright, I'd say the historical significance and the usefulness for preservation efforts outweighs concerns about copyright violation.
Copyright law is grossly overreaching. At some points, such as small, old, historical works, you have to draw a line.
Basically, costis attempted the precise method (clock glitching during ROM disable), which didn't work. So he pulled out the sledgehammer (massive clock and power glitching to randomize CPU state). You don't need much accuracy with a sledgehammer.
I doubt it powers on the LED. The LED on a GBC turns on even without a clock crystal, before the CPU runs any instructions. It may just be redundantly enabling an already enabled LED though. There's also no such thing as the clang "WAV": this is fixed-function sound hardware, so all it does is configure it to output the two notes. And it certainly doesn't copy the game binary to memory, since this is a system that uses ROM cartridges with in-place execution.
Good job, you just jumped from "mythical unreleased unhackable PS3-grade-security netbook" to "Lenovo S10e, which comes with RFID and a remote kill switch, both of unspecified robustness".
As I said in my original reply to you, call back when they come with a dedicated security CPU, a tamperproof hypervisor, encrypted memory, encrypted buses, a full chain of trust from on-cpu-die boot ROM and keys to individual software applications, and everything else that the PS3 has that has enabled it to resist attack so far.
And yet the article says NSW seeks to build 'unhackable' netbook network. The netbook network is getting built. By adding more identical netbooks to the pool already out there. Good job on trolling by taking an imprecise Slashdot summary as fact.
Seriously, get out of that bubble of yours and try reading yourself. The model is already fixed, Lenovo S10e. That's a bog-standard netbook with bog-standard components. If you're so certain that NSW is commissioning an ultra-secure, never-seen-before PC platform, please enlighten us all and point us towards the slightest hint (nevermind proof) that that is the case.
Already, the department has noted the loss or damage of just six netbooks out of the 20,000 rolled out since August - and have tracked one teacher using their device on a field trip in New Zealand.
Under PC Linux, you typically don't use mtd to write to the BIOS Flash. Instead, the usual tool would be Flashrom. Going by some of the first-hand experience comments elsewhere in the discussion, it looks like they didn't even disable CD/USB boot, nevermind BIOS flashing.
Slashdot Mirror
You're confusing homebrew with warez. Homebrew usually works pretty well, and HBC has a near zero chance of bricking your console. Applicaions vary in functionality and robustness, but they're safe since they're just applications that won't modify your console.
Loaders, on the other hand, besides typically illegal (they like to ship around chunks of IOS), are very dodgy and unreliable. System modification is required to install loaders, so it's an inherently risky activity. About 50% of the reports of permanent bricks I get from people are due to using Waninkoko's stuff. Stay far away, he never learned what that 'int' thing before function prototypes is for.
They just reauthorize those games online on your new console (via the serial numbers). When the system is totally bricked you lose your saves. They only notice homebrew or warez when they get "bricked" consoles that display an error message (which indicates System Menu operation), which they can usually fix by reinstalling stuff with their rescue mode DVDs and a small "flag" tool inserted into a memory card slot to put the menu into recovery mode.
I don't know about their hardware engineers, but my opinion of their software engineers has been steadily decreasing. Call me a dickhead if they want, but they fail at almost everything they do as far as system programming. Their system architecture is archaic and they've locked themselves out of many of the features and improvements that their compatitors are able to add. They tried twice to stop a certain savegame exploit and failed disastrously - yes, there were critical bugs in the anti-exploti code, as small as it is. I've disassembled a lot of their code and the list of WTFs would span hundreds of pages. Their "secure" IOS security is dismal. They implemented a homebrew crypto layer and completely screwed up the very core of RSA verification, resulting in the very first exploit to run homebrew. They appear to have never heard of things called "code reviews". They're using a scheme of forking IOS for each minor addition that makes it very difficult to maintain security fixes in the future, nevermind that older games will never get new features or improvements. Then there's the hugely botched boot2 update that this article is all about, and which they clearly didn't test well enough (I mean, come on, we can find it with a handful of Wiis and some minor testing and they can't?). They have to resort to stupid hacks like copying SD channels to NAND to play them because they never even attempted to develop an even slightly sane storage layer for IOS - access to everything goes through different APIs. The division of functionality between ARM and PPC code is chaotic: the USB stack is in IOS, the Bluetooth USB device driver is in the PPC but the Keyboard/mouse drivers are in IOS, the Bluetooth stack is in the PPC while the TCP/IP stack is in IOS, half of the SD driver is in IOS and the other half in the PPC, the NAND filesystem driver is in IOS but the FAT filesystem driver for SD is in the PPC, etc. The WiFi drivers are notoriously unreliable (Broadcom is probably to blame for that). They left in DVD-Video mode code and functionality that is what enables softmods - and when we tried to report it to them them before Wii piracy via homebrew existed, they harassed us and refused to let us speak with an engineer! Softmods, predictably, came later, when other people discovered that code.
As for their hardware engineers, they at least have horrible power management inside the Hollywood to blame for the WC24 heat issues causing GPU failures. The software guys also helped, though, by making IOS have a busy-wait idle thread. IOS uses 100% of the Starlet CPU during idle mode, while the fans are off and the system is slowly getting cooked.
Again, feel free to look for a flashing mechanism too, but our experiences and attempts, evidence from people who send in their Wiis for repair, and our generally bad opinion of Nintendo's engineers all point towards there not being one.
I didn't use a single tag in that post. I'm not sure what you're talking about. I think you're confusing a bad Slashdot/D2 vs. Safari interaction with people messing with fonts.
I'd test it but my iPhone's screen is currently cracked.
And what you're trying to say is...? Do you see a socket anywhere? I don't know about you, but we've never seen a repaired Wii with obvious signs of SMT reworking. Using a chip clip to program in-system is problematic and deinitely not the way the system was designed; see above reply.
Their system doesn't appear to be designed to accept external driving of the flash. The Hollywood boots and tries to talk to it as soon as you power it on. External NAND flashers need to overdrive the Wii's outputs very hard to properly do their jobs. As far as we can tell, the control outputs to the NAND Flash do not have tristate capability (they always drive hard high or low, even when the system is uninitialized or idle). The NAND power rail is also the 3.3V Hollywood power rail, so it is impossible to power the NAND Flash without powering up the Hollywood.
Nope, pretty sure that's not how they do it.
USB loading or any kind of "backup loading" is not supported by the Wiibrew community because 90% of its users are massive pirates. If you want to legitimately use games you own from USB, you're on your own. Fair warning: most of the software involved is crappy, unstable, and/or dangerous.
For what it's worth, I've yet to hear any report of a Wii being bricked by the HackMii installer (or any other prior versions, including the old standalone Homebrew Channel installer). So far, as far as we know, 100% of the Wiis bricked via "homebrew" have in fact been bricked via either dodgy piracy tools (the people behind them seem to go for insta-releasing to become famous, instead of actually doing that old thing called QA and Testing and doing things like checking error codes) or by people doing stupid silly things like modding their System Menu.
FWIW, 4.2 is reported to completely kill modchip region-free functionality. If they've done what I think they've done (started to check the region on the TMD, which is cryptographically signed), region-free via modchip is dead and won't be coming back.
If they don't like it, they're idiots. They make a profit on Wiimotes, why would they be against using them on computers?
And once again I really need to stop going to silly forums and unlearn bbcode. Gah.
Oh, it's going to work fine for [b]most[/b] people, but the bricking rate is still going to be much higher than normal. The boot2 flashing code isn't completely borked (I've successfully used it to flash early versions of BootMii 10-20 times), but the fact of the matter is sometimes it'll botch. I'd expect a sizable number of bricks, much higher than for "normal" system updates.
If Nintendo aren't idiots, they'll ditch the idea of putting boot2v4 on discs. They can still throw the rest of the 4.2 update on them with no ill consequences to unmodified consoles.
Because they fail at securing internet protocols. At this stage they probably just can't do anything for older games. Remember, their software architecture does not allow for [b]any[/b] kind of updates to already released games, and that includes the internet protocol stack.
Everyone need to keep in mind that software architecture-wise, the PS3 and Xbox 360 are light years ahead of the Wii. It's not that Nintendo doesn't do anything, it's that they can't because their architecture is very limited and they clearly didn't have much foresight when designing it.
You tell me how they do that. Not software - the ROM bits have no recovery functionality. Hardware? Massive props for you if you can find any kind of JTAG or similar port on the board, because quite a few people have wasted lots of time trying and failing to do so. As far as we can tell, they preflash the NAND chips before soldering, and I'm not aware of anyone who hasn't just had their motherboard replaced after this kind of unrecoverable brick.
Here's a pinout diagram of the Hollywood with everything that's definitely not a recovery port marked. Let me know if you find any flashing/recovery functionality on the remaining pins ;)
won't work, because you actually need to be a server (i.e. you need a domain with SRV records and open ports and a reasonably static IP and whatnot).
The open client protocol problem is simply a problem that hasn't been solved yet. I'm sure a solution will arrive. As long as the server-to-server federation protocol is open, you're golden.
He is. But seriously, this is a 4kB dump of an 11-year-old boot ROM. Copyright or no copyright, I'd say the historical significance and the usefulness for preservation efforts outweighs concerns about copyright violation.
Copyright law is grossly overreaching. At some points, such as small, old, historical works, you have to draw a line.
The same guy (costis) already dumped the SGB ROM a few days earlier, using a simpler clock-glitching-only techique. See the site.
Basically, costis attempted the precise method (clock glitching during ROM disable), which didn't work. So he pulled out the sledgehammer (massive clock and power glitching to randomize CPU state). You don't need much accuracy with a sledgehammer.
I doubt it powers on the LED. The LED on a GBC turns on even without a clock crystal, before the CPU runs any instructions. It may just be redundantly enabling an already enabled LED though. There's also no such thing as the clang "WAV": this is fixed-function sound hardware, so all it does is configure it to output the two notes. And it certainly doesn't copy the game binary to memory, since this is a system that uses ROM cartridges with in-place execution.
You seriously need to work on your trolling skills. Actually figuring out someone's nationality before xenophobic trolling helps.
Hint: wrong side of the ocean.
Good job, you just jumped from "mythical unreleased unhackable PS3-grade-security netbook" to "Lenovo S10e, which comes with RFID and a remote kill switch, both of unspecified robustness".
As I said in my original reply to you, call back when they come with a dedicated security CPU, a tamperproof hypervisor, encrypted memory, encrypted buses, a full chain of trust from on-cpu-die boot ROM and keys to individual software applications, and everything else that the PS3 has that has enabled it to resist attack so far.
And yet the article says NSW seeks to build 'unhackable' netbook network. The netbook network is getting built. By adding more identical netbooks to the pool already out there. Good job on trolling by taking an imprecise Slashdot summary as fact.
Seriously, get out of that bubble of yours and try reading yourself. The model is already fixed, Lenovo S10e. That's a bog-standard netbook with bog-standard components. If you're so certain that NSW is commissioning an ultra-secure, never-seen-before PC platform, please enlighten us all and point us towards the slightest hint (nevermind proof) that that is the case.
Under PC Linux, you typically don't use mtd to write to the BIOS Flash. Instead, the usual tool would be Flashrom. Going by some of the first-hand experience comments elsewhere in the discussion, it looks like they didn't even disable CD/USB boot, nevermind BIOS flashing.