Here Wii Go Again

Intro

I thought it was about time to update this page. Most of this stuff was written in very early March, but I just got around to uploading this page (in June...whoops?). Everything here should be pretty current, except maybe for the libogc/CVS part (stuff is being changed and deprecated constantly). I don't think I have to repeat the fact that Homebrew is up and running in 100% Wii-mode so real WiiDev can now begin. The main hub for Wii homebrew and on-going research is WiiBrew.org so go there for up to date info on WiiDev.

On this page you'll find some of my own (more recent) work with the Wii and a few Wii Homebrew related hints/tips/etc.
Some very important links:

  • WiiBrewThe majority of current Wii homebrew development/research is done here; updates come often but it looks like stuff has slowed down since March/April.
  • devkitProCurently the best and only compiler/lib/etc toolchain for Wii dev on Linux/OS X/Windows. Source and binaries available.
  • devkitPPCThe main Wii dev library (first Wii release is R14, latest update should be out as of June 1st). devkitPPC comes with devkitPro, but current (bleding-edge) versions must be grabbed from CVS (I will show you how at the bottom of this page).
*** UPDATE - 05/24/08 ***:
The official un-official Homebrew Channel has been released. This is the one by some of the members of Team Twiizers (now Homebrew Channel Team) and the only non-Nintendo channel you should even consider installing (in fact this is the only 3rd-party channel I have installed). I had the pleasure of beta-testing this channel since Beta1 and have seen it grow into what it is today: a wonderful (and very useful) piece of software made by a team of amazing individuals. Install it today and enjoy the hard work that was put into this professional channel made with 100% homebrew tools for your homebrew adventures. Thanks to all those whose hard work made this channel possible and for being so generous to the Wii homebrew community.
Here is the link to the HBC page:The Homebrew Channel

Research on News/Weather Channel .bin file formats:

I've been playing around with the News/Weather data files that are sent from Nintendo's servers (actually Akamai) and here's what I've found so far.

The forecast.bin/news.bin.XX (usually news.bin.00 to news.bin.23) files are sent to your Wii when WC24 is enabled if content is updated. The system gets these updates pretty regularly.
The files themselves are structured like this:

1) 0x140 byte "header" which seems to be an RSA signature (according to marcan).
2) Followed by the rest of the data which is LZ77 (LZSS) compressed. I gathered this by looking at the banner.cs file (which seems to be a WC24 [CHANS] script?) in the News channel update archive found in the firmware updates on Nintendo's servers. The banner.cs file had a reference to "CX_COMPRESSION_LZ" so it turned out to be the right compression format. This format is one of 4 compression methods available to developers using the "CX" compression library in the official SDK (confirmed by an official developer).
3) The compressed data consists of some application-specic opcodes followed by Headlines, followed by the ASCII text of the news (or Cities/States in Weather) and finally followed by plain old JPEG images for the news articles.

The news.bin.XX files are "containers" of sorts. All data is packed; headlines, news in ASCII and then JPEG's for each news story.

The raw news.bin.XX files can be grabbed from http://news.wapp.wii.com/v2/1/049/news.bin.00 (or /094/ for EU).

