Hacking 25th Chaos Communication Congress

[CIJC]

I'm barely watching this, and lol at the Firefox thing. Also bushing looks proud when he said you MUST buy the ticket in order to play a virtual console game.

Also marcan, slow down a bit buddy, somethings you can't understand.

oh well...

*goes back to watching*

Also: Awesome shirts.

i agree with every statement in your post.

 

[alex]

marcan: That's....(um...)
bushing: FAIL!

"not those keys"

 

[Diablo1123]

I justed watched it, pretty interestings.
Yea the shirts were nice, not as funny as the screwups with the firefox thing though

I found the thing about the PS3 interesting.

Anyone else see that they also won on the CTF game?

 

[[Nuke]]

Hah! It's definitely not done. Their goal is to REMOVE reliance on IOS/Nintendo code. As long as all it's doing is booting the hbc/System menu, they're not done.

Tona, do you have any more information on this? Removing IOS/Nintendo code kills libogc/devkipro, and all apps that run it. This effects me as a homebrew coder and i'd like to know more.

 

[linkinworm]

]

Hah! It's definitely not done. Their goal is to REMOVE reliance on IOS/Nintendo code. As long as all it's doing is booting the hbc/System menu, they're not done.

Tona, do you have any more information on this? Removing IOS/Nintendo code kills libogc/devkipro, and all apps that run it. This effects me as a homebrew coder and i'd like to know more.

quess they only remove the IOS from bootmii and a new HBC, maybe homebrew will require some new documents(from twiizers) and will just run on raw PPC code
just a guess.

 

[tona]

]
Tona, do you have any more information on this? Removing IOS/Nintendo code kills libogc/devkipro, and all apps that run it. This effects me as a homebrew coder and i'd like to know more.
Sure, in it's current state, pulling out IOS would kill libogc. But that's far from rendering the code useless.
If you read the big long (and long-winded) article on hackmii about bootmii, you'll hear about some ideas they're tossing around to deal with this issue. There's linux, an IOS-like API, and other things.
Regardless, running homebrew the old-fashioned way will probably still be possible, as PPC code under IOS is an important step in the current homebrew enablement methods. It may even be enabled in bootmii (as it is in the current state).

Team Twiizers still has homebrewers in mind with their bootmii plans. They're just trying to look ahead and avoid IOS dependencies and whatnot.

Edit: Dude, just hop on IRC and ask your questions

QUOTE('Linkinworm')maybe datal knew of something else to boot region free then when the bug came out then thought why waist time we can put this out in a week with this bug known.

Nah, region patching was known long before that. What I was referring to was Datel's apploader magic. Which was pretty cool, but not necessarily new or helpful. It was just a method of executing code without having to actually boot the disc.

 

[[Nuke]]

Team Twiizers still has homebrewers in mind with their bootmii plans. They're just trying to look ahead and avoid IOS dependencies and whatnot.

This seems a contradiction as Team Twiizers have not asked us coders what they want, we all seem to be kept in the dark, then expect to ride with it once released. IOS Free dev kills all what I'm working on, but this isn't why i'm voicing this. I feel strongly that console developers (not linux coders) want the true experience of that licensed coders get, Nintendo makes it hard to do that so we use the next best thing (homebrew) which gives a great experance and fun which you know.

Now you bring in a Linux IOS free dev environment and it gives you a console trying to be a PC, and we can then only contribute to linux, port some sdl apps but its just that, linux. Now don't get me wrong this is fun but it removes the real experience were looking for. If you take PS3 as an example it has a real poor homebrew scene, but then look at Xbox 360 XNA, even its 100 USD it has some cool contributions on it, not just doom ports but actual original demos and games. Yes Nintendo fucked up and should of given us ability to make Wiiware without the strings like XNA does, that would of been awesome.

Yes Team Twiizers gave us huge amount of fun on the Wii, but if this is the way forward, i think homebrew on the Wii will revert back to Gamecube Mode to keep the fun experience alive. I guess time will tell if im right or wrong on this.

 

