Funny, they have an example of the "binary junk" that Microsoft Office documents are composed of... except the excerpt is from a.PNG file, a perfectly well documented and open format. pHYs is the physical dimensions chunk and IDAT is the data chunk, AFAIR.
Even a one bit change in the input totally changes the output of data after encryption (with secure encryption algorithms anyway). So unless you feed a deterministic voice synthesizer to the VoIP compressor and adjust the timing to exactly match that of the packets, no, you aren't going to get any compressible chunks in the output data after encryption. At all. Besides, if the encryption is any good it'll use a random IV for every packet, because encrypting the same plaintext to the same ciphertext itself carries a whole load of security problems. Your file encryption program sucks.
IC bond wires are made of gold, and PCBs are gold plated very often these days. But IC wires are minuscule, and the PCB coating is so thin that it immediately dissolves when you solder to it.
Interestingly, we just released a new version of The Homebrew Channel for the Wii (beta8), and someone reported that it causes their router to crash. We've switched to an older version of the Wii system firmware (from IOS35 to IOS21 - no, not the Cisco kind of IOS) in older to support users without the newest updates (this applies to all users though, since all versions / branches of the firmware are kept on the Wii), and I have a feeling that some kind of bug in the WiFi networking in this version is causing it. Wonder if it has anything to do with the Windows problems....
Easy to brick when screwing around with system software or anything that installs / makes changes to your Wii. Just running applications is safe. The exception dump screen even lets you return to the Homebrew ChannelC using the Z button of the first Gamecube pad (most of the time, unless something got very messed up), so you don't have to reset the Wii.
Yes, it does. Not by itself, but if you look at the apps package, you'll see that we include Gecko Region Free, a tool to enable region-free game loading. Which, unlike other consoles, is not tied to the drive / security subsystem at all - it's just a simple check inside the system menu that can be patched out (or worked around), or you can just use a loader that doesn't check it.
Nonetheless, given Nintendo's past, they will probably go with great rage after all makers of such hacks, and sue them for piracy. With the net result being to so much raising sales, as mainly killing homebrew creativity.
Not going to happen. They may go after modchip makers (fair enough), but everything that us homebrewers do is legal if done right. Furthermore, the hacks that we use aren't designed to be used to play pirated games - in fact, doing this with DVD-R games is likely to be impossible due to certain protective measures that are in place to prevent hacking the DVD drive from software. The only big common link between homebrew and piracy right now are pirated Virtual Console games, which are mostly equivalent to the Homebrew Channel in that they're unsigned software, and they run the same way. However, further hacks probably will not enable VC piracy directly. And really, VC piracy is all Nintendo's (or rather, BroadOn's) fault. Their security system has several horrible bugs - after we released the tools to create channels and some bozo released a tool to extract decrypted VC channels from the wii's flash (*gasp*), the pirates had it easy. Not so with real disc-based titles.
There are no decent UI libraries yet. What you do get is direct access to the GPU with libOGC (the main homebrew library). The API is similar in spirit to OpenGL, though not directly compatible, and there is some setup needed. There's are a few examples on the devkitpro CVS (download the module 'examples'). Most are for GameCube, but don't be fooled - they can be compiled for Wii with no modifications, most of the time, by adding -mrvl to your CFLAGS and LDFLAGS. Graphics support is probably the least user-friendly part of libogc.
Input devices are quite easy to use, both GC pads and the Wiimote, in the latest version of libOGC (which requires the latest CVS devkitPPC). Once r15 is out, you'll get all of this in easy to use precompiled packages. Things like inactivity timeouts and auto-connection work out of the box, and you pretty much just call one function to scan for pads, and one function to read the current state structure.
SD filesystem support is also trivial. One init call, and then it's just stdio, using URL-ish paths: fat:/file, etc. With the Homebrew Channel, you also get your current directory set to the directory of your executable on the SD card (via argv[0]), so you can just open relative paths and they'll go to the right place on the SD card.
Networking is supported (via wlan and USB adapter), through an API that is mostly Berkeley Sockets compatible. A few things are somewhat nonstandard, but we can't do much about them - in this case, the TCP/IP stack is implemented in the IO/Security coprocessor, so we're just wrapping that interface.
Also, getting a USB Gecko is recommended. It's basically an interface that looks like a USB serial port on one end and plugs into your GC memory card slot on the other. While you can have a text console on-screen, the Gecko lets you have easy stdin/out directly from a PC, which is very useful for debugging. You can also call DEBUG_Init() and get a gdb stub listening over gecko when you get an exception, so you can easily get a backtrace and all of those goodies. We'll probably come up with something better in the future (via wifi?), but it's still a very nice, simple low-level peripheral to have.
Admittedly, the documentation now is very lacking, because most developers have been spending their time coding new features. Now that things are getting calmer and I have more time, I hope to start documenting things a lot better.
They don't seem very worried either. Virtual Console piracy is relatively popular recently, due to several massive flaws in their DRM, which also happen to enable our homebrew software (in part). They've had a fixed piece of security software install itself as part of the newest update, but they haven't flipped the right bit to enable it yet. It's been a long while. The big bug? A terribly, horribly, completely broken RSA implementation with an effective security of 8 bits - because they used strcmp() instead of memcmp() when testing signatures!
As for us, we'll still be able to run homebrew after they fix the security software. There are plenty of other bugs that we can use (most of which are not public yet, so chances are Nintendo doesn't know about them), and most do not enable VC piracy as directly as the one major bug that they "fixed".
For what it's worth, fixing a bricked wii is going to require a hardware programmer and some soldering, because it's bricked and as far as we know there's no backdoor to fix it (we're *gasp* using the proper term 'brick' here). However, hopefully we'll be able to develop a firmware modification that will insert a backdoor early into the boot process to provide a way of restoring if needed, assuming your Wii isn't bricked yet. Unfortunately, with the official software, the Wii is quite prone to permanent bricking. Even something as simple as a malformed channel banner file can cause it.
For those that do not know, "semibricked" (no, we did not invent the term) means that you've installed a version of the System Menu from another region (usually by using a game from another region that contains an update, with a modchip). The results are that you cannot access the Settings menu, as the internal inconsistency means that it tries to load the wrong files and ends up at an Opera 404 screen. Surprise! The Wii Settings menus are just HTML files. This can be easily fixed by running a game with an update for the right region that's newer than the installed one. The "fixes" up on our site are just the latest versions packaged as updates inside ISO images.
While, of course, this ability implies that you *can* run pirated software, with the right modifications, in practice I have yet to see a plausible black-hat group with the expertise needed to develop such a hack. And we're sure as heck not going to do it ourselves. All that people have been doing is Virtual Console piracy, which is quite easy once a few details got released / leaked, due to nintendo's multiple mistakes on their DRM. But patching commercial games to read their data from SD or USB is not at all trivial.
That's just an SD Gecko. It has no internal memory, it's just a way of plugging in an SD card into a memory card slot - the description is a lie. It was rather useful in the GC days, but was superseded by the internal SD slot on the Wii once we added support for it. The internal memory is not "expandable" like this.
For $150 you get an XC3S500, 16MB Flash, 64MB DDR SDRAM, Ethernet, a character LCD display, built-in programmer, ADCs and DACs, a whole bunch of smaller Flash/EEPROM memories, serial ports, one-bit-per-color VGA port, and a PS/2 mouse/keyboard port. I've been using it as a logic anazyer lately, and I'm going to try to write a NAND Flash emulator for it (interfaced via Ethernet to a PC). Great for beginner projects, and it can also implement quite a bit of older hardware:)
Surface mount chips are hard as in "you need to have some soldering experience" hard. It's orders of magnitude easier than HDD surgery, which requires a clean room and a lot of skill. Anyone can swap SMT chips at home with a rework station (or a heat gun in a pinch), a passable soldering iron, and some solder wick.
Hit the reset button on your computer. Your computer reboots. Memory was not cleared.
Erasing memory is not a prerequisite for rebooting a system. Maintaining a running system requires preserving memory. No one cares whether or not memory was erased once you want to reboot, since the CPU is just going to reboot from the BIOS (hence processor reset) and start loading everything from scratch into memory, overwriting whatever happened to be there before.
No, a change of 1C is exactly a change of 1K because they're defined that way. Which means that the melting point of ice is only approximately 0 C, or 273.15K, and that the boiling point of water is approximately 373.1339 K or 99.9839 C.
Clocking different parts of a chip with separate completely independent clocks is a bad idea, because then different parts of the chip are in different clock domains. This causes metastability problems when the drifting clocks periodically align to violate the timing constraints of the other side of the circuit. Then you need synchronizing circuits, which add delays and don't guarantee anything (the more you wait, the more you reduce your chance of failure, but there is always a chance).
Slashdot Mirror
Funny, they have an example of the "binary junk" that Microsoft Office documents are composed of... except the excerpt is from a .PNG file, a perfectly well documented and open format. pHYs is the physical dimensions chunk and IDAT is the data chunk, AFAIR.
Even a one bit change in the input totally changes the output of data after encryption (with secure encryption algorithms anyway). So unless you feed a deterministic voice synthesizer to the VoIP compressor and adjust the timing to exactly match that of the packets, no, you aren't going to get any compressible chunks in the output data after encryption. At all. Besides, if the encryption is any good it'll use a random IV for every packet, because encrypting the same plaintext to the same ciphertext itself carries a whole load of security problems. Your file encryption program sucks.
IC bond wires are made of gold, and PCBs are gold plated very often these days. But IC wires are minuscule, and the PCB coating is so thin that it immediately dissolves when you solder to it.
GPS would certainly be doable. 3G, not so much. Then you have the problem of making the official software use it, or roll your own.
Interestingly, we just released a new version of The Homebrew Channel for the Wii (beta8), and someone reported that it causes their router to crash. We've switched to an older version of the Wii system firmware (from IOS35 to IOS21 - no, not the Cisco kind of IOS) in older to support users without the newest updates (this applies to all users though, since all versions / branches of the firmware are kept on the Wii), and I have a feeling that some kind of bug in the WiFi networking in this version is causing it. Wonder if it has anything to do with the Windows problems....
It's called data compression.
Easy to brick when screwing around with system software or anything that installs / makes changes to your Wii. Just running applications is safe. The exception dump screen even lets you return to the Homebrew ChannelC using the Z button of the first Gamecube pad (most of the time, unless something got very messed up), so you don't have to reset the Wii.
Yes, it does. Not by itself, but if you look at the apps package, you'll see that we include Gecko Region Free, a tool to enable region-free game loading. Which, unlike other consoles, is not tied to the drive / security subsystem at all - it's just a simple check inside the system menu that can be patched out (or worked around), or you can just use a loader that doesn't check it.
Freeloader will die a certain death once nintendo updates their software. They use the same hack that we use (the RSA bug).
Not going to happen. They may go after modchip makers (fair enough), but everything that us homebrewers do is legal if done right. Furthermore, the hacks that we use aren't designed to be used to play pirated games - in fact, doing this with DVD-R games is likely to be impossible due to certain protective measures that are in place to prevent hacking the DVD drive from software. The only big common link between homebrew and piracy right now are pirated Virtual Console games, which are mostly equivalent to the Homebrew Channel in that they're unsigned software, and they run the same way. However, further hacks probably will not enable VC piracy directly. And really, VC piracy is all Nintendo's (or rather, BroadOn's) fault. Their security system has several horrible bugs - after we released the tools to create channels and some bozo released a tool to extract decrypted VC channels from the wii's flash (*gasp*), the pirates had it easy. Not so with real disc-based titles.
Yes, C/C++ is supported.
There are no decent UI libraries yet. What you do get is direct access to the GPU with libOGC (the main homebrew library). The API is similar in spirit to OpenGL, though not directly compatible, and there is some setup needed. There's are a few examples on the devkitpro CVS (download the module 'examples'). Most are for GameCube, but don't be fooled - they can be compiled for Wii with no modifications, most of the time, by adding -mrvl to your CFLAGS and LDFLAGS. Graphics support is probably the least user-friendly part of libogc.
Input devices are quite easy to use, both GC pads and the Wiimote, in the latest version of libOGC (which requires the latest CVS devkitPPC). Once r15 is out, you'll get all of this in easy to use precompiled packages. Things like inactivity timeouts and auto-connection work out of the box, and you pretty much just call one function to scan for pads, and one function to read the current state structure.
SD filesystem support is also trivial. One init call, and then it's just stdio, using URL-ish paths: fat:/file, etc. With the Homebrew Channel, you also get your current directory set to the directory of your executable on the SD card (via argv[0]), so you can just open relative paths and they'll go to the right place on the SD card.
Networking is supported (via wlan and USB adapter), through an API that is mostly Berkeley Sockets compatible. A few things are somewhat nonstandard, but we can't do much about them - in this case, the TCP/IP stack is implemented in the IO/Security coprocessor, so we're just wrapping that interface.
Also, getting a USB Gecko is recommended. It's basically an interface that looks like a USB serial port on one end and plugs into your GC memory card slot on the other. While you can have a text console on-screen, the Gecko lets you have easy stdin/out directly from a PC, which is very useful for debugging. You can also call DEBUG_Init() and get a gdb stub listening over gecko when you get an exception, so you can easily get a backtrace and all of those goodies. We'll probably come up with something better in the future (via wifi?), but it's still a very nice, simple low-level peripheral to have.
Admittedly, the documentation now is very lacking, because most developers have been spending their time coding new features. Now that things are getting calmer and I have more time, I hope to start documenting things a lot better.
They don't seem very worried either. Virtual Console piracy is relatively popular recently, due to several massive flaws in their DRM, which also happen to enable our homebrew software (in part). They've had a fixed piece of security software install itself as part of the newest update, but they haven't flipped the right bit to enable it yet. It's been a long while. The big bug? A terribly, horribly, completely broken RSA implementation with an effective security of 8 bits - because they used strcmp() instead of memcmp() when testing signatures!
As for us, we'll still be able to run homebrew after they fix the security software. There are plenty of other bugs that we can use (most of which are not public yet, so chances are Nintendo doesn't know about them), and most do not enable VC piracy as directly as the one major bug that they "fixed".
For what it's worth, fixing a bricked wii is going to require a hardware programmer and some soldering, because it's bricked and as far as we know there's no backdoor to fix it (we're *gasp* using the proper term 'brick' here). However, hopefully we'll be able to develop a firmware modification that will insert a backdoor early into the boot process to provide a way of restoring if needed, assuming your Wii isn't bricked yet. Unfortunately, with the official software, the Wii is quite prone to permanent bricking. Even something as simple as a malformed channel banner file can cause it.
For those that do not know, "semibricked" (no, we did not invent the term) means that you've installed a version of the System Menu from another region (usually by using a game from another region that contains an update, with a modchip). The results are that you cannot access the Settings menu, as the internal inconsistency means that it tries to load the wrong files and ends up at an Opera 404 screen. Surprise! The Wii Settings menus are just HTML files. This can be easily fixed by running a game with an update for the right region that's newer than the installed one. The "fixes" up on our site are just the latest versions packaged as updates inside ISO images.
Unsigned software != pirated commercial software.
While, of course, this ability implies that you *can* run pirated software, with the right modifications, in practice I have yet to see a plausible black-hat group with the expertise needed to develop such a hack. And we're sure as heck not going to do it ourselves. All that people have been doing is Virtual Console piracy, which is quite easy once a few details got released / leaked, due to nintendo's multiple mistakes on their DRM. But patching commercial games to read their data from SD or USB is not at all trivial.
That's just an SD Gecko. It has no internal memory, it's just a way of plugging in an SD card into a memory card slot - the description is a lie. It was rather useful in the GC days, but was superseded by the internal SD slot on the Wii once we added support for it. The internal memory is not "expandable" like this.
Here's one that's practically a steal: http://www.digilentinc.com/s3e/
:)
For $150 you get an XC3S500, 16MB Flash, 64MB DDR SDRAM, Ethernet, a character LCD display, built-in programmer, ADCs and DACs, a whole bunch of smaller Flash/EEPROM memories, serial ports, one-bit-per-color VGA port, and a PS/2 mouse/keyboard port. I've been using it as a logic anazyer lately, and I'm going to try to write a NAND Flash emulator for it (interfaced via Ethernet to a PC). Great for beginner projects, and it can also implement quite a bit of older hardware
Surface mount chips are hard as in "you need to have some soldering experience" hard. It's orders of magnitude easier than HDD surgery, which requires a clean room and a lot of skill. Anyone can swap SMT chips at home with a rework station (or a heat gun in a pinch), a passable soldering iron, and some solder wick.
The SWF format isn't open. Adobe just happens to let you see the spec if you agree not to write a Flash Player clone. Definitely not "open".
That's the other half.
You mean the one composed of electromagnetic interactions between gas molecules?
Hit the reset button on your computer.
Your computer reboots.
Memory was not cleared.
Erasing memory is not a prerequisite for rebooting a system. Maintaining a running system requires preserving memory. No one cares whether or not memory was erased once you want to reboot, since the CPU is just going to reboot from the BIOS (hence processor reset) and start loading everything from scratch into memory, overwriting whatever happened to be there before.
No, a change of 1C is exactly a change of 1K because they're defined that way. Which means that the melting point of ice is only approximately 0 C, or 273.15K, and that the boiling point of water is approximately 373.1339 K or 99.9839 C.
transKode almost got it right!
They dither (both spatially and temporally). That's how they get away with cheaper panels without making it look horrible.
Clocking different parts of a chip with separate completely independent clocks is a bad idea, because then different parts of the chip are in different clock domains. This causes metastability problems when the drifting clocks periodically align to violate the timing constraints of the other side of the circuit. Then you need synchronizing circuits, which add delays and don't guarantee anything (the more you wait, the more you reduce your chance of failure, but there is always a chance).