To extract the ASCII/JPEG's, just remove the first 0x140 bytes from the BIN file. Depending on your LZSS/LZ77 decompressor code, you may have to only remove 0x13C bytes if it checks for the "LZ77" file header signature. Now you have your LZ77-compressed container file. Uncompress with your LZ77 tool and you have your raw, uncompressed news.bin.XX file. There are probably markers for start/end of ASCII/JPEG data in the container file, but I haven't bothered to look into that. The top of the file contains summary text for the news articles (headline) which is displayed in "Slideshow" and when you initially enter a news section. Also, these headlines are displayed in the main System Menu on the News/Forecast channel icons (banners). For now (since I'm too lazy to write a tool for this) you can extract the ASCII/JPEG by hand with a hex editor (0xFFD8 is start of a JPEG, 0xFFD9 is end).

Here is what the news.bin.00 file looks like raw from Nintendo's server (first 0x200 bytes):
00000000 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000010 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040 571B 32A4 80FB B057 AC9E 03EF DF18 8391 W.2....W........
00000050 5805 CEFE C457 ABF6 3EE8 F868 01CB C967 X....W..>..h...g
00000060 4359 E8C9 93C3 3642 6A20 CF86 63CE D388 CY....6Bj ..c...
00000070 2A0A 5917 CC98 D681 E0B4 5A71 5697 600C *.Y.......ZqV.`.
00000080 B533 069F 96D5 F4EE E6B9 C69E 5EDC 3CD9 .3..........^.<.
00000090 1462 6948 23F4 59BC 11F2 2339 B418 19D1 .biH#.Y...#9....
000000A0 F8A1 0614 C068 85D6 D32D EF78 B63C 37BA .....h...-.x.<7.
000000B0 D10B 6EF5 6CC1 15AC FC86 5CC6 3E44 4292 ..n.l.....\.>DB.
000000C0 CC96 561F 1BD7 1692 52F7 6835 886D D634 ..V.....R.h5.m.4
000000D0 C98D 40D5 0450 24AC 6CA0 7EAB 7AEF 3CF1 ..@..P$.l.~.z.<.
000000E0 F2BE 4170 1255 2756 0BFC C6E1 85F2 B5B3 ..Ap.U'V........
000000F0 F0E0 AD07 044C 7B29 E05B 67C9 E80E B982 .....L{).[g.....
00000100 896F DB33 1AA2 A9CB 91B8 7FA6 729C 574F .o.3........r.WO
00000110 CAA9 792C B761 9CE6 926E C7AB F28C 4A21 ..y,.a...n....J!
00000120 CE5C 1C9F 74D1 D66F A051 25FF 16EF 6D70 .\..t..o.Q%...mp
00000130 EA8F 9945 4958 57BE 98BD FA79 2F13 13A4 ...EIXW....y/...
00000140 102C 6C00 0000 0002 0000 006C 2C00 2127 .,l........l,.!'
 00000150 DED6 0042 C0C0 0600 42C6 9C5E 0011 100B ...B....B..^....
00000160 0101 0203 0405 06FF FF50 010C 0100 001E .........P......
00000170 101A 0030 0C00 1000 053C 0038 0300 000A ...0.....<.8....
00000180 6C7C 0040 001A 0B10 3500 0F0B 1C8D 400F l|.@....5.....@.
00000190 4C01 E020 2D10 1868 0064 5678 0068 C000 L.. -..h.dVx.h..
000001A0 6C40 002E 103B 44AA 0036 8000 7C66 003E l@...;D..6..|f.>
000001B0 C800 847A B300 8B30 008C 0013 02AC 1094 ...z...0........
000001C0 005E A910 0F72 0066 A030 2704 1400 AC70 .^...r.f.0'....p
000001D0 4C00 0710 7300 1F04 CC00 4908 0041 0045 L...s.....I..A.E
000001E0 0003 2000 638A 0065 6900 6500 4F20 2009 .. .c..ei.e.O .
000001F0 7422 0073 0015 6F00 7500 0920 2000 6120 t".s..o.u.. .a

And here is what it looks like after removing the 0x140 byte header and uncompressing the LZ77'd data (again first 0x200 bytes but with no sig/RSA header):
00000000 D66F 0000 0000 6C2C 2127 DED6 0042 C0C0 .o....l,!'...B..
00000010 0042 C69C 5E00 0000 0042 C0C0 0102 0304 .B..^....B......
00000020 0506 FFFF FFFF FFFF FFFF FFFF 0100 001E ................
00000030 0000 0000 0000 000C 0000 053C 0000 0003 ...........<....
00000040 0000 0A7C 0000 0001 0000 0B00 0000 0003 ...|............
00000050 0000 0B1C 0000 0001 0000 0B4C 01E0 0000 ...........L....
00000060 0000 000B 0000 0068 0000 0078 0000 00C0 .......h...x....
00000070 0000 0040 0000 013C 0000 0044 0000 0180 ...@...<...D....
00000080 0000 0066 0000 01C8 0000 007A D66F 0030 ...f.......z.o.0
00000090 0000 0080 0000 02AC 0000 006C 0000 0330 ...........l...0
000000A0 0000 0072 0000 03A0 0000 0066 0000 0414 ...r.......f....
000000B0 0000 004C 0000 047C 0000 006C 0000 04CC ...L...|...l....
000000C0 0049 0041 0045 0041 0020 0063 0068 0069 .I.A.E.A. .c.h.i
000000D0 0065 0066 0020 0068 0069 0074 0073 0020 .e.f. .h.i.t.s.
000000E0 006F 0075 0074 0020 0061 0074 0020 0055 .o.u.t. .a.t. .U
000000F0 0053 002C 0020 0049 0073 0072 0061 0065 .S.,. .I.s.r.a.e
00000100 006C 0020 006F 0076 0065 0072 0020 0053 .l. .o.v.e.r. .S
00000110 0079 0072 0069 0061 006E 0020 0072 0065 .y.r.i.a.n. .r.e
00000120 0061 0063 0074 006F 0072 0020 0063 006C .a.c.t.o.r. .c.l
00000130 0061 0069 006D 0073 0000 0000 0048 0065 .a.i.m.s.....H.e
00000140 006E 0064 0072 0079 0020 0066 006F 0072 .n.d.r.y. .f.o.r
00000150 0067 0065 0073 0020 0061 0068 0065 0061 .g.e.s. .a.h.e.a
00000160 0064 0020 0061 0067 0061 0069 006E 0073 .d. .a.g.a.i.n.s
00000170 0074 0020 0044 0069 006E 0067 0000 0000 .t. .D.i.n.g....
00000180 0053 0070 0061 0069 006E 0020 0069 0073 .S.p.a.i.n. .i.s
00000190 0073 0075 0065 0073 0020 0073 0075 006E .s.u.e.s. .s.u.n
000001A0 0066 006C 006F 0077 0065 0072 0020 006F .f.l.o.w.e.r. .o
000001B0 0069 006C 0020 0077 0061 0072 006E 0069 .i.l. .w.a.r.n.i
000001C0 006E 0067 0000 0000 0050 006F 006C 0061 .n.g.....P.o.l.a
000001D0 0072 0020 0062 0065 0061 0072 0073 0020 .r. .b.e.a.r.s.
000001E0 0061 0074 0020 0072 0069 0073 006B 002C .a.t. .r.i.s.k.,
000001F0 0020 0062 0075 0074 0020 0074 0068 0072 . .b.u.t. .t.h.r

You can see the plain ASCII news story article summary text separated by 0x00000000 separation markers. The JPEG's are near the bottom of the container file (which you can't see here, too much to paste). There really isn't too much in these files. I've attempted to uncompress/modify/re-compress the data (and fix the "signature" header) and then intercept the Wii's request (to redirect to my version of the news.bin.XX files) but have come up short for now. I guess the header really is a signature of some sorts (RSA?). Bummer.

Datel's SD Media Launcher (latest disc release):

I've found an interesting (funny) string on the latest disc of Datel's SD Media Launcher (you can buy this latest Wii-compatible disc on codejunkies.com; yes it works with FW 3.2) I dumped my purchassed disc into an ISO and here's what I found in the image header:

00000000 4454 4C58 3031 0000 0100 0000 0000 0000 DTLX01..........
00000010 0000 0000 0000 0000 0000 0000 C233 9F3D .............3.=
00000020 4143 5449 4F4E 2052 4550 4C41 5920 2020 ACTION REPLAY
00000030 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040 4454 4C3D 5052 4F44 5543 5420 434F 4445 DTL=PRODUCT CODE
00000050 5820 203D 4D55 4C54 4920 5245 4749 4F4E X =MULTI REGION
00000060 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070 2863 2920 4441 5445 4C20 454C 4543 5452 (c) DATEL ELECTR
00000080 4F4E 4943 5320 3230 3037 2E00 0000 0000 ONICS 2007......
00000090 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000A0 506C 6561 7365 2064 6F20 6E6F 7420 6578 Please do not ex
000000B0 636C 7564 6520 7573 2066 726F 6D20 6675 clude us from fu
000000C0 7475 7265 2072 6576 6973 696F 6E73 206F ture revisions o
000000D0 6620 7468 6520 5769 6920 6669 726D 7761 f the Wii firmwa
000000E0 7265 0000 0000 0000 0000 0000 0000 0000 re..............
000000F0 4966 2079 6F75 2063 6F75 6C64 2072 6569 If you could rei
00000100 6E73 7461 7465 206F 7572 2070 7265 766F nstate our prevo
00000110 6975 7320 7072 6F64 7563 7473 2069 7420 ius products it
00000120 776F 756C 6420 6265 2061 2067 7265 6174 would be a great
00000130 2068 656C 7000 0000 0000 0000 0000 0000 help...........
00000140 4D61 6E79 2074 6861 6E6B 7300 0000 0000 Many thanks.....
00000150 4265 7374 2052 6567 6172 6473 0000 0000 Best Regards....
00000160 416C 6C20 6174 2044 6174 656C 0000 0000 All at Datel....

Funny stuff. Cry me a river, Datel.

WiiShop Fun: Part Deux

So after my original exploration of the WiiShop in 2006, Nintendo released a "patch" (about 10 days after the system launched) to plug that hole (if you don't remember what this is about, go to the bottom of this page to jump to the original page I created back in 2006). I read about the patch and how people could no longer browse the web via the Shop but had not updated my system after the initial system update on Nov 19th 2006, so this did not affect me. The patch turned out to be a fix to require SSL for the critical parts of accessing the WiiShop.
Fast forward about a year and a half and here I was still able to reproduce the "hack" with my "Firmware 2.0U" Wii. The fun really ended after Opera was released. The shop was no longer an interesting attack point. I hadn't really used my Wii and felt there was no need to update (I didn't buy any games at all which in effect would have required me to update my system).
Fast forward to February 28th, 2008... Wii Homebrew history was made: Twilight Hack was released. I was lucky enough to play with the pre-alpha alpha for about a week prior to public release (thanks b...) but officially, the exploit was released on the 28th. In order for me to use the exploit I had to run Zelda. Sad part is I never actually bought Zelda:TP on launch (I'm just not a fan, at all). So I went out and bought Zelda and popped it in. Lo' and behold a "system update" was necessary. I thought "What harm could this do?"... turns out I received a fresh batch of IOS17, an update to my channels....and a fix for the WiiShop hole.
All that time I didn't want to update just to keep at Firmware 2.0U and use the WiiShop hack...wasted. The WiiShop hole was plugged and as I learned from Team Twiizers, there was really no point in staying at an old firmware (actually, old IOS). So on March 21st, 2008 I updated to 3.2U. Tested the WiiShop exploit and, as expected, it was patched. I thought "Oh well, I don't really care anymore because Opera is out."
But then something came over me again and I started snifing Wii packets like the good old days. I set up my gear and went to town on anything that used Wii's network access. Found some nice stuff that I'm still working on :) ...and found out exactly to what extent Nintendo went to "fix" the WiiShop hole. Here are my findings:

  • I used some free software (not my own, why reinvent the wheel?) to do live interception of HTTP traffic by acting as a proxy between the Wii and the internet. This software allows me to intercept, modify, and reinject HTTP traffic. This is how I figured out what the "fix" was.
  • The initial connection to the WiiShop requests an SSL connection to "oss.shop.wii.com", port 443. The client initiates an SSL connection with the server (standard). For the first part of the connection, the client (in this case the Wii) accepts the server certificate and the connection seemingly goes through. You can do the same thing through a plain old web browser. Just accept whatever certificate you're given.
    Now, when you see port 443 you should immediately think "Oh no! SSL! We're done!"...WRONG. Lucky for me, Nintendo practices Security Through Obscurity. What's going on is that oss.shop.wii.com is sending out a self-generated certificate (made by Nintendo) that any SSL-capable browser can accept (after seeing the bad-cert warning). Don't believe me? Pop this URL into your browser: https://oss.shop.wii.com/oss/secure/W_01.jsp (Remember to use Firefox and change your User-Agent string to the WiiShop user-agent: "Opera/9.00 (Nintendo Wii; U; ; 1038-58; Wii Shop Channel/1.0; en)"). Firefox may ask you to accept a certificate. Go ahead and do that. If your User-Agent string is set correctly you should now see the entry page to the WiiShop just as if you were goint through the Wii. Just like back in 2006. But don't get too excited.
  • After the initial connection the WiiShop goes to a "CheckRegistered.jsp" (still on oss.shop.wii.com) page. This request is a POST to the JSP page which sends out the current titleID of the WiiShop and current Version of the WiiShop. The server then checks to see if an update (to the WiiShop) is available, and if one is available you are redirected to a nice page telling you to run a System Update. Then WiiShop downloads the usual .JS files (it does this every time you connect, not stored in NAND). BTW, the ever-useful JavaScript pages found in the original hack are back with a bonus...comments! Thats right, the dev's working on N's WiiShop system provide some very useful comments in the JavaScript/JSP pages. Some very interesting stuff there. Finally, you are redirected to a "CheckBalance.jsp" page on the "oss-auth.wii.shop.com" server at which time your connection fails (if you are intercepting traffic or going through your PC). Notice the "oss-auth" subdomain. This is where the REAL SSL connection comes into play. This is where intercepting the traffic fails as I do not have the client-side SSL cert required to authenticate onto the SSL system. But that doesn't mean the fun stops here.
  • With some clever interception and modification of live HTTP traffic, I was able to shape the WiiShop HTTP traffic to my liking.
  • Again, after the initial WiiShop connection, and after the required JS data is downloaded into memory, the WiiShop requests a secure connection to "oss-auth.shop.wii.com" (actually a longer URL with some POST data; not important). This is where the trouble starts. It seems in this connection request, the client accepts the server's certificate and then the server requests a CLIENT-side certificate which it verifies before letting the connection continue. I guess a "handshake" in SSL terms. The Wii contains the client certificate on the NAND in the system files. We (dasda and I) were able to locate what we believe to be and what looks like a client certificate but it is not in any standard format (PEM/PK12/DER) and we have yet to convert it into an acceptable format for insertion into a browser or the SSL interception tool I use. If you're interested you can find it under 0001000248414241 (HABA, WiiShop channel) -> 00000036 (U8 archive), extract the archive and look in the "opera" directory for "opcacrt6.dat" and/or "opcert6.dat". Accoding to marcan this (or these?) cert (RSA 4096) is in a bunch of other places (all IOS's, BOOT1/BOOT2) so this may not be what we need.
  • Normaly this is where we stop and the fun ends. But we can do some lazy tricks to get through this and play around on "oss.shop.wii.com" without ever reaching "oss-auth.shop.com".
    Now to do some cheap DNS manipulation. I was too lazy to mess around with BIND (and since I was on a Windows XP machine), I added "209.67.106.203 oss-auth.shop.wii.com" to my HOSTS file. The original address for oss-auth is .222. The WiiShop (now proxied through my machine) sends a request to "oss-auth" and expects to reach .222, but is instead sent to "oss" which is .203. One final step was to modify the Location paramenter of the Wii's HTTP request (using my HTTP inerception software) to a page I knew would result in an error page returned by the webserver. This worked like magic. You can also just let it get to InternalError.jsp and re-format the response page as seen in the pix below. The reason I wanted an error page to be returned is so that I can modify the HTTP server's response with my own HTML.
  • So whats the big deal? Well, since I get a nicely formatted error page from the oss.shop.wii.com webserver (a 401 in this case; because it can not understand what we're looking for), I can intercept the RESPONSE that is being sent to the Wii and then modify the HTML in the response HTTP packets to inject my own HTML into it thereby providing a way of generating a simple page that would otherwise not be possible because of the SSL garbage. Here are a few examples of what this means:
    ToDo: Insert pic of 401 error returned
    This is the original "Internal Error" page you see after the spoof/redirection.

    This is the Modified 401 error-page injected with my own HTML (notice the date...)

    Not bad, eh? You may say "Well, whats the point?" The point is I can reproduce the WiiShop "hack" today that I found almost 2 years ago. Also, the WiiShop provides some very interesting information that is not stored on the Wii's NAND and can not be grabbed from the Opera browser (the Shop's JS files don't work in Opera, obviously). The WiiShop has to communicate with Nintendo's ECommerce server to generate this data based on the consoleID/SN. The "fix" on Nintendo's part wasn't good enough, I guess. Also, I just wanted to see if I could do it again (and I can!). What else can be done? Oh...so...much...more... but if I told you, Nintendo might send out yet another patch...
    • Oh, one more thing. I took this info a little further and Just like in 2006, I managed to set up BIND and my Apache server to serve my own pages to the WiiShop. I'm able to automatically serve the HTML you see in the pic without having to manually intercept/modify/reinject HTTP data. All it took was setting up Apache with SSL and generating a bogus server certificate with OpenSSL for our spoofed oss.shop.wii.com server.

    If you're interested, here is the HTML that I currently serve to my WiiShop (note that some of the JS functions don't work; this is because I didn't bother trying to figure them out as they don't seem to hold much interesting data):Right-click, Save-As (this is just plain HTML). If for some reason you're looking for my old (2006) Wii/WiiShop page, you can find it here:Old Wii page.
    Misc Notes / End Result:

    I tried everything I could to get into oss-auth.shop.wii.com. The whole SSL client/server thing pisses me off simply because I'm not very well versed in SSL. I just can't figure out how to properly format the Wii's client certificate that we found on the NAND. It looks like it has the proper cert data, but it doesn't fit into any cert file format I've seen and OpenSSL chokes on it no matter what I try. I just can't figure out what else to do to get into oss-auth. My interception tools have no luck (no valid client cert to validate against oss-auth). The only success I've had is some SSL/ARP-spoofing trickery. This gets me about as far as seeing the Wii's GET/POST requests that it sends to oss-auth (decrypted thanks to ARP-poisoning) but thats as far as I can get (this is very slow and tedious work). I can't seem to see any data returned and I sure as hell can't do anything worthwhile with this sniffed SSL connection. I can see the POST data sent by the Wii (like when entering WiiPoints card numbers) but SSL snifing (at least for me) is like peeking through a small hole in the wall to try to see an entire city. My main goal was to, once again, get access to the SOAP IdentityAuthentication (IAS) and ECommerce servers (ECS). I did it in 2006 when Nintendo didn't properly secure their servers, but it looks like the have their shit locked up tight now. The WiiShop "browser" (also tested on Opera) does't allow XMLHTTP requests (cross-site scripting permission problem), this pretty much kills off my JavaScript raw-HTTP client idea. It works in good-old IE (like a charm I may add), but Opera (like Firefox) has this flaw locked down as well. I had an idea to use PHP for SOAP access but after my initial test using the unsecured NUS (update) server, I realized there would be no way for me to do the SSL client/server certificate handshake with PHP. My request would come from my SERVER and not the WII (duh, didn't think that one over). So, as of right now, it seems hopeless. I guess I don't really need to get into the SOAP servers anymore. But damn it was fun back in 2006. All that access to all that tasty ECommerce data...now gone forever (damn you N!). I just don't have the tools/time to do this alone and no one else seems to care about the WiiShop or the back-end ECommerce goodies. If you know how to properly re-format the SSL cert found on the NAND, let me know. End rant.

    Grabbing/building the latest libogc from CVS:

    *UPDATE*: I've been informed that some people are having problems building the CVS libogc with the latest devkitPro installer (1.4.6) and I'm not sure what exactly happened. Also, Vista seems to have problems compiling...but I don't use Vista so I don't care. So this walk-through may not work for everyone. I don't know what changed/broke in 1.4.6 but I don't care enough to install it to find out as the only thing that really changes feature-wise is libogc. I'm still using dkPro installer v1.4.5 and can grab/build libogc just fine.

    This section isn't so much for complete newbies to programming. It is more of a hint for people who can already code. While the original (stable) release of devkitPPC for Wii (R14) is nice for basic Wii code (and converting some GameCube code over to Wii mode), you will need the absolute bleeding-edge latest libogc to take full advantage of all the new Wii-mode development. The CVS (on the devkitPPC sourceforge link above) is updated almost daily with new features. Some of the more hacky and beta code you see floating around will not work without grabbing the latest CVS snapshot. For those of you working on Linux/OS X, there are plenty guides for working with CVS on those systems. Here I'll guide you through settings up and grabbing CVS snapshots on Windows XP. This guide assumes you installed devkitPro R14 with all the default settings into the default location.

    • 1. Download and install WinCVS from http://www.wincvs.org/ (Note: There are CVS alternatives for Windows like CVSNT so this guide should still be applicable.

    • 2. Fire it up and you should see something like this:

    • 3. Now click on the "Remote" menu and select "Checkout module..." and you'll see something like this:

      Enter "libgoc" for Module name. Then check CVSROOT and enter this: ":pserver:anonymous@devkitpro.cvs.sourceforge.net:/cvsroot/devkitpro" in that box.

    • 4. Click OK. Now WinCVS will connect to the SourceForge CVS repository and grab the latest snapshot of the libogc module. Before downloading, it will create a folder for you called "libogc" under C:\devkitPro\cvs\. This folder will contain the libogc CVS source files that you'll need to compile to bulid the latest libogc. When the download is complete you'll see "***** CVS exited normally with code 0 *****" on the bottom of your WinCVS status window. If you get an error, google around to find out what it means.

    • 5. Open Windows Explorer and move the "cvs" folder from under "C:\devkitPro" to "C:\devkitpro\devkitPPC".

    • 6. Fire up the "msys" environment (should be "C:\devkitPro\msys\msys\msys.bat").

    • 7. In the msys shell ("$") window type in "cd $DEVKITPPC". If you created an alias for "C:\devkitPro\devkitPPC to show" up as "/ppc" then just type "cd /ppc" otherwise The devkitPro installer should have set up the $DEVKITPPC env variable for you. This will move you into the "C:\devkitPro\devkitPPC\" directory. Then type in "cd cvs/libogc"

    • 8. Now type in "make" and press enter. This is the long part. Rebuilding libogc may take anywhere from 15 to 35 minutes depending on the changes and your machine. You'll see a few warnings here and there like "unused variable XXXX" but don't worry about that. As long as you don't see the build stop with an error code, you're OK. When the compilation is done (you will be brought back to the "$" prompt) go to the next step.

    • 9. Now type "make install". This will automatically copy and install the newly built libogc library into your devkitPPC directory.

    • 10. That is it. Now go back to your experimental Wii code that you found and rebuild it as normal. If you saw any compiler errors prior to grabbing the latest CVS snapshot, those errors should (hopefully) be gone now.

    Notes: Make sure you have all the necessary environment variables set up in MSYS:
    1) "c:/devkitPro/devkitPPC /ppc" in C:\devkitPro\msys\msys\etc\fstab
    2) "export PATH=$PATH:/ppc/bin"
    "export DEVKITPPC=/ppc"
    "export DEVKITPRO=/ppc" in C:\devkitPro\msys\msys\etc\profile.
    3)
    A word of warning about messing with CVS libogc. No one will help you. CVS is experimental and changes (and sometimes breaks) all the time. If you can't figure out how to grab and rebuild the CVS libogc, then just don't bother. If you can't get it compiled, you may have a hard time finding someone to help you with it. It is not meant to be used by most people and is not exactly end-user-friendly. You were warned.

    Original Wii Page (2006)

    If you're looking for my original Wii research page (written in 2006) then here it is for historical purposes (may be useful for some people still): Wii Page circa 2006