[WiiCrazy]

No, as far as I know Datel used the fakesigning bug after xt5 leaked the trucha signer tool. IIRC there may have been some speculation that they found the bug (or at least got wind of it) before the xt5 leak, but it's not really certain. It used at least one other interesting bug (or maybe it was a feature? see wiibrew forums "System Menu" section), but that bug/feature hasn't been useful to the homebrewing/hacking community all that much--nor has it been studied thoroughly.

Well then they either operated on the bug on a really constrained time window or they in a way knew the bug several months before the release... there is less than a month (2 week or so) after the release of trucha tool before freeloader's release...

The second bug you mean patching system menu using their custom apploader... but it's what the full product is actually... signing bug is just used to get that on the disc, without the signing bug it's useless... hence the 3.3 update killed freeloader

Without the signing bug for Datel,in theory, there were even no means to debug their custom apploader code... maybe they got development kits... dunno...

By the way I guess it's not exploiting a bug actually it just exploits the non-limited nature of memory accesses like current menu patchers/loaders

 

[bushing]

Well I'm not talking about names, I'm talking about the event as a whole... It was a 'we did this', 'we did that stuff' mostly...

The names could be the answer of these questions, these form the basis that makes later hacks possible

1. Who found the sign check bug?

2 or 3 sets of people. Segher (2-3 months before 24c3?), xt5 and marcan working together (I think?), and Datel.

We may never know for sure if Datel found the bug themselves at some early date (perhaps before Segher did). After we demonstrated the bug in December, several groups raced to rediscover the bug, which Segher had asked us not to disclose. We gave a few vague hints, and then xt5 and marcan found it (which was still quite an accomplishment)!

At some point after xt5 released the Trucha Signer (which was not a leak -- he found the bug himself, and therefore had the right to disclose it), Datel released FreeLoader. It used a variation of fakesigning that did not match either of our versions.

My suspicion is that Datel actually found the bug sometime in 2007, but realized that it would be too easily patched by Nintendo for them to release it as a product. They probably got the Freeloader code ready to go in Wii mode using that bug, internally, and then kept looking for a different bug to use. Once xt5 released the Trucha Signer, Datel no longer had anything to lose by exploiting the bug, so they sold as many copies as they could.

(I have no evidence of the above; it's purely conjecture and I'm not sure that everyone else agrees with me.)

2. Who was first to fakesign a disc and run it in a wii?
Me. First a day or two before 24c3 (but it was an unmodified copy of Lego Star Wars, so not very interesting), and then later a couple of hours before our presentation by patching the DOL on the disc.

3. Who first found the common decryption key?
tmbinc and segher. tmbinc dumped the RAM in pieces using the Tweezer Attack, but it was interleaved. segher wrote a program to reassemble the dumps into the correct order, and actually found the key inside the resulting dump.

QUOTEThe second bug you mean patching system menu using their custom apploader... but it's what the full product is actually... signing bug is just used to get that on the disc, without the signing bug it's useless... hence the 3.3 update killed freeloader

Yup. Also note that the GameCube's Freeloader was also a hacked apploader, so they had a conceptual base for their Wii work.

QUOTE

Without the signing bug for Datel,in theory, there were even no means to debug their custom apploader code... maybe they got development kits... dunno...

Right. They also couldn't do their PowerSaves stuff without it -- we did the Twilight Hack by using the fakesigning bug to patch Zelda to get debug output.

Rumor had it that Datel had access to an NDEV, but I don't have any proof of that.

 

[Brian117]

Pretty interesting conference.

That taught a lot of things about the Wii.

Great job Bushing and Marcan.

 

[linkinworm]

Well I'm not talking about names, I'm talking about the event as a whole... It was a 'we did this', 'we did that stuff' mostly...

The names could be the answer of these questions, these form the basis that makes later hacks possible

1. Who found the sign check bug?

