Those do sound like a pretty good idea, if they're using real fuses or antifuses to store data (as in a PROM). Physical wires aren't going to break and reconnect on their own very easily, even inside a chip.
On the other hand, if it's just an OTP memory (the "normal" kind of OTP) then it still isn't very good, because OTP is just EPROM without a window for UV light, and EPROM has lifetime issues.
Even block based ciphers have problems. If your data has random bit errors every now and then, a block cipher will corrupt an entire block (often 16 bytes) for each one of those. A no-feedback (XOR based) stream cipher might work though.
Also, digital pictures are best stored in uncompressed formats. Preferably a raw bitmap with no headers even, together with a printed document describing the format (which can be done in a sentence or two). Fixed resolution 8bit/channel RGB data will degrade gracefully with random bit errors (to an extent), unlike compressed formats like JPG and PNG which will just die completely.
I agree completely. Current digital technology is not designed to last for long periods of time untouched. Storage methods evolve, things move around, old hardware fails and new hardware shows up, and data is in a continuous flux. If you shove data into one device and leave it untouched for many years, chances are it will be gone one way or another, since normal storage devices just aren't meant for that kind of use. Flash memory gets erased, hard drives have bearings which stick and die, CDs and DVDs have dyes that can break down over time and aluminum that can oxidize, etc. The proper way of using current storage technology to store data for long amounts of time is to do what we've been doing all along: use normal methods of redundancy (offsite backups, etc), keep the data online, check up on it periodically, and move it over to new storage systems as the old ones become obsolete or break.
If you just want to stick some data in a box for 25 years, printing it out is bound to get you a much higher chance of getting it back. Other means exist of storing data for long periods of time, but consumer digital technology isn't it. Things like laser engraving, coupled with a good reference manual that describes the encoding could work, but these kinds of things are highly specialized and probably not available for a reasonable amount of money. Printing is.
Encryption is the kind of thing that you most certainly do not want to do, as it multiplies your chances of failure. Most often, changes to the encrypted data result in a completely random plaintext (from the point of corruption onwards). Some kinds of encryption don't have this problem, but almost all of them will increase your chances of failure to an extent. Then you also have to deal with preserving the key.
Flash memory works by trapping electrons on an insulated gate. Since there is no such thing as a perfect insulator, especially at high integration levels and taking into account quantum effects, those electrons will leech out over time. 25 years is probably more than enough to kill the data on a flash memory chip.
The "secret sauce" is the EFI BIOS and the power control / hardware monitoring chip. This chip also happens to contain decryption keys for encrypted OSX binaries.
JAR files are just ZIP archives. ZIP archives are based on the end of the file, where the central directory is located (this is also why you can often unzip a self-extracting exe using a normal unzip application). GIF files, like most other files, are based on the beginning of the file. ZIPs don't care if you shove data in front of them. GIFs don't care if you shove data after them.
$ cat file.gif file.zip > file.gizip Rename the result to.gif or.zip. Both work. You can also substitute JPG instead of the GIF, or any other file type that ignores trailing garbage.
I'm not sure if there's some kind of trick that is needed for the exploit to work, but the fact that you can make a file that works both as a zip and as almost any other file type has been known for ages.
That's correct. Technically, Nintendo could make a DVD-Video player channel. If Nintendo ignores our attempts to contact them, we'll give porting a DVD player a shot.
Bullshit. A Wii drive can read normal DVDs just fine physically. The only differences are in the disc authentication (BCA / copy protection) and in the odd sector format. The physical characteristics are just different ways of reading the discs and do not have anything to do with all of this.
It can't, unless you have a modchip and are willing to develop a DVD-playing application. There's rampant misinformation on this, as usual.
Let's set a few things straight:
Currently, there is no public method for reading DVD-Rs on an unmodded Wii.
This isn't the first "Custom Firmware" (I hate that word) for the Wii. Not even close. Not even the first public one. Or, alternately, this isn't and there has never been a true wii Custom Firmware, depending on how you look at it.
The "Custom Firmware" is only a small patch to the firmware that does two things: disable signature checks and disable a certain read restriction on the DVD code. What this does is let you use standard-format DVD-Rs (i.e. ISO9660 or Video DVDs) with the DVD drive on the Wii, but you still need a modchip.
The difference between this firmware and the original is exactly 5 bytes. 4 for the DVD maximum read restriction (an unsigned int), and one code byte patch for the signature disable. Hardly earth-shattering.
We released a legal open source firmware patcher some time ago. Approximately three days before this purpoted "custom firmware" came out, svpe had added the DVD restriction removal patch to it (this was in response to an outright modification to an older firmware, released with the original code and hence illegally, by nitrotux, which he distributed with a disc dumper, but our patcher patches all of the recent versions of the firmware which use a completely different subroutine for the check, so the patch is different even though the result is the same). The first revision of Waninkoko's "custom firmware" was so hastily done that it was basically a PPF patch over the original firmware. Except it's encrypted. And he even changed the key. Hence, the patch was useless and he ended up distributing the entire patched-and-reencrypted file in the form of the patch (the entire patcher was 2MB, which is the size of the entire firmware). The fact that he made this trivial mistake makes me think that he did this very quickly and stole the patches from the open source patchmii (the DVD patch is identical except for the actual number involved in the restriction, and the signature check disable patch, which is relatively hard to find and there are several ways of doing it, is exactly the same). He later released a newer version without the blatant patch fuckup which is presumably legal to distribute now, although it still requires people to rip the original firmware from a recent game (whereas our open source patcher automatically downloads it from Nintendo's servers).
Now onto the news. Recently, we actually did figure out a way of reading DVD-Rs without a modchip (!). Since this can be used for piracy (and could potentially cause quite an increase in it, since a free simple non-warranty-voiding pirate-game-playing hack is very appealing compared to the current modchip situation), we have tried to contact Nintendo about it (privately and publicly). If they ignore us, then we'll probably release an open source library and tools that will let Wii homebrew read information from a DVD-R on any Wii, modchip or not.
For anyone trying to draw parallels between the PSP and the Wii, I suggest this article. As for the PSP emulator, I'll believe it when I see more than a single screenshot.
Currently, there is no public method for reading DVD-Rs on an unmodded Wii.
This isn't the first "Custom Firmware" (I hate that word) for the Wii. Not even close. Not even the first public one. Or, alternately, this isn't and there has never been a true wii Custom Firmware, depending on how you look at it.
The "Custom Firmware" is only a small patch to the firmware that does two things: disable signature checks and disable a certain read restriction on the DVD code. What this does is let you use standard-format DVD-Rs (i.e. ISO9660 or Video DVDs) with the DVD drive on the Wii, but you still need a modchip.
The difference between this firmware and the original is exactly 5 bytes. 4 for the DVD maximum read restriction (an unsigned int), and one code byte patch for the signature disable. Hardly earth-shattering.
We released a legal open source firmware patcher some time ago. Approximately three days before this purpoted "custom firmware" came out, svpe had added the DVD restriction removal patch to it (this was in response to an outright modification to an older firmware, released with the original code and hence illegally, by nitrotux, which he distributed with a disc dumper, but our patcher patches all of the recent versions of the firmware which use a completely different subroutine for the check, so the patch is different even though the result is the same). The first revision of Waninkoko's "custom firmware" was so hastily done that it was basically a PPF patch over the original firmware. Except it's encrypted. And he even changed the key. Hence, the patch was useless and he ended up distributing the entire patched-and-reencrypted file in the form of the patch (the entire patcher was 2MB, which is the size of the entire firmware). The fact that he made this trivial mistake makes me think that he did this very quickly and stole the patches from the open source patchmii (the DVD patch is identical except for the actual number involved in the restriction, and the signature check disable patch, which is relatively hard to find and there are several ways of doing it, is exactly the same). He later released a newer version without the blatant patch fuckup which is presumably legal to distribute now, although it still requires people to rip the original firmware from a recent game (whereas our open source patcher automatically downloads it from Nintendo's servers).
Now onto the news. Recently, we actually did figure out a way of reading DVD-Rs without a modchip. Since this can be used for piracy (and could potentially cause quite an increase in it, since a free simple non-warranty-voiding pirate-game-playing hack is very appealing compared to the current modchip situation), we have tried to contact Nintendo about it (privately and publicly). If they ignore us, then we'll probably release an open source library and tools that will let Wii homebrew read information from a DVD-R on any Wii, modchip or not.
For anyone trying to draw parallels between the PSP and the Wii, I suggest this article. As for the PSP emulator, I'll believe it when I see more than a single screenshot.
As someone involved with Wii homebrew and hacking, honestly, that sort of patch isn't going to happen.
They can patch the game binary, but they can't patch game data without patching the binary to read data from elsewhere. Both patches would be very invasive. Nevermind the fact that the wii currently does not have an obvious place for this repository of patches.
Unless the game already comes with built-in upgrade/downloadable content features, Nintendo is probably not going to bother hacking up an update.
Wii games do run with a separate CPU taking care of security. There's a permissions system. However, said system is broken enough that we have 4 or 5 privilege escalation methods stowed away if we need them. Which means that the only real barrier to hacking the Wii is getting any code to run, which (practically speaking) means exploiting games via savegames. We'll always find one more bug in one more game.
Let's set thing straight. So far, homebrew on the Wii is an entirely different playfield from copied games. To play games on DVD-Rs, you need to hardware mod your drive, period.
Now, when you get to Virtual Console/WiiWare piracy, things get a little muddier. Unfortunately, if you can run homebrew, then you can effectively pirate VC games, because the terribly broken security means that you can pretty much just install them and they'll work. This might change in the future, when Nintendo fixes the problems.
Our (Team Twiizers') goal is to enable homebrew on the Wii, not piracy. We're not going to go out of our way to prevent piracy, but we also try to come up with methods of running homebrew that don't directly enable piracy. However, we can't work around the fact that, ultimately, if you can run unsigned code, then that code might be a game. We do have the advantage that pirates don't really have much of clue overall (so far), which is why we haven't seen a Wii ISO loader that can run games from an SD card yet. We sure as heck aren't going to write it, but if someone does, there's not much we can do about it.
As for homebrew, there is certainly a public, free, open source SDK available based on the GNU toolchain and an open source library to access the Wii hardware. In fact, most of the Wii's hardware is supported. Full graphics (though the API is mostly undocumented, it's all there), Wii Remote, SD card access, Gamecube pads, networking (WiFi or ethernet), USB mass storage, partial sound (no hardware acceleration yet), etc. See devkitpro for the toolchain and wiibrew for the community wiki.
The interesting thing is that modchips work in a completely different way, so these fixes don't really affect them. None of the current homebrew hacks/etc have anything to do with modchips or let people use pirated disc-based games.
As for VC/WiiWare piracy, it's true that the Homebrew Channel requires the same installation methods as hacked VC/WiiWare games, and both look the same to the system (unsigned channels). However, if Nintendo released an officially signed Homebrew Channel, we wouldn't have to worry about installing unsigned code any more. Then they could fix the unsigned channel bug, therefore killing VC/WiiWare piracy, and we wouldn't have to work around the fix (thus indirectly letting the pirates use it too). Pirate VC games are rather hard to run as "homebrew", because they want to read their data as channel contents.
That is not true. You can't block VC piracy without blocking the Homebrew Channel (at least not easily) because they're both unsigned channels. But you certainly can block those channels without blocking the root homebrew boot method (Twilight Hack). Furthermore, this patch did nothing to pirates because it doesn't affect existing installed channels, including the Homebrew Channel. Anyone who pirates VC likely already has it installed, so he can still pirate anything he wants. At most, this might be an attempt to stop everything from working on new or unhacked Wiis.
Besides, they ought to know better. The people doing the hacking to enable homebrew do not support piracy. However, if they don't actually target piracy specifically, it's just going to keep coming back via homebrew booting methods. If they break VC piracy we're not going to go fix it.
By the way, WAD is just a container format. You could upload channels in tar.gz format if you felt like it and wrote an installer that accepted that format. Idiots in these "scene" (read: warez) forums have somehow perpetrated the notion that piracy/channels are all about WADs. They were begging us for a WAD packer, even though one is not needed to make channels and that, if needed, it's about four lines of code anyway. The Wii itself does not store channels in WAD or any other format. WAD just happens to be the format that Nintendo created to distribute updates via game discs.
(This has nothing to do with Doom WADs, by the way. Nintendo WADs are just a simple packaging format that concatenates a bunch of pieces together and adds a header with the lengths.)
This has nothing to do with Virtual Console piracy, because this doesn't stop Virtual Console piracy at all (it all still works), because said piracy didn't exist three months ago when this update was compiled. System updates get a *lot* of testing.
No, they specifically targeted this at the Twilight Hack (i.e. homebrew), interestingly enough. Well, this and the fakesign exploit, but we expected them to fix the latter since that would shut down Datel's Freeloader (and because it was a huge bug). We certainly didn't expect them to patch the Twilight Hack though.
It took less than 12 hours for a fully working workaround. We haven't released it yet because the code needs a bit of cleanup and half of the team wasn't around when this whole thing happened so we need to make sure we're all on the same page.
Details in hackmii.com. Short version: the detection code is buggy and can be tricked by exploiting two small bugs. No need to find a new hack, we can just "hack the antihack" and then use the same old hack.
We're cleaning up code and committing everything to our internal source repos as I write this.
Slashdot Mirror
Those do sound like a pretty good idea, if they're using real fuses or antifuses to store data (as in a PROM). Physical wires aren't going to break and reconnect on their own very easily, even inside a chip.
On the other hand, if it's just an OTP memory (the "normal" kind of OTP) then it still isn't very good, because OTP is just EPROM without a window for UV light, and EPROM has lifetime issues.
Even block based ciphers have problems. If your data has random bit errors every now and then, a block cipher will corrupt an entire block (often 16 bytes) for each one of those. A no-feedback (XOR based) stream cipher might work though.
Also, digital pictures are best stored in uncompressed formats. Preferably a raw bitmap with no headers even, together with a printed document describing the format (which can be done in a sentence or two). Fixed resolution 8bit/channel RGB data will degrade gracefully with random bit errors (to an extent), unlike compressed formats like JPG and PNG which will just die completely.
I agree completely. Current digital technology is not designed to last for long periods of time untouched. Storage methods evolve, things move around, old hardware fails and new hardware shows up, and data is in a continuous flux. If you shove data into one device and leave it untouched for many years, chances are it will be gone one way or another, since normal storage devices just aren't meant for that kind of use. Flash memory gets erased, hard drives have bearings which stick and die, CDs and DVDs have dyes that can break down over time and aluminum that can oxidize, etc. The proper way of using current storage technology to store data for long amounts of time is to do what we've been doing all along: use normal methods of redundancy (offsite backups, etc), keep the data online, check up on it periodically, and move it over to new storage systems as the old ones become obsolete or break.
If you just want to stick some data in a box for 25 years, printing it out is bound to get you a much higher chance of getting it back. Other means exist of storing data for long periods of time, but consumer digital technology isn't it. Things like laser engraving, coupled with a good reference manual that describes the encoding could work, but these kinds of things are highly specialized and probably not available for a reasonable amount of money. Printing is.
Encryption is the kind of thing that you most certainly do not want to do, as it multiplies your chances of failure. Most often, changes to the encrypted data result in a completely random plaintext (from the point of corruption onwards). Some kinds of encryption don't have this problem, but almost all of them will increase your chances of failure to an extent. Then you also have to deal with preserving the key.
Flash memory works by trapping electrons on an insulated gate. Since there is no such thing as a perfect insulator, especially at high integration levels and taking into account quantum effects, those electrons will leech out over time. 25 years is probably more than enough to kill the data on a flash memory chip.
Nothing beats a paper hard copy.
The "secret sauce" is the EFI BIOS and the power control / hardware monitoring chip. This chip also happens to contain decryption keys for encrypted OSX binaries.
Emily's face is fake all along until they start showing the shading details. After those you get to see the real Emily for the first time.
You, sir, just reduced the security of your PINs to 34.93% of the original value.
Have a nice day.
JAR files are just ZIP archives. ZIP archives are based on the end of the file, where the central directory is located (this is also why you can often unzip a self-extracting exe using a normal unzip application). GIF files, like most other files, are based on the beginning of the file. ZIPs don't care if you shove data in front of them. GIFs don't care if you shove data after them.
$ cat file.gif file.zip > file.gizip .gif or .zip. Both work. You can also substitute JPG instead of the GIF, or any other file type that ignores trailing garbage.
Rename the result to
I'm not sure if there's some kind of trick that is needed for the exploit to work, but the fact that you can make a file that works both as a zip and as almost any other file type has been known for ages.
Isn't the column-based layout much more inefficient than a linear one, especially when skimming through many pages of links?
Wow, they made an IBM Personal System/3?
That's correct. Technically, Nintendo could make a DVD-Video player channel. If Nintendo ignores our attempts to contact them, we'll give porting a DVD player a shot.
Bullshit. A Wii drive can read normal DVDs just fine physically. The only differences are in the disc authentication (BCA / copy protection) and in the odd sector format. The physical characteristics are just different ways of reading the discs and do not have anything to do with all of this.
It can't, unless you have a modchip and are willing to develop a DVD-playing application. There's rampant misinformation on this, as usual.
Let's set a few things straight:
We released a legal open source firmware patcher some time ago. Approximately three days before this purpoted "custom firmware" came out, svpe had added the DVD restriction removal patch to it (this was in response to an outright modification to an older firmware, released with the original code and hence illegally, by nitrotux, which he distributed with a disc dumper, but our patcher patches all of the recent versions of the firmware which use a completely different subroutine for the check, so the patch is different even though the result is the same). The first revision of Waninkoko's "custom firmware" was so hastily done that it was basically a PPF patch over the original firmware. Except it's encrypted. And he even changed the key. Hence, the patch was useless and he ended up distributing the entire patched-and-reencrypted file in the form of the patch (the entire patcher was 2MB, which is the size of the entire firmware). The fact that he made this trivial mistake makes me think that he did this very quickly and stole the patches from the open source patchmii (the DVD patch is identical except for the actual number involved in the restriction, and the signature check disable patch, which is relatively hard to find and there are several ways of doing it, is exactly the same). He later released a newer version without the blatant patch fuckup which is presumably legal to distribute now, although it still requires people to rip the original firmware from a recent game (whereas our open source patcher automatically downloads it from Nintendo's servers).
Now onto the news. Recently, we actually did figure out a way of reading DVD-Rs without a modchip (!). Since this can be used for piracy (and could potentially cause quite an increase in it, since a free simple non-warranty-voiding pirate-game-playing hack is very appealing compared to the current modchip situation), we have tried to contact Nintendo about it (privately and publicly). If they ignore us, then we'll probably release an open source library and tools that will let Wii homebrew read information from a DVD-R on any Wii, modchip or not.
For anyone trying to draw parallels between the PSP and the Wii, I suggest this article. As for the PSP emulator, I'll believe it when I see more than a single screenshot.
... as usual.
Let's set a few things straight:
We released a legal open source firmware patcher some time ago. Approximately three days before this purpoted "custom firmware" came out, svpe had added the DVD restriction removal patch to it (this was in response to an outright modification to an older firmware, released with the original code and hence illegally, by nitrotux, which he distributed with a disc dumper, but our patcher patches all of the recent versions of the firmware which use a completely different subroutine for the check, so the patch is different even though the result is the same). The first revision of Waninkoko's "custom firmware" was so hastily done that it was basically a PPF patch over the original firmware. Except it's encrypted. And he even changed the key. Hence, the patch was useless and he ended up distributing the entire patched-and-reencrypted file in the form of the patch (the entire patcher was 2MB, which is the size of the entire firmware). The fact that he made this trivial mistake makes me think that he did this very quickly and stole the patches from the open source patchmii (the DVD patch is identical except for the actual number involved in the restriction, and the signature check disable patch, which is relatively hard to find and there are several ways of doing it, is exactly the same). He later released a newer version without the blatant patch fuckup which is presumably legal to distribute now, although it still requires people to rip the original firmware from a recent game (whereas our open source patcher automatically downloads it from Nintendo's servers).
Now onto the news. Recently, we actually did figure out a way of reading DVD-Rs without a modchip. Since this can be used for piracy (and could potentially cause quite an increase in it, since a free simple non-warranty-voiding pirate-game-playing hack is very appealing compared to the current modchip situation), we have tried to contact Nintendo about it (privately and publicly). If they ignore us, then we'll probably release an open source library and tools that will let Wii homebrew read information from a DVD-R on any Wii, modchip or not.
For anyone trying to draw parallels between the PSP and the Wii, I suggest this article. As for the PSP emulator, I'll believe it when I see more than a single screenshot.
As someone involved with Wii homebrew and hacking, honestly, that sort of patch isn't going to happen.
They can patch the game binary, but they can't patch game data without patching the binary to read data from elsewhere. Both patches would be very invasive. Nevermind the fact that the wii currently does not have an obvious place for this repository of patches.
Unless the game already comes with built-in upgrade/downloadable content features, Nintendo is probably not going to bother hacking up an update.
You can get the Simplified SD spec, which is basically the normal spec minus the DRM and some other unimportant details.
Wii games do run with a separate CPU taking care of security. There's a permissions system. However, said system is broken enough that we have 4 or 5 privilege escalation methods stowed away if we need them. Which means that the only real barrier to hacking the Wii is getting any code to run, which (practically speaking) means exploiting games via savegames. We'll always find one more bug in one more game.
Let's set thing straight. So far, homebrew on the Wii is an entirely different playfield from copied games. To play games on DVD-Rs, you need to hardware mod your drive, period.
Now, when you get to Virtual Console/WiiWare piracy, things get a little muddier. Unfortunately, if you can run homebrew, then you can effectively pirate VC games, because the terribly broken security means that you can pretty much just install them and they'll work. This might change in the future, when Nintendo fixes the problems.
Our (Team Twiizers') goal is to enable homebrew on the Wii, not piracy. We're not going to go out of our way to prevent piracy, but we also try to come up with methods of running homebrew that don't directly enable piracy. However, we can't work around the fact that, ultimately, if you can run unsigned code, then that code might be a game. We do have the advantage that pirates don't really have much of clue overall (so far), which is why we haven't seen a Wii ISO loader that can run games from an SD card yet. We sure as heck aren't going to write it, but if someone does, there's not much we can do about it.
As for homebrew, there is certainly a public, free, open source SDK available based on the GNU toolchain and an open source library to access the Wii hardware. In fact, most of the Wii's hardware is supported. Full graphics (though the API is mostly undocumented, it's all there), Wii Remote, SD card access, Gamecube pads, networking (WiFi or ethernet), USB mass storage, partial sound (no hardware acceleration yet), etc. See devkitpro for the toolchain and wiibrew for the community wiki.
The interesting thing is that modchips work in a completely different way, so these fixes don't really affect them. None of the current homebrew hacks/etc have anything to do with modchips or let people use pirated disc-based games.
As for VC/WiiWare piracy, it's true that the Homebrew Channel requires the same installation methods as hacked VC/WiiWare games, and both look the same to the system (unsigned channels). However, if Nintendo released an officially signed Homebrew Channel, we wouldn't have to worry about installing unsigned code any more. Then they could fix the unsigned channel bug, therefore killing VC/WiiWare piracy, and we wouldn't have to work around the fix (thus indirectly letting the pirates use it too). Pirate VC games are rather hard to run as "homebrew", because they want to read their data as channel contents.
Nintendo isn't going to give you the SDK unless you're worthy of getting it, in their eyes.
It's not a money issue, it's a "becoming a licensed developer" issue.
That is not true. You can't block VC piracy without blocking the Homebrew Channel (at least not easily) because they're both unsigned channels. But you certainly can block those channels without blocking the root homebrew boot method (Twilight Hack). Furthermore, this patch did nothing to pirates because it doesn't affect existing installed channels, including the Homebrew Channel. Anyone who pirates VC likely already has it installed, so he can still pirate anything he wants. At most, this might be an attempt to stop everything from working on new or unhacked Wiis.
Besides, they ought to know better. The people doing the hacking to enable homebrew do not support piracy. However, if they don't actually target piracy specifically, it's just going to keep coming back via homebrew booting methods. If they break VC piracy we're not going to go fix it.
By the way, WAD is just a container format. You could upload channels in tar.gz format if you felt like it and wrote an installer that accepted that format. Idiots in these "scene" (read: warez) forums have somehow perpetrated the notion that piracy/channels are all about WADs. They were begging us for a WAD packer, even though one is not needed to make channels and that, if needed, it's about four lines of code anyway. The Wii itself does not store channels in WAD or any other format. WAD just happens to be the format that Nintendo created to distribute updates via game discs.
(This has nothing to do with Doom WADs, by the way. Nintendo WADs are just a simple packaging format that concatenates a bunch of pieces together and adds a header with the lengths.)
This has nothing to do with Virtual Console piracy, because this doesn't stop Virtual Console piracy at all (it all still works), because said piracy didn't exist three months ago when this update was compiled. System updates get a *lot* of testing.
No, they specifically targeted this at the Twilight Hack (i.e. homebrew), interestingly enough. Well, this and the fakesign exploit, but we expected them to fix the latter since that would shut down Datel's Freeloader (and because it was a huge bug). We certainly didn't expect them to patch the Twilight Hack though.
It took less than 12 hours for a fully working workaround. We haven't released it yet because the code needs a bit of cleanup and half of the team wasn't around when this whole thing happened so we need to make sure we're all on the same page.
Details in hackmii.com. Short version: the detection code is buggy and can be tricked by exploiting two small bugs. No need to find a new hack, we can just "hack the antihack" and then use the same old hack.
We're cleaning up code and committing everything to our internal source repos as I write this.