IOS Dump

I am interested in how all the IOS functions and the System Menu talk. There are many ways to make the wii hackable through taking IOS functions and other parts that tell the system to do whatever that can be changed. As an example, the install of HBC could change IOS30 (that is the one the system menu uses right?) tell it to download the normal updates but have it patch the file after download before install to remove coding that is to kill homebrew and other small things. Eventually we could add functions to the IOS to in turn create or update the current system menu. So I ask, is there a tool to dump the decrypted format of the IOS?

There are a lot of ways to get unencrypted IOS modules.

You can read them directly from the Wii filesystem, decrypt a NAND dump with segher's tools, or decrypt an IOS WAD with segher's tools. Most of them are ARM ELFs that you can easily put through IDA.

Really? Hmm... I guess I know what I need to do next. Learn segher's tools so I can decrypt a NAND dump. Does his tools run on a computer or the wii. If on the computer, mac, windows, or linux? I could probably look it up to find it faster but thanks.

You'd probably be better off trying to understand how the system works and what tools are already available first, before trying to modify or enhance them. What you just described is what patchmii_core was written to do.

I figured that the patchmii_core is what I would have to use. I will start looking at all the wiki pages about the system. I never realized how detailed it is.

Yup, it's been a fun year!

Ya know the wii was a design failure for security by looking at how everything is laid out. There are millions of better ways. Not complaining since it helps us just seriously shocked.


P.S. Bushing, I want to personally thank you for all the work you have done for us. I have had my disagreements but you know, overall great job.

Never mind the layout, I think strncmp alone says enough. ;)

No, it was not a design failure. The design of the security systems isn't that bad at all: They sign everything (DVDs, Channels, Savegames,...) using well-established cryptography algorithms (RSA, elliptic curve cryptography, SHA-1,...). They even have a hardware AES and SHA-1 engine they use to be able to maintain a chain of trust during the boot process and a processor dedicated to almost all security.
Their implementation of this design is the real problem. Using a self-written RSA implementation with an obscure bug (strncmp) instead of using an already established one was just stupid and that's just one of the many problem :P

Yes, the only real "failures" as I see them resulted from:

1) Unencrypted memory, which is more of a cost vs. benefit issue (the other big consoles have it)
2) Outsourced Security to Some Guys Who Used To Work For ATI Or Something. Badly managed US companies have a habit of doing things half-assed. Heck, even well managed ones seem to do things half-assed.

The security wasn't too bad, but the disc drive was still easily hackable (This continues to be a huge failure), so we had an entrypoint for running gamecube homebrew. From that, there was a way to start sniffing for information inside the system.

the unencrypted memory wasn't such a bad decision at all. it probably saved them much money. it was just a really stupid idea to store encryption keys permanently there instead of the internal ram starlet has (x'ffff_????) or just giving the AES engine access to the OTP. Not cleaning MEM2 before switching to GC mode wasn't such a good idea too. :-)

Oh, where to begin ... we probably would never have gotten in if they hadn't been leaving keys lying around all over the place.

Really, the fact that they have a hardware AES engine without embedded key storage (ala iPhone) is inexcusable.