2 or 3 sets of people. Segher (2-3 months before 24c3?), xt5 and marcan working together (I think?), and Datel.

We may never know for sure if Datel found the bug themselves at some early date (perhaps before Segher did). After we demonstrated the bug in December, several groups raced to rediscover the bug, which Segher had asked us not to disclose. We gave a few vague hints, and then xt5 and marcan found it (which was still quite an accomplishment)!

At some point after xt5 released the Trucha Signer (which was not a leak -- he found the bug himself, and therefore had the right to disclose it), Datel released FreeLoader. It used a variation of fakesigning that did not match either of our versions.

My suspicion is that Datel actually found the bug sometime in 2007, but realized that it would be too easily patched by Nintendo for them to release it as a product. They probably got the Freeloader code ready to go in Wii mode using that bug, internally, and then kept looking for a different bug to use. Once xt5 released the Trucha Signer, Datel no longer had anything to lose by exploiting the bug, so they sold as many copies as they could.

(I have no evidence of the above; it's purely conjecture and I'm not sure that everyone else agrees with me.)

2. Who was first to fakesign a disc and run it in a wii?
Me. First a day or two before 24c3 (but it was an unmodified copy of Lego Star Wars, so not very interesting), and then later a couple of hours before our presentation by patching the DOL on the disc.

3. Who first found the common decryption key?

tmbinc and segher. tmbinc dumped the RAM in pieces using the Tweezer Attack, but it was interleaved. segher wrote a program to reassemble the dumps into the correct order, and actually found the key inside the resulting dump.

QUOTE

The second bug you mean patching system menu using their custom apploader... but it's what the full product is actually... signing bug is just used to get that on the disc, without the signing bug it's useless... hence the 3.3 update killed freeloader

Yup. Also note that the GameCube's Freeloader was also a hacked apploader, so they had a conceptual base for their Wii work.

so will you be releasing documentation on how we are going to code on the wii without the need of IOS?
(had to delete a couple of your points to my quote in here)

 

[tona]

]

Team Twiizers still has homebrewers in mind with their bootmii plans. They're just trying to look ahead and avoid IOS dependencies and whatnot.

This seems a contradiction as Team Twiizers have not asked us coders what they want, we all seem to be kept in the dark, then expect to ride with it once released. IOS Free dev kills all what I'm working on, but this isn't why i'm voicing this. I feel strongly that console developers (not linux coders) want the true experience of that licensed coders get, Nintendo makes it hard to do that so we use the next best thing (homebrew) which gives a great experance and fun which you know.

Now you bring in a Linux IOS free dev environment and it gives you a console trying to be a PC, and we can then only contribute to linux, port some sdl apps but its just that, linux. Now don't get me wrong this is fun but it removes the real experience were looking for. If you take PS3 as an example it has a real poor homebrew scene, but then look at Xbox 360 XNA, even its 100 USD it has some cool contributions on it, not just doom ports but actual original demos and games. Yes Nintendo fucked up and should of given us ability to make Wiiware without the strings like XNA does, that would of been awesome.

Yes Team Twiizers gave us huge amount of fun on the Wii, but if this is the way forward, i think homebrew on the Wii will revert back to Gamecube Mode to keep the fun experience alive. I guess time will tell if im right or wrong on this.

Once again, people are listening on IRC. Why aren't you there? Good ideas are never stifled. Perhaps we aren't directly "asking," but we're trying to piece together what we think is best from what we hear.

I agree that linux sounds somewhat inefficient for homebrew, and I've voiced my opinions on this matter, too. Yet getting rid of IOS doesn't mean using linux exclusively.

Getting rid of IOS just means that we will have to write something of our own to run in the Starlet. In its basic form, this could mean something as simple as a "proxy" IOS (Which will prod registers on command from the PPC), built by devkitARM. Current libogc functions which use IOS could be rewritten to be done on the PPC instead of doing ioctls.
In its fullest, a co-processor or an IOS replacement providing the functions of a standard IOS would be possible--yet take a lot of work.
The two of these, however, are doable alternatives to linux that wouldn't really "kill" much, and get us away from Nintendo code.

Now, let me paint another picture for you.
Wii homebrew stays as it is now: A constant battle against Nintendo's updates and IOS patches. Assuming we keep on finding bugs and ways to keep the homebrew channel installed, Nintendo could take the offensive: Find bugs in libogc's handling of IOS functions, and tweak certain IOS to kill homebrew that try to use those functions.
They could kill ReloadIOS, they will probably kill things like DVDX, and they essentially have control over what Wii hardware we can and can't use.
Of course, Nintendo software will still need to use these functions, so it's not likely they'd do anything to drastic, but the point remains that we're putting ourselves at the whim of Nintendo's proprietary software.
Not just that, though. We're practically at the whim of just one VERSION of IOS.
IOS36, and IOS35 work great for most homebrew, but if you've ever tried developing on different IOS versions, you'll find many libogc functions break completely. This weakens our hold under Nintendo's software--they only have to break one version of IOS and suddenly libogc no longer works.
That system IN ITSELF is bad for libogc--only being able to support one single version of IOS. The alternative of trying to support all IOS in one libogc is infeasable, and would become a giant mess of code--which could likely easily be broken by Nintendo's crap.

Here's another possibility: Nintendo could get tired of the current IOS situation and push an update for the system menu which changes the title booting methods: It keeps a list (updated) of titles which have been assigned "new" IOS to use--and uses the new IOS listed instead of that specified in the TMD. Suddenly, WiiWare, Brawl, and other games using IOS36 don't use IOS36 anymore, and they delete IOS36 from the system. Now libogc is going to be fairly broken, and all current homebrew will have to be recompiled with an updated libogc which has a new way to deal with selecting an IOS to use.

These are the kinds of contingencies we're talking about getting rid of. And they NEED to be removed--badly.
Linux doesn't have to be the answer--but it's going to be hard work regardless.


Now, if we're running homebrew from bootmii, with custom starlet code, we have a (hopefully) stable coding/homebrew environment which we control.
Nintendo's only control of the system is whether or not we can get bootmii installed. The hackers can deal with fighting off Nintendo's updates, homebrew is moved farther away from piracy, and hombrewers have a stable unchanging environment to work with. Sounds much better, doesn't it?

 

[[Nuke]]

well you all know I'm firmly against all this. I can't support something that tries to kill USB gecko, Gecko OS, Gecko 2.0 and users who support and use my stuff. Boot commercial games is important for Gecko users and what i work hard for.

Its not getting one over on pirates, as piracy on the Wii will always be there as the DVD is not secure. This just screws homebrewers like me and the 20,000+ Wiird members who use and enjoy my tools.

 

[djdynamite123]

well you all know I'm firmly against all this. I can't support something that tries to kill USB gecko, Gecko OS, Gecko 2.0 and users who support and use my stuff. Boot commercial games is important for Gecko users and what i work hard for.

Its not getting one over on pirates, as piracy on the Wii will always be there as the DVD is not secure. This just screws homebrewers like me and the 20,000+ Wiird members who use and enjoy my tools.

Looking at different angles team twiizers with what's going to happen.....possibly, creating and using stuff to hopefully keep bootmii stable, it would kill your Gecko softwares, so you would have to dig in...Again and work hard to sort your products out, to be able to run with how this bootmii and IOS situation may end up....
which we can understand your issue with that.....
It may not come down to that, it's just the possibility, with twiizers figuring out what suits best, to avoid problems with current, future homebrew and Nintendo strikes..

 

[tona]

]
well you all know I'm firmly against all this. I can't support something that tries to kill USB gecko, Gecko OS, Gecko 2.0 and users who support and use my stuff. Boot commercial games is important for Gecko users and what i work hard for.

Its not getting one over on pirates, as piracy on the Wii will always be there as the DVD is not secure. This just screws homebrewers like me and the 20,000+ Wiird members who use and enjoy my tools.

Well, of course hardware-based piracy hacks will still be there. The point of bootmii vs. piracy is to make it so new kernel-mode-access hacks can be implemented without giving access to whatever warezloader coders want them. AFAIK your gecko os doesn't use custom IOS code (needed for current software piracy), or use fakesigned or custom Identity content at all, so it won't be affected. The Twilight Hack and its successors (and probably still the HBC) will allow PPC code to run.

It's the Starlet hacks and kernel-mode stuff that really enable the would-be pirate "hackers." If you don't have a problem with the HBC team not releasing their new installation method for post-oct-23, there's no reason you should have a problem with the new stuff. It's the people that want to use the custom-content/starlet code hacks for themselves that will have issues.

 

[RexNebular]

Adding the ABILITY to run apps that don't require IOS can only be a good thing. I don't think anyone wants to delete IOS or break compatibility with official games. Bootmii will give everyone more power, choices and a great way to recover if something goes wrong.

 

[WiiCrazy]

Well I'm not talking about names, I'm talking about the event as a whole... It was a 'we did this', 'we did that stuff' mostly...

The names could be the answer of these questions, these form the basis that makes later hacks possible

1. Who found the sign check bug?

2 or 3 sets of people. Segher (2-3 months before 24c3?), xt5 and marcan working together (I think?), and Datel.

We may never know for sure if Datel found the bug themselves at some early date (perhaps before Segher did). After we demonstrated the bug in December, several groups raced to rediscover the bug, which Segher had asked us not to disclose. We gave a few vague hints, and then xt5 and marcan found it (which was still quite an accomplishment)!

At some point after xt5 released the Trucha Signer (which was not a leak -- he found the bug himself, and therefore had the right to disclose it), Datel released FreeLoader. It used a variation of fakesigning that did not match either of our versions.

My suspicion is that Datel actually found the bug sometime in 2007, but realized that it would be too easily patched by Nintendo for them to release it as a product. They probably got the Freeloader code ready to go in Wii mode using that bug, internally, and then kept looking for a different bug to use. Once xt5 released the Trucha Signer, Datel no longer had anything to lose by exploiting the bug, so they sold as many copies as they could.

(I have no evidence of the above; it's purely conjecture and I'm not sure that everyone else agrees with me.)

Well I guess things get messy between January 2008 and March 2008...
Thinking no one can talk on behalf of Datel here, what we will be talking will be only estimations. Though I'm good at making estimations, I'll stop it now as they won't improve the debate here.

Happy new year to all!

edit: quoted partially since forum didn't allow quoting all

 

[[Nuke]]

It's the Starlet hacks and kernel-mode stuff that really enable the would-be pirate "hackers." If you don't have a problem with the HBC team not releasing their new installation method for post-oct-23, there's no reason you should have a problem with the new stuff. It's the people that want to use the custom-content/starlet code hacks for themselves that will have issues.

If your still allowing homebrewers access to play their games from the system menu and IOS, how safe is bootmii?. Nintendo can patch boot2 just like that they can any other title, it requires only the same version number not higher. It is dangerous if you don't patch the System Menu. If you are patching the system menu then you need to have a installer for IOS wads that the game needs.

How are you going to tackle the above problem?

 

[tona]

]
If your still allowing homebrewers access to play their games from the system menu and IOS, how safe is bootmii?. Nintendo can patch boot2 just like that they can any other title, it requires only the same version number not higher. It is dangerous if you don't patch the System Menu. If you are patching the system menu then you need to have a installer for IOS wads that the game needs.

How are you going to tackle the above problem?

All of this is getting wildly off topic.

There are a number of ways to deal with this problem. You might want to reread the original bootmii post, though. It answers your very question. (Hint: Paragraph after the bullet points)
I'm not coding any of bootmii (so far) so it's not my place to talk about what the current plan is. Heck, most of what I've been writing here comes without any "inside" information. You can piece together all of this from that hackmii entry and the 25c3 presentation.